Login

Benvenuto, Ospite
Nome utente: Password: Ricordami
  • Pagina:
  • 1

ARGOMENTO:

Istanze Nat attive, pool acl e feature accessorie. 8 Anni 11 Mesi fa #1

  • roberto ulisse
  • Autore della discussione
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
Salve,
dall'osservazione dei comandi studiati per la configurazione del nat vengono spontanee alcune considerazioni, e cioe' che l'entita' nat che opera su un router deve essere unica perche' i comandi ip nat inside ed ip nat outside non vanno a specificare nulla se nn l'interfaccia alla quale si applicano attraverso il meccanismo che siottene "spostandosi" sull'interfaccia scelta e poi dando il comando che viene applicato ad essa, quindi sccome i comandi ip nat {inside|outside} non prevedono alcun parametro risulterebbe che implcitamente essi si rifericano all'unica entita' attiva, se fosse possibile avere piu' di una entita' nat attive non oso pensare quali potrebbero essere le discriminanti per le associazioni, quindi pare che l'entita' nat attivabile debba essere unica, e' vero?
Se e' vero (che l'entita' nat e' unica nei router cisco) e in considerazione che ad una interfaccia inside la sottorete e' continua negli indirizzi ( o no') allora mi chiedo che senso ha lasciare la possibilita'' di spezzettare le accoppiate acl binds pool per poi ritrovarsele comunque tutte nelle stesse interfaccie, cosi facendo i puo' overlappare sia nelle acl che nei pool, e che succede, forse anche un'overlap ha un senso speciale? forse quegli ip inside local che overlappano possono accedere ad ambedue i pool mentre gli inside global dei pool che overlappano sono messi a disposizione di ambedue le acl?
Queste considerazioni sorgono automaticamente, se il packet tracer fosse affidabile nche come strumento predittivo io farei ina autonmia le mie prove, purtroppo non e' cosi, quindi devo sottoporre alla vostra attenzione queste considerazioni:
Grazie :) per le risposte che mi saprete dare.

Si prega Accedi a partecipare alla conversazione.

Istanze Nat attive, pool acl e feature accessorie. 8 Anni 11 Mesi fa #2

  • instructor
  • Offline
  • Administrator
  • Administrator
  • Messaggi: 1385
  • Ringraziamenti ricevuti 172
Potrei avere un router con 4 interfacce, 2 inside e 2 outside.

Potrei quindi avere due regole di nat del tipo
ip nat inside source ACL1 pool POOL1 overload (dove la ACL1 fa match solo del traffico della LAN1 e viene tradotto sul POOL1 )

ip nat inside source ACL2 pool POOL2 overload (dove la ACL2 fa match solo del traffico della LAN2 e viene tradotto sul POOL2 )

Oppure potresti avere una traduzione della stessa LAN1 differente per interfaccia.
ip nat inside source ACL1 int s0/0 overload
ip nat inside source ACL1 int s0/1 overload

Quello che invece su IOS non si può fare è decidere che la LAN1 venga tradotta in maniera differente sull'intefaccia1 o sull'interfaccia2 in base a pool differenti

Si prega Accedi a partecipare alla conversazione.

