Last updated on December 10, 2021
Blog ITA - Post 3
Questo laboratorio – attraverso l’uso contestuale dei comandi ip nat inside source e ip nat outside source – verra’ utilizzato per discutere il NAT order of operation, ovvero l’ordine con cui un NAT router processa i pacchetti che viaggiano in direzione:
- inside-to-outside
- outside-to-inside
Nel caso in cui non abbiate avuto modo di leggere la prima parte del post, vi invito a farlo utilizzando il seguente link: NAT per IPv4 (prima parte)
Scenario
David (Site A) ha la necessita’ di collaborare con un nuovo partner – l’azienda Masaryk sro (Site B) – per lo sviluppo di un gestionale di contabilita’ e fatturazione elettronica.
Tale esigenza richiede che vi sia connnettivita’ tra Site A e Site B. Sfortuna vuole che i due siti adottino lo stesso piano di indirizzamento IPv4: 10.10.0.0/16.
David decide di adottare il NAT sul suo border router (R1) e, non avendo a disposizione un network engineer in azienda, sceglie di muoversi in assoluta autonomia (dopo una notte insonne spesa sul web).
Ecco un estratto della configurazione di R1:
R1#sh run | i source
ip nat inside source static 10.10.11.1 192.0.2.254
ip nat outside source static 10.10.7.1 203.0.113.254
R1#show ip route | b Gate
Gateway of last resort is 192.0.2.2 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 192.0.2.2, GigabitEthernet0/1
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.10.1.0/24 is directly connected, GigabitEthernet0/0
L 10.10.1.1/32 is directly connected, GigabitEthernet0/0
S 10.10.11.0/24 [1/0] via 10.10.1.2, GigabitEthernet0/0
192.0.2.0/24 is variably subnetted, 5 subnets, 3 masks
C 192.0.2.0/30 is directly connected, GigabitEthernet0/1
L 192.0.2.1/32 is directly connected, GigabitEthernet0/1
C 192.0.2.32/29 is directly connected, GigabitEthernet0/3
L 192.0.2.33/32 is directly connected, GigabitEthernet0/3
L’esigenza di David e’ di fare in modo che:
- PC1 [10.10.11.1] venga visto come 192.0.2.254 all’interno del Site B
- PC7 [10.10.7.1] venga visto come 203.0.113.254 all’interno del Site A
- vi sia connettivita’ tra PC1 e PC7
Problema
David ed il suo partner riscontrano un problema di connettivita’ tra R2 ed R8.
Quando PC7 [10.10.7.1] prova ad effettuare un ping test verso PC1 [192.0.2.254], David ha modo di osservare quanto segue:
R1#sh run | i source
ip nat inside source static 10.10.11.1 192.0.2.254
ip nat outside source static 10.10.7.1 203.0.113.254
R1#debug ip packet detail
IP packet debugging is on (detailed)
R1#debug ip nat detailed
IP NAT detailed debugging is on
R1#
*Nov 29 16:12:55.317: NAT*: o: icmp (10.10.7.1, 2) -> (192.0.2.254, 2) [2]
*Nov 29 16:12:55.317: NAT*: s=10.10.7.1->203.0.113.254, d=192.0.2.254 [2]
*Nov 29 16:12:55.317: NAT*: s=203.0.113.254, d=192.0.2.254->10.10.11.1 [2]
*Nov 29 16:12:55.319: NAT*: i: icmp (10.10.11.1, 2) -> (203.0.113.254, 2) [2]
*Nov 29 16:12:55.319: NAT*: s=10.10.11.1->192.0.2.254, d=203.0.113.254 [2]
*Nov 29 16:12:55.319: NAT*: s=192.0.2.254, d=203.0.113.254->10.10.7.1 [2]
*Nov 29 16:12:55.404: IP: s=192.0.2.254 (GigabitEthernet0/1), d=10.10.7.1, len 100, input feature
< output omitted >
*Nov 29 16:12:55.407: FIBipv4-packet-proc: route packet from GigabitEthernet0/1 src 192.0.2.254 dst 10.10.7.1
*Nov 29 16:12:55.408: FIBfwd-proc: packet routed by adj to GigabitEthernet0/1 192.0.2.2
*Nov 29 16:12:55.408: FIBipv4-packet-proc: packet routing succeeded
< output omitted >
R1#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
--- --- --- 203.0.113.254 10.10.7.1
icmp 192.0.2.254:3 10.10.11.1:3 203.0.113.254:3 10.10.7.1:3
--- 192.0.2.254 10.10.11.1 --- ---
NAT Order of Operations
Condivido con voi una domanda che spesso mi viene rivolta:
Cosa avviene prima, il NAT oppure il Routing ?
Sfortunatamente, la risposta propinata dal sottoscritto e’ sempre la stessa:
DIPENDE !!!
Ebbene si, cari lettori, dipende dalla direzione del flusso dati:
- CASO inside-to-outside:
- I step: Routing
- II step: NAT (traduzione local-to-global)
- CASO outside-to-inside:
- I step: NAT (traduzione global-to-local)
- II step: Routing
Per chi fosse alla ricerca di una classificazione piu’ specifica, eccovi serviti:
Significato dei comandi "ip nat inside source" e "ip nat outside source"
Prima di procedere con la disamina del debug e la risoluzione del problema, ritengo utile richiamare il significato dei comandi NAT implementati su R1:
ip nat inside source
- Traduce il SOURCE IP address dei pacchetti che viaggiano in direzione inside-to-outside (pacchetti in inbound sulla inside interface)
- Traduce il DESTINATION IP address dei pacchetti che viaggiano in direzione outside-to-inside (pacchetti in inbound sulla outside interface)
ip nat outside source
- Traduce il SOURCE IP address dei pacchetti che viaggiano in direzione outside-to-inside (pacchetti in inbound sulla outside interface)
- Traduce il DESTINATION IP address dei pacchetti che viaggiano in direzione inside-to-outside (pacchetti in inbound sulla inside interface)
Analisi del debug eseguito su R1
Ricordiamo i due NAT statici configurati:
- PC1 [10.10.11.1] viene visto come 192.0.2.254 nel Site B
- PC7 [10.10.7.1] viene visto come 203.0.113.254 nel Site A
Da una disamina accurata del debug eseguito su R1, e’ possibile concludere quanto segue:
- flusso dati ricevuto sulla outside interface (Gi0/3)
- l’ICMP packet giunge con source IP 10.10.7.1 e destination IP 192.0.2.254
- il NAT viene eseguito PRIMA del routing:
- il source IP viene correttamente tradotto: s=10.10.7.1->203.0.113.254
- il destination IP viene correttamente tradotto: d=192.0.2.254->10.10.11.1
- R1 fa routing sulla base del destination IP 10.10.11.1
- R1 fa forwarding del pacchetto sulla interfaccia Gi0/0
- flusso dati ricevuto sulla inside interface (Gi0/0)
- l’ICMP packet giunge con source IP 10.10.11.1 e destination IP 203.0.113.254
- il routing viene eseguito PRIMA del NAT:
- R1 fa routing sulla base del destination IP 203.0.113.254
- R1, a seguito della traduzione NAT, fa forwarding del pacchetto sulla interfaccia Gi0/1 (mentre PC7 e’ raggiungibile attraverso l’interfaccia Gi0/3)
Effettuando un packet capture sulla interfaccia Gi0/1 di R1, e’ possibile verificare la presenza di echo reply erroneamente inviati verso il router ISP:
Il debug, del resto, lo aveva evidenziato:
*Nov 29 16:12:55.407: FIBipv4-packet-proc: route packet from GigabitEthernet0/1 src 192.0.2.254 dst 10.10.7.1L’errore commesso da David non sta nell’implementazione del NAT, bensi’ nella mancanza di competenza sul tema NAT order of operation !
Soluzione
David si rivolge ad un vecchio compagno di baldoria – Alex, conosciuto come Papuf – giovane vizioso e scapestrato, un network engineer di talento.
” Papuf, ho un problema in azienda. Mi serve il tuo aiuto ! “.
Il buon Alex decide di aiutare l’amico in difficolta’.
Dopo un attenta analisi, Alex comprende che e’ sufficiente modificare il routing su R1, cosi’ da consentire una corretta connettivita’ tra PC1 e PC7.
R1(config)#ip route 203.0.113.254 255.255.255.255 gi0/3 192.0.2.34
Ne deriva che:
Punto 1
Il ping test effettuato da PC7 verso l’indirizzo 192.0.2.254 va a buon fine. Il packet capture sul link R1-R7 conferma quanto appena asserito:
Punto 2
il ping test effettuato da PC1 verso l’indirizzo 203.0.113.254 va a buon fine. Il packet capture sul link R1-R7 conferma quanto appena asserito:
David ha capito che un network engineer puo’ sempre essere d’aiuto !!!
