проблемка с впн-ом

[uStick]

Итак.

есть впн-сервер, 10.20.1.99
есть клиент, 10.20.10.20

коннекчусь к серверу:
pptp 10.20.1.99 call pptp debug dump logfd 2 nodetach

в логах pptp вижу:
local IP address 10.30.3.14
remote IP address 10.20.1.99

смотрю route, и вижу там новый маршрут:
10.20.1.99 * 255.255.255.255 UH 0 0 0 ppp0
10.20.1.0 * 255.255.255.0 U 0 0 0 eth0
link-local * 255.255.0.0 U 0 0 0 eth0
loopback * 255.0.0.0 U 0 0 0 lo


при этом проц загружается на 100%, ifconfig показывает сотни метров исходящего трафика для ppp0 до тех пор, пока не удалю этот новый маршрут. тогда всё отлично работает.

спрашивается: нафига pptp создаёт этот маршрут, если я и так вижу 10.20.1.99, и как сказать ему, что этого делать не надо? =)

[ruslandh]

1 В скриптах запуска наверное ошибка
2 А какой путь ошибочный ?

[uStick]

1. это проверял на нескольких дистрах, везде одно и то же. пробовал даже на LFS, без всяких скриптов запуска.
2. 10.20.1.99 * 255.255.255.255 UH 0 0 0 ppp0

нашёл по симптомам свою проблему тут: http://pptpclient.sourceforge.net/howto-diagnosis.phtml#ip_loop
но что-то не понять, чего там пишут. а хотелось бы разобраться с проблемой, а не удалять скриптом каждый раз маршрут.

кстати, помогает ещё ifconfig ppp1 pointopoint 10.30.3.14
тогда маршрут сам исчезает... но по идее там должен быть не local (10.30.3.14), как я указал, а remote (10.20.1.99) адрес.

в общем, запутался ))

[ruslandh]

А эта строчка зачем ?
Мне кажется она не нужна :

10.20.1.0 ... 0 eth0

[must die]

uStick


А если добавить nodefaultroute?

[uStick]

ruslandh: чтобы был доступ в локалку

must die: это ничего не меняет. оно по идее противоположно defaultroute? =) тогда это влияет только на маршрут
default * 0.0.0.0 U 0 0 0 ppp0
тут всё ок.

Хорошо. Сейчас выложу логи коннекта. Буду очень признателен, если кто-нибудь сравнит со своими =)
(особо интересует в логах pptp local IP address, remote IP address и что потом в ifconfig, потому что если меняю руками, то помогает)

Перед коннектом netstat -rn:

Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.20.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo


