LINUX.ORG.RU
решено Форум — Admin  

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

 


0

1

Добрый день. В локальной сети есть CentOS Linux release 7.4.1708. На нём сайт. Есть удалённый офис, связанный с локальной сетью посредством GREoverIPsec. Проблема: с локальной сети на сайт заходит, с удалённого офиса нет. Понятно что проблема в MTU. Непонятно как её правильно решить. Поставил на интерфейсе веб сервера mtu 1350 и всё заработало. Но мне не нравиться что ради одного удаленного офиса все будут работать с mtu 1350. Какие еще могут быть варианты решения? И я не совсем понимаю почему на linuxe не вступает в работу PMTUD и mtu не настраивается автоматически? Снял tcpdump, роутер отвечает что пакеты требуют фрагментации, но веб-сервер всё равно не пытается отправить пакет с меньшим MTU. Заранее спасибо!

← и снова OpenVPN
iHor.ru сдулся на iowait. Пора менять хостинг? →

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

anonymous
()
Ответ на: комментарий от anonymous

На туннелях стоит 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

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

hudsucker
() автор топика
Ответ на: комментарий от hudsucker

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

[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
это свидетельствует о том что Path MTU Discovery работает?

hudsucker
() автор топика
Ответ на: комментарий от hudsucker

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

hudsucker
() автор топика

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

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

vel ★★★★★
()
Ответ на: комментарий от vel

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

ping 10.77.99.70 -s 1500 -M want
то доходит

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

hudsucker
() автор топика
Ответ на: комментарий от hudsucker

Да, 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 Видно что соединение проходит нормально. Я только не понимаю почему здесь все пакеты дублируются...

hudsucker
() автор топика
Ответ на: комментарий от hudsucker

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

iptables -t mangle -A POSTROUTING -o eth1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss=1200
Смотрю tcpdump, в tcp [syn,ack] сервер клиенту уже сообщает что mss 1200. Но большие пакеты всё равно уходят с mtu 1500 (например, тот же TLS Sever Hello с размером ~2100 в итоге уходит как ~1500 и ~600). Что я делаю не так?

hudsucker
() автор топика
Ответ на: комментарий от hudsucker

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

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

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

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

vel ★★★★★
()
Ответ на: комментарий от vel

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

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

Сервер с MTU 1500 -> роутер с MTU 1500 -> роутер с GREoverIPsec c MTU 1422 -> роутер GREoverIPsec c MTU 1422 -> клиент Windows c MTU 1500.
Клиент к серверу большие пакеты отправляет успешно. Сервер к клиенту нет, пока не установишь поменьше MTU на его интерфейсе.

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

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

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

Та вроде нет.

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

hudsucker
() автор топика
Ответ на: комментарий от hudsucker 
ip ro add xxxx via xxxx mtu 1400 advmss 1340

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

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

или sysctl net.ipv4.ip_no_pmtu_disc=2

vel ★★★★★
()
Ответ на: комментарий от vel

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

net.ipv4.ip_no_pmtu_disc 0 стоит

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

hudsucker
() автор топика
Ответ на: комментарий от vel

Извините за долгий ответ. Дамп с веб-сервера на Винде. Здесь веб-сервер - 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 нет, и так и оставил.

hudsucker
() автор топика
Ответ на: комментарий от hudsucker

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

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

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

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

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

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

vel ★★★★★
()
Ответ на: комментарий от vel

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

На интерфейсе веб-сервера, который на 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 )

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

hudsucker
() автор топика
Ответ на: комментарий от hudsucker

Чёрные дыры это ведь когда на пути пакета на каком то узле, с маленьким 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 один сетевой интерфейс ?

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от vel

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 дней такого не наблюдалось

hudsucker
() автор топика
Ответ на: комментарий от hudsucker

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

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

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

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

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

vel ★★★★★
()
Ответ на: комментарий от vel

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

net.ipv4.conf.all.rp_filter
net.ipv4.conf.eth1.rp_filter
Огромное Вам спасибо за помощь и потраченное время! Теперь осталось понять почему это происходит, я так понимаю с маршрутизацией что то не так. Но уже хоть понятно где собака зарыта :)

hudsucker
() автор топика
Ответ на: комментарий от hudsucker

Вообщем вроде как стало понятно. Большой 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. Сам бы точно не догадался.

hudsucker
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← и снова OpenVPN
Admin
iHor.ru сдулся на iowait. Пора менять хостинг? →