Недавно поставил последнюю stable версию FreeBSD и столкнулся со странной проблемой. При соединении с провайдером по протоколу l2tp, не работают tcp-соединения, инициированные со стороны FreeBSD. Пинги ходят. Причем в тоже время, если активировать pf со включенным nat'ом, то c других машин, подключенных к FreeBSD, все отлично работает!Выглядит это так:
1) Пакеты на ng0 при вызове из FreeBSD команды ftp ftp.yandex.ru:
01:24:15.376780 IP (tos 0x0, ttl 64, id 9182, offset 0, flags [DF], proto TCP (6), length 60)
X.X.X.X.18211 > mirror.yandex.ru.ftp: Flags [S], cksum 0x30ab (correct), seq 1575215393, win 65535, options [mss 1360,nop,wscale 6,sackOK,TS val 51127810 ecr 0], lX.X.X.Xength 0
01:24:15.389104 IP (tos 0x0, ttl 57, id 20534, offset 0, flags [none], proto TCP (6), length 60)
mirror.yandex.ru.ftp > X.X.X.X.18211: Flags [S.], cksum 0x078d (correct), seq 2746157114, ack 1575215394, win 43338, options [mss 1300,sackOK,TS val 496809586 ecr 51127810,nop,wscale 12], length 0
01:24:16.788631 IP (tos 0x0, ttl 57, id 20535, offset 0, flags [none], proto TCP (6), length 60)
mirror.yandex.ru.ftp > X.X.X.X.18211: Flags [S.], cksum 0x062f (correct), seq 2746157114, ack 1575215394, win 43338, options [mss 1300,sackOK,TS val 496809936 ecr 51127810,nop,wscale 12], length 0
01:24:18.425590 IP (tos 0x0, ttl 64, id 9189, offset 0, flags [DF], proto TCP (6), length 60)
X.X.X.X.18211 > mirror.yandex.ru.ftp: Flags [S], cksum 0x24c1 (correct), seq 1575215393, win 65535, options [mss 1360,nop,wscale 6,sackOK,TS val 51130860 ecr 0], length 0
01:24:18.437909 IP (tos 0x0, ttl 57, id 20536, offset 0, flags [none], proto TCP (6), length 60)
mirror.yandex.ru.ftp > X.X.X.X.18211: Flags [S.], cksum 0x0493 (correct), seq 2746157114, ack 1575215394, win 43338, options [mss 1300,sackOK,TS val 496810348 ecr 51127810,nop,wscale 12], length 0
01:24:18.988711 IP (tos 0x0, ttl 57, id 20537, offset 0, flags [none], proto TCP (6), length 60)
mirror.yandex.ru.ftp > X.X.X.X.18211: Flags [S.], cksum 0x0409 (correct), seq 2746157114, ack 1575215394, win 43338, options [mss 1300,sackOK,TS val 496810486 ecr 51127810,nop,wscale 12], length 0
01:24:21.644590 IP (tos 0x0, ttl 64, id 9199, offset 0, flags [DF], proto TCP (6), length 60)
X.X.X.X.18211 > mirror.yandex.ru.ftp: Flags [S], cksum 0x182e (correct), seq 1575215393, win 65535, options [mss 1360,nop,wscale 6,sackOK,TS val 51134079 ecr 0], length 0
01:24:21.656910 IP (tos 0x0, ttl 57, id 20538, offset 0, flags [none], proto TCP (6), length 60)
mirror.yandex.ru.ftp > X.X.X.X.18211: Flags [S.], cksum 0x016e (correct), seq 2746157114, ack 1575215394, win 43338, options [mss 1300,sackOK,TS val 496811153 ecr 51127810,nop,wscale 12], length 0
---> Соединение не устанавливается1) Пакеты на ng0 при выполнении команды ftp ftp.yandex.ru с другого компа локальной сети (через nat на FreeBSD средствами PF):
01:26:16.261639 IP (tos 0x0, ttl 63, id 27695, offset 0, flags [DF], proto TCP (6), length 64)
X.X.X.X.60965 > mirror.yandex.ru.ftp: Flags [S], cksum 0xd148 (correct), seq 3205284718, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 416052165 ecr 0,sackOK,eol], length 0
01:26:16.271587 IP (tos 0x0, ttl 57, id 20539, offset 0, flags [none], proto TCP (6), length 60)
mirror.yandex.ru.ftp > X.X.X.X.60965: Flags [S.], cksum 0x87a2 (correct), seq 3487406062, ack 3205284719, win 43338, options [mss 1300,sackOK,TS val 496839805 ecr 416052165,nop,wscale 12], length 0
01:26:16.272025 IP (tos 0x0, ttl 63, id 29979, offset 0, flags [DF], proto TCP (6), length 52)
X.X.X.X.60965 > mirror.yandex.ru.ftp: Flags [.], cksum 0x1eee (correct), seq 1, ack 1, win 16422, options [nop,nop,TS val 416052175 ecr 496839805], length 0
01:26:16.285674 IP (tos 0x0, ttl 57, id 20540, offset 0, flags [none], proto TCP (6), length 137)
mirror.yandex.ru.ftp > X.X.X.X.60965: Flags [P.], cksum 0x8423 (correct), seq 1:86, ack 1, win 11, options [nop,nop,TS val 496839809 ecr 416052175], length 85
01:26:16.285732 IP (tos 0x0, ttl 57, id 20541, offset 0, flags [none], proto TCP (6), length 58)
mirror.yandex.ru.ftp > X.X.X.X.60965: Flags [P.], cksum 0xef45 (correct), seq 86:92, ack 1, win 11, options [nop,nop,TS val 496839809 ecr 416052175], length 6
01:26:16.286120 IP (tos 0x10, ttl 63, id 11591, offset 0, flags [DF], proto TCP (6), length 52)
X.X.X.X.60965 > mirror.yandex.ru.ftp: Flags [.], cksum 0x1e92 (correct), seq 1, ack 86, win 16411, options [nop,nop,TS val 416052189 ecr 496839809], length 0
---> Все отлично работает!Такое впечатление, что FreeBSD просто "не видит" пакеты [S.], приходящие на ng0. Не подскажете, куда копать?
> Недавно поставил последнюю stable версию FreeBSD и столкнулся со странной проблемой. При
> соединении с провайдером по протоколу l2tp, не работают tcp-соединения, инициированные
> со стороны FreeBSD. Пинги ходят. Причем в тоже время, если активировать
> pf со включенным nat'ом, то c других машин, подключенных к FreeBSD,
> все отлично работает!Смотреть в сторону MTU и MSS
> Смотреть в сторону MTU и MSSСейчас стоит 1400/1400. Пробовал все возможное уже, но не помогает :( Попробую сегодня еще раз, по порядку.
Сводные результаты тестов MTU / MRU
Тестировал изменяя параметры mpd.conf
set link mtu <value>
set link mru <value>
и исполняя команду
ftp ftp.yandex.ru
Результат снимался с интерфейса ng0 командой
tcpdump -vvv -i ng0 host 213.180.204.183
Отчет
MTU/MRU mss-fix? Iface MTU send_mss rec_mss
1400 NO 1400 1360 1300
1400 YES 1400 1360 1360
1300 NO 1300 1260 1300
1300 YES 1300 1260 1260
1460 NO 1456 1416 1410
1460 YES 1456 1416 1410
1500 NO 1456 1416 1410
DEFAULT NO 1456 1416 1410
1380 NO 1380 1340 1410
1380 YES 1380 1340 1340Соединение ни разу не прошло :(
Похоже, UDP тоже не работает:
root: # ntpdate -v 78.129.190.21
20 Feb 15:43:55 ntpdate[4772]: ntpdate 4.2.4p5-a (1)
20 Feb 15:44:00 ntpdate[4772]: no server suitable for synchronization found
Пакеты на ng0:
root: # tcpdump -i ng0 host 78.129.190.21
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ng0, link-type NULL (BSD loopback), capture size 65535 bytes
15:52:38.866559 IP X.X.X.X.ntp > 78.129.190.21.ntp: NTPv4, Client, length 48
15:52:38.926591 IP 78.129.190.21.ntp > X.X.X.X.ntp: NTPv4, Server, length 48
15:52:39.864257 IP X.X.X.X.ntp > 78.129.190.21.ntp: NTPv4, Client, length 48
15:52:39.924283 IP 78.129.190.21.ntp > X.X.X.X.ntp: NTPv4, Server, length 48
15:52:40.872079 IP X.X.X.X.ntp > 78.129.190.21.ntp: NTPv4, Client, length 48
15:52:40.932122 IP 78.129.190.21.ntp > X.X.X.X.ntp: NTPv4, Server, length 48
15:52:41.872067 IP X.X.X.X.ntp > 78.129.190.21.ntp: NTPv4, Client, length 48
15:52:41.932113 IP 78.129.190.21.ntp > X.X.X.X.ntp: NTPv4, Server, length 48Пинги однако ходят как и раньше без проблем, в том числе и c DF:
root: # ping -D -s 1372 78.129.190.21
PING 78.129.190.21 (78.129.190.21): 1372 data bytes
1380 bytes from 78.129.190.21: icmp_seq=0 ttl=56 time=62.339 ms
1380 bytes from 78.129.190.21: icmp_seq=1 ttl=56 time=62.567 ms
1380 bytes from 78.129.190.21: icmp_seq=2 ttl=56 time=62.380 msСоединения через туже сетевуху, но мимо туннеля (например, с ftp провайдера) также отлично работают.
DNS через l2tp туннель тоже не работает:
root: # nslookup google.com 8.8.8.8
;; connection timed out; no servers could be reached
В это время на ng0:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ng0, link-type NULL (BSD loopback), capture size 65535 bytes
17:17:52.575879 IP X.X.X.X.10513 > google-public-dns-a.google.com.domain: 12677+ A? google.com. (28)
17:17:52.606329 IP google-public-dns-a.google.com.domain > X.X.X.X.10513: 12677 15/0/0 A 195.98.65.185, A 195.98.65.157, A 195.98.65.155, A 195.98.65.147, A 195.98.65.181, A 195.98.65.143, A 195.98.65.170, A 195.98.65.151, A 195.98.65.173, A 195.98.65.166, A 195.98.65.162, A 195.98.65.187, A 195.98.65.177, A 195.98.65.158, A 195.98.65.172 (268)
17:17:57.577442 IP X.X.X.X.10513 > google-public-dns-a.google.com.domain: 12677+ A? google.com. (28)
17:17:57.589621 IP google-public-dns-a.google.com.domain > X.X.X.X.10513: 12677 15/0/0 A 195.98.65.185, A 195.98.65.157, A 195.98.65.155, A 195.98.65.147, A 195.98.65.181, A 195.98.65.143, A 195.98.65.170, A 195.98.65.151, A 195.98.65.173, A 195.98.65.166, A 195.98.65.162, A 195.98.65.187, A 195.98.65.177, A 195.98.65.158, A 195.98.65.172 (268)
17:18:02.594181 IP X.X.X.X.10513 > google-public-dns-a.google.com.domain: 12677+ A? google.com. (28)
17:18:02.606505 IP google-public-dns-a.google.com.domain > X.X.X.X.10513: 12677 15/0/0 A 195.98.65.185, A 195.98.65.157, A 195.98.65.155, A 195.98.65.147, A 195.98.65.181, A 195.98.65.143, A 195.98.65.170, A 195.98.65.151, A 195.98.65.173, A 195.98.65.166, A 195.98.65.162, A 195.98.65.187, A 195.98.65.177, A 195.98.65.158, A 195.98.65.172 (268)
Сейчас проверил в обратную сторону, те открыл на FreeBSD tcp порт 45678 с помощью программы nc:nc -l 45678
и попробовал подключиться снаружи телнетом:telnet X.X.X.X 45678
Соединиться не удалось.Пакеты на ng0:
22:38:13.834419 IP (tos 0x0, ttl 53, id 36160, offset 0, flags [DF], proto TCP (6), length 64)
55.gprs.mts.ru.39909 > X.X.X.X.45678: Flags [S], cksum 0x18b5 (correct), seq 3936149955, win 65535, options [mss 1300,nop,wscale 4,nop,nop,TS val 289199718 ecr 0,sackOK,eol], length 0
22:38:14.522044 IP (tos 0x0, ttl 53, id 21391, offset 0, flags [DF], proto TCP (6), length 64)
55.gprs.mts.ru.39909 > X.X.X.X.45678: Flags [S], cksum 0x14c7 (correct), seq 3936149955, win 65535, options [mss 1300,nop,wscale 4,nop,nop,TS val 289200724 ecr 0,sackOK,eol], length 0
22:38:15.242215 IP (tos 0x0, ttl 53, id 50075, offset 0, flags [DF], proto TCP (6), length 64)
55.gprs.mts.ru.39909 > X.X.X.X.45678: Flags [S], cksum 0x10d9 (correct), seq 3936149955, win 65535, options [mss 1300,nop,wscale 4,nop,nop,TS val 289201730 ecr 0,sackOK,eol], length 0
22:38:16.218003 IP (tos 0x0, ttl 53, id 23417, offset 0, flags [DF], proto TCP (6), length 64)
55.gprs.mts.ru.39909 > X.X.X.X.45678: Flags [S], cksum 0x0ced (correct), seq 3936149955, win 65535, options [mss 1300,nop,wscale 4,nop,nop,TS val 289202734 ecr 0,sackOK,eol], length 0
22:38:17.258127 IP (tos 0x0, ttl 53, id 38220, offset 0, flags [DF], proto TCP (6), length 64)Может быть такое, что пакеты не выходят из Netgraph, или еще каким-то образом не доходят до сокета? Самое странное, что система совершенно новая, никакие конфиги я особо не трогал. Из сторонних программ стоят только BIND, DHCPD и MPD.
Провайдер Билайн?На каком участке NAT находится?
> Провайдер Билайн?
> На каком участке NAT находится?Нет, провайдер Freedom, Воронеж. Насчет участка не понял вопрос, что имеется в виду? Мне домой заведен кабель от провайдера. Кабель воткнут в сервер. Таким образом доступна городская сеть. Подключение к интернету осуществляется через L2TP.
>> Провайдер Билайн?
>> На каком участке NAT находится?
> Нет, провайдер Freedom, Воронеж. Насчет участка не понял вопрос, что имеется в
> виду? Мне домой заведен кабель от провайдера. Кабель воткнут в сервер.
> Таким образом доступна городская сеть. Подключение к интернету осуществляется через L2TP.На физическим интерфейсе, который смотрит в сеть ISP, из какой сети выдан IP адрес?
На виртуальном интерфейсе туннеля, который поднят на провайдера, из какой сети выдан IP адрес?
> На физическим интерфейсе, который смотрит в сеть ISP, из какой сети выдан
> IP адрес?
> На виртуальном интерфейсе туннеля, который поднят на провайдера, из какой сети выдан
> IP адрес?
root: # ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000
options=4019b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,VLAN_HWTSO>
ether 2c:27:d7:14:f1:ec
inet 172.17.3.1 netmask 0xffff0000 broadcast 172.17.255.255
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=c019b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>
ether a0:b3:cc:e9:51:76
inet 10.7.13.140 netmask 0xffffffc0 broadcast 10.7.13.191
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33160
ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1400
inet X.X.X.X --> 195.98.64.216 netmask 0xffffffff
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>Интерфейсы:
em0: домашняя локальная сеть
bge0: cеть ISP
ng0: туннель l2tp в интернет, адрес X.X.X.X белыйМаршрутизация до поднятия туннеля:
root: # /usr/home/da # netstat -4rn
Routing tablesInternet:
Destination Gateway Flags Netif Expire
default 10.7.13.129 UGS bge0
10.0.0.0/8 10.7.13.129 UGS bge0
10.7.13.128/26 link#2 U bge0
10.7.13.140 link#2 UHS lo0
127.0.0.1 link#3 UH lo0
172.17.0.0/16 link#1 U em0
172.17.3.1 link#1 UHS lo0
195.98.64.65/32 10.7.13.129 UGS bge0
195.98.64.66/32 10.7.13.129 UGS bge0
195.98.65.128/26 10.7.13.129 UGS bge0Маршруты с поднятым туннелем:
root@home-da:/usr/home/da # netstat -4rn
Routing tablesInternet:
Destination Gateway Flags Netif Expire
default 195.98.64.216 UGS ng0
10.0.0.0/8 10.7.13.129 UGS bge0
10.7.13.128/26 link#2 U bge0
10.7.13.140 link#2 UHS lo0
127.0.0.1 link#3 UH lo0
172.17.0.0/16 link#1 U em0
172.17.3.1 link#1 UHS lo0
192.168.149.0/24 10.7.13.129 UGS bge0
195.98.64.65/32 10.7.13.129 UGS bge0
195.98.64.66/32 10.7.13.129 UGS bge0
195.98.64.216 link#5 UH ng0
195.98.65.128/26 10.7.13.129 UGS bge0
X.X.X.X link#5 UHS lo0Хосты 195.98.64.65 и 195.98.64.66 - это DNS сервера провайдера
В подсети 192.168.149.0/24 лежат l2tp сервера провайдера. Маршрут в эту подсеть я прописываю скриптом после поднятия туннеля, перед изменением default gateway.
Сегодня оставил в /etc/pf.conf только 3 строки:
set debug loud
pass in log (all) all allow-opts
pass out log (all) all allow-opts
При попытке подключиться по ftp к ftp.yandex.ru (213.180.204.183) в консоли появились следующие сообщения:
root: # tail /var/log/messages
Feb 22 20:37:52 fw kernel: pf: BAD state: TCP out wire: 213.180.204.183:21 X.X.X.X:45497 stack: - [lo=1665393824 high=1665438880 win=65535 modulator=0 wscale=6] [lo=2686160170 high=2686225706 win=43338 modulator=0 wscale=12] 4:2 SA seq=2834186493 (2834186493) ack=1665393824 len=0 ackskew=0 pkts=5:5 dir=in,rev
Feb 22 20:37:52 fw kernel: pf: State failure on: 1 | 5
Feb 22 20:37:56 fw kernel: pf: BAD state: TCP out wire: 213.180.204.183:21 X.X.X.X:45497 stack: - [lo=1665393824 high=1665438880 win=65535 modulator=0 wscale=6] [lo=2686160170 high=2686225706 win=43338 modulator=0 wscale=12] 4:2 SA seq=2834186493 (2834186493) ack=1665393824 len=0 ackskew=0 pkts=6:5 dir=in,rev
Feb 22 20:37:56 fw kernel: pf: State failure on: 1 | 5
Feb 22 20:38:02 fw kernel: pf: BAD state: TCP out wire: 213.180.204.183:21 X.X.X.X:45497 stack: - [lo=1665393824 high=1665438880 win=65535 modulator=0 wscale=6] [lo=2686160170 high=2686225706 win=43338 modulator=0 wscale=12] 4:2 SA seq=3031502001 (3031502001) ack=1665393824 len=0 ackskew=0 pkts=7:5 dir=in,rev
Feb 22 20:38:02 fw kernel: pf: State failure on: 1 | 5
Feb 22 20:38:03 fw kernel: pf: BAD state: TCP out wire: 213.180.204.183:21 X.X.X.X:45497 stack: - [lo=1665393824 high=1665438880 win=65535 modulator=0 wscale=6] [lo=2686160170 high=2686225706 win=43338 modulator=0 wscale=12] 4:2 SA seq=3031502001 (3031502001) ack=1665393824 len=0 ackskew=0 pkts=7:5 dir=in,rev
Feb 22 20:38:03 fw kernel: pf: State failure on: 1 | 5
Feb 22 20:38:05 fw kernel: pf: BAD state: TCP out wire: 213.180.204.183:21 X.X.X.X:45497 stack: - [lo=1665393824 high=1665438880 win=65535 modulator=0 wscale=6] [lo=2686160170 high=2686225706 win=43338 modulator=0 wscale=12] 4:2 SA seq=3031502001 (3031502001) ack=1665393824 len=0 ackskew=0 pkts=7:5 dir=in,rev
Feb 22 20:38:05 fw kernel: pf: State failure on: 1 | 5Мб кто-то знает, что это обозначает? Не может ли это быть как-то связано с моей проблемой?
Все, я сдаюсь. Снес все, поставил FreeBSD 10.1 RELEASE с нуля, поставил порт MPD5. Запустил - таже фигня. Больше никаких идей нет, пойду на freebsd.org
> Все, я сдаюсь. Снес все, поставил FreeBSD 10.1 RELEASE с нуля, поставил
> порт MPD5. Запустил - таже фигня. Больше никаких идей нет, пойду
> на freebsd.orgПопробуйте
ifconfig em0 -tso
ifconfig bge0 -tsoВ течении секунд 15 будет перестройка сетевой подсистемы. Потом ifconfig и dump в студию.
>> Все, я сдаюсь. Снес все, поставил FreeBSD 10.1 RELEASE с нуля, поставил
>> порт MPD5. Запустил - таже фигня. Больше никаких идей нет, пойду
>> на freebsd.org
> Попробуйте
> ifconfig em0 -tso
> ifconfig bge0 -tso
> В течении секунд 15 будет перестройка сетевой подсистемы. Потом ifconfig и dump
> в студию.Видимо заработало
>>> Все, я сдаюсь. Снес все, поставил FreeBSD 10.1 RELEASE с нуля, поставил
>>> порт MPD5. Запустил - таже фигня. Больше никаких идей нет, пойду
>>> на freebsd.org
>> Попробуйте
>> ifconfig em0 -tso
>> ifconfig bge0 -tso
>> В течении секунд 15 будет перестройка сетевой подсистемы. Потом ifconfig и dump
>> в студию.
> Видимо заработалоНу на самом деле я еще не успел проверить, тк сейчас в командировке. Как только вернусь, сразу попробую, спасибо за совет!
Примерно такая же фигня и у Билайна на 10 и 11. Бился с этим еще года 3 назад, понять не смог в чем беда.
На фре 9 версии работает все нормально.Кто нибудь победил ? Или хотя бы может жать божественный пинок в нужном направлении ?
Я к сожалению разобраться так и не смог. Пришлось отказаться от mpd :( Очень жаль, тк на нем у меня был еще и VPN сервер поднят. Если найдете причину, напишите обязательно пожалуйста.
> Я к сожалению разобраться так и не смог. Пришлось отказаться от mpd
> :( Очень жаль, тк на нем у меня был еще и
> VPN сервер поднят. Если найдете причину, напишите обязательно пожалуйста.тестирую шлюз на 11.0-RELEASE-p7 amd64 с акутальным на текущий момент в портах mpd5-5.8
в первом приближении выяснилось следующее:
mpd5.8 на l2tp и реализация ipv6 в 10, 11 и пожалуй начиная где-то с 9.2 категорически не дружат. при наличии в ядре ipv6 + sctp mpd ведет себя по разному:
поднимает ng интерфейс и ...
1. практически тут же разрывает соединение
2. соединение разрывается не сразу (может пройти 1,2 ... 5 минут), при этом через ng ничего не пропускается.
3. наблюдается ситуация, описаная автором ветки
4. соединение активно, трафик ходит, но через непредсказуемые интервалы времени mpd просто зависает наглухо (иногда помогает kill -9, а иногда только перезагрузка помогает)
5. дополнительно к наблюдению №4, предположительно если не предпринимать никаких активных действий по завершению чёртика mpd5, отваливается ssh, потом консоль (информация в консоль сыпется, на действия пользователя консоль не отвечает), потом машина уходит в ребут сама по себе. Тут как мне кажется просто чем-то кем-то (возможно mpd5) выжираются ресурсы и наступает кома ).
Но.
Отключил ipv6 в ядре. Ушли пункты 5, 4, 3, 2. Проблема 1 пока имеет место, но если раньше я раз 10 перезапускал mpd чтобы получить еще какие то наблюдения, то теперь №1 выскакивает крайне редко и, опять таки, имхо и скорее всего, по кривой реализации l2tp у билайна.Большой минус всего этого, теперь не получится пользоваться ipnat. Без поддержки ipv6 оно вменяемо работать отказывается.
Наблюдаю дальше, если что появится еще - напишу.
> Большой минус всего этого, теперь не получится пользоваться ipnat. Без поддержки ipv6
> оно вменяемо работать отказывается.Мб. надо что-то дополнительно настроить в IPv6? Спасибо за идею, на выходных пересоберу ядро без options INET6, посмотрю что получится.
>> Большой минус всего этого, теперь не получится пользоваться ipnat. Без поддержки ipv6
>> оно вменяемо работать отказывается.
> Мб. надо что-то дополнительно настроить в IPv6? Спасибо за идею, на выходных
> пересоберу ядро без options INET6, посмотрю что получится.Может быть. Читал где-то что ipv6 даже в 11 до сих пор нестабильна, особенно при частых up/down интерфейсов, и похоже очень особенно на виртуальных. Удивительно, что например, nmap последних версий, "насильно" втюхивает поддержку ipv6 пользователям.
Но, в принципе, ipfw nat справляется аналогично с задачами ipnat. Жаль что статистика у ipfw nat крайне скудная.
> Отключил ipv6 в ядре. Ушли пункты 5, 4, 3, 2.Собрала ядро без IPv6. Пункт 3 (заявленный в стартпосте) не ушел.
> При
> соединении с провайдером по протоколу l2tp, не работают tcp-соединения, инициированные
> со стороны FreeBSD. Пинги ходят.
> Такое впечатление, что FreeBSD просто "не видит" пакеты [S.], приходящие на
> ng0. Не подскажете, куда копать?Столкнулась тоже с этой проблемой. Все точно так же, уходит SYN, возвращается SYN-ACK, но ACK после этого не уходит. UDP запросы уходят, UDP ответы приходят (tcpdump показывает расшифровку DNS-ответов), но до пользовательской программы (host) эти ответы не доходят. Пинги работают.
Если в mpd.conf заменить l2tp на pptp, все работает.
Проблема проявляется только за NAT'ом (настроенном на шлюзе, являющимся defaultroute для моей машины). Если связаться с VPN-сервером напрямую, без NAT, тогда все работает.
NAT пробовался на pf и на ipfw - результат одинаковый.
Система 10.3-RELEASE-p11.А в Вашей конфигурации был ли NAT по дороге к VPN-серверу?
>[оверквотинг удален]
> SYN-ACK, но ACK после этого не уходит. UDP запросы уходят, UDP
> ответы приходят (tcpdump показывает расшифровку DNS-ответов), но до пользовательской
> программы (host) эти ответы не доходят. Пинги работают.
> Если в mpd.conf заменить l2tp на pptp, все работает.
> Проблема проявляется только за NAT'ом (настроенном на шлюзе, являющимся defaultroute для
> моей машины). Если связаться с VPN-сервером напрямую, без NAT, тогда все
> работает.
> NAT пробовался на pf и на ipfw - результат одинаковый.
> Система 10.3-RELEASE-p11.
> А в Вашей конфигурации был ли NAT по дороге к VPN-серверу?На машине был поднят NAT на pf, т.к. она же является роутером для локалки. Однако интерфейс, который смотрел на VPN сервер провайдера, был соединен с ним напрямую (разве что у провайдера NAT какой поднят, но для меня он прозрачен). У вас заработало по PPTP? И как, стабильно работает?
> На машине был поднят NAT на pf, т.к. она же является роутером
> для локалки. Однако интерфейс, который смотрел на VPN сервер провайдера, был
> соединен с ним напрямую (разве что у провайдера NAT какой поднят,
> но для меня он прозрачен).У Вас был белый или серый IP?
По возможности проверю с NAT'ом для локалки.
> У вас заработало по PPTP? И как, стабильно работает?Да, PPTP работает. Вроде стабильно, но надо еще смотреть (вчера первый день полета был).
>У Вас был белый или серый IP?Структура сети такая:
LAN -> FreeBSD pf NAT -> WAN провайдера
На этом этапе IP что-то вроде 192.168.110.25
Далее через mpd5 машина FreeBSD соединялась с VPN сервером провайдера и получала белый статический IP:
LAN -> FreeBSD pf NAT <-- (WAN) --> VPN -> InternetПричем, если с самой машины FreeBSD идти в инет после соединения с VPN, пакеты идут мимо NAT, напрямую на интерфейс ng0. NAT служит для маскарада моего LAN.
> По возможности проверю с NAT'ом для локалки.
Спасибо, было бы интересно.
> Да, PPTP работает. Вроде стабильно, но надо еще смотреть (вчера первый день
> полета был).У меня иногда до 3 дней работал стабильно. А бывало и нескольких секунд не держалось соединение :(
> Структура сети такая:
> LAN -> FreeBSD pf NAT -> WAN провайдера
> На этом этапе IP что-то вроде 192.168.110.25
> Далее через mpd5 машина FreeBSD соединялась с VPN сервером провайдера и получала
> белый статический IP:
> LAN -> FreeBSD pf NAT <-- (WAN) --> VPN -> InternetПогодите. В N10 Вы писали, что адрес на bge0 (интерфейс на провайдера) такой: 10.7.13.140.
А в подсети 192.168.149.0/24 лежат l2tp сервера провайдера.
Значит, где-то там по пути есть NAT.
Или что-то изменилось?
> Погодите. В N10 Вы писали, что адрес на bge0 (интерфейс на провайдера)
> такой: 10.7.13.140.
> А в подсети 192.168.149.0/24 лежат l2tp сервера провайдера.
> Значит, где-то там по пути есть NAT.
> Или что-то изменилось?Прошу прощения, это я не тот ip адрес в предыдущем сообщении скопировал (192.168.110.25). Правильный адрес на bge0, как вы верно заметили, 10.7.13.140. Между 10.7.0.0. и 192.168.149.0/24 вероятно настроена маршрутизация у провайдера. Есть ли у него при этом там NAT или нет, я не могу сказать.
Тут уже советовали отключить tso, как-то осталось без внимания.
Из той же серии: попробуйте сделать ifconfig bge0 -rxcsum
> Тут уже советовали отключить tso, как-то осталось без внимания.
> Из той же серии: попробуйте сделать ifconfig bge0 -rxcsumЕсли помогло, то, скорей всего, дело в баге, который пофиксили уже.