Il ping della VPN funziona ma il sito si blocca: controllate la dimensione

Le risposte di eco arrivano, il desktop remoto funziona e il browser resta su una pagina bianca finché non si arrende. Due spiegazioni si adattano a questo schema, e non sono varianti di un unico problema: una politica che non ha mai consentito il servizio, o pacchetti che smettono di starci quando il trasferimento cresce. La risposta di eco non esclude nessuna delle due.

Passate dalla domanda più piccola a quella più grande e annotate che cosa ha realmente dimostrato ogni passo.

Una risposta di eco risponde a una domanda molto più piccola

Una risposta di eco dice che lo stack IP della destinazione ha risposto a una richiesta ICMP della vostra sorgente. Non dice nulla sull'esistenza di un listener TCP sulla porta che vi serve, sul fatto che una politica consenta quella porta o sul fatto che l'host di destinazione filtri il traffico indipendentemente dal gateway. Un gateway che consente un servizio può scartarne un altro mentre entrambi gli obiettivi rispondono al ping. Leggete la risposta come un solo fatto su un solo pacchetto e una sola direzione.

Confermate la destinazione e la porta del servizio prima di interpretare qualsiasi altra cosa. L'indirizzo che avete testato e quello che usa l'applicazione sono talvolta record diversi, e un nome che si risolve in due indirizzi rende probabile tutto ciò.

Scoprite se la connessione è iniziata

Una connessione rifiutata subito è una risposta del listener o della politica: qualcosa ha risposto e ha detto no. Una connessione che si apre e poi si blocca quando i dati iniziano a muoversi indica la dimensione. Una connessione che non completa mai la stretta di mano dipende di solito dalla politica o dall'instradamento, e sembra un timeout più che un rifiuto.

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

Annotate quale di questi tre casi avete osservato prima di toccare le impostazioni MTU. Cambiare la dimensione del tunnel per riparare una connessione rifiutata spreca la modifica e nasconde la causa reale per un po'.

Misurate la dimensione con un numero dichiarato

Quando il blocco compare sotto carico, provate una dimensione di pacchetto con il bit di non frammentazione attivo e dichiarate l'aritmetica perché il risultato significhi qualcosa. Su Linux con iputils, un carico utile di 1392 byte più l'intestazione ICMP di 8 byte e l'intestazione IPv4 di 20 byte produce un pacchetto interno di esattamente 1420 byte. Dichiarate questa aritmetica nel ticket, perché un ping nudo che raggiunge il gateway non prova nulla su un'applicazione.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

Entrambe le sonde sono punti di misura, non raccomandazioni sulla dimensione del tunnel. Se ICMP viene filtrato da qualche parte sul percorso, un timeout non vi dice nulla sulla dimensione, perché il filtraggio e un pacchetto troppo grande appaiono identici dal lato client. Un successo non dice nulla nemmeno sulla direzione inversa o su un'altra destinazione.

Tenete conto del percorso esterno

L'incapsulamento aggiunge le proprie intestazioni, quindi il pacchetto sul filo è più grande di quello misurato dentro il tunnel. È lo scarto tra i due che rende possibili allo stesso tempo una richiesta piccola che funziona e una grande che fallisce.

La scoperta dell'MTU del percorso in IPv4 dipende dal feedback sui pacchetti che non possono essere inoltrati senza frammentazione, e IPv6 usa i messaggi Packet Too Big. La specifica IPv4 descrive quel meccanismo. Filtrare il feedback rompe la capacità del mittente di imparare e lo lascia a ritrasmettere pacchetti che non staranno mai. Per questo una richiesta piccola che funziona e una grande che fallisce convivono così comodamente.

Cambiate un numero e ritestate l'applicazione

Abbassate l'MTU del tunnel, o limitate la dimensione massima del segmento per TCP, poi ripetete il test originale dell'applicazione invece della sonda. Una sonda che riesce dopo la modifica e un'applicazione che resta bloccata sono un problema diverso con una forma simile, e solo il test dell'applicazione li distingue.

Conservate l'aritmetica nel registro della modifica: la dimensione misurata, l'overhead ipotizzato e il valore impostato. Chi lo riesamina in seguito può controllare l'ipotesi invece di ricavarla di nuovo da uno screenshot di un ping.

Se l'applicazione funziona a ogni dimensione provata, smettete di regolare numeri e guardate la politica che separa il servizio che funziona da quello che fallisce.