Newsgroup: it.comp.reti.cisco
Titolo: logica delle VPN

Salve Signori,
spero mi perdonerete se chiedo aiuto a voi (dei ng riguardanti le reti 
posso affermare che qui ci sono le punte di diamante) per questioni che 
si spingono un attimino prima dell'IOS o degli apparati in se per se.
ho cercato a lungo, ma ho trovato solo spiegazioni commerciali e, ancor 
peggio, solo spiegazioni tecniche incomplete. Mi servirebbe sapere 
qualche fondamento sulle VPN:
immaginiamo lo scenario:
LAN1
192.168.1.x
terminatoreVPN1 (che sia un firewall o un altro apparato che fa solo quello)
interfaccia in 192.168.1.1
interfaccia out 192.168.100.1
ovviamente in NAT MAP
router1
192.168.100.2
dall'altra parte contestualmente attraverso internet
LAN2
192.168.2.x
terminatoreVPN2
int in 192.168.2.1
int out 192.168.100.1
nat map
router2
192.168.100.2
- è uno scenario plausibile e corretto?
- la condizione fondamentale, diciamo la regola d'oro è:
----- che i due terminatori si debbano poter pingare
----- che la chiave condivisa e i protocolli utilizzati nella 
crittografia siano identici
----- che gli apparati siano compatibili (in questo caso diciamo uguali)
----- che le reti locali siano diverse
- nel momento in cui si alza la vpn, un terminale in una rete vede 
tranquillamente uno nella rete "remota"?
- se il terminatore 1 mi chiede "netwok remota" sarà 192.168.2.0 o 
192.168.100.0 ?
- se il terminatore 1 mi chiede "ip del terminatore 2" sarà l'ip 
pubblico dell'altra rete, oppure l'ip locale del terminatore 2?
- SUL ROUTER NON DEBBO FARE NULLA? (immaginiamo che ci sia un altro 
apparato dietro il router che alza le vpn, e non il router stesso) non 
ci sono porte da aprire? o protocolli da abilitare? o nat da fare?
io sull'affermazione "che le LAN siano diverse" mi chiedo: è una 
condizione assoluta o un consiglio (per evitare broadcast e traffico 
inutile su banda stretta)?
per ora basta :)
grazie in anticipo.


E' una condizione assoluta, le vpn comunque "ruotano" i pacchetti e non è 
possibile ruotare trafffico tra due lan della stessa classe, ovviamente 
esiste la possibilità di bypassare il problema con il nat, facendo in modo 
che due lan della stessa classe si possano vedere per il semplice fatto che 
ciascuna vede l'altra tramite indirizzi fittizi.
Ciao,
         Tosh. 

 meno.
grazie tosh, gentilissimo. ti chiedo un'ultima cosa: se il router sta in 
   NAT MAP (tutti ad uno) può creare problemi? tutto sommato riconosce 
che l'ip del terminatore vpn sta generando dei pacchetti e li 
reindirizza verso di esso, giusto? oppure debbo modificare il nattaggio, 
mettendo l'ip del terminatore direttamente pubblico?
grazie!


Dipende dai terminatori, se questi gestiscono quello che cisco chiama "nat 
traversal", vale a dire l'incapsulamento automatico dei pacchetti ipsec in 
pacchetti udp o tcp, allora puoi posizionarti tranquillamente dietro ad un 
nat o ad un pat (che dovrebbe essere quello che tu chiami "tutto ad uno") 
senza problemi.
Se invece i terminatori non gestiscono il nat traversal devi metterli 
direttamente su ip pubblico o fare un nat 1:1 sui router, in questo ultimo 
caso devi assicurarti che i router upstream siano in grado di nattare 
correttamente i pacchetti ipsec e puoi usare solo esp come payload ipsec, 
che è comunque ormai lo standard.
Ciao,
        Tosh. 

 
PPTP
dato che comunque di vpn si tratta, ho provato anche questo tipo.
ho provato ad alzare una pptp, se mi autentifico da locale sul 
terminatore, tutto ok. se passo dall'esterno (ovviamente utilizzando una 
connessione diversa) non entro sul terminatore.
con ethereal leggo protocolli tipo:
PPP
L2TP
analizzando tutto questo, mi sembra di aver capito che il mio 827 (ecco 
cisco cosa centra!) deve essere indottrinato per trasferire il tutto al 
terminatore vpn, allora ho preso questa riga:
ip nat inside source static ??????
dunque non capisco, posso pattare solo TCP e UDP, per il resto come 
funziona?
mi sfugge qualcosa


PPTP non è pattabile, devi nattarlo (ip nat inside source static ....) ed il 
router deve essere sufficientemente recente da fare un nat compatibile con 
il pptp, inoltre devi accertarti di non avere access-list che ti bloccano il 
pptp stesso (tcp 1723) in ingresso ed il GRE in entrambe le direzioni.
Ciao,
         Tosh. 

 che è comunque ormai lo standard.
Io sapevo che il NAT traversal si abilitava quando c'era NAT appunto e non quando c'era un Nat 
diverso da quello 1:1. E poi non ho mai visto che puoi specificare la porta UDP sulla quale 
contattare il remote end-point.... o sì?In questo caso... link per favore
Alex

Io sapevo che il NAT traversal si abilitava quando c'era NAT appunto e non 
quando c'era un Nat
diverso da quello 1:1. E poi non ho mai visto che puoi specificare la porta 
UDP sulla quale
contattare il remote end-point.... o sì?In questo caso... link per favore
Da quanto ne so io il nat traversal attiva automaticamente l'incapsulamento 
di ipsec in udp sulla porta 4500 se rileva un qualunque tipo di nat, quello 
che volevo dire è che se NON hai il nat traversal ed i router upstream lo 
supportano, puoi fare un nat 1:1 e impostare i terminatori su ip privati.
Per quanto riguarda la porta, il nat traversal credo utilizzi la porta 4500 
e basta, ma esistono molti prodotti che supportano ipsec over udp (che non è 
lo stesso di nat traversal) e/o ipsec over tcp con la possibilità di 
configurare manualmente la porta.
Ciao,
         Tosh.