Newsgroup: it.comp.reti.cisco
Titolo: Newbie delle VPN ha bisogno di un grosso aiuto. (lungo)

Salve a tutti, mi scuso sin da ora per il crossposting qui e sul
it.comp.ip-admin ma sono abbastanza disperato... :-(
Spero che anche essendo forse un pò OT qualcuno possa aiutarmi.
Passando al mio problema devo fare un paio di premesse:
Ho terminato da poco un corso CISCO presso una netacad alla fine del quale
era previsto uno stage di 3 settimane (15 gg
 lavorativi) presso una delle aziende che avevano aderito all'iniziativa.
Sono stato assegnato presso un ISP locale, non uno dei "grossi" tipo
infostrada o telecom, cmq molto importante qui nella mia regione. Al nostro
primo incontro (circa 10 gg fà), per definire cosa avrei fatto nella loro
azienda in queste 3 settimane, mi parlarono di lavorare ai backups della
loro server farm e di VPN. Sulle VPN in particolare mi dissero che avevano
in cantiere un progetto sulle VPN per poter fornire il servizio ai loro
clienti. Per come me ne parlarono pensavo che tra un backup e l'altro mi
avrebbero fatto vedere come si configurava una VPN.... mi sbagliavo di
grosso.... Cmq sia, nel frattempo mi sono certificato CCNA (il corso mi
preparava per questa certificazione) e da 3 giorni ho iniziato lo stage.
Il problema è nato dal primo giorno, ovvero al momento di assegnarmi le
mansioni che avrei dovuto svolgere. In pratica mi sono stati tolti i backups
e mi è stato chiesto di presentare un progetto generale sulle VPN da
presentare alla parte amministrativa dell'azienda e alla parte tecnica
strutturato in modo che i tecnici leggessero contenuto tecnico e
l'amministrazione contenuto più semplice e di facile comprensione. Sul
momento ero contento di quel compito ma adesso mi rendo conto che forse
avrei dovuto preoccuparmi fin da subito.... Perchè? Per 3 motivi principali:
1) Partivo senza la benchè minima conoscenza in materia di VPNs.
2) Da quello che mi hanno detto in questa azienda, dalle risposte che hanno
dato alle mie domande e da quello che ho potuto saggiare nell'ambiente le
cose sono 2: o ne capiscono meno di me in materia o mi stanno mettendo alla
prova, tra l'altro loro stessi affermano che non ne hanno sviluppate e che
non ne capiscono molto, dunque non sono solo mie supposizioni ma potrebbero
anche essere balle...
3) Non ho nessun supporto, ne qualcuno che ne capisca, ne un router ne un
libro sull'argomento, ho solo un pc e una connessione ad internet. Mi è
anche stato fatto capire che non c'è speranza di averne se non presentando
prima il progetto.
Andando a fondo mi è stato richiesto di:
1) Stendere un documento per l'amministrazione sulle vpn in generale che
fosse facilmente comprensibile
2) Stendere un documento tecnico particolareggiato da presentare all'area
tecnica
3) Discutere i protocolli e gli standars (questo punto a posteriori mi ha
stranizzato dato che non esistono degli standards nelle vpn da quello che ho
potuto studiare...)
4) Proporre 4 casistiche di offerta:
a) connessione punto-punto tra 2 sedi mediante adsl 256/128
b) connessione punto-punto tra 2 sedi mediante adsl 640/128
c) connessione punto-punto tra 2 sedi mediante adsl 1280/512 2048/512 o hdsl
d) connessione punto-multipunto tra una sede e 10 hosts connessi a internet
tramite dial-up o adsl (vpn software praticamente)
5) Sviluppare un sistema di backup per le linee principali su isdn. (almeno
questo lo so fare)
Ci sarebbero altri 3 punti che non ricordo precisamente ma non sono molto
importanti.
Altre richieste riguardano le macchine da utilizzare per le 4 offerte, non
devono essere necessariamente CISCO (<- leggi devo usare quasi
obbligatoriamente anche altri tipi di routers).
Un altro problema è sorto rispetto al tunnelling, io avevo proposto ipsec e
l2tp over ipsec dopo un pò di studi ma loro mi hanno parlato anche di
pptp.... su questo punto però se porto motivazioni valide credo di poterla
spuntare...
In definitiva i miei problemi principali sono: scegliere i metodi di
tunneling e studiarli; scegliere gli apparati (che dovrei anche essere in
grado di configurare per sommi capi...); fare il tutto in 12 giorni
lavorativi....
Come ho già detto per il tunneling la mia scelta era caduta su IPSec e L2TP,
ma onestamente oltre a IPSec non so cosa scegliere.. mi servirebbe un
protocollo tipo GRE o L2TP per poter eventualmente far viaggiare traffico
non IP ma non so cosa scegliere per ignoranza e anche per paura di non
trovare documentazione adatta oltre alle RFC (sono troppo grandi e tecniche
per poterle studiare per bene in pochi giorni) come mi è già successo per
L2TP. In questi 3 giorni mi sono fatto una cultura di massima sulle VPN in
generale (trusteed, secured e hybrid) e sono riuscito a studiare abbastanza
a fondo (senza entrare negli algoritmi) la suite IPSec (ike, ah e esp), ma
adesso sono ad un punto morto...
Se poteste aiutarmi su qualsiasi punto di cui sopra sarebbe per me di
grandissimo aiuto, anche solo qualche buon link (non ho la fobia dei tasti
search ne dei motori di ricerca... relamente non trovo documenti adatti!),
magari in italiano o qualche dritta sui tunnels più usati e interoperabili
tra le varie case...
Grazie in anticipo a chi contribuirà a risollevarmi un pò e scusate per il
thread lunghetto... :(
Ciauz.

 lavorativi....
qui da me si direbbe "te par?"
 
di solito se viene uno stagista da noi segue me per imparare da me delle
cose, non vicevarsa. forse non ho capito nulla?
quello che ti chiedono loro e' un progetto dettagliato che dovrebbe fare
un tecnico esperto che tra parlare con loro, stendere, rivedere e
presentare richiederebbe 2 settimane.
figuriamoci senza saperne nulla. e poi loro affiderebbero una parte cosi'
importante della loro rete ad uno stagista , permettimi, inesperto?
sei sicuro di volere lavorare li?
magari al prossimo stagista chiederanno di fare il bilancio e di fare la
previsione per gli investimenti finanziarii.
sono perplesso.
un mayhem che ti consiglia i "case studies" sul sito cisco. ma la tua
domanda e' troppo generica.
-- 
 Everyone is gay, with someone's else ass 
 Cisco  FAQ: 
http://mayhem.oltrelinux.com/icrc
 SPP  wpage: 
http://www.spippolatori.com
 Key on 
pgp.mit.edu
 ID C7393613

 Salve a tutti, mi scuso sin da ora per il crossposting qui e cuttone
Francamente, sei in una situazione niente male... Ti vorro' dare qualche
consiglio, ma vorrei approfittare del tuo spunto per fare qualche
riflessione sulla situazione in cui versano le societa' che dovrebbero
fornire servizi tecnologici (hai detto che sei da un grande provider...):
Far fare a te, appena passato il CCNA, ed alla prima esperienza
professionale seria (credo) un lavoro del genere, significa semplicemente
risparmiare sui costi, e' infatti prassi comune (da te confermata) quella di
ricorrere a ragazzi sottopagati alle prime armi (ma pieni di buona volonta')
per realizzare attivita' di discreto impegno sottocosto. Io considero questa
situazione francamente ridicola, anche solo per il fatto che esternamente ci
vorrebbero far passare il messaggio che quello delle reti e dei servizi
coinvolti sia un mondo rutilante iperuranico, fatto di professionalita', di
serieta', di successo, insomma: il futuro da auspicare. Detto questo,
sperando che mi sia stata perdonata la lunghezza della considerazione, ti
do' qualche modesto consiglio:
Il lavoro e' di una mole notevole, ti conviene concentrarti sugli aspetti
fondamentali e lasciar perdere la fuffa di contorno, quindi magari elimina a
priori l'eterogenita' dei possibili apparati, e considera quelli che piu'
conosci (cisco immagino...). A questo punto definisci ancora di piu' il
quadro, IMHO lascia perdere L2TP e considera solo IPSec e 3DES, e delinea i
possibili scenari: VPN LAN-to-LAN e VPN Client-to-LAN, nel primo caso
gestisci tutto con router cisco (poi vederemo come) e ti smarchi quindi il
secondo con un SW VPN client (scelta obbligata per semplificare quello
cisco..). Per le LAN to LAN puoi proporre due scelte fondamentali, IPSec o
GRE over IPSec (cioe' criptare un tunnel GRE): quando le sessioni da
criptare diventano tante puo' convenire infatti incapsulare in un tunnel e
poi criptare pacchetti tutti uguali, inoltre se hai applicazioni multicast
non c'e' alternativa. Devi poi considerare i casi in cui vi possa essere
NAT, quindi vanno considerate le possibilita' di usare NAT traversal. Un
buon punto di partenza e' ovviamente il sito cisco (anche se qualche
configurazione degli esempi e' cannata...). Probabilmente poi dovrai
considerare qualche FW e magari un VPN concentrator per le client-to-LAN.
Spero ti rispondano anche altre persone piu' competenti sull'argomento, in
ogni caso cerca di restringere il campo e concentrarti su cose semplici e
fattibili: KISS Keep It Simple & Stupid.
In bocca al lupo
cronenberg
--
Il cielo stellato sopra di te, la legge morale dentro.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 domanda e' troppo generica.
Spero di aver chiarito un pò.
Grazie tante comunque.

 serieta', di successo, insomma: il futuro da auspicare.
E' la stessa riflessione che avevo fatto anche io leggendo un articolo su
punto informatico riguardo i "salari" di chi lavora nel mondo IT e di come
tra agevolazioni statali e "ingenuità" di noi giovani le varie società
producessero tanto manodopera fresca, a basso costo e sostituendola quando
le condizioni non erano più favorevoli (vedi fine del periodo di
"apprendistato" dovere scegliere tra assumere a spese proprie o licenziare).

Grazie mille per i consigli, cercherò di orientarmi su ciò che conosco...
L2TP al posto di GRE è fattibile? lo chiedo solo per una questione di
interoperabilità. Alla fine studiare l'uno o l'altro non cambia molto al
momento.
Ciauz.

 questione di
cut
Non sono espertone di L2TP, ma mi sembra che sia un mecccanismo di
incapsulamento del livello OSI 2 nel 3, mentre GRE e' IP in IP. Non sono a
conoscenza di situazioni VPN che non possano essere gestite con IP, IPSec,
GRE. Ovviamente escludo il caso in cui si vogliano usare meccanismi nativi
di incapsulamento nei client Microsoft.


 di incapsulamento nei client Microsoft.
Per il client to lan credo che vorranno un supporto per i client nativi MS
ovvero l2tp e l2tp over ipsec.

 ovvero l2tp e l2tp over ipsec.
Peccato, io preferisco ignorarli e lavorare con un VPN client su IP, tipo il
client cisco o il contivity nortel...


 il client cisco o il contivity nortel...
soprattutto visto il nat traversal e l'encapsulate ipsec in tcp.
altrimenti o modem o morte.
un mayhem che odia i modem


 altrimenti o modem o morte.
Il nat traversal ho avuto modo di conoscerlo, non posso dire lo stesso per
encapsulate ipsec in tcp. Cmq potreste spiegarmi quale sarebbe il problema
tra il client M$ e queste due feature?
Tks

 tra il client M$ e queste due feature?
cut
Il nat traversal incapsula preventivamente in UDP 4500 quando si "accorge"
che c'e' un NAT in mezzo; ipsec in TCP fa' una cosa simile ma in una porta
TCP a piacimento. Questi meccanismi vengono usati quando esistono NAT o
filtri tra i peer VPN (che ad esempio non fanno passare UDP 500, ipsec,
etc.) e devono essere gestiti "o" dal SW VPN client, "o" dallo strato
applicativo microsoft (che non conosco sinceramente...). Evidentemente L2TP
microsoft non supporta tutto cio'. In definitiva, il consiglio che ti posso
dare e' che con un VPN client per le client-to-LAN riesci a gestire la
maggior parte delle situazioni, e standardizzi in questo modo la
metodologia.


 Il cielo stellato sopra di te, la legge morale dentro.
Vediamo se ho capito, il problema sorge quando io che mi connetto via client
mi trovo dietro nat non traversal o quando l'host che voglio contattare si
trova dietro un nat traverso perchè il client di MS non può incapsulare il
mio pacchetto in modo che dall'altra parte possa essere ricevuto/utenticato
e perche in caso di ricevimento di un pacchetto inviato con nat traversal
non è in grado di de-encapsularlo?
Quindi se io mi connettessi tramite modem (analog, isdn o adsl) potrei usare
il client MS a patto che l'host o la rete che voglio contattare non sia
dietro nat?
Spero di averci azzeccato... :p
Grazie ancora per l'aiuto che mi state dando.

 incapsulare il
Non proprio, ci sono problemi in generale a far passare IPSec attraverso un
NAT, o quando un FW blocca la UDP 500 (IKE) o IPSec. Per aggirare qualsiasi
porcheria possa trovarsi nel mezzo un trucco e' quello di incapsulare
"tutto" in IP/UDP 4500 puro, di modo che NAT e FW vedano passare pacchetti
IP "puri", senza sapere che dentro ci possa essere IPSec. Nel caso in cui
eventuali FW non facciano passare neanche UDP, ma solo, ad esempio, TCP 80,
altro trucco e' incapsulare tutto in IP/TCP 80 puro.
--
Il cielo stellato sopra di te, la legge morale dentro.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Il cielo stellato sopra di te, la legge morale dentro.
Ok, quindi ricapitolando sicuramente il client non ha la versatilità
necesari aper gestire un firewall molto restrittivo, non può incapsulare in
TCP ma a quanto ho letto sul sito microsoft dovrebbe poter gestire un
traversal puro (udp 4500). Cmq sia il momento in cui io mi connettessi via
modem il prblema sussisterebbe se dall'altra parte ci fose un bel firewall a
bloccare la udp 500, se la rete remota è dietro nat traversal ma non dietro
firewall non dovrei avere problemi o sbaglio?
Scusa se insisto ma dovrò motivare certe scelte e quindi devo capire per
bene le motivazioni.. Per esemio devo capire per bene perchè esp ha anche
lui problemi con il nat. (AH l'ho capito.)
Sempre 1000 grazie.

 lui problemi con il nat. (AH l'ho capito.)
perche' esp ha problemi con il nat?
un mayhem che lo usa correntemente


 --
Appena trovato una buona spiegazione. Se non ho capito male non c'è nessun
problema con NAT finchè non ci sono porte di mezzo ovvero finchè si devono
mappare solamente indirizzi. I problemi di conseguenza li avrebbe col PAT. O
sbaglio anche ora?

 perche' esp ha problemi con il nat?
cut
IPSec ha problemi col NAT, se con ESP intendi IPSec/ESP non credo tu riesca
a farlo funzionare senza NAT traversal..
--
Il cielo stellato sopra di te, la legge morale dentro.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 --
Scusa, un'altra domanda. il problema con il pat si presenta quando dobbiamo
fare comunicare due hosts di cu almeno uno č dietro nat/pat e sono i 2 hosts
a gestire ipsec e non il router? In uno scenario tipo lan to lan o client to
lan in cui a gestire ipsec sono i due routers connessi ad internet o il
client e il router connesso ad internet il nat non č un problema perchč il
pacchetto (se spedito in tunnel mode) viene prima autenticato e/o decriptato
e poi passato al nat/pat per smistarlo verso la rete locale.... o no?
Grazie.

 avrebbe col PAT. O sbaglio anche ora?
corretto
un mayhem ed il monitor troppo grande


 Grazie.
Ho cannato di brutto qua... nel caso di lan to lan non si crea il problema
perchè ho una route statica che mi indirizza verso l'interfaccia su cui è
presente il tunnel, nel caso di client to lan ccon l2tp su ipsec dovrei
potere negoziare un indirizzo "privato" per il client. Mi è un pò oscuro il
caso di un client ipsec con ip pubblico verso rete privata remota dietro
router con ip pubblico...
Che nervoso a non avere una macchina per potere fare prove...

 riesca a farlo funzionare senza NAT traversal..
qui scendiamo negli scenarii.
nat 1:1. esp-3des funzione. ah-* no
per ovvie ragioni.
se poi scegliamo altri scenarii (nat overload) concordo con te.
un mayhem che deve aspettare le 20.30 per mangiare


 rete locale.... o no?
in una situazione come questa, l'access-list che dice cosa nattare esclude
il traffico che sara' gestito dalla vpn.
quindi quei pacchetti non vengono mai nattati
un mayhem che perd i documenti (e le i) 


 Che in lingua comune vuol dire? :)
"te par?" potrebbe essere elegantemente tradotto con un "secondo lei e'
verosimilmente realizzabile quello che mi sta chiedendo?"
un mayhem in ritardo e le domande gia' risposte
