проблемка с впн-ом - Компьютерный форум OSzone.net

Компьютерный форум OSzone.net (http://forum.oszone.net/index.php)

- Общий по Linux (http://forum.oszone.net/forumdisplay.php?f=9)

- - проблемка с впн-ом (http://forum.oszone.net/showthread.php?t=81513)

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

Итак.

есть впн-сервер, 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, и как сказать ему, что этого делать не надо? =)

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

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

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

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

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

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

10.20.1.0 ... 0 eth0

uStick

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

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 всё чисто.

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

Нашёл 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)