NAT simmetrico e VPN: misurate la mappatura, non l’etichetta

Un thread di supporto si chiude con il verdetto «NAT simmetrico, la VPN qui non funzionerà», e poi il client viene reinstallato tre volte senza motivo. L’etichetta fa danni perché risponde a una domanda che nessuno ha posto. Un client che si connette verso l’esterno a un server fisso crea una mappatura nel momento in cui invia il primo pacchetto, e la risposta è lasciata tornare secondo regole che quasi ogni rete applica. Ciò che la mappatura dipendente dall’estremità complica davvero sono due pari che cercano di raggiungersi nello stesso momento, e questa è un’altra prova.

Due domande si nascondono dietro un’etichetta

La prima domanda è se un host dietro questa rete possa aprire una sessione verso un indirizzo pubblico e una porta noti. Per un client tunnel è il caso normale, e la risposta è quasi sempre sì. Il router registra la sorgente interna, assegna una porta esterna e lascia passare la risposta perché appartiene a una sessione iniziata dall’interno.

La seconda domanda è se due host dietro reti diverse possano scoprire un percorso condiviso e scambiarsi pacchetti senza un server in mezzo. Dipende da come ciascuna rete assegna quelle porte esterne, ed è l’unico punto in cui il comportamento della mappatura conta.

Confondere le due cose produce la classica diagnosi sbagliata: una funzione tra pari fallisce, qualcuno esegue un test del tipo di NAT, vede la categoria peggiore e conclude che nemmeno il tunnel ordinario può funzionare. Il tunnel non è mai stato ciò che falliva.

Mappatura e filtraggio sono proprietà separate

La terminologia dell’RFC è più precisa dei nomi usati dai fornitori, e vale la pena riportarla nel ticket perché dirime le discussioni. La mappatura è come viene assegnata la porta esterna. Il filtraggio è quali pacchetti in ingresso sono lasciati passare. Una rete può essere rigida su una e liberale sull’altra, ed è quella combinazione che un protocollo tra pari deve sopravvivere.

La terza riga è ciò che la maggior parte dei router domestici e degli operatori mobili intende per simmetrico. Notate che l’etichetta descrive solo l’assegnazione. Una rete con quella mappatura e un filtraggio liberale può comunque accettare pacchetti in ingresso sulla porta appena assegnata, per questo la foratura dei buchi riesce su alcune e fallisce su altre.

Il filtraggio ha i suoi tre casi e il suo nome per ciascuno. Scrivere «NAT simmetrico» in un ticket quando si intende «filtraggio dipendente da indirizzo e porta» manda la persona successiva al capitolo sbagliato del manuale. I due si comportano diversamente in prova, quindi l’errore non è accademico.

Misurate la mappatura invece di darle un nome

Potete osservare la porta assegnata direttamente dal lato server di qualsiasi servizio UDP controlliate. Avviate una cattura sull’host pubblico, inviate dal client e leggete la porta di origine con cui è arrivato il pacchetto:

sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820

La riga dell’estremità è la più utile delle tre, perché WireGuard registra l’ultimo indirizzo e l’ultima porta ricevuti da ogni pari. Confrontate quella porta con quella che il client crede di usare. Differiranno ogni volta che avviene una traduzione, e la domanda importante è se il valore resta stabile.

Ripetete l’osservazione verso una seconda porta di destinazione o un secondo server e confrontate di nuovo. Se la porta esterna cambia per destinazione, la mappatura dipende da indirizzo e porta. Se resta uguale, la rete vi dà una sola mappatura e la scoperta ha una possibilità.

Gli strumenti basati su STUN riportano la stessa classificazione in un solo passo, e si possono usare quando la rete consente UDP in uscita verso un server STUN pubblico. Quando non lo consente, il metodo di cattura qui sopra funziona ancora e non richiede altro che un host che già controllate.

Scegliete una correzione adatta al guasto

Se la funzione che fallisce è tra pari, le risposte supportate sono un relè, un servizio di incontro che entrambi i pari possono raggiungere, o una topologia diversa. TURN esiste esattamente per questo, e un prodotto che include il proprio relè vi sta dicendo che si aspetta che alcune reti siano ostili.

Se la funzione che fallisce è un tunnel ordinario, il comportamento della mappatura non è il vostro problema e nulla di quanto sopra si applica. Verificate che il client invii davvero, che il server veda il pacchetto e che la risposta torni. Quella sequenza sono tre osservazioni e non richiede di sapere nulla della categoria NAT del router.

Ciò che non funziona è spargere cambi di porta locale finché qualcosa si connette. Cambiare la porta di origine del client non cambia come la rete assegna le mappature. Un successo casuale al quinto tentativo è un falso positivo, e sarà citato come correzione per mesi.

Registrate l’architettura, non il verdetto

Una nota utile dice quale protocollo, in che direzione inizia la sessione, se c’è un relè sul percorso e cosa è stato osservato sul cavo. «NAT simmetrico, non funziona» è inutilizzabile, perché è allo stesso tempo sbagliato sul tunnel e privo di informazioni sul percorso tra pari.

Includete la stabilità della porta misurata e il comportamento del filtraggio se li avete provati. Questi due fatti permettono a qualcun altro di prevedere se una nuova funzione funzionerà su quella rete senza ripetere tutta l’indagine. Invecchiano anche meglio di una categoria di fornitore che significa qualcosa di leggermente diverso su ogni pagina di aiuto.

Infine, tenete a portata di mano la terminologia dell’RFC 4787 quando lo scrivete. Usare i termini precisi costa una frase e impedisce al lettore successivo di ripetere la stessa diagnosi sbagliata, ed è tutto lo scopo di scrivere la nota.