È l'ISP a bloccare l'UDP, o è l'app dentro il tunnel?

Qualcuno riferisce che la VPN «blocca l'UDP», e questa frase nasconde due affermazioni completamente diverse. Una riguarda il trasporto che la rete di accesso può vedere, l'altra i pacchetti di un'applicazione dopo che sono stati decifrati dentro il tunnel. Un tunnel cifrato può essere filtrato dall'esterno senza alcuna chiave, e un'applicazione UDP interna può fallire per motivi che non hanno nulla a che fare con il filtraggio. Decidi quale affermazione stai verificando prima di raccogliere prove.

Due intestazioni, una parola

In una distribuzione IPsec con NAT-traversal, il pacchetto esterno è UDP, indirizzato tra i due estremi della VPN, di solito sulla porta 4500. All'interno, il carico utile cifrato trasporta tutto ciò che il tunnel inoltra, che può essere a sua volta TCP o UDP. La parola UDP compare quindi due volte, con significati e visibilità diversi.

Una rete intermedia vede l'intestazione esterna e nulla di quella interna. Può consentire, modellare o scartare il flusso esterno, e non ha bisogno di decifrare nulla per farlo. È proprio questa asimmetria il motivo per cui le due affermazioni si confondono: la stessa parola descrive ciò che la rete filtra e ciò che l'applicazione invia. Annota il livello accanto alla parola ogni volta che registri un riscontro, e la confusione in gran parte scompare.

L'intestazione interna diventa visibile solo all'estremo ricevente, dopo la decifratura. Da quel punto il pacchetto viene inoltrato come qualsiasi altro, soggetto a rotte, criteri e filtraggio proprio dell'estremo. Sono decisioni separate prese da apparati diversi.

Cosa la rete può ancora vedere

La cifratura nasconde il carico utile e l'intestazione di trasporto interna, non il fatto che un flusso esista. Gli indirizzi degli estremi, le porte, le dimensioni dei pacchetti e la temporizzazione restano visibili, e questo basta per classificare il traffico in modo euristico o per bloccare una destinazione specifica.

sudo tcpdump -ni eth0 'udp port 4500'
sudo tcpdump -ni tun0 'udp port 5201'

La prima cattura mostra il flusso esterno sull'interfaccia fisica, la seconda mostra il flusso interno sull'interfaccia del tunnel. Eseguirle entrambe insieme risponde direttamente alla domanda: se il flusso esterno esiste e quello interno no, l'applicazione non ha mai inviato nulla nel tunnel. Se esistono entrambi e non torna nulla, il problema è oltre il tunnel, alla destinazione o sul percorso di ritorno.

RFC 3948 definisce l'incapsulamento UDP esterno, e la specifica ESP definisce la disposizione protetta al suo interno. Nessuno dei due documenti promette che una rete di accesso farà passare il flusso esterno, perciò vale la pena eseguire un test di raggiungibilità sulla tupla esterna prima di qualsiasi teoria su quella interna. Una tupla esterna bloccata produce un tunnel che non si forma mai, non un tunnel che si forma e poi perde un'applicazione.

Perché un'app UDP fallisce dentro un tunnel che funziona

Un tunnel che trasporta un'applicazione web ma non un'applicazione UDP ha diverse spiegazioni plausibili, e il filtraggio del protocollo interno da parte dell'ISP non è la prima. La più comune è la copertura: le due applicazioni non entrano entrambe nello stesso tunnel, perché manca la rotta verso la destinazione UDP o le regole di tunnel diviso del client la escludono.

La seconda è l'estremo. Un server VPN che consente un elenco di protocolli, un firewall sulla destinazione o un servizio che non ascolta mai sulla porta attesa produrranno tutti un timeout che sembra identico a un blocco di rete.

La terza è la dimensione dei pacchetti. Le applicazioni UDP inviano spesso datagrammi più grandi di una richiesta web, e l'incapsulamento riduce l'MTU utilizzabile, così dopo un handshake riuscito può seguire il silenzio sul primo carico utile a dimensione piena. Questo schema si legge facilmente come un blocco, perché i pacchetti piccoli passano e quelli grandi svaniscono. Una sonda MTU rapida lo risolve in meno di un minuto, e la risposta di solito è un carico utile più piccolo o un MSS corretto, non un filtro di rete.

ping -M do -s 1400 -c 2 10.60.0.20
iperf3 -u -c 10.60.0.20 -p 5201 -b 1M -t 5

Il primo comando verifica se un pacchetto grande sopravvive al percorso con la frammentazione disattivata, il che espone rapidamente un problema di MTU. Il secondo invia un flusso UDP piccolo e limitato e riporta perdite e jitter. Un flusso che parte e poi si blocca indica la dimensione, non un blocco.

Segnala il livello, non il protocollo

Scrivi il riscontro in una delle tre forme: consegna esterna fallita, inoltro interno fallito, o applicazione fallita. Ognuna ha un responsabile diverso, e mescolarle manda il ticket al team sbagliato.

Cambiare una porta locale non può creare un ascoltatore corrispondente all'altro capo, quindi una soluzione lato client che sembra aiutare è di solito la prova che la destinazione originale era sbagliata. Allo stesso modo, un profilo alternativo fornito dimostra qualcosa sulla raggiungibilità e nulla sulla correttezza della configurazione dell'applicazione.

Tieni anche l'inferenza separata dall'osservazione. L'analisi del traffico può suggerire cos'è un flusso senza decifrarlo, ed è un riscontro utile, ma non è la stessa affermazione della lettura dell'intestazione interna. Indica quale delle due hai davvero.