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.