Diagnosticare il NAT e leggere il traffico Hide NAT nei packet capture

Un problema di NAT su Quantum R82 raramente è «il NAT non funziona». Quasi sempre la regola esiste, la traduzione magari avviene, ma qualcosa a monte o a valle — routing, proxy ARP, ordine delle regole, accelerazione — impedisce al flusso di chiudersi. Il metodo di livello expert parte da un presupposto semplice: la regola in SmartConsole dichiara l’intenzione, il pacchetto sul gateway dichiara la realtà. Le due cose si confrontano, non si deducono l’una dall’altra.

I tre punti in cui la traduzione si rompe

Il NAT Rule Base ha due metà simmetriche: Original Source, Destination e Services da un lato; Translated Source, Destination e Services dall’altro, più Install On e Comments. Le regole automatiche le genera il Management Server dalle proprietà dell’oggetto, quelle manuali le scrive l’amministratore. La differenza pesa in diagnosi: con le regole manuali l’enforcement si ferma alla prima regola che corrisponde, mentre con quelle automatiche il gateway può applicarne due insieme, una per la sorgente e una per la destinazione. SmartConsole ordina inoltre le automatiche con una gerarchia fissa: prima Static NAT per host e gateway, poi Hide NAT per host e gateway, poi le stesse due famiglie a livello di network.

Il secondo punto è il proxy ARP. Con il NAT automatico il gateway risponde per conto degli oggetti tradotti alle ARP Request che arrivano dalla rete esterna. Con le regole manuali no: per le Manual NAT rules vanno configurate le voci di proxy ARP che associano l’indirizzo tradotto all’indirizzo MAC dell’interfaccia del gateway sulla stessa rete degli indirizzi tradotti. Su IPv6 il meccanismo equivalente è il proxy NDP, e anche gli intervalli tradotti del CGNAT non lo generano in automatico. Un traffico che «sembra non tradotto» spesso non è mai arrivato al gateway.

Il terzo punto è il routing: l’indirizzo tradotto deve essere raggiungibile e il ritorno deve ripassare dal gateway, altrimenti la traduzione è corretta e la connessione resta comunque muta.

Hide NAT: quello che il capture mostra davvero

fw monitor osserva il pacchetto in quattro punti di ispezione: i prima che entri in un Chain Module in ingresso, I dopo che lo ha attraversato in ingresso, o prima che entri in un Chain Module in uscita, O dopo che lo ha attraversato in uscita. Si selezionano con -m, per esempio -m iIoO, e si restringe il campo con un filtro INSPECT passato a -e, nella forma host(1.2.3.4), accept; oppure port(443), accept;. L’output si scrive su file con -o, indicando un percorso sulla partizione più capiente, tipicamente sotto /var/log/.

Su una connessione in Hide NAT la sorgente viene sostituita: l’indirizzo originale esiste solo nella parte iniziale del percorso, poi al suo posto compare l’indirizzo dietro cui la rete si nasconde. Chi filtra il capture sul solo indirizzo originale vede metà storia e conclude che il pacchetto si perde. Il confronto fra i quattro punti serve esattamente a stabilire dove l’indirizzo cambia, invece di darlo per scontato. fw ctl chain completa il quadro, perché elenca i Chain Module in ingresso e in uscita nell’ordine in cui il traffico li attraversa.

Quando il capture non basta: il kernel debug

Se il capture non spiega la sparizione, si scende al kernel debug. La procedura R82 è rigida e va eseguita nell’ordine: fw ctl debug 0, fwaccel dbg resetall, fw ctl set int simple_debug_filter_off 1, poi si impostano i filtri, si alloca il buffer con fw ctl debug -buf 8200, si verifica con fw ctl debug | grep buffer, si abilitano moduli e flag con fw ctl debug -m e infine si raccoglie con fw ctl kdebug -T -f -o /var/log/kernel_debug.txt. Si riproduce il problema, si interrompe con CTRL+C e si ripulisce tutto ripetendo i tre comandi di reset.

I filtri si impostano per tupla, con i parametri simple_debug_filter_saddr_N, daddr_N, sport_N, dport_N e proto_N. I parametri con lo stesso indice sono in AND, indici diversi sono in OR. Qui la trappola dell’Hide NAT si ripresenta identica: un filtro costruito solo sull’indirizzo sorgente originale taglia fuori la metà tradotta del flusso. Conviene usare due indici, uno per l’indirizzo originale e uno per quello tradotto, e leggerli insieme.

Trappole tipiche d’esame

Aspettarsi l’indirizzo originale in un capture di Hide NAT. È l’errore più frequente su questo modulo. In Hide NAT la sorgente viene sostituita lungo il percorso: se il filtro nomina solo l’indirizzo interno, il traffico scompare a metà e la diagnosi devia verso il routing o verso una regola inesistente. Davanti a un output di fw monitor interrotto, chiediti sempre quale punto di ispezione stai guardando prima di concludere che il pacchetto sia stato scartato.

Fermarsi a SmartConsole. Vedere la regola corretta nella console non dimostra che la traduzione avvenga: dimostra che il Management Server ha ricevuto l’intenzione. Serve il traffico. Una domanda che propone «verificare la configurazione in SmartConsole» come passo conclusivo ti sta offrendo la scorciatoia sbagliata.

Dimenticare il proxy ARP. Quando la traduzione non avviene e la configurazione è ineccepibile, il sospetto numero uno sono le voci di proxy ARP mancanti per le regole manuali, non la regola in sé. Senza risposta ARP il pacchetto non raggiunge mai il gateway, e nessun capture fatto sul gateway lo mostrerà: non c’è niente da mostrare.