ARGOMENTO:

Salve,
nell'esercizio 11.2.1.4 Packet Tracer qui la topografia:



in base a considerazioni sull'output di questo comando:



considerate che il comando ha dato quell'output dopo che io ho aperto una pagna web dal pc1 verso
64.100.50.1,

Inoltre essendo questo o show run:



e considerate che l'interfaccia s0/0/0 che rappresenta la inside global ha anche indirizzo 209.165.128.130/29 (e perche' non /30?) come si giustifica ilfatto che nello sh ip nat trovo 209.165.128.129 e non il 10.0.37.205 che e' l'indirizzo globale dal quale e' partita la richiesta e li dve i messaggi devono arrivare alla fine, si puo' attribuire questo fatto alla presenza di un ulteriore NAT o anche di un PROXY tra la interfaccia OUTSIDE di R1 ed il client pc1?
Oltre a questo fatto io naturalmente avrei impostato come inside global l'indirizzo della interfaccia s0/0/0 che e' 209.165.128.130 (ho provato a farlo e funziona tutto pare) perche' nell'esercizio si e' usato un ip differente? forse per farmi capire che possono esserci piu' ip differenti? Magari perche l'ip dell'interfaccia del router puo' essee utile per fare le sessioni ssh per il management?
Allego l'esercizio con ambedue le configurazioni,



al server si accede sia attraverso l'ip 172.16.16.1 che attraverso l'ip 209.165.128.130.
impostando il nat sul .130, sul router non si potra fare gestione attraverso l'interfaccia .130?
C'e' veramente un proxy or un nat in mezzo?

un'ultima cosa, il processo di nat per come lo vedo io e' simmetrico, cioe' dalle due reti (inside ed outside) ogni host vede degli ip che sono immagine degli host raggiungibili nell'altra rete, possiamo affermare che quindi non esiste differenza sostanziale nel comportamento del nat nei due versi e che quindi il temine inside ed outside siano intercambiabili?
Si puo' dire che il nat e simmetrico, o c'e' qualche differenza?
Ho visto con l'help in packet tracer che al comando ip nat puo' seguire la parola inside oppure outside, cosa significa?
Grazie delle risposte che saprete dare.

roberto ulisse ha scritto: e considerate che l'interfaccia s0/0/0 che rappresenta la inside global ha anche indirizzo 209.165.128.130/29 (e perche' non /30?)

L'ISP potrebbe averti assegnato 5 indirizzi pubblici, quindi potrebbe essere che l'ISP abbia il .129, ma a te vengano assegnati dal 130 al 134, potresti decidere autonomamente quali utilizzare per il NAT magari overload e quale per l'indirizzo di interfaccia.

roberto ulisse ha scritto: come si giustifica ilfatto che nello sh ip nat trovo 209.165.128.129 e non il 10.0.37.205 che e' l'indirizzo globale dal quale e' partita la richiesta e li dve i messaggi devono arrivare alla fine, si puo' attribuire questo fatto alla presenza di un ulteriore NAT o anche di un PROXY tra la interfaccia OUTSIDE di R1 ed il client pc1?

Esattamente, effettivamente l'indirizzo del PC1 non è ruotabile quindi deve essere nattato, probabilmente sul suo default gateway (data la nuvola questo non può dirsi con esattezza). Quindi su R1 vedi il PC1 con il suo indirizzo Inside-Global che per R1 è l'indirizzo Outside-Global o Outside-Local.

roberto ulisse ha scritto: perche' nell'esercizio si e' usato un ip differente? forse per farmi capire che possono esserci piu' ip differenti? Magari perche l'ip dell'interfaccia del router puo' essee utile per fare le sessioni ssh per il management?

Esattamente, se utilizzi l'indirizzo di interfaccia per fare NAT statico o Port Forwarding perdi l'accesso al router stesso per l'intero IP o per le porte su cui hai fatto il forwarding, quindi in ambiente enterprise dove hai disponibilità di un pool di ip pubblici statici se evita di fare traduzione usando l'IP di interfaccia.

roberto ulisse ha scritto: al server si accede sia attraverso l'ip 172.16.16.1 che attraverso l'ip 209.165.128.130.
impostando il nat sul .130, sul router non si potra fare gestione attraverso l'interfaccia .130?
C'e' veramente un proxy or un nat in mezzo?

Se riesci ad accedere al server con il suo IP pubblico questa è da considerarsi una imprecisione dell'esercizio, evidentemente nella nuvola è stato configurato un routing di default che fa si che il server sia raggiungibile anche da suo indirizzo privato, questo ovviamente si discosta da una situazione reale nella quale gli indirizzi privati non sono ruotabili su internet.

roberto ulisse ha scritto: un'ultima cosa, il processo di nat per come lo vedo io e' simmetrico, cioe' dalle due reti (inside ed outside) ogni host vede degli ip che sono immagine degli host raggiungibili nell'altra rete, possiamo affermare che quindi non esiste differenza sostanziale nel comportamento del nat nei due versi e che quindi il temine inside ed outside siano intercambiabili?
Si puo' dire che il nat e simmetrico, o c'e' qualche differenza?
Ho visto con l'help in packet tracer che al comando ip nat puo' seguire la parola inside oppure outside, cosa significa?

