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.