L'HTTPS di un container si blocca su una VPN aziendale? Prova la gamba DTLS

Dentro un container dietro una VPN aziendale il DNS risolve, la pagina di accesso si carica, un endpoint di salute risponde, e poi una richiesta HTTPS si blocca finché non scade il tempo. Ricostruire l'immagine e cambiare le variabili del proxy non cambia nulla, perché la parte che fallisce non è nell'immagine. Il client si autentica su un trasporto e sposta i dati in volume su un altro, e solo il secondo è rotto.

Due trasporti, un sintomo confuso

Un client aziendale basato su TLS di solito si autentica su una normale connessione TLS, poi negozia un secondo canale dati basato su UDP per la sessione. Quando quella seconda gamba funziona, prestazioni e latenza migliorano. Quando viene filtrata o non passa nel percorso, tutto ciò che precede il trasferimento in volume riesce e il trasferimento stesso si ferma, che è esattamente il modello qui sopra.

Un container non cambia quella negoziazione; cambia il percorso che prendono i pacchetti esterni. L'host traduce il flusso del container, quindi i datagrammi UDP escono da una porta sorgente diversa dal socket locale del client e tornano attraverso una voce di traduzione che scade con un timer molto più breve di un flusso TCP stabilito. Se il tunnel funziona sull'host e fallisce nel container, confronta quei due flussi prima di dare la colpa all'applicazione. Quel confronto chiarisce più di qualsiasi ricostruzione dell'immagine.

Decidi con l'esperimento, non con l'intuito

L'esperimento più economico disattiva il canale dati UDP e ripete la richiesta. Usa il client da riga di comando invece del wrapper desktop, così l'opzione viene davvero applicata: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Se la richiesta che si bloccava ora si completa, la gamba DTLS era il problema e il resto era rumore.

Conferma il risultato in entrambe le direzioni dallo stesso container: una richiesta in volume con l'opzione e una senza. Un cambiamento di comportamento che segue l'opzione è una prova; una pagina che alla fine si carica non lo è.

Se l'opzione risolve, decidi perché

Tre condizioni producono lo stesso sintomo e richiedono risposte diverse. Il percorso può filtrare UDP del tutto, il che rende l'opzione la risposta permanente corretta per quella rete. Il percorso può consentire UDP ma scartare i datagrammi grandi, il che indica l'MTU e non il filtraggio. Oppure il percorso può essere abbastanza lossy da far rendere la gamba UDP peggio del TCP, che è una decisione di capacità e non di raggiungibilità.

Distinguile prima di documentare un aggiramento. Il filtraggio sopravvive a ogni dimensione di pacchetto, i problemi di MTU compaiono solo sopra una soglia e la perdita si manifesta come ritrasmissione e ritardo variabile, non come un blocco netto. Ogni test restringe la causa senza cambiare la configurazione del client.

Controlla la dimensione dei pacchetti prima di tenere l'aggiramento

Se la causa è la dimensione, l'interfaccia del tunnel accetta pacchetti che il percorso non può portare, e il problema torna su qualsiasi trasporto appena i payload crescono. Confronta le interfacce: ip link show tun0 sull'host, poi docker network inspect bridge per leggere l'MTU registrato nelle opzioni di rete. Un bridge del container ancora a 1500 byte sotto un tunnel che ne porta meno è il riscontro abituale.

Sonda verso l'alto da una dimensione nota buona con un test di non frammentazione dentro il tunnel, poi abbassa l'MTU della rete del container o limita l'MSS TCP sul tunnel. L'una o l'altra correzione spesso rende di nuovo utilizzabile il percorso UDP ed elimina la necessità dell'opzione, che è il risultato migliore quando il filtraggio non è la causa.

Decidi cosa sei disposto a scambiare

Con il canale dati disattivato, il tunnel porta il suo carico dentro una connessione TCP. Su un percorso pulito è solo più lento; su uno con perdite, un solo segmento perso ritarda tutto ciò che segue e la ritrasmissione esterna compete con quella interna. Questo scambio si adatta allo sviluppo interattivo e alle piccole chiamate API, e si adatta male ai trasferimenti in volume o alle sessioni lunghe su collegamenti mobili.

Qualunque opzione scegli, annota quale trasporto ha finito per usare il tunnel e perché. Un container che dipende silenziosamente da un'opzione aggiunta da qualcuno mesi prima è la prossima interruzione, e chi la dovrà diagnosticare non saprà se l'opzione era un aggiramento per il filtraggio o un residuo di un esperimento sull'MTU.