fetch001 Опубликовано 19 октября, 2011 · Жалоба Помогите разобратся с проблемой туннеля. Имеются 2 сервера FreeBSD1, FreeBSD2 Настроенны они таким образом: FreeBSD1 vlan2 ip 192.168.10.113/24 локалка vlan4 ip 10.0.28.194/30 провайдер Настройки туннеля: gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 tunnel inet 10.0.28.194 --> 10.0.28.170 inet 192.168.10.113 --> 192.168.14.1 netmask 0xffffffff options=1<ACCEPT_REV_ETHIP_VER> Правила ipfw: # ipfw sh | more ipfw: DEPRECATED: 'sh' matched 'show' as a sub-string 00001 1568 93712 allow ip from any to any via gif0 00100 9549 5434190 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 00400 34173 33074300 allow tcp from me 20,21 to any keep-state 00600 380 16356 deny tcp from any 135,137-139 to any 00700 564793 52470603 deny udp from any 135,137-139 to any 00800 4401150 3586422614 allow ip from 172.16.16.0/24 to 192.168.10.100 00900 2260086 173715574 allow ip from 192.168.10.100 to 172.16.16.0/24 01000 107 13276 allow ip from 172.16.16.0/24 to 192.168.10.103 01000 83 11590 allow ip from 192.168.10.103 to 172.16.16.0/24 10000 85025 4724201 divert 8668 ip from 172.16.16.0/24 to any out via vlan2 10100 36172 9143413 divert 8668 ip from 192.168.10.0/24 to any out via vlan2 10200 172805 7545755 divert 8668 ip from 192.168.11.0/24 to any out via vlan2 10300 396447 483817456 divert 8668 ip from any to 172.16.24.113 in via vlan2 10400 13698 1886743 divert 8668 ip from any to 192.168.10.113 in via vlan2 10500 33984 1361253 allow icmp from any to any icmptypes 0,3,4,8,11 10600 739095 507665509 allow ip from me to any 10700 439696 490862792 allow ip from any to any in recv vlan2 10800 7042 695318 allow tcp from any to me established 10900 0 0 allow ospf from any to me 11000 68 4352 allow ospf from any to 224.0.0.5 11100 0 0 allow ospf from any to 224.0.0.6 11200 0 0 allow ospf from me to any 11300 61 2996 allow tcp from any to me dst-port 22,80,53,1723,3128 setup 11400 0 0 allow gre from any to me setup 11500 34912 3318242 fwd 127.0.0.1,3128 tcp from 192.168.11.0/24 to any dst-port 80 11600 3265 208018 allow udp from any to any dst-port 53 11900 171551 7495224 allow ip from 192.168.11.0/24 to any 12000 349204 463288016 allow ip from any to 192.168.11.0/24 12100 85904 4766726 allow ip from 172.16.16.0/24 to any 12200 29036 4911698 allow ip from any to 172.16.16.0/24 12300 11950 3913962 allow ip from 192.168.10.0/24 to any 12400 35614 16199332 allow ip from any to 192.168.10.0/24 12500 348917 24633634 allow ip from 10.0.28.160/27 to any 12600 0 0 allow ip from any to 10.0.28.160/27 12650 3094 148512 allow ip from 192.168.14.0/24 to any 12650 0 0 allow ip from any to 192.168.14.0/24 65535 396 84389 deny ip from any to any Если я допустил ошибку в правилах, буду очень благодарен за исправку. # netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 172.16.24.1 UGS 608 261835 vlan2 10.0.15.0/24 10.0.28.193 UG1 0 0 vlan4 10.0.28.160/27 10.0.28.193 UG1 0 421333 vlan4 10.0.28.192/30 link#10 U 0 30 vlan4 10.0.28.194 link#10 UHS 0 186 lo0 127.0.0.1 link#6 UH 0 1434 lo0 172.16.0.0/24 link#9 U 0 6707 vlan3 172.16.0.1 link#9 UHS 0 0 lo0 172.16.16.0/24 link#11 U 1 1162067 vlan5 172.16.16.1 link#11 UHS 0 0 lo0 172.16.24.0/24 link#8 U 13 12554 vlan2 172.16.24.113 link#8 UHS 0 0 lo0 172.18.18.0/24 link#3 U 0 0 xl0 172.18.18.1 link#3 UHS 0 0 lo0 192.168.10.0/24 link#8 U 1 2589004 vlan2 192.168.10.113 link#7 UHS 1 3357 lo0 192.168.14.0/24 192.168.14.1 UGS 0 112 gif0 192.168.14.1 link#7 UH 0 790 gif0 ======================================================================================= FreeBSD2 rl0 ip 192.168.14.1/24 локалка rl1 ip 10.0.28.170/27 провайдер настройки туннеля: gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 tunnel inet 10.0.28.170 --> 10.0.28.194 inet 192.168.14.1 --> 192.168.10.113 netmask 0xffffff00 options=1<ACCEPT_REV_ETHIP_VER> Правила ipfw: # ipfw sh|more ipfw: DEPRECATED: 'sh' matched 'show' as a sub-string 00001 2584 199072 allow ip from any to any via gif0 65000 14555 3110317 allow ip from any to any 65535 0 0 deny ip from any to any # netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.10.113 UGS 0 2943 gif0 10.0.28.160/27 link#2 U 0 0 re1 10.0.28.170 link#2 UHS 0 0 lo0 10.0.28.194 10.0.28.161 UGHS 0 4267 re1 127.0.0.1 link#6 UH 0 136 lo0 192.168.10.0/24 192.168.10.113 UGS 0 0 gif0 192.168.10.113 link#7 UH 0 1327 gif0 192.168.14.0/24 link#3 U 0 306 re2 192.168.14.1 link#3 UHS 1 0 lo0 Временами связь с FreeBSD1 на FreeBSD2 пропадает, даже подвисает ssh но PING стабильно проходит. Сразу после подвисания ssh, начинаю коннектится опять по этой схеме FreeBSD1 > ssh > FreeBSD2 все нормально. Минут через 3-5 опять ситуация повторяется. Клиенты со стороны FreeBSD2 жалуются на то что на FTP сервер (на стороне FreeBSD1) при загрузке файлов останавливается на 10-20%. Кусочек логов tcpdump с сервера FreeBSD1 именно в тот момент когда подвисает ssh и все остальные службы: # tcpdump -i gif0 -n tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on gif0, link-type NULL (BSD loopback), capture size 96 bytes 17:35:00.364239 IP 192.168.14.1.22 > 192.168.10.113.16901: Flags [.], ack 64, win 8326, options [nop,nop,TS val 2253429692 ecr 89255782], length 0 17:35:00.687251 IP 192.168.14.7.3384 > 192.168.0.20.3402: Flags [s], seq 219138927, win 65535, options [mss 1460,nop,nop,sackOK], length 0 17:35:02.318831 IP 192.168.14.10.2693 > 192.168.0.20.3402: Flags [s], seq 2070203026, win 65535, options [mss 1460,nop,nop,sackOK], length 0 17:35:03.642198 IP 192.168.14.7.3384 > 192.168.0.20.3402: Flags [s], seq 219138927, win 65535, options [mss 1460,nop,nop,sackOK], length 0 17:35:05.282035 IP 192.168.10.113.16901 > 192.168.14.1.22: Flags [P.], ack 1, win 8326, options [nop,nop,TS val 89260679 ecr 2253367905,nop,nop,sack 1 {49:1105}], length 48 17:35:05.359738 IP 192.168.14.1.22 > 192.168.10.113.16901: Flags [P.], ack 112, win 8326, options [nop,nop,TS val 2253434727 ecr 89260679], length 48 17:35:05.359758 IP 192.168.10.113.16901 > 192.168.14.1.22: Flags [.], ack 1, win 8326, options [nop,nop,TS val 89260754 ecr 2253367905,nop,nop,sack 1 {49:1153}], length 0 17:35:05.371363 IP 192.168.14.1.22 > 192.168.10.113.16901: Flags [P.], ack 112, win 8326, options [nop,nop,TS val 2253434728 ecr 89260679], length 48 17:35:05.371377 IP 192.168.10.113.16901 > 192.168.14.1.22: Flags [.], ack 1, win 8326, options [nop,nop,TS val 89260765 ecr 2253367905,nop,nop,sack 1 {49:1201}], length 0 17:35:05.377967 IP 192.168.14.1.22 > 192.168.10.113.16901: Flags [P.], ack 112, win 8326, options [nop,nop,TS val 2253434728 ecr 89260679], length 48 17:35:05.377980 IP 192.168.10.113.16901 > 192.168.14.1.22: Flags [.], ack 1, win 8326, options [nop,nop,TS val 89260771 ecr 2253367905,nop,nop,sack 1 {49:1249}], length 0 17:35:05.384620 IP 192.168.14.1.22 > 192.168.10.113.16901: Flags [P.], ack 112, win 8326, options [nop,nop,TS val 2253434728 ecr 89260679], length 48 17:35:05.384633 IP 192.168.10.113.16901 > 192.168.14.1.22: Flags [.], ack 1, win 8326, options [nop,nop,TS val 89260778 ecr 2253367905,nop,nop,sack 1 {49:1297}], length 0 17:35:05.391272 IP 192.168.14.1.22 > 192.168.10.113.16901: Flags [P.], ack 112, win 8326, options [nop,nop,TS val 2253434728 ecr 89260679], length 48 17:35:05.391285 IP 192.168.10.113.16901 > 192.168.14.1.22: Flags [.], ack 1, win 8326, options [nop,nop,TS val 89260784 ecr 2253367905,nop,nop,sack 1 {49:1345}], length 0 Никак не пойму что происходит, уважаемые форумчане кто сталкивался с такой траблой пожалуйста поделитесь информацией. Как быть где копать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 19 октября, 2011 (изменено) · Жалоба покажите MTU на vlan2 и vlan4 Имхо, понижайте MTU на gif0 до 1460 и ниже. Изменено 19 октября, 2011 пользователем vlad11 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fetch001 Опубликовано 19 октября, 2011 · Жалоба покажите MTU на vlan2 и vlan4 Имхо, понижайте MTU на gif0 до 1460 и ниже. # ifconfig vlan4 vlan4: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 00:01:02:fa:c2:9c inet 10.0.28.194 netmask 0xfffffffc broadcast 10.0.28.195 media: Ethernet autoselect (100baseTX <full-duplex>) status: active vlan: 4 parent interface: xl0 # ifconfig vlan2 vlan2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 00:01:02:fa:c2:9c inet 172.16.24.113 netmask 0xffffff00 broadcast 172.16.24.255 inet 192.168.10.113 netmask 0xffffff00 broadcast 192.168.10.255 media: Ethernet autoselect (100baseTX <full-duplex>) status: active vlan: 2 parent interface: xl0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fetch001 Опубликовано 19 октября, 2011 · Жалоба покажите MTU на vlan2 и vlan4 Имхо, понижайте MTU на gif0 до 1460 и ниже. Сменил MTU проблема не исчезла: логи tcpdump^ 18:35:17.534612 IP 192.168.10.113.30076 > 192.168.14.1.ssh: Flags [P.], ack 1, win 8272, options [nop,nop,TS val 92727911 ecr 2848036599,nop,nop,sack 1 {49:1553}], length 48 18:35:17.605998 IP 192.168.14.1.ssh > 192.168.10.113.30076: Flags [P.], ack 240, win 8272, options [nop,nop,TS val 2848085361 ecr 92727911], length 48 18:35:17.606021 IP 192.168.10.113.30076 > 192.168.14.1.ssh: Flags [.], ack 1, win 8272, options [nop,nop,TS val 92727979 ecr 2848036599,nop,nop,sack 1 {49:1601}], length 0 18:35:18.419620 IP 192.168.10.113.30076 > 192.168.14.1.ssh: Flags [P.], ack 1, win 8272, options [nop,nop,TS val 92728760 ecr 2848036599,nop,nop,sack 1 {49:1601}], length 48 18:35:18.492299 IP 192.168.14.1.ssh > 192.168.10.113.30076: Flags [P.], ack 288, win 8272, options [nop,nop,TS val 2848086254 ecr 92728760], length 48 18:35:18.492323 IP 192.168.10.113.30076 > 192.168.14.1.ssh: Flags [.], ack 1, win 8272, options [nop,nop,TS val 92728830 ecr 2848036599,nop,nop,sack 2 {1649:1697}{49:1601}], length 0 18:35:18.498892 IP 192.168.14.1.ssh > 192.168.10.113.30076: Flags [P.], ack 288, win 8272, options [nop,nop,TS val 2848086254 ecr 92728760], length 48 18:35:18.498906 IP 192.168.10.113.30076 > 192.168.14.1.ssh: Flags [.], ack 1, win 8272, options [nop,nop,TS val 92728836 ecr 2848036599,nop,nop,sack 2 {1649:1745}{49:1601}], length 0 18:35:19.564209 IP 192.168.10.113.30076 > 192.168.14.1.ssh: Flags [P.], ack 1, win 8272, options [nop,nop,TS val 92729858 ecr 2848036599,nop,nop,sack 2 {1649:1745}{49:1601}], length 48 18:35:19.638435 IP 192.168.14.1.ssh > 192.168.10.113.30076: Flags [P.], ack 336, win 8272, options [nop,nop,TS val 2848087408 ecr 92729858], length 48 18:35:19.638457 IP 192.168.10.113.30076 > 192.168.14.1.ssh: Flags [.], ack 1, win 8272, options [nop,nop,TS val 92729930 ecr 2848036599,nop,nop,sack 2 {1649:1793}{49:1601}], length 0 18:35:19.648337 IP 192.168.14.1.ssh > 192.168.10.113.30076: Flags [P.], ack 336, win 8272, options [nop,nop,TS val 2848087408 ecr 92729858], length 48 18:35:19.648352 IP 192.168.10.113.30076 > 192.168.14.1.ssh: Flags [.], ack 1, win 8272, options [nop,nop,TS val 92729939 ecr 2848036599,nop,nop,sack 2 {1649:1841}{49:1601}], length 0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 19 октября, 2011 · Жалоба Менять надо с помощью pf, см. нотацию "scrub". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 19 октября, 2011 · Жалоба покажите MTU на vlan2 и vlan4 Имхо, понижайте MTU на gif0 до 1460 и ниже. Сменил MTU проблема не исчезла: Упорно не вижу в tcpdump'e новых данных о MTU Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fetch001 Опубликовано 19 октября, 2011 (изменено) · Жалоба покажите MTU на vlan2 и vlan4 Имхо, понижайте MTU на gif0 до 1460 и ниже. Сменил MTU проблема не исчезла: Упорно не вижу в tcpdump'e новых данных о MTU gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280 tunnel inet 10.0.28.194 --> 10.0.28.170 inet 192.168.10.113 --> 192.168.14.1 netmask 0xffffff00 options=1<ACCEPT_REV_ETHIP_VER> gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280 tunnel inet 10.0.28.170 --> 10.0.28.194 inet 192.168.14.1 --> 192.168.10.113 netmask 0xffffff00 options=1<ACCEPT_REV_ETHIP_VER> Если подразумевалось снизить mtu набрал команду ifconfig gif0 mtu 1460 Результат тот-же: 21:37:16.635427 IP 192.168.14.1.22 > 192.168.10.113.65531: Flags [.], ack 17296, win 8289, options [nop,nop,TS val 562597805 ecr 103 199933,nop,nop,sack 1 {17344:17920}], length 0 21:37:16.701190 IP 192.168.10.113.65531 > 192.168.14.1.22: Flags [P.], ack 26753, win 8289, options [nop,nop,TS val 103208618 ecr 56 2597805], length 48 21:37:16.769711 IP 192.168.14.1.22 > 192.168.10.113.65531: Flags [.], ack 17296, win 8289, options [nop,nop,TS val 562597946 ecr 103 199933,nop,nop,sack 1 {17344:17968}], length 0 21:37:17.010323 IP 192.168.10.113.65531 > 192.168.14.1.22: Flags [P.], ack 26753, win 8289, options [nop,nop,TS val 103208914 ecr 56 2597946], length 48 21:37:17.085822 IP 192.168.14.1.22 > 192.168.10.113.65531: Flags [.], ack 17296, win 8289, options [nop,nop,TS val 562598259 ecr 103 199933,nop,nop,sack 1 {17344:18016}], length 0 21:37:17.239656 IP 192.168.10.113.65531 > 192.168.14.1.22: Flags [P.], ack 26753, win 8289, options [nop,nop,TS val 103209134 ecr 56 2598259], length 48 21:37:17.311279 IP 192.168.14.1.22 > 192.168.10.113.65531: Flags [.], ack 17296, win 8289, options [nop,nop,TS val 562598487 ecr 103 199933,nop,nop,sack 1 {17344:18064}], length 0 21:37:17.389902 IP 192.168.10.113.65531 > 192.168.14.1.22: Flags [P.], ack 26753, win 8289, options [nop,nop,TS val 103209279 ecr 56 2598487], length 48 21:37:17.461813 IP 192.168.14.1.22 > 192.168.10.113.65531: Flags [.], ack 17296, win 8289, options [nop,nop,TS val 562598645 ecr 103 199933,nop,nop,sack 1 {17344:18112}], length 0 21:37:17.580265 IP 192.168.10.113.65531 > 192.168.14.1.22: Flags [P.], ack 26753, win 8289, options [nop,nop,TS val 103209461 ecr 56 2598645], length 48 21:37:17.654233 IP 192.168.14.1.22 > 192.168.10.113.65531: Flags [.], ack 17296, win 8289, options [nop,nop,TS val 562598834 ecr 103 199933,nop,nop,sack 1 {17344:18160}], length 0 Изменено 19 октября, 2011 пользователем fetch001 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 19 октября, 2011 · Жалоба Компьютер(MTU 1500)<-->router|IPSec(MTU 1460)<-->router|IPSec(MTU 1460)<-->Сервер(MTU 1500) Компьютер обращается к серверу, MTU 1500 с обоих сторон. Откуда сервер узнает, что по дороге есть туннель, с меньшим MTU? Написал же, scrub в pf - валидный вариант. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 19 октября, 2011 · Жалоба Нужны такие пакеты: 17:35:00.687251 IP 192.168.14.7.3384 > 192.168.0.20.3402: Flags [s], seq 219138927, win 65535, options [mss 1460,nop,nop,sackOK], length 0 Откуда сервер узнает, что по дороге есть туннель, с меньшим MTU? Написал же, scrub в pf - валидный вариант. роутеры в прямой видимости. На линии нет никакого оборудования типа конвертеров оптика/медь? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fetch001 Опубликовано 20 октября, 2011 · Жалоба Нужны такие пакеты: 17:35:00.687251 IP 192.168.14.7.3384 > 192.168.0.20.3402: Flags [s], seq 219138927, win 65535, options [mss 1460,nop,nop,sackOK], length 0 Откуда сервер узнает, что по дороге есть туннель, с меньшим MTU? Написал же, scrub в pf - валидный вариант. роутеры в прямой видимости. На линии нет никакого оборудования типа конвертеров оптика/медь? Оборудования только ADSL модем Huawei SmartAX MT880. Схема подключения: FreeBSD1 <провайдер>--VPN(routing)--<провайдер> FreeBSD2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 20 октября, 2011 · Жалоба Понижайте mtu на обоих линках, пока не заработает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 20 октября, 2011 · Жалоба gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280 /etc/pf.conf scrub on gif0 all max-mss 1280 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 24 октября, 2011 · Жалоба Вообще-то тогда уж scrub on gif0 all max-mss 1240. MSS = MTU - 40 bytes. А вообще на вопрос "Откуда сервер узнает, что по дороге есть туннель, с меньшим MTU?" давно придуман ответ в виде path MTU discovery. И даже целых два варианта :) Ну это так, к слову. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 24 октября, 2011 · Жалоба А вообще на вопрос "Откуда сервер узнает, что по дороге есть туннель, с меньшим MTU?" давно придуман ответ в виде path MTU discovery. И даже целых два варианта :) Открой для себя rfc2923 "TCP Problems with Path MTU Discovery". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 25 октября, 2011 (изменено) · Жалоба Краткое прочтение RFC 2000 года показало некоторое устаревание проблем, изложенных в нём. Вернее, принятие во внимание путей их решения, предложенных в нём же - особенно это касается TCP: открой для себя RFC 4821. "Packetization Layer Path MTU Discovery". Изменено 25 октября, 2011 пользователем Dyr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 25 октября, 2011 · Жалоба IPSec занимает промежуточное положение между IP уровнем и уровнем пакетирования и как выражаются авторы RFC 4821 "может быть отнесена" либо туда, либо туда. Однако сама идеология IPSec, "шифровать, но не изменять содержимое" делает отсылку каких либо сообщений внутри шифруемого пакета делом безнадёжным, а отсылка сообщения публичными узлами, являющимися сторонами туннеля во первых - не всегда возможна, а во вторых - бессмысленна, т.к. с точки зрения "клиент-сервер", этих узлов просто нет. Всё это сильно затрудняет PMTU в системах, содержащих туннель на базе IPSec и "scrub" в pf является наиболее приемлемым вариантом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 25 октября, 2011 · Жалоба Краткое прочтение RFC 2000 года показало некоторое устаревание проблем, изложенных в нём. Они не только не устарели, но стали более актуальны, т.к. в свежих фикспаках для Windows брандмауэр, похоже, блокирует работу собственного pmtud. Единственное решение проблемы - mssfix на шлюзе при входе в IP-туннель. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 25 октября, 2011 · Жалоба Они не только не устарели, но стали более актуальны, т.к. в свежих фикспаках для Windows брандмауэр, похоже, блокирует работу собственного pmtud. Эм...ссылко? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 25 октября, 2011 · Жалоба Эм...ссылко? helpdesk.sertolovo.ru Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 25 октября, 2011 · Жалоба P.S. Я бы предложил использовать не scrub из pf, а ядерную ноду ng_tcpmss: http://www.unix.com/man-page/FreeBSD/4/ng_tcpmss/ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 25 октября, 2011 · Жалоба helpdesk.sertolovo.ru Смешно, да. Я там как-то не присутствую. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...