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

TCP-соединение через IPSec (Linux / Strongswan) останавливается после превышения PMTU

Резервное копирование (через Bacula) одного из моих серверов («A»), подключенных через IPSec (Strongswan при тестировании Debian) к демону хранения («B»), не завершается в 95% случаев, когда они запускаются. По-видимому, происходит следующее:

  1. Bacula открывает TCP-соединение с IP-адресом демона хранилища. (А → Б)
  2. Поскольку настройка ядра net.ipv4.ip_no_pmtu_disc=0 установлен по умолчанию, бит IP Don't Fragment установлен в пакете с открытым текстом.
  3. При маршрутизации пакета в туннель IPSec бит DF полезной нагрузки копируется в IP-заголовок пакета ESP.
  4. Через некоторое время (часто около 20 минут) и до нескольких гигабайт отправленных данных отправляется пакет, немного превышающий размер пакетов ESP до этого. (А → Б)
  5. Поскольку интерфейс демона хранилища имеет меньший MTU, чем у отправляющего хоста, маршрутизатор по пути отправляет хосту ошибку ICMP типа 3, код 4 (требуется фрагментация и не было установлено фрагментация). (какой-то роутер → A)
  6. Соединение прерывается, по какой-то причине хост A рассылает ~ 100 пустых дублированных ACK на B (в течение ~ 20 мс).

(Пакеты ICMP достигают хоста A, и нет правил iptables, блокирующих ICMP.)

Возможные причины, почему это происходит, о которых я могу думать:

Как лучше всего исправить это, не отключая глобальное обнаружение PMTU и не снижая MTU интерфейса? Может быть, очистить бит DF как-нибудь, как это делает FreeBSD с ipsec.dfbit = 0?

Вы можете попробовать создать правило в iptables для установки TCP MSS для трафика, предназначенного для VPN, на более низкое значение. Но без захвата пакетов сложно угадать, что происходит.

Если обнаружение PMTU в сценарии VPN не удается, это обычно проблема с общедоступными IP-адресами шлюзов или маршрутизаторов между ними или с отфильтрованными сообщениями ICMP. Зажим MSS - это всего лишь уродливый обходной путь.