Parlando di NAT Statico questo è effettivamente simmetrico, tuttavia il comando ip nat inside source <inside_local> <inside_global >dice che fai traduzione dell'ip sorgente inside_local sulla interfaccia inside, e dell'ip destinazione inside_global sull'interfaccia outside, quindi è importante istruire il router su cosa per te è inside e cosa è outside.

errata corrige, dove ho scritto" al server si accede sia attraverso l'ip 172.16.16.1 che attraverso l'ip 209.165.128.130." volevo invece dire cosi' "al server si accede sia attraverso l'ip 64.100.50.1 che attraverso l'ip 209.165.128.130"
nel senso che configurando un "doppio nat" con i comandi:
ip nat inside source static 172.16.16.1 64.100.50.1
ip nat inside source static 172.16.16.1 209.165.128.130
si ottiene l'effetto di rndere il serer raggiungibile con ambedue gli indirizzi,questo mi faceva riflettere che evidentemente il nat statico e' anche stateful, nel senso che ricorda in qualche modo chi ha instaurato la sessione verso il server, del resto se cosi non fosse avrebbe difficolta' a gestire due sessioni tcp provenient da server differenti, quindi ance il nat statico "maneggia" in qualche modo porte e stato delle sessioni e sequanzialita degli avvenimenti, nel senso che ragiona molto di piu' di quanto apparentemente pare essere sufficiente e cioe' una traduzione "combinatoria e non sequenziale" di indirizzi attraverso la tabella di associaione inside local con inside global.
Mi chiedo in questa situazione di configurazione particolare (e strana) del nat le richieste di sessione, o anche solo i semplici pacchetti udp, originati dal server nella rete inside con quale indirizzo si presentaranno nella rete outside con il 209.165.128.130 oppure con il 64.100.50.1?

Ok, in realtà posto che la configurazione come tu stesso dici è anomala, quindi fuori da ogni best practice, in realtà quello che succede è piuttosto strano:
- Il server è raggiungibile su entrambi gli indirizzi
- La traduzione al contrario però dovrebbe avvenire in ordine di configurazione, cosa che però a te non risulta, nel senso che le sessioni sembrano funzionare per entrambi gli indirizzi

Il punto è che il nat non è una funzionalità stateful, dammi qualche giorno per verificare il funzionamento su macchine reali, perchè posto che non ho mai provato una cosa del genere il risultato che mi aspetto è che outside2inside funzioni su entrambi gli indirizzi, inside2outside la traduzione dovrebbe avvenire sempre secondo la prima regola e quindi sessioni TCP verso la l'indirizzo di traduzione della seconda regola non dovrebbero funzionare.

Io ho fatto qualche prova con il packet tracer ed ho verificato che in questa configurazione anomala l'inside global viene preso un po uno ed un po l'altro, considera che ho fatto prove generando traffico di ping da server e pc, counque con lo show ip nat translation fa vedere un solo inside global come in figura, ma col packet tracer ste condizioni limite forse non sono sondabili, grazie delle risposte, ci aggiorniamo a quando avrai altre notizie.
Qui la print screen delle prove che ho fatto.



notte.

Ricordo che restava aperta una questione ancora da definire, e nella sostanza se il nat statico e' stateful o stateless, e la domanda sorgeva dall'osservazione che associando lo stesso inside local a due differenti inside global succedeva che in uscita la traduzione dell'inside local venga scelto sempre il primo inside global configurato mentre in ingresso succedeva che l'inside local veniva raggiunto da ambedue gli inside global e che le sessioni http su tcp si instauravano regolarmente consentendo a piu' di un host appartenente alla rete outside di accedere al server http e servire due sessioni contemporaneamente, questo fatto induceva che la natura del nat non fosse stateless ma stateful.

Non preoccuparti, non mi sono dimenticato, semplicemente non ho tempo. Ma appena posso andrò sugli apparati a verificare il comportamento.

L'ho riscritto sopratutto per risintetizzare, lo sforzo di sintesi dopo lo sforzo di analisi e' un po una soddisfazione, io ho sempre pensato che non esistono domande alle quali non c'e' risposta (anche se in realta' non e vero, in matematica se si e' coerenti non si e' completi a voler essere comleti si diventa incoerenti, e' l'errore in cui incappano le religion, pensare di essere complete e coerenti ....) ma se una frase e' una domanda allora c'e' sempre una risposta, il problema e' formulare frasi che siano domande compiute. Spesso un po ttti per approssimazione fretta ansia di risultato o esigenze di produttivita' tendiamo a trascurare la razionalizzazione di questo aspetto e passiamo a chiedere senza neanche rifettere bene se la dmanda e' ben posta.
Tutto qui, le cose manmano entrano ne uzzle e trovano il loro posto, ma la via e' dura, e' sempre stata dura.

Ecco la risposta alla questione che dibattevamo

Praticamente IOS va in errore e non insierisce il comando in config perchè si tratta di una situazione non gestita.

Quindi e' un'errore (di approssimazione) del packet tracer, difatti era una delle prime cose che pensai quando verificai questa cosa cosi strana.
Grazie