Проблема с pptp подключением из Ubuntu к FreeBSD.

Есть и такой ОС.

Модератор: weec

Правила форума
Убедительная просьба юзать теги [cоde] при оформлении листингов.
Сообщения не оформленные должным образом имеют все шансы быть незамеченными.
Ответить
Syn
проходил мимо
Сообщения: 5
Зарегистрирован: 2009-06-14 10:52:41

Проблема с pptp подключением из Ubuntu к FreeBSD.

Непрочитанное сообщение Syn » 2009-06-14 13:41:39

На FreeBSD7.2 поставил poptop

Код: Выделить всё

gw# cat /etc/ppp/ppp.conf
pptp:
 enable proxy
 set timeout 180
 enable MSChapV2
 enable pap chap
 set ifaddr 10.0.1.100 10.0.1.101-10.0.1.120 255.255.255.0

Код: Выделить всё

gw# cat /etc/ppp/ppp.secret
# client        secret       IP addresses
user1            pass1         *
user2            pass2         *

Код: Выделить всё

gw# cat /usr/local/etc/pptpd.conf
debug
noipparam
С винды (XP, Vista) цепляюсь нормально, получаю адрес, вижу машины в сети 10.0.1.0/24,
все замечательно работает.

Код: Выделить всё

F:\>ping 10.0.1.2

Обмен пакетами с 10.0.1.2 по 32 байт:

Ответ от 10.0.1.2: число байт=32 время=29мс TTL=63
Ответ от 10.0.1.2: число байт=32 время=30мс TTL=63
Ответ от 10.0.1.2: число байт=32 время=30мс TTL=63
Ответ от 10.0.1.2: число байт=32 время=33мс TTL=63

Статистика Ping для 10.0.1.2:
    Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
Приблизительное время приема-передачи в мс:
    Минимальное = 29мсек, Максимальное = 33 мсек, Среднее = 30 мсек

Код: Выделить всё

gw# tcpdump -i tun1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun1, link-type NULL (BSD loopback), capture size 96 bytes
16:19:15.276885 IP 10.0.1.116 > 10.0.1.2: ICMP echo request, id 1024, seq 3584, length 40
16:19:15.277038 IP 10.0.1.2 > 10.0.1.116: ICMP echo reply, id 1024, seq 3584, length 40
16:19:16.280128 IP 10.0.1.116 > 10.0.1.2: ICMP echo request, id 1024, seq 3840, length 40
16:19:16.280275 IP 10.0.1.2 > 10.0.1.116: ICMP echo reply, id 1024, seq 3840, length 40
16:19:17.280616 IP 10.0.1.116 > 10.0.1.2: ICMP echo request, id 1024, seq 4096, length 40
16:19:17.280757 IP 10.0.1.2 > 10.0.1.116: ICMP echo reply, id 1024, seq 4096, length 40
16:19:18.283587 IP 10.0.1.116 > 10.0.1.2: ICMP echo request, id 1024, seq 4352, length 40
16:19:18.283726 IP 10.0.1.2 > 10.0.1.116: ICMP echo reply, id 1024, seq 4352, length 40
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel
Пробуем подключиться из Ubuntu, авторизация проходит, но машины в сети
10.0.1.0/24 не видно. Со стороны сервера icmp пакеты от клиента видно,
а также видно что ответы на клиента уходят:

Код: Выделить всё

 ping 10.0.1.2  
PING 10.0.1.2 (10.0.1.2) 56(84) bytes of data.

--- 10.0.1.2 ping statistics ---
14 packets transmitted, 0 received, 100% packet loss, time 13011ms

Код: Выделить всё

