In questo articolo vedremo come “nattare” l’ip sorgente  in caso di NAT statico.  Lo schema che segue descrive uno scenario tipo in cui applicare questa soluzione.

Nello scenario descritto nella figura qui sopra  abbiamo un’ azienda con più sedi (qui per semplicità ne ho evidenziata solo una) e due connettività internet (A e B). La connettività A è la principale ed è quella usata per la pubblicazione  dei servizi (posta, www, ecc .) messi in una server-farm in screened zone (DMZ). La screened zone è gestita da un firewall (nei miei test ho usato ISA/TMG di microsoft) e la connettività B è gestita da un router Cisco (nei miei test ho usato un 1841).

E se volessimo usare la INTERNET B come backup per la pubblicazione dei servizi, sarebbe possibile ?

Con un semplice NAT statico operato sul Cisco 1841 (INTERNET B) la risposta è NO. Il traffico proveniente dalla internet B verrebbe bloccato dal firewall che gestisce la DMZ, perché considerato spoofing. Andiamo più nel dettaglio.

Nella sede A, il firewall ha tre schede di rete :

1)      LAN: tutte le classi IP della LAN + WAN, così come dichiarate in LAT e quindi considerate TRUSTED

2)      DMZ: la classe IP (pubblica o privata e indifferente in questo contesto) considerata SCREENED

3)      INT: tutto il resto è considerato UNTRUSTED

Semplifichiamo al massimo un pacchetto IP (TCP) per analizzare solo i dati che ci interessano.

Quando il Client A richiede l’accesso ad uno dei servizi in DMZ (es. www) , il pacchetto IP che si presenta sulla INT A sarà del tipo :

Il firewall analizza la richiesta e accerta che sulla INT A (untrusted) arrivi un pacchetto IP (TCP) con un indirizzo IP UNTRUSTED. A questo punto è tutto normale e procede con la lavorazione del pacchetto, operando il NAT sulla destinazione ed inoltrando il pacchetto sulla DMZ.

Adesso analizziamo invece il pacchetto IP con NAT statico standard proveniente da CLIENT B

Il 1841 analizza la richiesta e accerta che sulla INT B (untrusted) arrivi un pacchetto IP (TCP) con un indirizzo IP UNTRUSTED. A questo punto è tutto normale e procede con la lavorazione del pacchetto, operando il NAT sulla destinazione ed inoltrando il pacchetto sulla DMZ.

Il pacchetto IP viene spedito  attraverso la WAN sulla interfaccia LAN del firewall, che provvederà a controllare se il pacchetto arriva da una sorgente TRUSTED. Ma Y.Y.Y.Y non è TRUSTED e il pacchetto verrà scartato perché considerato spoofing.

A questo punto entra in gioco la soluzione proposta in questo articolo: sostituzione dell’ip sorgente con uno trusted. Riprendendo  la connessione del client B  sulla porta 80:

Il 1841 analizza la richiesta e accerta che sulla INT B (untrusted) arrivi un pacchetto IP (TCP) con un indirizzo IP UNTRUSTED. Tutto  è normale e procede con la lavorazione del pacchetto, operando il NAT sulla destinazione.

Prima di inoltrarlo, però, opera un secondo NAT, questa volta sull’ip sorgente.

Il pacchetto IP viene spedito  attraverso la WAN sulla interfaccia LAN del firewall, che provvederà a controllare se il pacchetto arriva da una sorgente TRUSTED. L’ip 192.168.2.x è TRUSTED perché appartiene alla classe IP della sede periferica ed è presente nella LAT del firewall. Il pacchetto verrà inoltrato al server WEB nella DMZ.

A questo punto, si potrà utilizzare la connessione ad internet della sede B come eventuale backup di emergenza per l’accesso ai servizi in server-farm nella sede A.

Bene, ora entriamo nel merito della programmazione del nostro router Cisco :

Definiamo il NAT statico per la pubblicazione del servizio :

ip nat inside source static tcp 192.168.0.3 80 2.2.2.2 80

Definiamo una access list che poi useremo per matchare il traffico  tramite la route-map.

access-list 101 permit tcp any host 2.2.2.2 eq http

Definiamo una route-map che intercetti il traffico definito dalla access-list 101 :

route-map MATCH_AL_101  permit 10

 match ip address 101

Definiamo un pool di IP TRUSTED da utilizzare per la sostituzione dell’ip sorgente :

ip nat pool LAN_B 192.168.2.100 192.168.2.110 prefix-length 24

Definiamo la NAT per la sostituzione dell’ip sorgente :

ip nat outside source route-map MATCH_AL_101  pool LAN_B add-route

A questo punto il nostro router è pronto. Ma vediamo un debug per verificare le sostituzioni :

La richiesta da y.y.y.y arriva sulla WAN del router :

*Aug 20 09:33:42.459: NAT: o: tcp (y.y.y.y, 34710) -> (2.2.2.2, 80) [22970]

Viene operato il NAT del sorgente con il primo IP definito nel pool

*Aug 20 09:33:42.459: NAT: s=y.y.y.y->192.168.2.100, d=2.2.2.2 [22970]

Viene operato il NAT statico :

*Aug 20 09:33:42.459: NAT: s=192.168.2.100, d=2.2.2.2->192.168.0.3 [22970]

Il pacchetto è stato inoltrato al server web che risponde alla richiesta :

*Aug 20 09:33:42.483: NAT: i: tcp (192.168.0.3, 80) -> (192.168.2.100, 34710) [4216]

Conclusioni :

Questa soluzione è stata realizzata in laboratorio e non è mai stata testata in un ambiente di produzione. Tempo permettendo, nei prossimi giorni, conto di testarla in un ambiente di produzione in modo da verificare eventuali anomalie di funzionamento e vi aggiornerò sui risultati. Nel frattempo mi sento di raccomandarvi di considerarla solo come una soluzione a scopo didattico.