Почему страницы OpenConnect зависают, пока вы не снизите MTU туннеля

Вход проходит, главная страница портала отрисовывается, а затем виджет панели или отчёт остаётся на waiting for host, пока браузер не сдастся. Публичные сайты всё это время загружаются нормально, и никакие учётные данные не менялись. То, что маленькие ответы доходят, а большие застревают, — признак потолка размера пакета, а не правила доступа. Подтвердите это чтение, прежде чем менять что-либо ещё в профиле.

Отделите проблему размера от проблемы политики

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

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

Измерьте потолок DF-пробами

Измерьте потолок, а не угадывайте его. Отправляйте пробы, которые отказываются от фрагментации, и снижайте нагрузку шаг за шагом, пока не вернётся ответ, начиная с команды вроде ping -M do -s 1472 host. Ответ, который жалуется на необходимость фрагментации при установленном DF, означает, что значение всё ещё слишком велико. Повторите на 1462, затем на 1452, и остановитесь на первом размере, который ответит. Запишите число вместе с хостом, который вы проверяли, потому что ответ принадлежит этому пути, а не протоколу вообще.

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

Примените значение к устройству туннеля

Примените результат к интерфейсу, созданному клиентом, а не к адаптеру Wi-Fi. В клиенте Linux это ip link set dev tun0 mtu 1300 , а затем ip link show tun0 , чтобы убедиться, что значение применилось. Используйте то имя устройства, которое сообщает клиент, потому что оно зависит от реализации и от того, как построен туннель.

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

Сначала используйте собственные запросы MTU клиента

Когда вы управляете вызовом, клиент может запросить размер, а не быть исправленным после. --mtu запрашивает у сервера MTU туннеля, а --base-mtu объявляет MTU нижележащего пути, чтобы шлюз мог вывести число туннеля. Оба — запросы, и руководство клиента не обещает, что шлюз выполнит хоть один из них.

Это различие определяет порядок работы. Сначала попробуйте запрос и изучите интерфейс, который он создаёт, а затем вернитесь к локальной настройке устройства, если выбранное шлюзом значение всё ещё застревает.

Проверьте передачей, которая не удалась, и затем сделайте это постоянным

Локальное изменение ip link действует, пока клиент не перестроит туннель, что происходит при следующем переподключении или возобновлении. Поместите значение туда, где начинается соединение: обёртка, которая запускает клиента и затем настраивает устройство, юнит systemd с шагом ExecStartPost, или опция клиента, когда шлюз её принимает. Держите её рядом с профилем в системе контроля версий, чтобы следующий человек видел, почему число там.

Тестируйте запросом, который не удался, а не главной страницей. Откройте отчёт, скачайте вложение или выполните получение репозитория, которое зависло, и отметьте точно, где оно останавливается, если всё ещё останавливается. Страница, которая отрисовывается после изменения, доказывает мало, потому что отрисовывалась и раньше.

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