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


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

  1. Bacula открывает TCP-соединение с VPN-интерфейсом демона хранилища. (A → B)
  2. Поскольку настройка ядра net.ipv4.ip_no_pmtu_disc=0 устанавливается по умолчанию, бит IP Do not Fragment установлен в пакет открытого текста.
  3. При маршрутизации пакета в туннель IPSec бит DF полезной нагрузки копируется в заголовок IP пакета ESP.
  4. Через некоторое время (часто около 20 минут) и до нескольких гигабайт отправленных данных отправляется пакет, немного превышающий пакеты ESP. (A → B)
  5. Поскольку интерфейс демона хранения имеет более низкий MTU, чем один из отправляющего хоста, маршрутизатор по пути отправляет ICMP тип 3, код 4 (Fragmentation Needed and Do not Fragment is Set) ошибка для хоста. (некоторый маршрутизатор → A)
  6. Подключение ларьков, по какой-то причине host A наводняет ~ 100 пустых дубликатов ACK до B (в течение ~ 20 мс).

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

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

  • Ошибка ядра (Debian 3.13.7-1)
  • Реализация Linux IPSec намеренно игнорирует сообщение PMTU как меру безопасности, поскольку оно незащищено и повлияет на существующее SA. (похоже, действительное поведение в соответствии с RFC 4301 8.2.1)
  • Должен что-то сделать с PMTU Aging (RFC 4301 8.2.2)

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


5
2017-07-10 19:08


Источник


Я смог подтвердить, что отключить обнаружение PMTU, установив net.ipv4.ip_no_pmtu_disc=1 действительно устраняет эту конкретную проблему. На мой взгляд, это не идеальное решение. - al.


Ответы:


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


2
2017-07-13 03:33



Поскольку ESP отправляется через UDP, я не могу настроить MSS. Конечно, я мог применять ограничения MSS к незашифрованному TCP-соединению, но это было бы не менее обходным путем, чем снижение MTU интерфейса или вообще отключение обнаружения PMTU. - al.
Вероятнее всего, обнаружение PMTU не работает из-за отсутствия ответов ICMP (требуется Дефрагментация) с сервера IPsec. Совет, приведенный выше, касается ограничения MSS для соединений через IPsec, а не для основного туннеля ESP. - stimur
Ошибки ICMP достигают хоста IPSec просто отлично. Поскольку наименьший MTU всех хмелей неизвестен, должен быть угадан определенный предел ПСС. - al.
Вы можете запустить mturoute для определения наименьшего MTU. - Ben


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


0
2017-07-28 21:12