1 |
On Mon, 17 Aug 2009 02:37:42 -0700 |
2 |
Keith Dart <keith@×××××××××.biz> wrote: |
3 |
|
4 |
> === On Mon, 08/17, Mike Kazantsev wrote: === |
5 |
> > But then, as usual, pppd messes up the routing table, adding the |
6 |
> > following route: |
7 |
> > |
8 |
> > __pptp_server_ip__ dev ppp0 proto kernel scope link src |
9 |
> > __given_ip__ |
10 |
> |
11 |
> That's not messed up, that's what it's supposed to do. |
12 |
|
13 |
Guess it's just because all the gateways I've connected to lead to the |
14 |
outside world, not the inner network with local IPs, so "inner" and |
15 |
"outer" IPs there are the same (yes, both networks are actually the same |
16 |
"outside world", see below). |
17 |
|
18 |
|
19 |
> > resulting in routing table like this: |
20 |
> > |
21 |
> > __pptp_server_ip__ dev ppp0 proto kernel scope link src |
22 |
> > __given_ip__ 192.168.0.0/28 dev ath0 proto kernel scope link src |
23 |
> > 192.168.0.11 127.0.0.0/8 via 127.0.0.1 dev lo |
24 |
> > default via 192.168.0.10 dev ath0 |
25 |
> |
26 |
> The __pptp_server_ip__ (you don't say what it is) should be the inner, |
27 |
> or tunneled IP address to the server's tunneled interface. |
28 |
> |
29 |
> > ...and ppp0 falls off in two minutes, because of inability to access |
30 |
> > __pptp_server_ip__. |
31 |
> > |
32 |
> > Naturally, all packets to __pptp_server_ip__ should go through |
33 |
> > 192.168.0.10 gateway, so I've always managed to work around this |
34 |
> > problem (with ISPs) by adding a route like this: |
35 |
> |
36 |
> No they shouldn't, because it probably isn't routable. It may be |
37 |
> that your local IP network and the remote tunneled IP network are the |
38 |
> same. That would cause you problems. If your connection is dropping |
39 |
> then it may be that your destination is behind a firewall. It's hard |
40 |
> to tell exactly what is going on with the limited information here. |
41 |
|
42 |
Hm, the "inner" word clears it up, thanks for the tip. |
43 |
|
44 |
Indeed, the networks, routed by local and pptp gateway do overlap, |
45 |
because they both lead to the outside internet (although both are a bit |
46 |
restricted subset of it). |
47 |
So the should-be-inner IP (__pptp_server_ip__) is just identical to |
48 |
the outer one. |
49 |
|
50 |
I wonder if it does matter whether the remote gateway is closed to a |
51 |
__given_ip__ - connection was established from first gw's outer IP |
52 |
anyway, so the route to it is indeed severed: to send a packet to ppp0 |
53 |
gw, I need to use ppp0 and to use ppp0 I need to send that packet to |
54 |
ppp0 gw ;) |
55 |
|
56 |
Okay, I'll try to be more specific, although your guess about networks' |
57 |
layout seem to be correct anyway. |
58 |
Note that the host 87.224.197.1 should be accessible via both gateways. |
59 |
|
60 |
|
61 |
tests (1): |
62 |
|
63 |
# ping -c 1 87.224.197.1 |
64 |
PING 87.224.197.1 (87.224.197.1) 56(84) bytes of data. 64 bytes from |
65 |
87.224.197.1: icmp_seq=1 ttl=57 time=4.67 ms |
66 |
|
67 |
# ping -c 1 93.182.147.2 |
68 |
PING 93.182.147.2 (93.182.147.2) 56(84) bytes of data. 64 bytes from |
69 |
93.182.147.2: icmp_seq=1 ttl=51 time=107 ms |
70 |
|
71 |
"ip ro" before "pon": |
72 |
|
73 |
192.168.0.0/28 dev ath0 proto kernel scope link src 192.168.0.13 |
74 |
127.0.0.0/8 via 127.0.0.1 dev lo |
75 |
default via 192.168.0.10 dev ath0 |
76 |
|
77 |
"pon": |
78 |
|
79 |
... |
80 |
rcvd [IPCP ConfAck id=0x2 <compress VJ 0f 01> <addr 93.182.147.27>] |
81 |
local IP address 93.182.147.27 |
82 |
remote IP address 93.182.147.2 |
83 |
Script /etc/ppp/ip-up started (pid 5048) |
84 |
Script /etc/ppp/ip-up finished (pid 5048), status = 0x0 |
85 |
|
86 |
"ip ro" now: |
87 |
|
88 |
93.182.147.2 dev ppp0 proto kernel scope link src 93.182.147.27 |
89 |
192.168.0.0/28 dev ath0 proto kernel scope link src 192.168.0.13 |
90 |
127.0.0.0/8 via 127.0.0.1 dev lo |
91 |
default via 192.168.0.10 dev ath0 |
92 |
|
93 |
tests (2): |
94 |
|
95 |
# ip ro add 87.224.197.1 dev ppp0 |
96 |
|
97 |
# ping 87.224.197.1 |
98 |
PING 87.224.197.1 (87.224.197.1) 56(84) bytes of data. ^C |
99 |
--- 87.224.197.1 ping statistics --- |
100 |
7 packets transmitted, 0 received, 100% packet loss, time 7000ms |
101 |
|
102 |
# ping 93.182.147.2 |
103 |
PING 93.182.147.2 (93.182.147.2) 56(84) bytes of data. ^C |
104 |
--- 93.182.147.2 ping statistics --- |
105 |
3 packets transmitted, 0 received, 100% packet loss, time 3000ms |
106 |
|
107 |
2 minutes later ("pon" output): |
108 |
|
109 |
Modem hangup |
110 |
Connect time 2.0 minutes. |
111 |
Sent 1847283226 bytes, received 0 bytes. |
112 |
Script /etc/ppp/ip-down started (pid 5169) |
113 |
MPPE disabled |
114 |
sent [LCP TermReq id=0x2 "MPPE disabled"] |
115 |
Connection terminated. |
116 |
Script pptp 93.182.147.2 --nolaunchpppd finished (pid 5042), status = 0x0 |
117 |
Script /etc/ppp/ip-down finished (pid 5169), status = 0x0 |
118 |
|
119 |
ppp0 is destroyed along with it's routes and both pings work again via |
120 |
192.168.0.10 gw, while I wanted to access 87.224.197.1 via the tunnel. |
121 |
|
122 |
If I'll add "ip ro del 93.182.147.2 dev ppp0" quickly enough to "test |
123 |
(2)" block, both pings will work - packets to 93.182.147.2 will be |
124 |
routed via 192.168.0.10 and to 87.224.197.1 via 93.182.147.2. |
125 |
|
126 |
|
127 |
And so the question stays the same: |
128 |
|
129 |
> > So, the question: can I tell pppd/kernel not to add this route |
130 |
> > somehow? I bet there should be some option, but I'm unable to find |
131 |
> > it in man page or google. |
132 |
> > Prehaps I can ban pppd from adding _any_ routes somehow? |
133 |
|
134 |
Not a chance? :( |
135 |
|
136 |
|
137 |
> That's not the problem to solve. The most common problem is setting up |
138 |
> routes to the tunneled destination. You probably need to add some |
139 |
> static routes to the remote networks. You can do this by adding a |
140 |
> shell script to /etc/ppp/ip-up.d directory: |
141 |
|
142 |
Yes, there's that, but it seem to be the easiest part, since I know |
143 |
exactly which hosts should be accessed via tunnel - just a bunch of "ip |
144 |
route" commands to ifup. No problem here. |
145 |
|
146 |
|
147 |
-- |
148 |
Mike Kazantsev // fraggod.net |