gw# tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes
16:21:55.677768 IP 10.0.1.109 > 10.0.1.2: ICMP echo request, id 59435, seq 1, length 64
16:21:55.679613 IP 10.0.1.2 > 10.0.1.109: ICMP echo reply, id 59435, seq 1, length 64
16:21:56.686827 IP 10.0.1.109 > 10.0.1.2: ICMP echo request, id 59435, seq 2, length 64
16:21:56.686979 IP 10.0.1.2 > 10.0.1.109: ICMP echo reply, id 59435, seq 2, length 64
16:21:57.689331 IP 10.0.1.109 > 10.0.1.2: ICMP echo request, id 59435, seq 3, length 64
16:21:57.689500 IP 10.0.1.2 > 10.0.1.109: ICMP echo reply, id 59435, seq 3, length 64
16:21:58.686609 IP 10.0.1.109 > 10.0.1.2: ICMP echo request, id 59435, seq 4, length 64
16:21:58.686766 IP 10.0.1.2 > 10.0.1.109: ICMP echo reply, id 59435, seq 4, length 64
16:21:59.687390 IP 10.0.1.109 > 10.0.1.2: ICMP echo request, id 59435, seq 5, length 64
16:21:59.687546 IP 10.0.1.2 > 10.0.1.109: ICMP echo reply, id 59435, seq 5, length 64
16:22:00.689636 IP 10.0.1.109 > 10.0.1.2: ICMP echo request, id 59435, seq 6, length 64
16:22:00.689793 IP 10.0.1.2 > 10.0.1.109: ICMP echo reply, id 59435, seq 6, length 64
16:22:01.686456 IP 10.0.1.109 > 10.0.1.2: ICMP echo request, id 59435, seq 7, length 64
16:22:01.686616 IP 10.0.1.2 > 10.0.1.109: ICMP echo reply, id 59435, seq 7, length 64
16:22:02.686240 IP 10.0.1.109 > 10.0.1.2: ICMP echo request, id 59435, seq 8, length 64
16:22:02.686400 IP 10.0.1.2 > 10.0.1.109: ICMP echo reply, id 59435, seq 8, length 64
16:22:03.688991 IP 10.0.1.109 > 10.0.1.2: ICMP echo request, id 59435, seq 9, length 64
16:22:03.689160 IP 10.0.1.2 > 10.0.1.109: ICMP echo reply, id 59435, seq 9, length 64
16:22:04.686466 IP 10.0.1.109 > 10.0.1.2: ICMP echo request, id 59435, seq 10, length 64
16:22:04.686625 IP 10.0.1.2 > 10.0.1.109: ICMP echo reply, id 59435, seq 10, length 64
^C
20 packets captured
22 packets received by filter
0 packets dropped by kernel
Пробую пинговать клиента со стороны сервера, видно что пакеты в туннель
уходят, но ответа нет.

Код: Выделить всё

gw# ping 10.0.1.109
PING 10.0.1.109 (10.0.1.109): 56 data bytes
^C
--- 10.0.1.109 ping statistics ---
9 packets transmitted, 0 packets received, 100.0% packet loss

Код: Выделить всё

gw# tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes
16:24:12.349122 IP 10.0.1.100 > 10.0.1.109: ICMP echo request, id 28214, seq 0, length 64
16:24:13.370146 IP 10.0.1.100 > 10.0.1.109: ICMP echo request, id 28214, seq 1, length 64
16:24:14.391341 IP 10.0.1.100 > 10.0.1.109: ICMP echo request, id 28214, seq 2, length 64
16:24:15.412558 IP 10.0.1.100 > 10.0.1.109: ICMP echo request, id 28214, seq 3, length 64
16:24:16.433791 IP 10.0.1.100 > 10.0.1.109: ICMP echo request, id 28214, seq 4, length 64
16:24:17.454947 IP 10.0.1.100 > 10.0.1.109: ICMP echo request, id 28214, seq 5, length 64
16:24:18.476141 IP 10.0.1.100 > 10.0.1.109: ICMP echo request, id 28214, seq 6, length 64
^C
7 packets captured
7 packets received by filter
0 packets dropped by kernel
gw#
Если слушать трафик на клиенте во время пинга, то видно что ответов со стороны сервера нет

Код: Выделить всё

