HTTPS-ul dintr-un container se blochează pe un VPN corporate? Testați piciorul DTLS

Într-un container din spatele unui VPN corporate, DNS-ul se rezolvă, pagina de autentificare se încarcă, un endpoint de stare răspunde, iar apoi o cerere HTTPS se blochează până expiră timpul. Reconstruirea imaginii și schimbarea variabilelor de proxy nu schimbă nimic, pentru că partea defectă nu este în imagine. Clientul se autentifică printr-un transport și mută date mari prin altul, iar doar al doilea este stricat.

Două transporturi, un simptom confuz

Un client corporate bazat pe TLS se autentifică de obicei printr-o conexiune TLS obișnuită, apoi negociază un al doilea canal de date bazat pe UDP pentru sesiune. Când acel al doilea picior funcționează, debitul și latența se îmbunătățesc. Când este filtrat sau nu încape pe traseu, tot ce precede transferul mare reușește, iar transferul în sine se oprește, ceea ce este exact tiparul de mai sus.

Un container nu schimbă acea negociere; schimbă traseul pe care merg pachetele exterioare. Gazda traduce fluxul containerului, așa că datagramele UDP pleacă de pe alt port sursă decât socketul local al clientului și se întorc printr-o intrare de traducere care expiră pe un cronometru mult mai scurt decât un flux TCP stabilit. Dacă tunelul funcționează pe gazdă și eșuează în container, comparați acele două fluxuri înainte de a da vina pe aplicație. Acea comparație lămurește mai mult decât orice reconstruire a imaginii.

Decideți prin experiment, nu prin intuiție

Cel mai ieftin experiment dezactivează canalul de date UDP și repetă cererea. Folosiți clientul din linia de comandă în loc de ambalajul desktop, ca steagul să fie chiar aplicat: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Dacă cererea care se bloca acum se termină, piciorul DTLS era problema, iar restul era zgomot.

Confirmați rezultatul în ambele direcții din același container: o cerere mare cu steag și una fără. O schimbare de comportament care urmează steagul este dovadă; o pagină care într-un final se încarcă nu este.

Dacă steagul rezolvă, decideți de ce

Trei condiții produc același simptom și cer răspunsuri diferite. Traseul poate filtra UDP complet, ceea ce face din steag răspunsul permanent corect pentru acea rețea. Traseul poate permite UDP dar poate arunca datagramele mari, ceea ce indică MTU și nu filtrare. Sau traseul poate fi suficient de pierzător încât piciorul UDP să se comporte mai rău decât TCP, ceea ce este o decizie de capacitate și nu de accesibilitate.

Distingeți-le înainte de a documenta o soluție de ocolire. Filtrarea supraviețuiește la orice dimensiune de pachet, problemele de MTU apar doar peste un prag, iar pierderea se manifestă ca retransmisie și întârziere variabilă, nu ca o blocare curată. Fiecare test restrânge cauza fără a schimba configurația clientului.

Verificați dimensiunea pachetului înainte de a păstra soluția de ocolire

Dacă dimensiunea este cauza, interfața tunelului acceptă pachete pe care traseul nu le poate duce, iar problema revine pe orice transport de îndată ce încărcăturile cresc. Comparați interfețele: ip link show tun0 pe gazdă, apoi docker network inspect bridge pentru a citi MTU-ul înregistrat în opțiunile de rețea. Un pod de container rămas la 1500 de octeți sub un tunel care duce mai puțin este descoperirea obișnuită.

Sondați în sus de la o dimensiune bună cunoscută cu un test de interzicere a fragmentării în tunel, apoi coborâți MTU-ul rețelei containerului sau limitați MSS-ul TCP pe tunel. Oricare dintre corecturi face adesea traseul UDP din nou utilizabil și elimină nevoia de steag, ceea ce este rezultatul mai bun când filtrarea nu este cauza.

Decideți ce sunteți dispus să schimbați

Cu canalul de date dezactivat, tunelul își duce încărcătura într-o conexiune TCP. Pe un traseu curat asta este doar mai lent; pe unul cu pierderi, un singur segment pierdut întârzie tot ce urmează și retransmisia exterioară concurează cu cea interioară. Această permutare se potrivește dezvoltării interactive și apelurilor API mici și se potrivește prost transferurilor mari sau sesiunilor lungi pe legături mobile.

Orice opțiune ați alege, notați ce transport a folosit tunelul în final și de ce. Un container care depinde în tăcere de un steag adăugat de cineva acum luni este următoarea pană, iar cel care o depanează nu va ști dacă steagul a fost o soluție de ocolire pentru filtrare sau un rest dintr-un experiment de MTU.