Perché le pagine di OpenConnect si bloccano finché non abbassi l’MTU del tunnel

L’accesso riesce, la pagina iniziale del portale viene disegnata, e poi un widget della dashboard o un report resta su waiting for host finché il browser non si arrende. I siti pubblici si caricano normalmente per tutto il tempo, e nessuna credenziale è cambiata. Il fatto che arrivino risposte piccole mentre quelle grandi si bloccano è la firma di un tetto di dimensione del pacchetto e non di una regola di accesso. Conferma questa lettura prima di modificare qualsiasi altra cosa nel profilo.

Separa un problema di dimensione da un problema di criterio

Inizia escludendo un rifiuto. Se il gateway ti avesse rifiutato, la connessione sarebbe fallita subito invece di caricare una pagina a metà. Un tunnel che sale e poi si blocca solo sui trasferimenti più grandi ti dice che il percorso esterno non riesce a portare il pacchetto interno.

Il meccanismo è l’incapsulamento. Ogni pacchetto interno guadagna intestazioni di tunnel, quindi un carico utile che stava nel collegamento fisico diventa un pacchetto esterno che non ci sta più, e tutto ciò che porta il bit do-not-fragment viene scartato senza una risposta che il browser possa interpretare.

Misura il tetto con sonde do-not-fragment

Misura il tetto invece di indovinarlo. Invia sonde che rifiutano la frammentazione e abbassa il carico utile passo dopo passo finché torna una risposta, partendo da un comando come ping -M do -s 1472 host. Una risposta che si lamenta che serve la frammentazione mentre DF è impostato significa che il valore è ancora troppo alto. Ripeti a 1462, poi a 1452, e fermati alla prima dimensione che risponde. Annota il numero insieme all’host che hai sondato, perché la risposta appartiene a quel percorso e non al protocollo in generale.

Sonda l’indirizzo a cui il tunnel invia davvero il traffico. Una sonda esterna verso il nome pubblico del gateway e una sonda interna verso un server interno misurano salti diversi, e il filtraggio ICMP su una delle due può far sembrare rotto un percorso sano.

Applica il valore al dispositivo del tunnel

Applica il risultato all’interfaccia creata dal client, non all’adattatore Wi-Fi. Su un client Linux è ip link set dev tun0 mtu 1300 seguito da ip link show tun0 per confermare che il valore è stato applicato. Usa il nome di dispositivo che il client riporta, perché varia con l’implementazione e con il modo in cui il tunnel è stato costruito.

Abbassare l’MTU del tunnel riduce il carico utile che ogni pacchetto trasporta, quindi la velocità complessiva cala un po’, ed è il prezzo per non mandare le risposte grandi in un buco nero. Un numero più piccolo non è automaticamente più sicuro. Cambiare invece l’adattatore fisico sparge il danno su ogni connessione di quel collegamento lasciando i pacchetti interni sovradimensionati altrettanto sovradimensionati.

Usa prima le richieste MTU del client stesso

Quando controlli l’invocazione, il client può chiedere una dimensione invece di essere corretto dopo. --mtu chiede al server un MTU di tunnel, e --base-mtu dichiara l’MTU del percorso sottostante così che il gateway possa ricavare il numero del tunnel. Entrambe sono richieste, e il manuale del client non promette che il gateway ne rispetti una.

Questa distinzione fissa l’ordine di lavoro. Prova prima la richiesta e ispeziona l’interfaccia che produce, poi torna all’impostazione locale del dispositivo se il valore scelto dal gateway si blocca ancora.

Verifica con il trasferimento che ha fallito, poi rendilo persistente

Una modifica locale di ip link dura finché il client non ricostruisce il tunnel, cosa che accade alla riconnessione o ripresa successiva. Metti il valore dove inizia la connessione: un wrapper che esegue il client e poi regola il dispositivo, un’unità systemd con un passo ExecStartPost, o l’opzione del client quando il gateway l’accetta. Tienilo accanto al profilo nel controllo di versione perché la persona successiva veda perché c’è il numero.

Prova con la richiesta che ha fallito, non con la pagina iniziale. Apri il report, scarica l’allegato o esegui il recupero del repository che si è bloccato, e annota esattamente dove si ferma se si ferma ancora. Una pagina che si disegna dopo la modifica dimostra poco, perché si disegnava anche prima.

Se lo stesso trasferimento si blocca nello stesso punto, la teoria dell’MTU non è dimostrata. Cattura il traffico sul tunnel e controlla quale lato smette di inviare prima di cambiare di nuovo il numero, e tieni annotato il valore precedente perché il rollback resti un solo comando.