(10:48:52) attid:  tcpdump -i ppp0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
10:48:20.691715 IP 10.0.1.109 > 10.0.1.2: ICMP echo request, id 24104, seq 55, length 64
10:48:21.691776 IP 10.0.1.109 > 10.0.1.2: ICMP echo request, id 24104, seq 56, length 64
10:48:22.691838 IP 10.0.1.109 > 10.0.1.2: ICMP echo request, id 24104, seq 57, length 64
10:48:23.691901 IP 10.0.1.109 > 10.0.1.2: ICMP echo request, id 24104, seq 58, length 64
10:48:24.691961 IP 10.0.1.109 > 10.0.1.2: ICMP echo request, id 24104, seq 59, length 64
10:48:25.692027 IP 10.0.1.109 > 10.0.1.2: ICMP echo request, id 24104, seq 60, length 64
10:48:26.692091 IP 10.0.1.109 > 10.0.1.2: ICMP echo request, id 24104, seq 61, length 64
10:48:27.692159 IP 10.0.1.109 > 10.0.1.2: ICMP echo request, id 24104, seq 62, length 64
Получается, что пакеты либо застревают где-то в туннеле, либо доходят до
Ubuntu, но она их по какой-то причине не воспринимает.
На клиенте таблицы в iptables пустые и по идее резаться не должно.

Вот так выглядит интерфейс на стороне клиента

Код: Выделить всё

(11:26:07) attid:  ifconfig ppp0
ppp0      Link encap:Point-to-Point Protocol  
          inet addr:10.0.1.109  P-t-P:10.0.1.100  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:1729 errors:573 dropped:0 overruns:0 frame:0
          TX packets:1738 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:79899 (78.0 KB)  TX bytes:99169 (96.8 KB)
А вот так поднимается соединение с клиента

Код: Выделить всё

(10:36:13) attid: Using interface ppp0
Connect: ppp0 <--> /dev/pts/2
CHAP authentication succeeded: Welcome!!
CHAP authentication succeeded
Deflate (9/15) compression enabled
Cannot determine ethernet address for proxy ARP
local  IP address 10.0.1.115
remote IP address 10.0.1.100
Очень не нравится строка в логе "Cannot determine ethernet address for proxy
ARP", а также то что счетчики ошибок на прием на ppp0 интерфейсе клиента
не нулевые.

Что делать? Как быть? Очень не хочется менять poptop на что-то другое.

P.S. Чуть позже заметил, что MTU на туннеле с Ubuntu всегда устанавливается
1500, на туннелях с Windows машин значение MTU ниже.

Для Ubuntu в туннеле MTU 1500, а для Windows 1490.

Код: Выделить всё

gw# ifconfig
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        inet 10.0.1.100 --> 10.0.1.108 netmask 0xffffff00
        Opened by PID 80304
tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1490
        inet 10.0.1.100 --> 10.0.1.104 netmask 0xffffff00
        Opened by PID 80310

Код: Выделить всё

gw# grep 80304 /var/log/all.log
Jun 14 18:06:27 gw pptpd[80304]: CTRL (PPPD Launcher): program binary = /usr/sbin/ppp
Jun 14 18:06:27 gw ppp[80304]: Phase: Using interface: tun0
Jun 14 18:06:27 gw ppp[80304]: Phase: deflink: Created in closed state
Jun 14 18:06:27 gw ppp[80304]: Phase: PPP Started (direct mode).
Jun 14 18:06:27 gw ppp[80304]: Phase: bundle: Establish
Jun 14 18:06:27 gw ppp[80304]: Phase: deflink: closed -> opening
Jun 14 18:06:27 gw ppp[80304]: Phase: deflink: Connected!
Jun 14 18:06:27 gw ppp[80304]: Phase: deflink: opening -> carrier
Jun 14 18:06:27 gw ppp[80304]: Phase: deflink: carrier -> lcp
Jun 14 18:06:28 gw ppp[80304]: Phase: bundle: Authenticate
Jun 14 18:06:28 gw ppp[80304]: Phase: deflink: his = none, mine = CHAP 0x05
Jun 14 18:06:28 gw ppp[80304]: Phase: Chap Output: CHALLENGE
Jun 14 18:06:28 gw ppp[80304]: Phase: Chap Input: RESPONSE (16 bytes from attId)
Jun 14 18:06:28 gw ppp[80304]: Phase: Chap Output: SUCCESS
Jun 14 18:06:28 gw ppp[80304]: Phase: deflink: lcp -> open
Jun 14 18:06:28 gw ppp[80304]: Phase: bundle: Network
Jun 14 18:06:29 gw ppp[80304]: Phase: deflink: IPV6CP protocol reject closes IPV6CP !
Jun 14 18:06:29 gw ppp[80304]: Warning: ff02:5::/32: Change route failed: errno: Network is unreachable
Jun 14 18:06:29 gw ppp[80304]: Warning: ff02:5::/32: Change route failed: errno: Network is unreachable
Jun 14 18:06:29 gw ppp[80304]: Phase: deflink: IPV6CP protocol reject closes IPV6CP !
Jun 14 18:06:32 gw ppp[80304]: Phase: deflink: IPV6CP protocol reject closes IPV6CP !
Jun 14 18:06:35 gw ppp[80304]: Phase: deflink: IPV6CP protocol reject closes IPV6CP !
Jun 14 18:06:38 gw ppp[80304]: Phase: deflink: IPV6CP protocol reject closes IPV6CP !
Jun 14 18:06:41 gw ppp[80304]: Phase: deflink: IPV6CP protocol reject closes IPV6CP !

