Container-HTTPS hang in 'n korporatiewe VPN? Toets die DTLS-been

Binne 'n container agter 'n korporatiewe VPN los DNS op, die aanmeldbladsy laai, 'n gesondheidseindpunt antwoord, en dan hang 'n HTTPS-versoek tot dit uitloopt. Om die image te herbou en proxy-veranderlikes te wysig verander niks, want die deel wat faal is nie in die image nie. Die kliënt verifieer oor een transport en stuur grootmaatdata oor 'n ander, en net die tweede een is stukkend.

Twee transporte, een verwarrende simptoom

'n TLS-gebaseerde korporatiewe kliënt verifieer gewoonlik oor 'n gewone TLS-verbinding en onderhandel dan 'n tweede UDP-gebaseerde datakanaal vir die sessie. Wanneer daardie tweede been werk, verbeter deurset en latensie. Wanneer dit gefiltreer word of nie deur die pad kan pas nie, slaag alles voor die grootmaatoordrag en die oordrag self stop, wat presies die patroon hierbo is.

'n Container verander nie daardie onderhandeling nie; dit verander die pad wat die buitenste pakkette neem. Die gasheer vertaal die container-vloei, so die UDP-datagramme vertrek vanaf 'n ander bronpoort as die kliënt se plaaslike socket, en hulle keer terug deur 'n vertaalinskrywing wat op 'n baie korter tydhouer verval as 'n gevestigde TCP-vloei. As die tonnel op die gasheer werk en in die container faal, vergelyk daardie twee vloei voordat jy die toepassing blameer. Daardie vergelyking beslis meer as enige herbou van die image.

Besluit deur eksperiment, nie deur intuïsie nie

Die goedkoopste eksperiment skakel die UDP-datakanaal af en herhaal die versoek. Gebruik die opdragreëlkliënt eerder as die lessenaar-omhulsel, sodat die vlag werklik toegepas word: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. As die versoek wat gehang het nou voltooi, was die DTLS-been die probleem en die res geraas.

Bevestig die resultaat in albei rigtings uit dieselfde container, een grootmaatversoek met die vlag en een sonder. 'n Gedragsverandering wat die vlag volg is bewyse; 'n bladsy wat uiteindelik laai is nie.

As die vlag dit regmaak, besluit waarom

Drie toestande veroorsaak dieselfde simptoom, en hulle vra verskillende reaksies. Die pad kan UDP heeltemal filtreer, wat die vlag die korrekte permanente antwoord vir daardie netwerk maak. Die pad kan UDP toelaat maar groot datagramme laat val, wat op MTU eerder as filtering dui. Of die pad kan so verliesryk wees dat die UDP-been swakker presteer as TCP, wat 'n kapasiteitsbesluit is eerder as 'n bereikbaarheidsbesluit.

Onderskei hulle voordat jy 'n tydelike oplossing dokumenteer. Filtering oorleef elke pakketgrootte, MTU-probleme verskyn net bo 'n drempel, en verlies wys as hertransmissie en wisselende vertraging eerder as 'n skoon hang. Elke toets vernou die oorsaak sonder om die kliëntkonfigurasie te verander.

Kontroleer pakketgrootte voordat jy die tydelike oplossing hou

As grootte die oorsaak is, aanvaar die tonnelkoppelvlak pakkette wat die pad nie kan dra nie, en die probleem keer op enige transport terug sodra die loonvrag groei. Vergelyk die koppelvlakke: ip link show tun0 op die gasheer, dan docker network inspect bridge om die MTU te lees wat in die netwerkopsies aangeteken is. 'n Container-brug wat nog op 1500 grepe staan onder 'n tonnel wat minder dra, is die gewone bevinding.

Tast opwaarts vanaf 'n bekende-goeie grootte met 'n do-not-fragment-toets binne die tonnel, en verlaag dan die container-netwerk se MTU of knyp TCP MSS op die tonnel vas. Enige van die twee regstellings maak die UDP-pad dikwels weer bruikbaar en verwyder die nodigheid van die vlag, wat die beter uitkoms is wanneer filtering nie die oorsaak is nie.

Besluit waarvoor jy bereid is om in te ruil

Met die datakanaal afgeskakel, dra die tonnel sy loonvrag binne 'n TCP-verbinding. Op 'n skoon pad is dit bloot stadiger; op 'n verliesryke pad vertraag 'n enkele verlore segment alles agter hom en die buitenste hertransmissie kompeteer met die binneste een. Daardie ruil pas by interaktiewe ontwikkeling en klein API-oproepe, en pas swak by grootmaatoordragte of lang sessies oor mobiele skakels.

Watter opsie jy ook kies, teken aan watter transport die tonnel uiteindelik gebruik het en waarom. 'n Container wat stilweg afhanklik is van 'n vlag wat iemand maande gelede bygevoeg het, is die volgende onderbreking, en die persoon wat dit ontfout sal nie weet of die vlag 'n tydelike oplossing vir filtering was of 'n oorblyfsel van 'n MTU-eksperiment nie.