On Mon, 17 Aug 2009 02:37:42 -0700 Keith Dart <ke...@dartworks.biz> wrote:
> === On Mon, 08/17, Mike Kazantsev wrote: ===
> > But then, as usual, pppd messes up the routing table, adding the
> > following route:
> >
> > __pptp_server_ip__ dev ppp0 proto kernel scope link src
> > __given_ip__
>
> That's not messed up, that's what it's supposed to do.
Guess it's just because all the gateways I've connected to lead to the
outside world, not the inner network with local IPs, so "inner" and
"outer" IPs there are the same (yes, both networks are actually the same
"outside world", see below).
> > resulting in routing table like this:
> >
> > __pptp_server_ip__ dev ppp0 proto kernel scope link src
> > __given_ip__ 192.168.0.0/28 dev ath0 proto kernel scope link src
> > 192.168.0.11 127.0.0.0/8 via 127.0.0.1 dev lo
> > default via 192.168.0.10 dev ath0
>
> The __pptp_server_ip__ (you don't say what it is) should be the inner,
> or tunneled IP address to the server's tunneled interface.
>
> > ...and ppp0 falls off in two minutes, because of inability to access
> > __pptp_server_ip__.
> >
> > Naturally, all packets to __pptp_server_ip__ should go through
> > 192.168.0.10 gateway, so I've always managed to work around this
> > problem (with ISPs) by adding a route like this:
>
> No they shouldn't, because it probably isn't routable. It may be
> that your local IP network and the remote tunneled IP network are the
> same. That would cause you problems. If your connection is dropping
> then it may be that your destination is behind a firewall. It's hard
> to tell exactly what is going on with the limited information here.
Hm, the "inner" word clears it up, thanks for the tip.
Indeed, the networks, routed by local and pptp gateway do overlap,
because they both lead to the outside internet (although both are a bit
restricted subset of it).
So the should-be-inner IP (__pptp_server_ip__) is just identical to
the outer one.
I wonder if it does matter whether the remote gateway is closed to a
__given_ip__ - connection was established from first gw's outer IP
anyway, so the route to it is indeed severed: to send a packet to ppp0
gw, I need to use ppp0 and to use ppp0 I need to send that packet to
ppp0 gw ;)
Okay, I'll try to be more specific, although your guess about networks'
layout seem to be correct anyway.
Note that the host 87.224.197.1 should be accessible via both gateways.
tests (1):
# ping -c 1 87.224.197.1
PING 87.224.197.1 (87.224.197.1) 56(84) bytes of data. 64 bytes from
87.224.197.1: icmp_seq=1 ttl=57 time=4.67 ms
# ping -c 1 93.182.147.2
PING 93.182.147.2 (93.182.147.2) 56(84) bytes of data. 64 bytes from
93.182.147.2: icmp_seq=1 ttl=51 time=107 ms
"ip ro" before "pon":
192.168.0.0/28 dev ath0 proto kernel scope link src 192.168.0.13
127.0.0.0/8 via 127.0.0.1 dev lo
default via 192.168.0.10 dev ath0
"pon":
...
rcvd [IPCP ConfAck id=0x2 <compress VJ 0f 01> <addr 93.182.147.27>]
local IP address 93.182.147.27
remote IP address 93.182.147.2
Script /etc/ppp/ip-up started (pid 5048)
Script /etc/ppp/ip-up finished (pid 5048), status = 0x0
"ip ro" now:
93.182.147.2 dev ppp0 proto kernel scope link src 93.182.147.27
192.168.0.0/28 dev ath0 proto kernel scope link src 192.168.0.13
127.0.0.0/8 via 127.0.0.1 dev lo
default via 192.168.0.10 dev ath0
tests (2):
# ip ro add 87.224.197.1 dev ppp0
# ping 87.224.197.1
PING 87.224.197.1 (87.224.197.1) 56(84) bytes of data. ^C
--- 87.224.197.1 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 7000ms
# ping 93.182.147.2
PING 93.182.147.2 (93.182.147.2) 56(84) bytes of data. ^C
--- 93.182.147.2 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 3000ms
2 minutes later ("pon" output):
Modem hangup
Connect time 2.0 minutes.
Sent 1847283226 bytes, received 0 bytes.
Script /etc/ppp/ip-down started (pid 5169)
MPPE disabled
sent [LCP TermReq id=0x2 "MPPE disabled"]
Connection terminated.
Script pptp 93.182.147.2 --nolaunchpppd finished (pid 5042), status = 0x0
Script /etc/ppp/ip-down finished (pid 5169), status = 0x0
ppp0 is destroyed along with it's routes and both pings work again via
192.168.0.10 gw, while I wanted to access 87.224.197.1 via the tunnel.
If I'll add "ip ro del 93.182.147.2 dev ppp0" quickly enough to "test
(2)" block, both pings will work - packets to 93.182.147.2 will be
routed via 192.168.0.10 and to 87.224.197.1 via 93.182.147.2.
And so the question stays the same:
> > So, the question: can I tell pppd/kernel not to add this route
> > somehow? I bet there should be some option, but I'm unable to find
> > it in man page or google.
> > Prehaps I can ban pppd from adding _any_ routes somehow?
Not a chance? :(
> That's not the problem to solve. The most common problem is setting up
> routes to the tunneled destination. You probably need to add some
> static routes to the remote networks. You can do this by adding a
> shell script to /etc/ppp/ip-up.d directory:
Yes, there's that, but it seem to be the easiest part, since I know
exactly which hosts should be accessed via tunnel - just a bunch of "ip
route" commands to ifup. No problem here.
--
Mike Kazantsev // fraggod.net
signature.asc
Description: PGP signature
