Назад | Перейти на главную страницу

ping не работает с MTU> = 298

Для контекста моя первоначальная проблема заключается в том, что мое ssh-соединение с моими серверами зависает на expecting SSH2_MSG_KEX_ECDH_REPLY когда я подключаюсь к ним через VPN (в данном случае OpenVPN работает в pfsense).

Интернет указывает, что это может быть связано с проблемами MTU.

При попытке отладить это произошло следующее:

ping -s 297 -M do $HOST

работает нормально, но

ping -s 298 -M do $HOST

просто зависает.

MTU установлен на 1500 как на моем компьютере, так и на хосте и интерфейсе pfsense (хотя интерфейс отключен в пользовательском интерфейсе pfsense, я не уверен, что так должно быть).

Почему так происходит? Что-то, блокирующее пакеты, слишком велико? Где я могу найти больше улик?

mtr $HOST указывает на два перехода: к pfsense, затем к самому серверу

У меня была очень похожая проблема дома, когда SSH-соединения зависали (насколько я помню) в том же месте в настройке соединения. Для меня настройка локального параметра MTU помогла несколько уменьшить проблему, но чтобы проблема исчезла, Пришлось включить зондирование TCP MTU. После этого у меня не было подобных проблем. Только позволяя RELATED пакеты через iptables, как описано в Ответ Костикса, не помогло.

Для Linux попробуйте

sudo sysctl net.ipv4.tcp_mtu_probing=1

Возможные значения:

  • 0 = отключено
  • 1 = по умолчанию отключено, включается при обнаружении черной дыры ICMP
  • 2 = всегда включен, использовать исходный MSS tcp_base_mss

Остальные операционные системы будут похожими и разными.

Обратите внимание, что это нужно делать в клиентской системе, а не в брандмауэре (то есть не в поле pfSense) - если, конечно, вы не инициируете свои SSH-соединения из брандмауэра.

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

Для решения этой проблемы (помимо механизма фрагментации IP-адресов) так называемый "Обнаружение MTU пути" механизм существует.

Обратите внимание, что он полагается на протокол ICMP для правильной работы. Помимо прочего, это означает, что если у вас жесткие настройки брандмауэра, у вас должно быть что-то вроде

iptables -t nat -A $CHAIN -m state --state RELATED -j ACCEPT

в ваших правилах для вашего INPUT цепочка (и в FORWARD цепочке, если ваш брандмауэр также выполняет SNAT для своих клиентов).

Состояние "related" означает, что когда получен пакет ICMP типа 3, код 4 (пункт назначения недоступен / требуется фрагментация), подсистема conntrack решает, какое соединение оно относится к а затем передает его дальше в стек netfilter. Состояние такого пакета "СВЯЗАН", как известно iptables¹ поэтому, если у вас есть отказ в передаче таких пакетов - как это часто бывает, когда люди отключают все сразу, а затем пробивают минимальные дыры - обнаружение P-MTU не будет работать должным образом.

Также обратите внимание, что даже если вы «отключите» надлежащую поддержку P-MTU на своих сторонах, она все равно может быть сломана где-то посередине.

Чтобы справиться с этим, существует как минимум две ручки:

  • Крепление MSS к MTU в стеке IP.
  • Ограничение этих вещей на уровне OpenVPN tun-mtu, tun-mtu-extra и mssfix ручки.

Обратите внимание, что эти настройки действительно влияют на производительность, поэтому используйте их в крайнем случае.

¹ Потому что, хотя он и не является частью IP-обмена, он явно связан с ним.