Проблема с MTU на CentOS 7

Зачем изменять mtu на интерфейсе у сайта? MTU нужно менять на туннели gre. А для iptables смотри -j TCPMSS --clamp-mss-to-pmtu и -j TCPMSS –set-mss XXXX

На туннелях стоит MTU 1400, если поставлю автосогласование, то будет чуть больше. Если я правильно понимаю, если поставить 1500, то будут проблемы, ведь еще добавятся заголовки ipsec и gre и кадр станет слишком большой для Интернета. Или я не прав?

Что-то я совсем с этими MTU уже запутался... Ситуация сейчас такая:

[root@srv-m29-cld-01 ~]# ping 10.77.99.70 -s 1500
PING 10.77.99.70 (10.77.99.70) 1500(1528) bytes of data.
1508 bytes from 10.77.99.70: icmp_seq=1 ttl=125 time=4.53 ms
1508 bytes from 10.77.99.70: icmp_seq=2 ttl=125 time=4.74 ms
1508 bytes from 10.77.99.70: icmp_seq=3 ttl=125 time=4.82 ms
1508 bytes from 10.77.99.70: icmp_seq=4 ttl=125 time=4.27 ms


[root@srv-m29-cld-01 ~]# ping 10.77.99.70 -s 1500 -M want
PING 10.77.99.70 (10.77.99.70) 1500(1528) bytes of data.
1508 bytes from 10.77.99.70: icmp_seq=1 ttl=125 time=4.04 ms
1508 bytes from 10.77.99.70: icmp_seq=2 ttl=125 time=4.32 ms
1508 bytes from 10.77.99.70: icmp_seq=3 ttl=125 time=4.12 ms

[root@srv-m29-cld-01 ~]# ping 10.77.99.70 -s 1500 -M do
PING 10.77.99.70 (10.77.99.70) 1500(1528) bytes of data.
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500

То есть пинги большими пакетами идут, а сайт всё равно не открывается

Вообще, если вот это проходит:

[root@srv-m29-cld-01 ~]# ping 10.77.99.70 -s 1500 -M want
PING 10.77.99.70 (10.77.99.70) 1500(1528) bytes of data.
1508 bytes from 10.77.99.70: icmp_seq=1 ttl=125 time=4.04 ms
1508 bytes from 10.77.99.70: icmp_seq=2 ttl=125 time=4.32 ms
1508 bytes from 10.77.99.70: icmp_seq=3 ttl=125 time=4.12 ms

и еще... в этой же локальной сети есть веб сервера на винде. Они открываются нормально. А CentOSом какие то непонятки

Снял tcpdump, роутер отвечает что пакеты требуют фрагментации, но веб-сервер всё равно не пытается отправить пакет с меньшим MTU

А до сервера эта icmp дошла? Нефиг фильтровать все icmp.

Ну именно эта не дошла, так как у нее стоит флаг df. Доходит до туннеля, где mtu 1400 и отбрасывается. Если пинговать так:

ping 10.77.99.70 -s 1500 -M want 

Не фильтруем ничего Повторюсь, в этой же локальной сети, где веб-сервер на линуксе, стоит веб-сервер на виндовсе. Последний работает нормально. Я никак не могу въехать в чём разница. Наверное, если были бы проблемы с туннелем или заблочены icmp, не работали бы оба.

Хм, а на линкусе этот icmp(3,4) виден?

Завтра сниму еще раз дамп, посмотрю. Сегодня, к сожалению, уже нет возможности

Да, icmp(3,4) приходит. Вот так это выглядит, когда на интерфейсе установлен MTU 1500 (здесь адрес веб сервера 192.168.0.116, адрес клиента 10.77.99.70): https://ibb.co/SNQfCQL Видно что приходит icmp(3,4) и говорит какой pmtu для канала.

А вот так выглядит соединение когда на интерфейсе установлен MTU 1350 (сайт открывается нормально): https://ibb.co/px5z6Sj Видно что соединение проходит нормально. Я только не понимаю почему здесь все пакеты дублируются...

Установил уже на сервере:

iptables -t mangle -A POSTROUTING -o eth1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss=1200 

А вот так выглядит соединение когда на интерфейсе установлен MTU 1350

Надеюсь, что с обоих сторон mtu одинаковый...

В линкусе можно задавать mtu и mss для маршрута.

Нет ли где ассиметрии при маршрутизации или icmp-редиректов ?

Надеюсь, что с обоих сторон mtu одинаковый...

По обоими сторонами вы имеет ввиду клиента и сервер? На клиенте всегда 1500, на сервере при 1500 не работает, при 1350 работает. То есть когда не работает то одинаковые, когда не работает, то разные...Но я не сильно понимаю, какую роль это играет? Они ведь не объязательно должны быть одинаковые? Вообще схема с MTU такая:

Сервер с MTU 1500 -> роутер с MTU 1500 -> роутер с GREoverIPsec c MTU 1422 -> роутер GREoverIPsec c MTU 1422 -> клиент Windows c MTU 1500.

В линкусе можно задавать mtu и mss для маршрута

Как это сделать не подскажите? MSS меня в iptables. Всё равно шлёт 1500 (см. сообщение выше)

Нет ли где ассиметрии при маршрутизации или icmp-редиректов ?

Та вроде нет.

Вообще меня сильно смущает, что CentOS не реагирует никак на полученные icmp3:4. Я думаю проблема скорее всего здесь, а не в сети.