Код: Выделить всё

gw# grep 80310 /var/log/all.log
Jun 14 18:07:19 gw pptpd[80310]: CTRL (PPPD Launcher): program binary = /usr/sbin/ppp
Jun 14 18:07:19 gw ppp[80310]: Phase: Using interface: tun1
Jun 14 18:07:19 gw ppp[80310]: Phase: deflink: Created in closed state
Jun 14 18:07:19 gw ppp[80310]: Phase: PPP Started (direct mode).
Jun 14 18:07:19 gw ppp[80310]: Phase: bundle: Establish
Jun 14 18:07:19 gw ppp[80310]: Phase: deflink: closed -> opening
Jun 14 18:07:19 gw ppp[80310]: Phase: deflink: Connected!
Jun 14 18:07:19 gw ppp[80310]: Phase: deflink: opening -> carrier
Jun 14 18:07:19 gw ppp[80310]: Phase: deflink: carrier -> lcp
Jun 14 18:07:20 gw ppp[80310]: Phase: bundle: Authenticate
Jun 14 18:07:20 gw ppp[80310]: Phase: deflink: his = none, mine = CHAP 0x05
Jun 14 18:07:20 gw ppp[80310]: Phase: Chap Output: CHALLENGE
Jun 14 18:07:20 gw ppp[80310]: Phase: Chap Input: RESPONSE (16 bytes from meas)
Jun 14 18:07:20 gw ppp[80310]: Phase: Chap Output: SUCCESS
Jun 14 18:07:20 gw ppp[80310]: Phase: deflink: lcp -> open
Jun 14 18:07:20 gw ppp[80310]: Phase: bundle: Network
Jun 14 18:07:20 gw ppp[80310]: Phase: deflink: IPV6CP protocol reject closes IPV6CP !
Jun 14 18:07:20 gw ppp[80310]: Phase: deflink: IPV6CP protocol reject closes IPV6CP !
Jun 14 18:07:20 gw ppp[80310]: Warning: ff02:6::/32: Change route failed: errno: Network is unreachable
Jun 14 18:07:23 gw ppp[80310]: Phase: deflink: IPV6CP protocol reject closes IPV6CP !
Jun 14 18:07:26 gw ppp[80310]: Phase: deflink: IPV6CP protocol reject closes IPV6CP !
Jun 14 18:07:29 gw ppp[80310]: Phase: deflink: IPV6CP protocol reject closes IPV6CP !
Jun 14 18:07:32 gw ppp[80310]: Phase: deflink: IPV6CP protocol reject closes IPV6CP !
Пробовал играться значениями mtu/mru в /etc/ppp.conf на обоих сторонах, снижал до 1400,
ничего не изменилось, пакеты не ходят.
Вернуться к началу
Хостинговая компания Host-Food.ru
Хостинг HostFood.ru
 

