FreeBSD, pf, change MSS

[mr.Scamp 41]

Подскажите эффективный способ подстраивать TCP MSS в проходящем трафике для FreeBSD,

для Linux и iptables это выглядит вот так -j TCPMSS --clamp-mss-to-pmtu.

Пробовал pf, scrub on gre0 fragment reassemble max-mss 1436, но к сожалению, не помогло, возможно, потому что все правила ниже без keep state.

[natiss 16]

Подскажите эффективный способ подстраивать TCP MSS в проходящем трафике для FreeBSD,

для Linux и iptables это выглядит вот так -j TCPMSS --clamp-mss-to-pmtu.

Пробовал pf, scrub on gre0 fragment reassemble max-mss 1436, но к сожалению, не помогло, возможно, потому что все правила ниже без keep state.

Опять это в Linux, отвыкайте уже

 

tcpmssd was written by Ruslan Ermilov <ru@FreeBSD.org> based on work

done by Patrick Bihan-Faou <patrick@mindstep.com>.

 

tcpmssd is a divert(4) program that adjusts outgoing TCP data so that

the requested segment size is not greater than the amount allowed by

the interface MTU.

 

This is necessary in many setups to avoid problems caused by routers

that drop ICMP Datagram Too Big messages. Without these messages,

the originating machine sends data, it passes the rogue router then

hits a machine that has an MTU that is not big enough for the data.

Because the IP Don't Fragment option is set, this machine sends an

ICMP Datagram Too Big message back to the originator and drops the

packet. The rogue router drops the ICMP message and the originator

never gets to discover that it must reduce the fragment size or drop

the IP Don't Fragment option from its outgoing data.

 

cd /usr/ports/net/tcpmssd && make install clean

[mr.Scamp 41]

ой, а можно как-нибудь без divert?

[natiss 16]

ой, а можно как-нибудь без divert?

Можно, если осторожно.

http://www.gsp.com/cgi-bin/man.cgi?section=4&topic=ng_tcpmss

диверт в нетграф

[mr.Scamp 41]

А как же pf? Почему он не работает для меня?

На форумах есть success stories об этой конфигурации.

 

Хм, ng_tcpmss это интереснее, насколько я знаю, оно используется mpd.

Может, не дивертить в него, а вставить его после/перед ng_gre?

[natiss 16]

А как же pf? Почему он не работает для меня?

На форумах есть success stories об этой конфигурации.

 

Хм, ng_tcpmss это интереснее, насколько я знаю, используется mpd.

Может, не дивертить в него, а вставить его после/перед ng_gre?

Я pf изменять mss не пробовал. Ничего не скажу.

А ng_tcpmss - те же, простите, яйца, что и tcpmssd, только в профиль. Используется не надройка nas - mpd, а ядро - netgraph.

ipfw add 101 divert 8899 ip from any to any via igb1

или

ipfw add 101 netgraph 101 ip from any to any via igb1

загрузка будет такая же.

Минус первого варианта - если не будет запущен tcpmsssd, в ipfw и далее в сеть ничего не вернется.

Минус второго - если есть еще правила ipfw, надо выключать one_pass - необоснованно увеличите нагрузку на сервер. Ну и немножко дебильный (с) синтаксис нод.

Какой объем трафика обрабатываете?

Да, и кстати, зачем менять его? vlan-ы?

[mr.Scamp 41]

Менять, потому что gre-туннель, нагрузка планируется до мегабит 100, может больше.

Divert-a не хочу, потому что опасаюсь увеличения нагрузки на сервер и снижения надежности,

[natiss 16]

Т.е. изменять mss хотите, а загружать процессор нет? Самый "легкий" путь pf, остальные грузят сильнее. Разбирайтесь с ним в таком случае. Но учтите, что в связке pf+ipfw могут быть сюрпрайзы.

[mr.Scamp 41]

pf не работает,

ng_tcpmss похоже тоже, хотя трафик в ноду бежит

16:32:13.275214 IP 193.106.144.36.4372 > 193.0.6.139.80: S 2105092612:2105092612(0) win 65535 <mss 1436,nop,nop,sackOK>
16:32:13.322461 IP 193.0.6.139.80 > 193.106.144.36.4372: S 2148163758:2148163758(0) ack 2105092613 win 5840 <mss 1460,nop,nop,sackOK>
16:32:13.322721 IP 193.106.144.36.4372 > 193.0.6.139.80: . ack 1 win 65535
16:32:13.323908 IP 193.106.144.36.4372 > 193.0.6.139.80: P 1:429(428) ack 1 win 65535

[natiss 16]

Пробуйте tcpmssd - оно точно работает.

[mr.Scamp 41]

Но на рядом стоящем NAS-e с mpd работает же!

16:56:57.708614 IP 193.106.145.190.1874 > 193.0.6.139.80: S 2035330837:2035330837(0) win 16384 <mss 1354,nop,nop,sackOK>
16:56:57.756776 IP 193.0.6.139.80 > 193.106.145.190.1874: S 3724095564:3724095564(0) ack 2035330838 win 5840 <mss 1436,nop,nop,sackOK>

Что я делаю не так?

 

Алсо вспомнил, почему не нравиться DIVERT - его нет в моем ядре.

[natiss 16]

Но на рядом стоящем NAS-e с mpd работает же!

16:56:57.708614 IP 193.106.145.190.1874 > 193.0.6.139.80: S 2035330837:2035330837(0) win 16384 <mss 1354,nop,nop,sackOK>
16:56:57.756776 IP 193.0.6.139.80 > 193.106.145.190.1874: S 3724095564:3724095564(0) ack 2035330838 win 5840 <mss 1436,nop,nop,sackOK>

Что я делаю не так?

 

Алсо вспомнил, почему не нравиться DIVERT - его нет в моем ядре.

Так вы скажите что вы вообще делаете. Откуда ж я знаю, что не так

[mr.Scamp 41]

Уточню.

Есть тазик, с несколькими езернетами, на нем терминируется gre-туннель.

Часть клиентов приходит по езеру, часть по pptp с NAS-а на соседнем тазике.

Есть pf, без nat, во всех правилах pass no state.

Те, кто включены по езеру с MTU 1500, не могут попасть на некоторые сайты, которые видны через этот gre-туннель. Специфика этих хостов такова, что во всех пакетах от них стоит флаг DF.

[natiss 16]

А так

 

в pf.conf :

scrub in on $ext_if all fragment reassemble no-df min-ttl 20 max-mss 1440

Где $ext_if - интерфейс, который смотрит в интернет.

 

?

[mr.Scamp 41]

natiss, посмотрите внимательнее первый пост, пожалуйста

%sudo pfctl -vvsr | head
@0 scrub on gre0 proto tcp all no-df max-mss 1436 fragment reassemble
 [ Evaluations: 8443501   Packets: 657112    Bytes: 103976377   States: 0     ]

not works for me

[natiss 16]

В первом посте было просто scrub on gre0 fragment reassemble max-mss 1436

А попробуйте для интереса tcpmssd, если не сложно пересобрать ядро

[mr.Scamp 41]

Опытным путем установил, что максимальный MSS для этого линка равен 1396.

Как pf scrub, так и ng-нода работают отлично.

Всем спасибо за советы.