Istanze Nat attive, pool acl e feature accessorie. 8 Anni 11 Mesi fa #3

  • roberto ulisse
  • Autore della discussione
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
Vediamo se ho capito bene,
prima pero' vorrei mettere alcuni puntini sulle i su alcune grossolane approssimazioni che ho usato fare in passato nell'uso dei termini processo ed entita' e vorrei appunto precisare che il processo un'attivita "fisica" (segnali elettrici interrupt scritture in memoria ecc,.. ecc..) definita da un programma e che sta girando in un elaboratore mentre le entita' sono quei processi che dialogano con un'altro processo (entita' corrispondente) che girano in un'altro elaboratore e che in genere derivano runtime dallo stesso programma (quindi un delirio allo specchio :P ); pertanto secondo questa definizione il termine entita' attribuito all'oggetto NAT se usato da me in passato lo considero errato, il NAT, in un contesto mio razionale, si materializza come processo e non come entita', mi sbaglio o c'e' una quache cosa particolare che fa comunicare le entita' nat tra loro, o ci sono dei vincoli di design che impongoo al nat la natura di processo? (i.e. se qualcuno si inventasse un nat intelligente che per operare dovesse farsi configurare da una entita' di management protocollare integrata nel nat stesso questo nuovo oggetto si chiamerebbe ancora nat oppure dovrebbe essere assimilabile ad un qualche oggeto di nuova natura e quindi ad altro?).
Fatta questa, per me importante precisazione, passo alle considerazioni e vediamo se ho recepito bene quanto mi hai gentilmente spiegato.
Nella prima parte in pratica dici che di processi :P nat attivi ce ne possono essere piu' di uno e che l'associazione delle regole avviene atraverso il match tra le acl appartenenti alla regola di binding e la sottorete configurata sull'interfaccia, quindi con un meccanismo analogo a quello utilizzato quando col comando network si bindano (collegano) le interfaccie all'entita :P di routing attiva nel router, quindi cio' avviene implicitamente, e comunque questo era il meccanismo che temevo, perche' e' veramente molto farraginoso, vabbe' questa e' una mia considerazione.
La seconda parte e' meno chiara e cioe' quando scrivi:
" Oppure potresti avere una traduzione della stessa LAN1 differente per interfaccia.

ip nat inside source ACL1 int s0/0 overload
ip nat inside source ACL1 int s0/1 overload"
cosa intendi dire che le associazioni inside-local:porta <-> inside global: porta avvengono distribuendo gli accessi alla rete outside con una modalita' bilanciata sulle interfaccie, cioe' il nat fa lavorare tutte e due le interfaccie secondo un suo criterio, magari a blianciamento di carico (se ci riesce)?
L'ultima frase non l'ho capita "Quello che invece su IOS non si può fare è decidere che la LAN1 venga tradotta in maniera differente sull'intefaccia1 o sull'interfaccia2 in base a pool differenti "

Certo che la situazione e' ingarbugliata,
a proposito ed in relazione a questa immagine


che descrive le modalita' di configurazione del nat ritengo in base a cio' che io risco ad elaborare che ci sia una ridondanza nella definizione che, sulla base del modello, che io conosco di nat,, non riesco a giustificare e cioe' che lo step 4 e' inutile ridondanza di quanto gia' espresso nello step 2, oltre a questo non riesco a capire che necessita' esista, se non quella di volersi complicare la vita inutilmente :P , nel creare batch di comandi differenziati quando il caso dell'ip unico e' gia contemplato e ritengo ben risolto con la modalita che vede definire un pool con un solo indirizzo ip, o mi sbaglio?
Grazie per le risposte che mi saprai dare.


dove sono descritti
Allegati:

Si prega Accedi a partecipare alla conversazione.

Istanze Nat attive, pool acl e feature accessorie. 8 Anni 11 Mesi fa #4

  • instructor
  • Offline
  • Administrator
  • Administrator
  • Messaggi: 1385
  • Ringraziamenti ricevuti 172
Provo a spiegarmi meglio.

E' possibile tradurre la stessa porzione di rete (nel precedente ho detto LAN per semplicità immaginando un ambiente SOHO), questa porzione di rete la puoi selezionare con una ACL.
Poi puoi decidere che la stessa porzione di rete possa essere tradotta con indirizzi global differenti utilizzando interfacce differenti del router, chiaramente utilizzando il nat overload.

Quello che non puoi fare è anche dando due comandi di seguito è decidere quando la stessa porzione di rete intercettata dall'ACL venga tradotta con il POOL1 e quando con il POOL2, perchè anche dando i comandi di seguito di fatto viene utilizzato sempre il primo perchè si procecde in ordine.

ip nat inside source list ACL1 pool POOL1
ip nat inside source list ACL1 pool POOL2

Il comando ip nat inside source ACL int INTERFACE rappresenta una ridondanza di informazioni, ma per mantenere coerenza con la configurazione più generale
ip nat inside source ACL pool POOL dove effettivamente non viene individuata alcuna interfaccia di outside.

Aggiungo che esiste un modo alternativo per configurare il NAT che è forse più logico, ma questo è fuori dallo scopo del corso.
Ringraziano per il messaggio: roberto ulisse

Si prega Accedi a partecipare alla conversazione.

Istanze Nat attive, pool acl e feature accessorie. 8 Anni 11 Mesi fa #5

  • roberto ulisse
  • Autore della discussione
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
Quindi se ho capio bene configurando due bind della stessa acl su due interfaccie differenti verra' comunque utilizzata come inside global sempre nell'ordine la prima configurata, ovviamente fino ad esaurimento del limite della 4000 porte, e solo successivamente si passera' alla seconda interfaccia con le altre 4000 porte disponibili.
Sinceramente non riesco a capire quando scrivi: "Il comando ip nat inside source ACL int INTERFACE rappresenta una ridondanza di informazioni, ma per mantenere coerenza con la configurazione più generale ip nat inside source ACL pool POOL dove effettivamente non viene individuata alcuna interfaccia di outside." parli di mantenimento di coerenza,a mio parere coerenza vorrebbe che il caso particolare si riconducesse a quello generale e se ne discostasse solo per esprimere qualcosa di sostanzialmente differente, ma a quanto pare non c'e' nulla di differente,tra il caso generale e quello particolare, se non un'ulteriore limite che e' solo conseguenza e non causa/motivo e che viene dal fatto che indicando le interfaccie al posto degli ip si vengono a perdere le possibilita di accedere in telnet per il management del router (cosi come abbiamo concluso essere di fatto in qualche topic precedente).
So che ti sto facendo lavorare e ti ringrazio veramente dell'impegno in profondita', a mio parere operare in un contesto tecnologicamente avanzato impone un'atteggiamento orientato alla qualita' e la qualita' si costruisce sul rigore e mai sulla approssimazione, o meglio se si fa approssimaione anche questa approssimazione e' controllata valutata e validata da qualcuno che ha controllato che comunque si chiuda in coerenza.
Capisco anche che spesso e' difficile mettere in sintonia le necessita' di carattere didattico edi limiti dei "programmi di studio" con le emergenze (intese come emergere) di domande e chiarimenti quando purtroppo si e' legati da logiche limitanti.
Ti ringrazio delle eventuali ulteriori indicazioni che mi saprai dare.

Si prega Accedi a partecipare alla conversazione.

Ultima Modifica: da roberto ulisse. Motivo: chiarimento

Istanze Nat attive, pool acl e feature accessorie. 8 Anni 11 Mesi fa #6

  • roberto ulisse
  • Autore della discussione
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
p.s. probabilmente per me sarebbe stato piu' facile proficuo e veloce capire il nat studiandolo secondo quella modalita' alternativa che hai accennato in conclusione del post quando ha scritto: " Aggiungo che esiste un modo alternativo per configurare il NAT che è forse più logico, ma questo è fuori dallo scopo del corso. " . Chissa he tutte queste domande non nascano dall'impatto che ha proprio questa metodolgia di presentare le cose che male si adatta al mio metodo di analisi e razionalizzazione delle questioni tecniche che e' consolidato ed e' il mio piu' grande patrimonio che ho maturato in 40 anni, perche' io sono 40 anni che ragion secondo lgi schemi che in qualche modo si evincono dai post e che ho cercato di proporre, chiudere in coerenza per me e' sempre significato mettere ordine secondo questa mia logica interpretativa e secondo i metodi ed i modelli che in 40 anni ho costruito, secondo questa mia lavagna virtuale nella quale non c'e' nessuna confusione ma ogni parola termine definizione hail suo posto preciso e definito, ed in questa logica il processo di apprendmento e' il transitorio dopo il quale tutto converge =D :P ed assume consistenza, credimi e' na faticata, ma sono abituato da sempre faccio cosi.

Si prega Accedi a partecipare alla conversazione.

Ultima Modifica: da roberto ulisse.

Istanze Nat attive, pool acl e feature accessorie. 8 Anni 11 Mesi fa #7

  • instructor
  • Offline
  • Administrator
  • Administrator
  • Messaggi: 1385
  • Ringraziamenti ricevuti 172
Figurati Roberto, capisco che sei una persona che ama spaccare il bit in 4 e se posso essere utile ne sono contento.

Mi spiego meglio,
la configurazione nat segue questa logica:

1.definire il traffico che si intende tradurre con ACL
2.definire il pool di traduzione (con quali indirizzi si intende tradurre, indirizzi tradotti)
3.definire il binding tra ACL e POOL
4.definire le interfacce interne ed esterne con ip nat inside/outside

per mantenere coerenza tra le diverse implementazioni nat si eseguono sempre tutti e 4 questi passi, anche nel caso in cui lo step 3 sia
ip nat inside source ACL interface INT overload
anche se concordo che nel comando è implicitamente contenuto un "ip nat outside".

Considera tuttavia che la mia risposta si basa su una supposizione perchè le implementazioni non sempre vengono giustificate e commentate dal vendor, per capire quali siano i motivi storici e tecnici di questa scelta bisognerebbe avere contatto con il team di sviluppo della funzionalità. Tuttavia rispetto alla mole di funzionalità e tecnologie esistenti dobbiamo trovare una sintesi per riuscire ad avere il tempo in una vita di impararne almeno l'1%, cioè arrivare a capire come le cose funzionano, con un livello di dettaglio che possiamo reputare adeguato rispetto ai nostri scopi.

I nostri scopi possono essere far funzionare una rete o superare un esame di certificazione o semplice amore di conoscenza, che credo sia il tuo caso (anche se spero supererai l'esame di certificazione).
Tuttavia in questo terzo caso spesso dobbiamo arrenderci all'evidenza del fatto che non abbiamo abbastanza informazioni perchè il codice rimane segreto, tuttavia ci viene in qualche modo garantito il rispetto delle rfc, e quelle sono il nostro faro.

Si prega Accedi a partecipare alla conversazione.

  • Pagina:
  • 1
Moderatori: jpalombi