HTTPS в контейнере за корпоративным VPN зависает? Проверьте плечо DTLS

Внутри контейнера за корпоративным VPN DNS разрешается, страница входа загружается, конечная точка проверки здоровья отвечает, и затем запрос HTTPS зависает до истечения тайм-аута. Пересборка образа и смена переменных прокси ничего не меняют, потому что сбойная часть не в образе. Клиент аутентифицируется по одному транспорту и перевозит большие данные по другому, и сломан только второй.

Два транспорта, один запутанный симптом

Корпоративный клиент на базе TLS обычно аутентифицируется по обычному TLS-соединению, а затем согласует второй канал данных на базе UDP для сеанса. Когда это второе плечо работает, пропускная способность и задержка улучшаются. Когда его фильтруют или он не помещается в путь, всё до массовой передачи проходит успешно, а сама передача встаёт, что в точности соответствует картине выше.

Контейнер не меняет эти переговоры; он меняет путь внешних пакетов. Хост транслирует поток контейнера, поэтому датаграммы UDP уходят с другого исходного порта, чем локальный сокет клиента, и возвращаются через запись трансляции, которая истекает по куда более короткому таймеру, чем установленный поток TCP. Если туннель работает на хосте и не работает в контейнере, сравните эти два потока, прежде чем винить приложение. Это сравнение решает больше, чем любая пересборка образа.

Решайте экспериментом, а не интуицией

Самый дешёвый эксперимент отключает канал данных UDP и повторяет запрос. Используйте клиент командной строки, а не настольную обёртку, чтобы флаг действительно применился: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Если зависавший запрос теперь завершается, проблема была в плече DTLS, а остальное шум.

Подтвердите результат в обе стороны из одного и того же контейнера: один большой запрос с флагом и один без. Изменение поведения, которое следует за флагом, является доказательством; страница, которая в конце концов загружается, нет.

Если флаг помогает, решите почему

Три условия дают одинаковый симптом и требуют разных ответов. Путь может полностью фильтровать UDP, что делает флаг правильным постоянным ответом для этой сети. Путь может разрешать UDP, но отбрасывать крупные датаграммы, что указывает на MTU, а не на фильтрацию. Либо путь может быть настолько подвержен потерям, что плечо UDP работает хуже TCP, а это решение о ёмкости, а не о достижимости.

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

Проверьте размер пакета, прежде чем оставлять обход

Если причина в размере, интерфейс туннеля принимает пакеты, которые путь не может нести, и проблема возвращается на любом транспорте, как только нагрузка растёт. Сравните интерфейсы: ip link show tun0 на хосте, затем docker network inspect bridge, чтобы прочитать MTU, записанный в параметрах сети. Мост контейнера, всё ещё на 1500 байтах под туннелем, который несёт меньше, это обычная находка.

Зондируйте вверх от известного хорошего размера тестом запрета фрагментации внутри туннеля, затем снизьте MTU сети контейнера или ограничьте TCP MSS на туннеле. Любая из этих правок часто снова делает путь UDP пригодным и убирает надобность в флаге, что является лучшим исходом, когда причина не фильтрация.

Решите, чем вы готовы поступиться

С отключённым каналом данных туннель несёт нагрузку внутри соединения TCP. На чистом пути это просто медленнее; на пути с потерями один потерянный сегмент задерживает всё за ним, и внешняя повторная передача конкурирует с внутренней. Такой обмен подходит для интерактивной разработки и небольших вызовов API и плохо подходит для массовых передач или долгих сеансов через мобильные каналы.

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