Услуги хостинговой компании Host-Food.ru

Хостинг HostFood.ru

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/
Вернуться к началу
rainy
мл. сержант
Сообщения: 76
Зарегистрирован: 2008-02-01 23:26:45

Re: Проблема с pptp подключением из Ubuntu к FreeBSD.

Непрочитанное сообщение rainy » 2009-06-15 10:30:47

а покажите ещё таблицу маршрутов после установления туннеля.
Вернуться к началу
Syn
проходил мимо
Сообщения: 5
Зарегистрирован: 2009-06-14 10:52:41

Re: Проблема с pptp подключением из Ubuntu к FreeBSD.

Непрочитанное сообщение Syn » 2009-06-15 15:16:06

rainy писал(а):а покажите ещё таблицу маршрутов после установления туннеля.
На клиенте после поднятия соединения:

Код: Выделить всё

attid@attid-desktop:~$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.1.100      0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
xx.xx.67.204    0.0.0.0         255.255.255.252 U     0      0        0 vlan
10.0.1.0        10.0.1.100      255.255.255.0   UG    0      0        0 ppp0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 lan
0.0.0.0         xx.xx.67.205    0.0.0.0         UG    100    0        0 vlan
На сервере в этот же момент:

Код: Выделить всё

gw# netstat -r
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            yy.yy.166.129      UGS         0   191177    re0
10.0.1.0           link#1             UC          0        0    rl0
10.0.1.2           00:19:21:be:51:97  UHLW        1   109995    rl0   1025
10.0.1.3           00:a0:d2:1b:99:fc  UHLW        1     1058    lo0
10.0.1.4           00:0f:fe:47:50:6b  UHLW        1     3364    rl0   1072
10.0.1.9           00:1d:7d:c3:f4:e8  UHLW        1        3    rl0    176
10.0.1.109         10.0.1.100         UGH         0        2   tun0
10.0.1.109         00:a0:d2:1b:99:fc  UHLS2       1        0    rl0
10.0.1.110         10.0.1.100         UGH         0     4371   tun0
10.0.1.110         00:a0:d2:1b:99:fc  UHLS2       1        0    rl0
yy.yy.166.128/25   link#2             UC          0        0    re0
yy.yy.166.129      00:22:90:6c:b5:20  UHLW        2        0    re0   1191
yy.yy.166.136      00:1a:4d:3d:a8:d0  UHLW        1       21    lo0
localhost          localhost          UH          0      104    lo0
Вернуться к началу
rainy
мл. сержант
Сообщения: 76
Зарегистрирован: 2008-02-01 23:26:45

Re: Проблема с pptp подключением из Ubuntu к FreeBSD.

Непрочитанное сообщение rainy » 2009-06-16 9:21:16

а "netstat -s" смотрели, там тоже много полезной информации.
У меня в аналогичной конфигурации используется MTU 1280
Вернуться к началу
Syn
проходил мимо
Сообщения: 5
Зарегистрирован: 2009-06-14 10:52:41

Re: Проблема с pptp подключением из Ubuntu к FreeBSD.

Непрочитанное сообщение Syn » 2009-06-29 8:11:39

Вылечилось кардинальным образом - сносом poptop и установкой MPD. Совместимость с Ubuntu`ой была достигнута отключением в mpd.conf сжатия и шифрования от Microsoft

Код: Выделить всё

# Включаем компрессию данных, совсестимую с Microsoft-клиентами
#set ccp yes mppc
#set ccp yes mpp-compress

# Включаем шифрование, совместимое с Microsoft-клиентами
#set ccp yes mpp-e40
#set ccp yes mpp-e128
#set ccp yes mpp-stateless
#set bundle yes crypt-reqd
Не смотря на то, что в VPN звонилке на Ubuntu`е заявлена поддержка mppc и mppe при включении данных опций на клиенте и на сервере соединение не устанавливалось.

С соединениями в VPN сервером с виндового клиента проблем не было, как сшифрованием и компрессией, так и без них.
Вернуться к началу