Problemino di FULL-NATTING

[marcoexo]

Ciao,

premetto che non sono un esperto di CISCO ios, solo recentemente ho configurato un 2811 per NAT/VPN.

Ho questo problema, che ho già risolto su un linux usato come router :

Ho alcuni host interni che devo raggiungere da fuori con connessioni ISP diverse.
Ho due accessi internet da due ISP, per garantire la ragiungibilità degli host questi dovevano essere sempre accessibili da due router separati (connessi ai due ISP).

Quindi ho configurato un router linux per consentire la raggiungibilità da fuori dell'host senza dover impostare nell'host il gw verso quel preciso router.

Questo in linux si fa premettendo ai pacchetti ricevuti l'indirizzo sorgente del router stesso :

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 151.100.100.105

dove 151.100.100.105 è l'ip interno del router.

Avrei bisogno di fare lo stesso in CISCO IOS, qualche suggerimento ?

In pratica il problema è questo : Se ora non imposto nell'host (es. Windows server) il router CISCO come gateway, ma quello di un altro router, perdo l'accesso da fuori col CISCO.... (ora ho usato il classico NAT overloading e NAT statico all'host, se imposto il GW al router, non ho problemi...)

Grazie per i suggerimenti
Marco

[marcoexo]

bump...

Possibile che nessun 'Wizard' della rete abbia una soluzione ?

Rimango in stato 'Still waiting', grazie !

Marco

[marcoexo]

Aggiungo alcune considerazioni al mio problema :

In effetti si tratta di 'Mascherare' la sorgente dei pacchetti con l'ip del router stesso, questo perchè secondo me accade questo :

se arriva una richiesta da fuori, il router trova la destinazione interna, natta l'indirizzo sorgente e si aspetta una reply.

Questa reply non arriva perchè il gw impostato sull'host è un altro che non sa cosa farsene del pacchetto di risposta (non trova associazioni valide nei suoi nat)

Quindi, mascherando la sorgente del pacchetto nattato (inserendoci direttamente l'ip del cisco) con l'ip stesso del cisco risolverei il problema perchè l'host risponderebbe direttamente a lui.

Ho provato nat inside e outside di tutti i tipi, ma proprio non so come fare questa cosa...

Marco

Marco

[Rizio]

Ti sei già dato la soluzione da solo: nè Cisco nè linux possono nattare qualcosa che non arriva loro (o meglio, che arriva con un indirizzo diverso da quello per cui hanno fatto nat).
L'unico modo che mi viene in mente è mettere in piedi il nat sui 2 router coinvolti in maniera che il primo natt sul secondo e il secondo natti sull'host ma anche se funzionasse davvero imho è una porcata tremenda.

Rizio

[marcoexo]

In realtà, questa soluzione sul router linux funziona benissimo, e modifica il source del pacchetto in modo corretto, (non devo mettere nessun gw nell'host)

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 151.100.100.105

semplicemente Natta la sorgente a 151.100.100.105 per tutto quello che esce da eth0 (rete interna con questo ip), siccome questo è un indirizzo di rete locale l'host lo raggiunge senza nessun gateway e quindi non dipende da cosa imposto come gw nell'host

Ora, io sto studiando come funziona il natting su cisco, e credo che questo sia un overload verso l'ip 151.100.100.105 giusto ?

in pratica devo nattare la sorgente dei pacchetti in uscita sulla rete locale in modo che corrisponda all'ip dell'host, ora se non metto come gw il router .201 nell'host .34 non lo raggiungo da fuori

La mia config ha un natting per consentire agli utenti accesso internet, e l'accesso da fuori ad un host interno

ip nat pool myovrld x.x.x.z x.x.x.z prefix-length 24
ip nat inside source list 100 pool myovrld overload
ip nat inside source static tcp 151.100.100.34 ppp x.x.x.k ppp extendable
access-list 100 permit ip 151.100.100.0 0.0.0.255 any

interface FastEthernet0/1
description $ES_LAN$$ETH-LAN$
ip address 151.100.100.201 255.255.255.0
ip nat inside

interface ATM0/IMA1.1 point-to-point
description $ETH-SW-LAUNCH$$INTF-INFO-FE 0/0$$FW_INSIDE$$ETH-WAN$
bandwidth 4096
ip address x.x.x.x 255.255.255.252
ip nat outside
ip virtual-reassembly
pvc 10/100
protocol ip x.x.x.y broadcast
encapsulation aal5snap
!

[Rizio]

In realtà, questa soluzione sul router linux funziona benissimo, e modifica il source del pacchetto in modo corretto, (non devo mettere nessun gw nell'host)

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 151.100.100.105

semplicemente Natta la sorgente a 151.100.100.105 per tutto quello che esce da eth0 (rete interna con questo ip), siccome questo è un indirizzo di rete locale l'host lo raggiunge senza nessun gateway e quindi non dipende da cosa imposto come gw nell'host

Perdonami ma questo, AFAIK è impossibile.
Se l'host da nattare (o gli host) non ha la macchina linux impostato come GW o non E' la stessa macchina linux, o non USA servizi che vengono PROXATI dalla macchina linux, iptables non pò nattare pacchetti che NON gli arrivano (in qualunque modo) tra 2 ip differenti.

La regola di iptable che hai scritto natta la sorgente di tutto ciò che esce dall'ethernet 0 nella tabella nat in fase di prerouting con questo ip 151.100.100.105, però concorderai con me che qualcuno i pacchetti che deve nattare li spedirà pure ad iptable, giusto?
Se l'host non si rivolge alla macchina che fà nat nessuno può nattare i suoi pacchetti.

Detto questo mi sembra che la config che hai scritto sia fondamentalmente corretta, l'hai provata?

Rizio

[marcoexo]

Con Linux la cosa funziona e spiego il perchè :

Correttamente, come dici tu, i pacchetti che il router linux fa uscire da etho verso la lan interna, 'avrebbero' un ip sorgente inside gobal nattato con ip globale.

L'istruzione postrouting di iptables, sostituisce questo ip con quello del router stesso, che per essere raggiunto dall'host non ha bisogno di gw perchè è sulla stessa lan.

L'host riceve il pacchetto e per il reply, -senza interrogare gw- spedisce il pacchetto sulla rete interna che viene prelevato da etho (151.100.100.105)

Ti assicuro che qui la cosa funzionabene da un paio di anni circa, quando lo configurai per la prima volta.

Gli host interni sono raggiungibili da due ISP indifferentemente, da due router diversi, il mio problema è che sto configurando un terzo router, ma questo è il 2811 CISCO...

Marco

[Rizio]

L'istruzione postrouting di iptables, sostituisce questo ip con quello del router stesso, che per essere raggiunto dall'host non ha bisogno di gw perchè è sulla stessa lan.

Questo se usi (o cerchi di usare) un suo servizio/demone/utility/ quellochetipare. Ti posso garantire che se tu metti 2 macchine in rete tra loro e su nessuna delle 2 definisci nessun gateway e non cerchi di raggiungere alcun servizio loro se ne fregano di vedersi via arp request. Giuro.
Poi possono entrare in gioco tanti meccanismi di auto discovery tipo quelli di bonjiur di apple o quelli introdotti da microsoft con winXP ma di base, nelle RFC del tcp non viene menzionato alcun servizio di auto-settaggio di gateway o simili.

L'host riceve il pacchetto e per il reply, -senza interrogare gw- spedisce il pacchetto sulla rete interna che viene prelevato da etho (151.100.100.105)

Scusa "riceve il pacchetto" come?! L'host che manda il pacchetto al "tuo linux che natta" dov'è stato informato ad utilizzare quella macchina? Se usa l'arp request è perchè l'ha richiesta non per un discovery generico! Anche le modalità di funzionamento dell'arp hanno delle regole ben definite.

Ti assicuro che qui la cosa funzionabene da un paio di anni circa, quando lo configurai per la prima volta.

Gli host interni sono raggiungibili da due ISP indifferentemente, da due router diversi, il mio problema è che sto configurando un terzo router, ma questo è il 2811 CISCO...

Marco

Purtroppo, per esperienza, in informatica il fatto che qualcosa funzioni significa solo che è meglio non toccarlo, nient'altro.

[marcoexo]

Questo se usi (o cerchi di usare) un suo servizio/demone/utility/ quellochetipare. Ti posso garantire che se tu metti 2 macchine in rete tra loro e su nessuna delle 2 definisci nessun gateway e non cerchi di raggiungere alcun servizio loro se ne fregano di vedersi via arp request. Giuro.
Poi possono entrare in gioco tanti meccanismi di auto discovery tipo quelli di bonjiur di apple o quelli introdotti da microsoft con winXP ma di base, nelle RFC del tcp non viene menzionato alcun servizio di auto-settaggio di gateway o simili.

Non mi dire che non hai mai connesso due pc con uno switch senza nessun router, stessa maschera stessa subnet, si parlano senza nessun gw... non scomodiamo l'auto discovery...

Scusa "riceve il pacchetto" come?! L'host che manda il pacchetto al "tuo linux che natta" dov'è stato informato ad utilizzare quella macchina? Se usa l'arp request è perchè l'ha richiesta non per un discovery generico! Anche le modalità di funzionamento dell'arp hanno delle regole ben definite.

Lo riceve perchè l'istruzione iptables sostituisce l'indirizzo sorgente, non la destinazione, che è già stata nattata verso quell'host.
Il pacchetto che arriva da fuori è già nattato e routato (clausola POSTROUTIING)

Purtroppo, per esperienza, in informatica il fatto che qualcosa funzioni significa solo che è meglio non toccarlo, nient'altro.

Faccio questo lavoro da quasi 30 anni L'informatica ma in particolare il networking da molti grattacapi, ma preferisco ritenere che sia tutto governato da leggi deterministiche...
Cerco di risolvere e cmq posterò i risultati dei miei esperimenti...

Marco

[Rizio]

Non mi dire che non hai mai connesso due pc con uno switch senza nessun router, stessa maschera stessa subnet, si parlano senza nessun gw... non scomodiamo l'auto discovery...

Si ma non è questo il caso di cui tiamo parlando me e te. Si vedono certamente ma se tu non dici ad un host di cercare l'altro il primo, non potrà utilizzare i servizi (E.g. lo SNAT) del secondo.

Lo riceve perchè l'istruzione iptables sostituisce l'indirizzo sorgente, non la destinazione, che è già stata nattata verso quell'host.
Il pacchetto che arriva da fuori è già nattato e routato (clausola POSTROUTIING)

Nope, la risposta è: lo riceve perchè l'host 1 glielo manda con il programma X che usa il protocollo Y, allora ci stà che venga (s)nattato, altrimenti no.

Faccio questo lavoro da quasi 30 anni L'informatica ma in particolare il networking da molti grattacapi, ma preferisco ritenere che sia tutto governato da leggi deterministiche...
Cerco di risolvere e cmq posterò i risultati dei miei esperimenti...

Non manco mai di rispetto alle persone più vecchie di me ma qui c'è qualcosa che tocca (o che per te è dato per assunto mentre io, che non conosco la tua realtà, non posso sapere), cmq aspetto l'esito delle tue prove per capire meglio.

In ogni caso le regole di nat che avevi postato mi sembravano formalmente corrette per quanto ne so io, vedremo il resto non appena hai risolto.

Ciao
Rizio

[marcoexo]

Ok Rizio, il dialogo è cmq sempre molto costruttivo e mi fa piacere intavolare discussioni che possono essere utili a tanti...

(A parte che mi hai dato del vecchio non miho offendo LOL.... ma anche tu a 48 suonati ti sentirai giovane come oggi....)

Forse non è chiaro il mio problema, ho trovato un link che lo spiega bene, si tratta della differenza fra HALF NAT e FULL NAT, evidentemente devo trovare un modo per implemetare il FULL NAT sul nostro 2811...

questa img da una idea chiarissima del problema che abbiamo
http://www.isaserver.org/img/upl/nlbser ... ge1218.gif

e questo è l'articolo relativo, dice come risolvere su un server ISA WINDOWS, è praticamente ciò che ho fatto sul router linux, cioè implemetare il FULL NAT verso l'host interno...

http://www.isaserver.org/tutorials/nlbserverpub.html

...to be contnued...
Marco

[Rizio]

(A parte che mi hai dato del vecchio non miho offendo LOL.... ma anche tu a 48 suonati ti sentirai giovane come oggi....)

Naaaa, era in senso lavorativo, non potrei mai altrimenti

Venendo a noi ho dato una scorsa rapida al doc che hai linkato, lì però viene menzionato NLB (che per Cisco può essere comparabile all'HSRP), cioè hai 2 macchine che, attraverso una sorta di meccanismo che potremmo comparare all'arp "poisoning" gestiscono un IP unico in comune.
Infatti, come immaginavo, anche nel post c'è il problema dei pacchetti di ritorno che non possono uscire perchè manca loro la rotta corretta verso il firewall che ha fatto precedentemente NAT dell'handshake, ed è proprio il problema che continuo a vedere nella ta configurazione e, che sappia io, è aggirabile solo definendo un default GW comune (che può essere l'IP in NLB/HSRP) oppure utilizzando un proxy applicativo (attivo o passivo).
Risolvere il problema con il FULL NAT credo sia corretto (anche se forse ti converrebbe capire se puoi mettere in cluster o in HSRP i 2 apparati, ma questa è un'altra ipotesi e magari parlando dei 28xx non tutto si può fare) però secondo me devi sempre far arrivare i pacchetti al router per potergli chiedere di nattarli.

Purtroppo non ho approfondito l'articolo perchè sono a corto di tempo e non conoscendo ISA server sarebbe stato mooolto lungo, però aspetto tue notizie così impariamo qualcosa di nuovo tutti e due....

Ciao
Rizio