ip ro add xxxx via xxxx mtu 1400 advmss 1340

Вообще меня сильно смущает, что CentOS не реагирует никак на полученные icmp3:4. Я думаю проблема скорее всего здесь, а не в сети.

a iptables на CentOS пустой ?

или sysctl net.ipv4.ip_no_pmtu_disc=2

iptables не пустой, но там правила по умолчанию плюс несколько открытых портов. И я стопал его, результата не дало.

net.ipv4.ip_no_pmtu_disc 0 стоит

Попробую сегодня еще с рабочего веб-сервера на Видне сделать tcpdump, посмотрю как там трафик бегает и в чём отличие CentOS'a.

Есть чего интересного?

Извините за долгий ответ. Дамп с веб-сервера на Винде. Здесь веб-сервер - 192.168.0.50, клиент - 10.77.99.70. https://ibb.co/GFb7bZZ

Здесь PMTUD срабатывает нормально. Сервер отправляет большой TLSv2 Server Hello, от роутера приходит icmp3:4, сервер разбивает большой pdu на два с размерами 1436 и 655. Дальше вся инфа отправляется с размером 1436, как и должно быть.

Почему у меня CentOS так не делает я так и не понял. Поэтому уменьшил mtu на интерфейсе до 1372, померял iperf'ом что разницы в скоростях при 1372 и 1500 нет, и так и оставил.

Поэтому уменьшил mtu на интерфейсе до 1372, померял iperf'ом что разницы в скоростях при 1372 и 1500 нет, и так и оставил

На каком интерфейсе ?

Смена mtu должна быть выполнена у всех участников ip-сети.

Я уже встречал черные дыры с MTU, где с разных сторон были разные MTU.

Есть одна странная идея - а что за сетевая карта на CentOS ?

Я бы попробовал на ней отключить TSO ( ethtool -K ethX tso off )

На каком интерфейсе?

На интерфейсе веб-сервера, который на CentOS'e. Я так понимаю, что другие участники сети согласовывают размер MSS во время установки tcp сессии c веб-сервером. Так что если на веб-сервере mtu пониже, то и другие участники сети будут использовать mtu пониже. Или я не прав?

Я уже встречал черные дыры с MTU, где с разных сторон были разные MTU.

Чёрные дыры это ведь когда на пути пакета на каком то узле, с маленьким mtu, заблочен icmp3:4. В моем случае icmp3:4 приходит.

Есть одна странная идея - а что за сетевая карта на CentOS ?

А вот это хороший вопрос :) CentOS это виртуальная машина на Hyper-V, а в Hyper-V вставлена Intel(R) Ethernet Server Adapter I350-T4 #4.

Я бы попробовал на ней отключить TSO ( ethtool -K ethX tso off )

Отключал, не помогло

Чёрные дыры это ведь когда на пути пакета на каком то узле, с маленьким mtu, заблочен icmp3:4. В моем случае icmp3:4 приходит.

Есть второй вариант: любой хост в сети молча отбрасывает пакеты больше чем MTU. Это когда в одной ip-сети машины с разными mtu.

Если ты поменял MTU интерфейса только на одном хосте в ip-сети, то ты ССЗБ.

Я правильно понимаю общюю схему сети?

CentOS(guest) <-> Hyper-V <-> local network mtu 1500 <-> router <-> (ipGRE mtu < 1500) <-> router <-> local network mtu 1500 <-> client

CentOS получает от роутера icmp(3,4), но ни как не реагирует на него?

На CentOS один сетевой интерфейс ?

CentOS(guest) <-> Hyper-V <-> local network mtu 1500 <-> router <-> (ipGRE mtu < 1500) <-> router <-> local network mtu 1500 <-> client

Да, всё верно

CentOS получает от роутера icmp(3,4), но ни как не реагирует на него?

Ага

На CentOS один сетевой интерфейс ?

Два, один с белым IP в интернет, один с серым ip в LAN.

Есть второй вариант: любой хост в сети молча отбрасывает пакеты больше чем MTU. Это когда в одной ip-сети машины с разными mtu.

Та я постарею пока на всех хостах поменяю MTU :) Если какой-то хост внутри сети будет выеживаться, тогда на нём и поменяю mtu. Пока за 7 дней такого не наблюдалось

Два, один с белым IP в интернет, один с серым ip в LAN.

Если tcpdump видит пакет, а реакции на него нет, значит его дропнули.

В системах с несколькими сетевыми интерфейсам есть замечательные грабли по имени rp_filter

посмотри настройки sysctl net.ipv4.conf | grep '\.rp_filter'

Нужно выключить его ( см. linux/Documentation/networking/ip-sysctl.txt).

Да, вы правы! :) Работает, если отключить

net.ipv4.conf.all.rp_filter
net.ipv4.conf.eth1.rp_filter

Вообщем вроде как стало понятно. Большой PDU отправлялся с адреса 192.168.0.116 на роутер 192.168.0.78, оттуда он отправлялся на роутер 10.254.254.1, на котором узкий vpn туннель. Соответственно, icmp3:4 приходил с адреса 10.254.254.1, о котором в таблице маршрутизации CentOSa информации нет, и шлюз по умолчанию на другом интерфейсе. Соответственно срабатывал Reverse Path Filtering и этот icmp3:4 дропался. Добавил статический маршрут для сети 10.254.254.0 через интерфейс eth1 и все стало на свои места. Спасибо, vel. Сам бы точно не догадался.