Гре-туннель и МТУ

[Fouriki]

Добрый день! нарисовалась неприятность. Есть 2 сервера: juicer и kittyfuck.

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

juicer# uname -a
FreeBSD juicer 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Wed Apr 22 00:21:18 UTC 2009     four@juicer:/usr/src/sys/i386/compile/JUICERIX  i386

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

kittyfuck# uname -a
FreeBSD kittyfuck 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:55:53 UTC 2010     root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386

Juicer подключен к интернету и к локальной сети провайдера через один интерфейс

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

juicer# ifconfig rl1
rl1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=8<VLAN_MTU>
        ether 00:50:22:9f:fb:ff
        inet 92.50.174.10 netmask 0xfffffffc broadcast 92.50.174.11
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active

kittyfuck подключен только к локальной сети данного провайдера

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

kittyfuck# ifconfig xl0
xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=80009<RXCSUM,VLAN_MTU,LINKSTATE>
        ether 00:50:04:52:d4:ce
        inet 10.164.132.29 netmask 0xffffff00 broadcast 10.164.132.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active

между ними проброшен gre-tunnel

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

juicer# ifconfig gre0
gre0: flags=9051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> metric 0 mtu 1400
        tunnel inet 92.50.174.10 --> 10.164.132.29
        inet 192.168.150.2 --> 192.168.150.1 netmask 0xffffff00

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

kittyfuck# ifconfig gre0
gre0: flags=9051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> metric 0 mtu 1400
        tunnel inet 10.164.132.29 --> 92.50.174.10
        inet 192.168.150.1 --> 192.168.150.2 netmask 0xffffff00

и прописаны маршруты в подсети

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

juicer# netstat -rn | grep 192.168.5.0
192.168.5.0/24     192.168.150.1      UGS         0   991279   gre0

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

kittyfuck# netstat -rn | grep 192.168.0
192.168.0.0/16     192.168.150.2      UGS         0      894   gre0

Также дефолт гейт на киттифак указывает на жусер

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

kittyfuck# netstat -rn | grep default
default            gre0               US          0   812617   gre0

К киттифак своим интерфейсом rl0 смотрит в локальную сеть

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

kittyfuck# ifconfig rl0
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=8<VLAN_MTU>
        ether 00:50:22:91:d5:4e
        inet 192.168.5.2 netmask 0xffffff00 broadcast 192.168.5.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active

и имеет на борту mpd4 в виде сервера

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

ng0: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
ng5: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
ng1: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1360
        inet 192.168.10.1 --> 192.168.10.111 netmask 0xffffffff

kittyfuck# ps ax | grep mpd
 8585   0  I+     0:00.21 mpd4 -f mpd.server.conf
kittyfuck# mpd4 -v
Version 4.4.1 (root@freebsd.org 20:18  8-Jun-2010)

Локальный траффик с китти пущен через свой интерфейс с помощью маршрутов и наттинга

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

kittyfuck# ipfw sh
ipfw: DEPRECATED: 'sh' matched 'show' as a sub-string
01000   25003    1258582 nat 1 ip from 192.168.5.0/24 to any via xl0
01100 1706941  589519150 nat 1 ip from any to any in via xl0
65000 6603211 1862652222 allow ip from any to any
65535     396      38458 deny ip from any to any

На джусире такие правила
Восклицательными выделены значимаые правила

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

juicer# ipfw sh
ipfw: DEPRECATED: 'sh' matched 'show' as a sub-string
00010   0     0 allow ip from any to any via lo0
!!! 00050  21  2029 nat 1 ip from 192.168.0.0/16 to not 192.168.0.0/16 via rl1
!!! 00060  77 42105 nat 1 ip from any to any in via rl1
!!! 00100  82  6788 allow ip from 192.168.5.0/24 to any
!!! 00105   0     0 allow ip from 192.168.10.0/24 to any
!!! 00110   0     0 allow ip from 192.168.255.0/25 to any
!!! 00120   0     0 allow ip from 192.168.150.0/24 to any
00500  48  4842 allow ip from any to me
00500  67  6145 allow ip from me to any
00700   0     0 allow ip from 192.168.0.0/24 to 192.168.1.0/24
00700   0     0 allow ip from 192.168.1.0/24 to 192.168.0.0/24
10000  10   400 allow ip from 192.168.0.0/16 to table(1)
15000   0     0 allow ip from 192.168.0.3 to 89.202.0.0/16
15001   0     0 allow ip from 192.168.0.3 to 72.32.7.91
15100   0     0 allow ip from 192.168.0.4 to 94.100.177.1 dst-port 25
15400   0     0 allow ip from 192.168.0.199 to any dst-port 25
15500   0     0 allow ip from 192.168.0.195 to any dst-port 110
15510   0     0 allow ip from 192.168.0.195 to any dst-port 25
15700   0     0 deny ip from any to any dst-port 25
20999   5  1389 allow ip from 192.168.0.150 to not 192.168.0.0/16
21000   4   192 pipe 1 ip from not 192.168.0.0/16 to 192.168.0.150
22000   1    40 allow ip from any to any dst-port 443
25000   5   200 allow ip from 192.168.0.72 to any
25100   0     0 allow ip from 192.168.0.112 to any dst-port 21
25100   0     0 allow ip from 192.168.0.199 to any dst-port 8080
25100   0     0 allow ip from 192.168.0.3 to any
25100   0     0 allow ip from 192.168.0.199 to any
25100   0     0 allow ip from 192.168.0.112 to any
27000   0     0 count ip from 192.168.5.0/24 to not 192.168.0.0/16
27000   0     0 count ip from 192.168.5.0/24 to not 192.168.0.0/16 dst-port 80
30000   0     0 fwd 192.168.0.1,3128 tcp from 192.168.0.0/24 to any dst-port 80
30001   0     0 fwd 192.168.0.1,3128 tcp from 192.168.0.0/24 to any dst-port 8080
40001   0     0 allow ip from 192.168.0.21 to any dst-port 5190
40001   0     0 allow ip from 192.168.0.195 to any dst-port 5190
40001   0     0 allow ip from 192.168.0.21 to any dst-port 443
40001   0     0 allow ip from 192.168.0.195 to any dst-port 443
40001   0     0 allow ip from 192.168.0.13 to any dst-port 5190
40001   0     0 allow ip from 192.168.0.13 to any dst-port 443
50000   0     0 allow ip from table(2) to any
!!! 65000 150 80598 allow ip from any to 192.168.0.0/16
65535   0     0 deny ip from any to any

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

