Il NAT automatico copre la maggior parte dei casi: si spunta Add Automatic Address Translation rules nella pagina NAT dell’oggetto e il Management Server genera le regole da solo. Static NAT ne produce due — una traduce la sorgente in uscita, l’altra la destinazione in ingresso — mentre Hide NAT ne produce una sola, sul solo indirizzo sorgente: verso un oggetto nascosto le connessioni entranti non sono ammesse.

Una regola manuale serve quando la traduzione dipende da qualcosa che l’oggetto non sa da sé: tradurre solo verso una certa destinazione, tradurre anche il servizio, fare una traduzione unidirezionale o bidirezionale, usare un Dynamic Object. La riga ha sei colonne — Original Source, Original Destination, Original Services e i tre Translated corrispondenti — e ogni campo resta su = Original dove non si vuole toccare nulla.

Due comportamenti vanno tenuti separati, perché è lì che la domanda si sbaglia. Le regole manuali funzionano alla prima corrispondenza: il gateway applica la prima che matcha e smette di cercare. Le automatiche no: sulla stessa connessione il gateway può applicarne due, una per la sorgente e una per la destinazione. Nella NAT Rule Base le automatiche compaiono in un ordine deciso da SmartConsole — prima Static, poi Hide, prima host e gateway, poi reti e range — e la guida R82 indica di collocare le manuali sotto quelle automatiche già generate.

Proxy ARP e routing: quello che la regola manuale non fa

Con il NAT automatico il Security Gateway risponde al posto degli oggetti tradotti alle ARP Request che arrivano dalla rete esterna. Con il NAT manuale non lo fa. L’indirizzo tradotto non appartiene a nessuna interfaccia del gateway: se nessuno risponde, il router a monte non sa a quale MAC consegnare i pacchetti e il traffico non arriva, pur essendo la regola scritta correttamente. Va quindi configurata una voce di Proxy ARP che associa l’indirizzo tradotto al MAC dell’interfaccia del gateway sullo stesso segmento; in IPv6 l’equivalente è il Proxy NDP. La documentazione R82 segnala anche un caso in cui le voci non nascono da sole: i range tradotti di CGNAT.

Il secondo pezzo mancante è il routing: Proxy ARP risponde alla domanda «chi risponde per questo indirizzo», la tabella di routing a «dove mando il pacchetto una volta tradotto». Sono configurazioni distinte e una non implica l’altra.

Il Management Server dietro NAT

Un Management Server con indirizzo privato dietro un dispositivo NAT è un caso a sé: le connessioni che contano viaggiano in due direzioni opposte, SmartConsole che entra e i Security Gateway gestiti che riportano log e stato. Il server deve dichiarare l’indirizzo con cui il resto del mondo lo vede.

Si apre l’oggetto del Management Server in Gateways & Servers, pagina NAT: si spunta Add Automatic Address Translation rules, si sceglie Static come metodo, si inserisce l’indirizzo pubblico tradotto, si indica su quale Security Gateway o dispositivo non Check Point installare la regola e si decide quale indirizzo i gateway devono usare — quello originale, quello tradotto, oppure la scelta basata sulla topologia. L’opzione Apply for Security Gateway control connections estende il comportamento alle connessioni di controllo, ed è quella che serve quando il traffico di management attraversa un tunnel VPN. Infine si installa la Access Control Policy sui gateway coinvolti.

Il singolo gateway può sovrascrivere la scelta comune nella propria pagina NAT > Management / Log Servers. Due precisazioni della guida: la configurazione non è supportata su uno Standalone che riceve connessioni da fuori del dominio NATato, e per un Log Server dietro NAT la procedura è identica.

Trappole tipiche d’esame

  • La regola manuale corretta che non fa passare niente. È lo scenario che il vendore chiama «regole NAT definite male»: la riga è giusta, il traffico non arriva. Manca il Proxy ARP, o manca la rotta verso l’indirizzo originale. Se la domanda dice «automatic NAT funzionava, manual NAT no», la risposta sta quasi sempre in ARP, non nella traduzione.
  • Prima corrispondenza contro doppia corrispondenza. Una domanda che descrive due regole che matchano la stessa connessione si risolve sapendo se sono manuali o automatiche: le manuali si fermano alla prima, le automatiche possono applicarsi in coppia, sorgente e destinazione.
  • Hide NAT e le connessioni entranti. Hide NAT traduce solo la sorgente: pretendere che un oggetto nascosto riceva una sessione dall’esterno è il guasto che il vendore descrive. Per l’accesso entrante serve Static NAT.
  • Il Management cambia indirizzo e SmartConsole non entra più. Dichiarare la traduzione sull’oggetto non basta: va deciso con quale indirizzo i gateway raggiungono il server e, se il management passa in VPN, spuntata Apply for Security Gateway control connections. E la regola va installata sul dispositivo giusto.
  • Updatable Objects che restano fermi. Si aggiornano da soli, senza installare la policy: reinstallare la policy non è la cura. Servono invece Management Server e Security Gateway capaci di raggiungere il cloud Check Point — un gateway senza uscita diretta va fatto passare dal Management con il parametro ProxyRoute. Ricorda anche che un Updatable Object non si può inserire in un network group.