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-ом.