Вот так вкратце выглядит сетка. Задача: раздавать инет клиентам киттифака: локалке и пптп-пирам.
Все бы ничего, но...
Не работает. Точнее работает, но не совсем. Пинги бегают, телнет идет, телнет на 80 порт идет и даже на некорректный запрос отвечает. Вообщем, если смотреть телнетом, то работает, а если смотреть программами - то не работает. Ни почта, ни веб, ни аська. Веб показывает 1% из страниц и то не полностью и не всегда. Почта задыхается на получении списка писем, аська - на получении списка контактов.
Причем с самого роутера (китти) - все работает отлично.
Гуглением и опросом знакомых пришли к выводу, что проблема в MTU. Что где то не пролезает. Поменяв на клиентской машине мту на поменьше проблема частично решилась. Но это костыль и решать надо не так.
Собственно, вопрос. Кто сталкивался и какие есть идеи решения?

Сорри, если много лишней инфы, хотелось не упустить ничего

[Хостинг 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/

[Burner]

какие тут могут быть идеи - начиная с клиента, проверяете каждый проходимый пакетом интерфейс, определяете где конкретно нестандартное mtu. Если у вас на сервере - исправляете, если у провайдера - уменьшаете свой.

[Fouriki]

то есть, уменьшение мту на интерфейсах, которые смотрят в сеть провайдера должно помочь? но ведь через них все бегает нормально. и через туннель даже бегает нормально. проблема, как я ее вижу, (поправьте, если я не прав) в том, что от клиента прилетает слишком жирный фрагмент и он не пролазит в туннель и надо как то скорректировать размер этого пакета. в иптейблз есть --clamp-mss-to-pmtu, но иптейблз не вариант, разумеется

[FreeBSP]

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

pf
scrub all out  reassemble

чтото в этом духе. пинок дан, вперед гугломанить
PS сори, скверное настроение

[Burner]

то есть, уменьшение мту на интерфейсах, которые смотрят в сеть провайдера должно помочь? но ведь через них все бегает нормально. и через туннель даже бегает нормально. проблема, как я ее вижу, (поправьте, если я не прав) в том, что от клиента прилетает слишком жирный фрагмент и он не пролазит в туннель и надо как то скорректировать размер этого пакета. в иптейблз есть --clamp-mss-to-pmtu, но иптейблз не вариант, разумеется

локализуйте проблему!

[Fouriki]

Так проблема локализована и понятна. Локальный комп генерирует пакеты с большим мту, которые не пролазят. Менять на клиентских машинах мту - моветон и вообще костыль. Поэтому надо сделать так, чтобы роутер (китти) отсылал пакеты с нужным мту.

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

pf
scrub all out  reassemble

чтото в этом духе. пинок дан, вперед гугломанить
PS сори, скверное настроение

так у меня ипфв же, не пф.

[FreeBSP]

а про связки ipfw+pf не слышал?
ipfw в такой связке обычно исполняет роль шейпера, а пакеты разруливает pf
причем это не какая то блажь, а реальная зарекомендовавшая себя связка.
у тебя всем будет заниматься ipfw, а pf будет только нормализовывать траффик. кстати с ipsec это может сыграть злую шутку.. его может понадобится отдельно обрабатывать... посмотреть надо
вкрути pf в систему, разрешающий по умолчанию и только со скрабом. Нагрузки пустой рулсет прибавит не сильно, а проблему решит. но посмотри порядок прохождения пакетов через файеры - может понадобится. пропускаемый пакет бедет идти так

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

 net1<-->FW1<-->FW2 <--> KERNEL<--> FW2 <-->FW1<-->net2

кто из файеров pf а кто ipfw - посмотри, это мона в сырцах ядра посмотреть, но проще на практике проверить правилами типа count и log

[Fouriki]

ипсека у меня нет, про связку не слышал, каюсь. спасибо, покопаю в эту сторону

[Burner]

Так проблема локализована и понятна. Локальный комп генерирует пакеты с большим мту, которые не пролазят. Менять на клиентских машинах мту - моветон и вообще костыль. Поэтому надо сделать так, чтобы роутер (китти) отсылал пакеты с нужным мту.

про MTU path discovery слышали когда-нибудь? Если пакеты не проходят, значит оно не работает. Вот и ищите, почему.