L2TP/IPsec attraverso NAT: cosa si rompe davvero e perché

L’affermazione che NAT rompa L2TP/IPsec è mezzo vera e quindi inutile. La traduzione degli indirizzi è normale, il traversal NAT esiste proprio per sopravvivergli, e milioni di client si connettono ogni giorno da dietro un router. Ciò che si rompe è una fase precisa di uno scambio preciso: IKE non riceve mai risposta, il tunnel incapsulato viene scartato da una policy che consente un solo protocollo, oppure la mappatura di traduzione scade mentre il tunnel è inattivo. Una volta saputo in quale fase siete, la correzione è di solito una singola regola o un keepalive, non un nuovo progetto di VPN.

Il mito è la domanda sbagliata

La domanda utile non è «NAT rompe questo» ma «quale parte dello scambio viene tradotta, e cosa ne fa il dispositivo che traduce». L2TP/IPsec è un protocollo a strati: IKE negozia, ESP protegge, e L2TP trasporta PPP dentro quella protezione. La traduzione degli indirizzi interagisce diversamente con ogni strato, e le firme dei guasti si distinguono se si guarda la fase di negoziazione invece della finestra di errore.

Un router che naviga sul web con successo dimostra solo che TCP con traduzione della porta sorgente funziona. Non dice nulla su UDP 500, UDP 4500 o protocollo 50, e sono proprio queste tre cose da cui dipende questo deployment.

Fase 1: IKE deve almeno ricevere una risposta

Il primo scambio va al responder su UDP 500. Se non torna alcuna risposta, nient’altro conta: la chiave precondivisa, la proposta e le credenziali restano non lette. Osservate la richiesta e la risposta invece di dedurre dal timeout del client:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

Una richiesta senza risposta di solito significa che un firewall o l’operatore a monte scarta il pacchetto, non che il server lo abbia rifiutato. Una risposta con un carico di notifica che nomina una proposta o un problema di certificato significa che i pacchetti sono arrivati e che la negoziazione è fallita sul contenuto, il che è una riparazione completamente diversa.

Quando entrambi i peer sono dietro una traduzione, l’iniziatore deve solo raggiungere il responder, quindi la maggior parte dei deployment lato client funziona dalla fase 1. L’hosting lato server è dove inizia il problema in ingresso, ed è per questo che le due situazioni non dovrebbero mai essere discusse come una sola.

Fase 2: l’incapsulamento cambia ciò che vede il firewall

ESP è un protocollo IP, non una porta TCP o UDP, e la traduzione degli indirizzi di porta ordinaria non ha alcun campo porta da riscrivere. Per questo il traversal NAT sposta il carico protetto in UDP 4500: l’incapsulamento dà al dispositivo che traduce qualcosa che sa tradurre. Quando ciò accade, una regola firewall scritta solo per UDP 500 consente la negoziazione e scarta il tunnel, il che produce il risultato confuso in cui il log mostra una fase 1 riuscita e nessun traffico.

Lo stesso scambio IKE può anche spostarsi su UDP 4500 dopo il rilevamento di un NAT, cosa che sorprende chi ha consentito 500 e nulla più. Consentite entrambe le porte in entrambe le direzioni sul percorso, e ricordate che un firewall con stato mantiene il flusso solo finché vede traffico.

Il protocollo 50 conta ancora sui percorsi senza traduzione, e sui percorsi in cui un dispositivo intermedio è configurato per consentirlo. Se diagnosticate per esclusione, disattivate l’ipotesi invece di aggiungere regole in blocco: consentite 500, 4500 ed ESP, confermate che il tunnel sale, poi rimuovete ciò che si è rivelato superfluo. Una regola che nessuno sa spiegare è una regola che nessuno rimuoverà quando diventerà la causa del guasto successivo. Scrivete la riduzione nel registro delle modifiche insieme alla fase che ha corretto, così il prossimo ingegnere parte dalle vostre prove e non dalla stessa regola empirica.

Fase 3: la mappatura scade e il tunnel muore

Un dispositivo che traduce mantiene lo stato dei flussi che inoltra, e quello stato ha una durata. Un tunnel L2TP/IPsec trasporta poco traffico quando nessuno lo usa, quindi un tunnel inattivo può sopravvivere alla sua mappatura e smettere di ricevere il traffico di ritorno. Il client resta convinto di essere connesso, il server non vede nulla, e il primo sintomo è di solito un timeout dell’applicazione e non un errore VPN.

Rilevamento del peer morto e keepalive NAT esistono per questo, ed entrambe le estremità devono essere disposte a inviarli. Se il vostro server è dietro una traduzione, il requisito lato Windows è un’impostazione di registro documentata che fa assumere al server l’incapsulamento UDP per i propri pacchetti in uscita; senza di essa il responder invia ESP che il dispositivo che traduce non riesce a rimappare. È un problema di configurazione del server, non del client.

Un cambio di indirizzo WAN produce lo stesso esito da un’altra direzione: la mappatura viene ricostruita attorno a un nuovo indirizzo, e la vecchia associazione di sicurezza punta ora a una tupla che non esiste più. Il comportamento di riconnessione appartiene all’implementazione del client, ed è per questo che «riconnetti dopo il riavvio del router» funziona su un client e su un altro richiede un interruttore manuale.

Ospitare dietro un NAT dell’operatore è un problema diverso

Se volete ospitare un server L2TP/IPsec a casa e raggiungerlo dall’esterno, il requisito è la raggiungibilità in ingresso non sollecitata, e non è ciò che offre il traversal NAT. Un NAT dell’operatore davanti al vostro router significa che non esiste alcuna porta che possiate inoltrare e che vi renda raggiungibili, perché l’indirizzo pubblico è condiviso e la mappatura è solo in uscita.

Nessuna casella IPsec pass-through cambia questo, e nessuna configurazione del client lo compensa. Le risposte supportate sono un indirizzo davvero raggiungibile, un endpoint ospitato o un’architettura in cui ogni partecipante effettua una connessione in uscita. La specifica di incapsulamento UDP risolve il problema della traduzione per i flussi che esistono; non crea un percorso in ingresso dove l’operatore non ne offre uno.

Quindi confrontate le reti invece di indovinare. Portate lo stesso dispositivo e profilo su un’altra rete consentita e osservate quale fase fallisce lì. Se funziona altrove, la differenza è nel percorso, e questo riduce la ricerca alle tre fasi qui sopra invece che all’intera configurazione.