Лог pptp:
pppd options in effect:
debug # (from command line)
nodetach # (from command line)
logfd 2 # (from command line)
linkname adsl # (from /etc/ppp/peers/pptp)
dump # (from command line)
active-filter xxx # [don't know how to print value] # (from /etc/ppp/filters)
noauth # (from /etc/ppp/peers/pptp)
user юзернэйм # (from /etc/ppp/peers/pptp)
/dev/pts/1 # (from command line)
38400 # (from command line)
lock # (from /etc/ppp/options)
nocrtscts # (from /etc/ppp/peers/pptp)
local # (from /etc/ppp/peers/pptp)
asyncmap 0 # (from /etc/ppp/options)
lcp-echo-failure 4 # (from /etc/ppp/options)
lcp-echo-interval 30 # (from /etc/ppp/options)
lcp-restart 2 # (from /etc/ppp/options)
lcp-max-configure 60 # (from /etc/ppp/options)
noipdefault # (from /etc/ppp/options)
defaultroute # (from /etc/ppp/peers/pptp)
nobsdcomp # (from /etc/ppp/peers/pptp)
nodeflate # (from /etc/ppp/peers/pptp)
noipx # (from /etc/ppp/options)
using channel 4
Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xe082da8d> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <mru 1490> <asyncmap 0x0> <auth chap MS-v2> <magic 0xe2f61161> <pcomp> <accomp>]
sent [LCP ConfAck id=0x1 <mru 1490> <asyncmap 0x0> <auth chap MS-v2> <magic 0xe2f61161> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xe082da8d> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0xe082da8d]
rcvd [LCP EchoReq id=0x0 magic=0xe2f61161]
sent [LCP EchoRep id=0x0 magic=0xe082da8d]
rcvd [CHAP Challenge id=0x22 <c9eb9154204164f2b63ba4a747237743>, name = "serv"]
sent [CHAP Response id=0x22 <2fa751ad516755ebb0bf9a3149d5ec99000000000000000060ad9400f952f20f734a9346c74f1108030698c8e2b92f5d00>, name = "юзернэйм"]
rcvd [LCP EchoRep id=0x0 magic=0xe2f61161]
rcvd [CHAP Success id=0x22 "S=29A3A01BEF014DB9D8BF227455A2158485D1F4EA"]
CHAP authentication succeeded
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]
rcvd [CCP ConfReq id=0x1 <mppe -H -M -S -L -D +C> <deflate 15> <deflate(old#) 15> <bsd v1 15>]
sent [CCP ConfReq id=0x1]
sent [CCP ConfRej id=0x1 <mppe -H -M -S -L -D +C> <deflate 15> <deflate(old#) 15> <bsd v1 15>]
rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 10.20.1.99>]
sent [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr 10.20.1.99>]
rcvd [IPCP ConfNak id=0x1 <addr 10.30.3.14>]
sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 10.30.3.14>]
rcvd [CCP ConfAck id=0x1]
rcvd [CCP ConfReq id=0x2]
sent [CCP ConfAck id=0x2]
rcvd [IPCP ConfAck id=0x2 <compress VJ 0f 01> <addr 10.30.3.14>]
local IP address 10.30.3.14
remote IP address 10.20.1.99
rcvd [CCP ConfReq id=0x2]
sent [CCP ConfReq id=0x2]
sent [CCP ConfAck id=0x2]
sent [CCP ConfReq id=0x2]
# ^ эти 4 строки повторяются несколько десятков раз....
Hangup (SIGHUP)
Connect time 0.8 minutes.
Sent 449398369 bytes, received 1538 bytes.
sent [LCP TermReq id=0x2 "User request"]
Terminating on signal 15
Modem hangup
Connection terminated.


После коннекта ifconfig:
ppp0 Link encap:Point-to-Point Protocol
inet addr:10.30.3.14 P-t-P:10.20.1.99 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1490 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:1227452 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:95 (95.0 b) TX bytes:438403073 (418.0 Mb)

netstat -rn:
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.20.1.99 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
10.20.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0

Тут удаляем маршрут и всё начинает работать:
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.20.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0

Дистр - OpenSuSE 10.2
На время проверки сделал SuSEfirewall2 off, в iptables --list всё чисто.

В принципе, находил в инете подобное, но везде решается скриптами, как и у меня сейчас. Но хочется разобраться...

[uStick]

Нашёл http://pptpclient.sourceforge.net/diagrams.phtml, Figure #3 - как раз мой случай )) только там надо читать вместо ppp0 -> eth0, а вместо ppp1 -> ppp0

То есть, как я понял, суть такова:
GRE-to-PPP пишет свои GRE'шные пакеты в сокет. а дальше они должны идти на сервер 10.20.1.99 через eth0, но у нас прописан маршрут, согласно которому пакеты для 10.20.1.99 надо слать через ppp0....
ну и с callmgr то же самое...

осталось понять, почему это происходит =)
там же, над диаграммой, указаны возможные причины:
* public IP address of the PPTP server matches the remote IP address of the tunnel, (solution, see our Routing HOWTO)
* use of the defaultroute option in the PPTP configuration, or;
* the use of ipchains or iptables rules that filter traffic,

по поводу 1го - жду ваших логов, потому как уже запутался, где public, где remote... )
2 - проверил, без defaultroute то же самое.
3 - как уже писал, всё правила почистил.

PS
я так понимаю, internal server address (тут: http://pptpclient.sourceforge.net/routing.phtml#same-ip) - это адрес, который имеет сервер в сети своего провайдера? (сервер находится в нашей локалке + к сети прова подключен через wifi)