L'HTTPS del contenidor s'encalla en una VPN corporativa? Prova la pota DTLS

Dins d'un contenidor darrere d'una VPN corporativa, el DNS es resol, la pàgina d'inici de sessió es carrega, un punt de comprovació de salut respon i llavors una petició HTTPS s'encalla fins que expira. Reconstruir la imatge i canviar les variables del proxy no canvia res, perquè la part que falla no és a la imatge. El client s'autentica per un transport i mou les dades massives per un altre, i només el segon està trencat.

Dos transports, un símptoma confús

Un client corporatiu basat en TLS normalment s'autentica per una connexió TLS ordinària i després negocia un segon canal de dades basat en UDP per a la sessió. Quan aquesta segona pota funciona, el rendiment i la latència milloren. Quan es filtra o no cap pel camí, tot el que hi ha abans del trànsit massiu té èxit i el trànsit mateix s'atura, que és exactament el patró anterior.

Un contenidor no canvia aquesta negociació; canvia el camí que segueixen els paquets exteriors. L'amfitrió tradueix el flux del contenidor, de manera que els datagrames UDP surten d'un port d'origen diferent del sòcol local del client i tornen per una entrada de traducció que caduca amb un temporitzador molt més curt que un flux TCP establert. Si el túnel funciona a l'amfitrió i falla al contenidor, compara aquests dos fluxos abans de culpar l'aplicació. Aquesta comparació resol més que qualsevol reconstrucció d'imatge.

Decideix amb experiments, no amb intuïció

L'experiment més barat desactiva el canal de dades UDP i repeteix la petició. Fes servir el client de línia d'ordres en lloc de l'embolcall d'escriptori, perquè l'opció s'apliqui de veritat: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Si la petició que s'encallava ara es completa, la pota DTLS era el problema i la resta era soroll.

Confirma el resultat en totes dues direccions des del mateix contenidor: una petició massiva amb l'opció i una sense. Un canvi de comportament que segueix l'opció és una prova; una pàgina que finalment es carrega no ho és.

Si l'opció ho arregla, decideix per què

Tres condicions produeixen el mateix símptoma i demanen respostes diferents. El camí pot filtrar UDP del tot, cosa que fa de l'opció la resposta permanent correcta per a aquesta xarxa. El camí pot permetre UDP però descartar datagrames grans, cosa que apunta a l'MTU i no al filtratge. O el camí pot tenir prou pèrdues perquè la pota UDP rendeixi pitjor que TCP, cosa que és una decisió de capacitat i no d'abastabilitat.

Distingeix-les abans de documentar una solució alternativa. El filtratge sobreviu a qualsevol mida de paquet, els problemes d'MTU només apareixen per sobre d'un llindar i la pèrdua es manifesta com a retransmissió i retard variable, no com un encallament net. Cada prova acota la causa sense canviar la configuració del client.

Comprova la mida del paquet abans de mantenir la solució alternativa

Si la causa és la mida, la interfície del túnel accepta paquets que el camí no pot portar, i el problema torna a qualsevol transport tan bon punt les càrregues creixen. Compara les interfícies: ip link show tun0 a l'amfitrió, després docker network inspect bridge per llegir l'MTU que consta a les opcions de xarxa. Un pont de contenidor que encara és a 1500 bytes sota un túnel que en porta menys és la troballa habitual.

Sondeja cap amunt des d'una mida bona coneguda amb una prova de no-fragmentació dins del túnel, i després baixa l'MTU de la xarxa del contenidor o limita l'MSS de TCP al túnel. Qualsevol de les dues correccions sovint fa tornar a ser utilitzable el camí UDP i elimina la necessitat de l'opció, que és el resultat millor quan el filtratge no és la causa.

Decideix què estàs disposat a intercanviar

Amb el canal de dades desactivat, el túnel porta la seva càrrega dins d'una connexió TCP. En un camí net això només és més lent; en un camí amb pèrdues, un sol segment perdut endarrereix tot el que hi ha darrere i la retransmissió exterior competeix amb la interior. Aquest intercanvi va bé per al desenvolupament interactiu i les crides d'API petites, i encaixa malament amb transferències massives o sessions llargues per enllaços mòbils.

Tant se val quina opció triïs, anota quin transport va acabar fent servir el túnel i per què. Un contenidor que depèn en silenci d'una opció que algú va afegir fa mesos és la propera caiguda, i qui la depuri no sabrà si l'opció era una solució alternativa per al filtratge o una resta d'un experiment d'MTU.