Come il traversal NAT incapsula l’ESP dentro UDP

Due client dietro lo stesso router parlano con un solo gateway IPsec, e uno continua a cadere mentre l’altro resta connesso. L’ESP nativo è il protocollo IP 50 senza porte, quindi un traduttore non ha nulla su cui ancorare una mappatura quando più client condividono un indirizzo. Il traversal NAT colma questa lacuna incapsulando l’ESP in UDP sulla 4500, e quell’intestazione spiega la maggior parte dei sintomi che seguono. Indica anche il dispositivo da modificare.

Perché il piano dati si sposta sulla porta 4500

Durante la configurazione IKEv2 confronta gli indirizzi e le porte che ciascun lato ritiene di usare, scambiando hash nelle proprie notifiche di rilevamento NAT. Quando gli hash non coincidono, un traduttore si trova da qualche parte sul percorso, ed entrambi i peer spostano il traffico protetto sull’incapsulamento UDP. Per questo una sessione che ha incontrato un traduttore appare diversa da una che non l’ha incontrato.

L’involucro è una busta, non un cambio di protocollo: L’ESP conserva la sua intestazione, il controllo di integrità e la cifratura, e UDP fornisce solo le porte di cui il traduttore ha bisogno. La porta 500 trasporta lo scambio IKE; la 4500 trasporta i dati incapsulati dopo il rilevamento, e spesso anche i messaggi IKE successivi. Nessuna delle due porte rende il flusso una connessione TCP, un’ipotesi che inganna la maggior parte di chi legge una cattura.

Controllate le due fasi in ordine

Dimostrate prima lo scambio di controllo, poi il percorso dati, e tenete i due separati nelle vostre note. Una cattura che mostra traffico sulla 500 e mai sulla 4500 di solito significa che il percorso dati è filtrato, quindi la correzione spetta alla regola del firewall e non al client.

Osservate entrambe le porte con tcpdump -ni any 'udp port 500 or udp port 4500', e leggete la tabella di traduzione sul router mentre una sessione è attiva. Quella tabella mostra la porta di origine che il gateway vedrà davvero, e una cattura sul portatile discorda per concezione: il portatile crede 500 mentre il gateway vede 4500 con una porta di origine tradotta, ed entrambi hanno ragione. Lo stesso flusso, prima e dopo la traduzione:

client 192.0.2.10:500 -> router 203.0.113.7:62000 -> gateway 198.51.100.9:4500

Sintomi che l’involucro spiega, e due che non spiega

Un router che consente lo scambio di controllo e blocca i dati incapsulati produce il rapporto «tunnel attivo, ma non passa nulla». Le tabelle di mappatura scadono, quindi una sessione inattiva ha bisogno del traffico di mantenimento che i peer inviano di proposito, e quei pacchetti non sono controlli di salute. Quando più client dietro un gateway falliscono insieme, esaminate la traduzione di quel gateway e qualsiasi vecchia funzione di passaggio diretto. L’involucro non spiega un’applicazione che fallisce per ogni client dopo l’attivazione del tunnel, né un avviso di certificato su una pagina di blocco; entrambi stanno sopra questo livello.

Leggete la tabella di mappatura per due client insieme: se entrambi mostrano la stessa porta tradotta, il dispositivo non li separa come il gateway richiede. Una modalità di passaggio diretto che consegna l’ESP nativo a un solo host non equivale a servire più client tradotti, anche se i fornitori descrivono entrambe come compatibili con IPsec. Il doppio NAT aggiunge uno strato di mappatura e un altro punto di scadenza, ma non interrompe automaticamente le connessioni in uscita.

Il traffico di mantenimento merita una riga propria nel manuale operativo, perché è ciò che tiene aperto il percorso di risposta durante i periodi di inattività. Attivatelo dove il fornitore lo documenta, e controllatelo per primo quando una sessione muore dopo qualche minuto di silenzio anziché al primo uso.

Cambiate il proprietario della mappatura, poi riprovate

Seguite le impostazioni di traversal NAT supportate su entrambi i peer invece di indovinare una porta. Modificare la porta di origine locale su un client non può cambiare il servizio in ascolto all’altro capo, e di solito rompe la mappatura già costruita. Se il client si trova dietro un dispositivo che non controllate, la modifica appartiene al suo proprietario.

Dopo ogni modifica, ripetete entrambi i controlli di fase e confermate che un pacchetto dati passi, non solo che la schermata di stato sia diventata verde. Tenete le tuple, l’output della tabella di mappatura e la modifica della regola in un’unica nota, così la persona successiva non riparte dallo scambio di controllo. Le note di strongSwan sul traversal NAT coprono l’incapsulamento e le impostazioni di mantenimento dietro entrambe le fasi.