Lo Static NAT è una traduzione uno a uno e bidirezionale: un indirizzo interno ne espone uno raggiungibile dall’esterno, e il traffico di ritorno deve poter tornare indietro. Proprio perché è simmetrico, si diagnostica in due tempi: prima si legge che cosa il Management Server ha effettivamente prodotto, poi si guarda che cosa il gateway fa davvero ai pacchetti. Saltare il secondo tempo è l’errore che il vendore segnala per primo su questo modulo.

Leggere la configurazione in SmartConsole senza fidarsi

La configurazione automatica vive nella scheda NAT dell’oggetto, sotto NAT e Advanced, dove si attiva Add automatic address translation rules e si sceglie il metodo. Con il metodo Static si indica l’indirizzo tradotto; il campo Install on Gateway decide se la traduzione la eseguono tutti i gateway oppure solo quelli indicati.

Il dettaglio che conta in diagnosi è quante regole nascono da quella spunta. Per lo Static NAT il Management Server genera due regole, una per la traduzione della sorgente e una per quella della destinazione; per l’Hide NAT ne genera una sola, perché traduce solo la sorgente. Per oggetti di tipo network o address range si aggiunge anche una regola che evita di tradurre il traffico interno alla stessa rete. Nel NAT Rule Base queste regole compaiono in sola lettura e in un ordine deciso da SmartConsole: prima Static NAT per host e gateway, poi Hide NAT per host e gateway, poi le stesse famiglie a livello di network. Se una connessione corrisponde sia a una regola NAT normale sia a una regola per le reti interne, prevale quella normale.

Le regole manuali servono quando quella meccanica non basta: sorgenti o destinazioni specifiche, traduzione di sorgente e destinazione nello stesso pacchetto, Static NAT in una sola direzione, traduzione dei servizi, oggetti dinamici. In cambio chiedono lavoro a mano, a partire dalle voci di proxy ARP. Cambia anche l’enforcement: le regole manuali si fermano alla prima corrispondenza, le automatiche possono applicarsi in coppia.

Infine, il NAT non autorizza niente. La Access Control Policy deve permettere la connessione con gli oggetti giusti, e la verifica in console non è completa finché non hai guardato anche quella.

Confermare la traduzione sul traffico

Il controllo decisivo è il capture. fw monitor espone quattro punti di ispezione: i prima che il pacchetto entri in un Chain Module in ingresso, I dopo che lo ha attraversato, o prima del Chain Module in uscita, O dopo. Si selezionano con -m, per esempio -m iIoO, si restringe il campo con un filtro INSPECT in -e, per esempio host(1.2.3.4), accept;, e si salva con -o su un percorso della partizione più capiente, tipicamente sotto /var/log/.

La lettura corretta non consiste nel ricordare a memoria in quale punto avvenga la traduzione, ma nel confrontare i quattro punti sullo stesso pacchetto e osservare dove gli indirizzi cambiano. fw ctl chain dà la mappa, perché elenca i Chain Module in ingresso e in uscita nell’ordine in cui il traffico li attraversa. Su uno Static NAT sano vedrai tradurre la destinazione nel senso entrante e la sorgente nel senso uscente, e vedrai entrambe le direzioni: se ne vedi una sola, il problema è sul ritorno — routing o proxy ARP — non sulla regola.

Attenzione a SecureXL: fw monitor mostra anche il traffico accelerato, ma i parametri di posizione non si applicano al traffico accelerato, che resta osservato nelle posizioni inbound e outbound predefinite. Un confronto fra i quattro punti su una connessione accelerata può quindi sembrare incompleto senza che ci sia alcun difetto di NAT.

Quando la configurazione è giusta e il traffico non passa

Restano tre sospetti. Il primo è il proxy ARP: con il NAT automatico il gateway risponde da solo alle ARP Request che arrivano dall’esterno per l’indirizzo tradotto, con le regole manuali no, e senza risposta ARP il pacchetto non arriva mai. Su IPv6 il meccanismo equivalente è il proxy NDP. Il secondo è il routing del ritorno. Il terzo è la Access Control Policy.

Se serve scendere di livello, la procedura di kernel debug R82 si apre con fw ctl debug 0, fwaccel dbg resetall e fw ctl set int simple_debug_filter_off 1, prosegue con i filtri per tupla, fw ctl debug -buf 8200 e fw ctl debug -m, raccoglie con fw ctl kdebug -T -f -o /var/log/kernel_debug.txt e si chiude ripetendo i tre reset. I filtri con lo stesso indice sono in AND, indici diversi in OR: per seguire una traduzione servono due indici, uno per l’indirizzo originale e uno per quello tradotto.

Trappole tipiche d’esame

Dichiarare verificato lo Static NAT guardando solo SmartConsole. La console mostra l’intenzione, non l’effetto. Nelle domande costruite su uno scenario, la risposta che si ferma alla configurazione è quasi sempre l’esca: manca il passo che osserva il traffico.

Leggere un capture di Hide NAT cercando l’indirizzo originale. Vale anche quando il caso in esame è Static: se sullo stesso gateway convivono le due modalità, filtrare sull’indirizzo interno fa sparire metà del flusso in Hide NAT e induce a concludere che il pacchetto sia stato scartato.

Non pensare al proxy ARP. Quando la traduzione sembra non avvenire, le voci di proxy ARP mancanti per una regola manuale spiegano il sintomo meglio di qualunque ipotesi sulla regola. Il pacchetto non arriva, quindi il capture sul gateway è vuoto: un capture vuoto non prova che il NAT sia rotto, è un indizio che punta all’ARP.