Openswan HOWTO. ESP (rfc2406): Encapsulating Security Payload garantisce la privatezza e l'integrità di un pacchetto cifrando il contenuto di esso

Transcript

1 Openswan HOWTO Introduzione Realizzare una VPN (Virtual Private Network), collegando due network remoti attraverso la tecnologia del tunneling è oramai un pratica comune. Molti sono i software che permettono di effettuare una connessione tra due reti e incapsularla in un tunnel. In ambiente GNU/Linux ci sono molte soluzione come Vtund oppure Openvpn, ma sicuramente una di quelle che sono considerate più complete ed affidabili è Openswan, naturale evoluzione del progetto FreeSwan, che consente di utilizzare il protocollo IPSec (IP Securety), per la cifratura dei dati in transito. In effetti una VPN deve consentire di salvaguardare: Riservatezza permette che un dato sia ricevuto e leggibile solo e soltanto dal destinatario dello stesso, rendendo inutile il tentativo di intercettazione da parte di terzi. Integrità deve consentire di poter verificare l autenticità dei dati ricevuti verificandone l integrità all arrivo. Autenticazione Deve permette di verificare con certezza l'identità del mittente secondo le logiche del meccanismo di autenticazione della doppia chiave asimmetrica (pubblica-privata). Tutte queste caratteristiche sono implementate dall IPSEC che fornisce un set di estensioni al protocollo IP che permettono la crittazione di dati oltre all implementazione delle tre caratteristiche sopra elencate. IPSEC è composto da tre protocolli principali: IPsec è composto da una parte che si occupa del mantenimento di un canale sicuro per la trasmissione dei dati e da una seconda parte che si occupa dello scambio di chiavi. AH (rfc2402): Authentication Header Consente l'autenticazione di un pacchetto crittografando con un algoritmo forte l'header IP del pacchetto stesso ESP (rfc2406): Encapsulating Security Payload garantisce la privatezza e l'integrità di un pacchetto cifrando il contenuto di esso IKE: Internet Key Exchange E responsabile della negoziazione tra i parametri di connessione. Esistono diversi campi di applicazioni in cui utilizzare una connessione del tipo VPN IPSEC: Connessione tra Network separati: quando si vogliono connettere in modo diretto, ma sicuro, due network separati dalla rete internet. In questo modo la connessione avviene tra due nodi (VPN Gateway) che permetto alle due reti di agire come se fossero collegate fisicamente.

2 Connessione diretta tra sistemi: spesso si può utilizzare anche una connessione in VPN del tipo point to point per connettersi ad un altro host in modo sicuro, attraverso un canale non sicuro come le rete internet Connessione client VPN ad un VPN gateway: quando si connette uno o più client ad un gateway in grado di gestire simultaneamente più tunnel. In questo caso si parla di connessioni Road Warrior", connessione tipica di client o notebook che si collegano da una rete esterna non fidata. Installazione di OpenSWAN OpenSWAN è il progetto che eredita il lavoro del Team che ha sviluppato il suo progenitore ovvero FreeSwan. Esiste anche un altra evoluzione, StrongSwan con caratteristiche leggermente diverse. In realtà dalla versione 2.6.x del kernel abbiamo il supporto nativo per ipsec grazie al progetto KAME. Ecco perché FreeSWAN è terminato evolvendosi in OpenSWAN e strongswan, due soluzioni in grado di utilizzare i certificati X.509. La particolarità di strongswan risiede nella possibilità di gestire anche i certificati di revoca. Openswan utilizza come algoritmi di crittografia AES e 3DES, mentre strongswan supporta anche Serpent, Blowfish, Twofish. Dal punto di vista pratico il pacchetto di OpenSWAN, consiste in una patch del kernel che permette di compilare il modulo ipsec.o. La sua applicazione è semplice e non richiede la ricompilazione completa del kernel e neppure il riavvio del sistema. Inoltre Open S/WAN contiene all interno del suo codice la Nat-Transversal patch, indispensabile per oltrepassare un punto di NAT (ad esempio un router), grazie all incapsulamento delle comunicazioni all'interno di un flusso UDP. Infatti questa patch consente di realizzare un tunnel se ci si trova in questa condizione: Local Subnet <--> Internet <--> Gateway <--> Local Subnet Questa operazione è indispensabile nel caso in cui non sia il router (gateway) della nostra rete a gestire la VPN, ma un host alle sue spalle all interno della rete stessa. Il sito ufficiale è mentre per strongswan Per poter applicare la patch al kernel occorre prima scaricare la versione LATEST del pacchetto oltre alle MATH Library che sono richieste: wget wget (richieste) tar xvfz openswan-2.3.0dr2.tar.gz cd openswan-2.3.0dr2 A questo punto dalla source directory di openswan compilare i tools e il modulo ipsec.o: make KERNELSRC=/usr/src/linux-2.4 programs module Come root per installare i tools in userspace il modulo ipsec.o: make KERNELSRC=/usr/src/linux-2.4 install minstall Su Slackware 10 con kernel si sono verificati dei problemi di compilazione. Se li aveste anche voi li potete risolvere in questo modo: Editare programs/makefile, e rimuovere la vice 'starter' dalla direttiva SUBDIRS += line

3 A questo punto siamo pronti per configurare ed installare il servizio IPSEC. Schema Prima di configurare il tunnel e fare tutte le verifiche necessarie cerchiamo di capire come sarà strutturata la nostra rete unita dal tunnel. Per poter verificare con sicurezza l instaurarsi ed il funzionamento del tunnel o si hanno ha disposizione due punti in due network distinti separati da internet, su cui lavorare liberamente, oppure si creano due subnetwork in rete locale e si mettono in mezzo i due punti del tunnel. Per effettuare una test completo ho effettuato quest ultima operazione: LATO SINISTRO (left) vpnl Sottorete /24 Client della sottorete /32 LATO DESTRO (right) vpnr Sottorete /24 Client della sottorete /32 Configurazione Prima di vedere come configurare il sistema occorre specificare il metodo di autenticazione che vogliamo utilizzare. Si possono usare metodi diversi: Pre -shared keys RSA keys

4 X.509 certificates Nel nostro caso useremo le chiavi RSA che dovranno essere scambiate tra i sistemi, aggiungendole al file di configurazione. Adesso possiamo configurare due nodi allo stesso modo. La procedura prevede: Procedura 1. Creazione chiavi e scambio tra i due nodi 2. Configurazione ipsec.conf per entrambi i nodi 3. Avvio di ipsec tra i due nodi 4. Test sul traffico tra i due nodi LEFT RIGHT <----INTERNET/LAN----> vpnl vpnr Generazione delle Chiavi RSA su entrambi i nodi (Autenticazione con Preshared keys) Per prima cosa occorre creare le chiavi RSA sui due nodi tunnel ed inserirle nel file di configurazione (ipsec.conf) che andrà copiato uguale su entrambi i sistemi: root@vpnl:/#ipsec newhostkey --output - >>/etc/ipsec.secrets root@vpnr:/#ipsec newhostkey --output - >>/etc/ipsec.secrets #ipsec.secrets : RSA { # RSA 2192 bits vpnl Sat Oct 23 13:09: # for signatures only, UNSAFE FOR ENCRYPTION #pubkey=0saqn6ujisbxxb6yirw4xxpvfzu7jjj0drev85z1ap474fvnj5kiq864yiz4onhp812wntf8+bshq18ljgs6tgxd qyjbhzyzr6gbobswr/9mzi/zsg4d TkI9B9dzZlBaLJ50O4obXNdUU52AtVtv93ad63GBHIU5Q9iCb18QNz2YNZRr2ytFneUWM0ppSN0x3MjcdZYDl6RYCiejnE51 XEbf6HfEQhJqFgDOox0CiLL3g+mM/YpQzQJk nlhys3qouo4b8nzyedrwvyzbpjvv7hqia5gi/ikmb2pgtxucc80o0bssprl8fcc3ez5bgygsauy3l4nccpxa6valn6w2y2//u 9F65NqocH7lG3lNuYOa4fEZIJ La chiave pubblica segue la direttiva pubkey e va inserita nel file ipsec,conf con le direttive leftrsasigkey e rightrsasigkey. Verifica delle Chiavi Possiamo verificare le chiavi sui due sistemi: root@vpnl:/usr/src/mon-1.0.0pre4# ipsec showhostkey --left # RSA 2192 bits vpnl Sat Oct 23 13:09: lefttrsasigkey=0saqn6ujisbxxb6yirw4xxpvfzu7jjj0drev85z1ap474fvnj5kiq864yiz4onhp812wntf8+bshq18ljgs6tg xdqyjbhzyzr6gbobswr/9mzi/zsg4dtki9b9dzzlbalj50o4obxnduu52atvtv93ad63gbhiu5q9icb18qnz2ynzrr2ytfne UWM0ppSN0x3MjcdZYDl6RYCiejnE51XEbf6HfEQhJqFgDOox0CiLL3g+mM/YpQzQJknlhys3QoUo4B8nzyedRwVyZbPjvV7H qia5gi/ikmb2pgtxucc80o0bssprl8fcc3ez5bgygsauy3l4nccpxa6valn6w2y2//u9f65nqoch7lg3lnuyoa4fezij

5 ipsec showhostkey --right # RSA 2192 bits vpnr Sat Oct 23 17:21: rightrsasigkey=0saqnjjujbdjtywc9pcmkuyms6zeyftrda2mzpx5zgye00883dwojwimufb82dak+3becbnnci8uky294d b5scwbfvwgoqal9rm37t0zocnufcbnka3plfj8whlqihao8zz9joerthijz9edwpn6brx+ab2qfcmtpybdaf2g6+h5he+jag qnspsymq+2xtmaonijvi/yanqtiqg9rk4adta9xgdznmj4ht6roy6qvip5ntfdpvwwky+y2v04ainbnd35sw3lrnts02qxf 69F9ehQWWa8aF9Zun2eSXquMixUk2gBfAdozQDCxUH7aEBtKzduHU9F53pZsyYemh7eVnXWUIrMVkd2nWJWM9VuIWlJ1i Wv4z Configurazione per entrambi i punti A questo punto abbiamo tutti gli strumenti per configurare il tunnel: #ipesec.conf version 2.0 config setup interfaces=%defaultroute forwardcontrol=yes klipsdebug=all plutodebug=all conn tunnel #LEFT - vpnl left= leftid=@vpn1.netlink.it leftrsasigkey=0saqn6ujisbxxb6yirw4xxpvfzu7jjj0drev85z1ap474fvnj5kiq864yiz4on Hp812wNTF8+bshQ18LjGs6TgxDqYjbHzYZr6GbOBsWr/9MZ$ leftsubnet= /24 leftnexthop= #RIGHT - vpnr right= rightid=@vpn2.netlink.it rightrsasigkey=0saqnjjujbdjtywc9pcmkuyms6zeyftrda2mzpx5zgye00883dwojwimuf B82dAk+3BeCbnNCI8uKy294db5SCwbfvwgoqaL9rm37t0zoCnu$ rightsubnet= /24 rightnexthop= auto=start Il file di configurazione risulta diviso in 3 parti: Nelle prime due sezioni vengono impostati i parametri di carattere generale. Quello più importante è la direttiva interface che definisce quale sia l interfaccia utilizzata per collegarsi verso l esterno e dunque per impostare il tunnel. In genere l interfaccia scelta è quella che consente la connessione ad internet, può essere l eth0 in caso di connessione via linea dedicata (CDN o ADSL) oppure ppp0 o ippp0 in caso di connessioni PSTN o ISDN. La terza sezione invece è quella proprio specifica per la configurazione dei due lati del tunnel (left e right). Le direttive nel dettaglio: conn: attraverso questa direttiva si specifica il nome scelto per la connessione che vogliamo realizzare; leftid: è il nome completo del dominio della prima macchina; leftrsasigkey: è la chiave pubblica della prima macchina, deve essere copiato dal file /etc/ipsec.secrets nel quale è identificata dalla variabile pubkey;

6 left: è l indirizzo IP pubblico della prima macchina, cioè quello pubblicamente visibile da internet. leftsubnet: è la subnetmask della rete alle spalle della macchina di sinistra (left) leftnexthop: è l indirizzo del gateway della rete, ovvero l IP del primo sistema attraverso cui transitano i pacchetti destinati verso internet. auto: definisce il metodo con cui la VPN deve essere attivata. Impostandolo su start la VPN si attiva automaticamente al boot del sistema attraverso gli script nella /etc/rc.d/init.d. Gli stessi identici parametri vanno impostati per la macchina posta sul lato destro (right), per la quale vengono impostate le direttive: rightid rightrsasigkey right rightsubnet rightnexthop Ovviamente le stesse impostazioni di configurazione devono essere fatte per l altro sistema per il quale basta utilizzare lo stesso identico file. Nel caso avessimo voluto usare le Pre Shared Keys (PSK) avremmo potuto semplicemente creare una chiave con il comando: root@vpnr:/etc/ipsec.d# ipsec ranbits --continuous 128 0x37f6976b608f4cf306593c045accec07 Il file ipsec.secrets deve essere modificato in questo modo: IP-nodo1 IP-nodo2 : PSK "chiave creata" Nel mio caso: : PSK 0x37f6976b608f4cf306593c045accec07 La configurazione del file ipsec,conf cambia in questo modo: #ipesec.conf version 2.0 config setup interfaces=%defaultroute forwardcontrol=yes klipsdebug=all plutodebug=all conn tunnel authby=secret #LEFT - vpnl left= leftsubnet= /24 leftnexthop= #RIGHT - vpnr right= rightsubnet= /24 rightnexthop=

7 auto=start Questa configurazione è ancora più semplice da mettere in pratica. Il terzo sistema prevede l uso dei certificati, ma per motivi di tempo non è stato incluso in questo documento. Avvio/Arresto Prima di avviare ipsec controlliamo che siano presenti tutti gli elementi di sistema ed i moduli necessari per poter utilizzare pienamente le sue funzioni. Per fare questo possiamo utilizzare il comando: root@vpnl:/etc# ipsec verify Checking your system to see if IPsec got installed and started correctly: Version check and ipsec on-path Linux Openswan 2.3.0dr2 (klips) Checking for IPsec support in kernel Checking for RSA private key (/etc/ipsec.secrets) Checking that pluto is running Two or more interfaces found, checking IP forwarding Checking NAT and MASQUERADEing Checking for 'ip' command Checking for 'iptables' command Opportunistic Encryption DNS checks: Looking for TXT in forward dns zone: vpnl [MISSING] Does the machine have at least one non-private address? [FAILED] Per superare la verifica ho dovuto caricare il moduli per il NAT ed ablilitare l IP forwarding root@vpnl:/etc# modprobe iptable_nat root@vpnl:/usr/src/openswan-2.3.0dr2# sh /etc/rc.d/rc.ip_forward start Adesso possiamo avviare effettivamente ipsec e successivamente verificare la corretta instaurazione del tunnel: root@vpnl:/usr/src/openswan-2.3.0dr2/doc# /etc/rc.d/init.d/ipsec --stop ipsec_setup: Stopping Openswan IPsec... root@vpnl:/usr/src/openswan-2.3.0dr2/doc# /etc/rc.d/init.d/ipsec --start ipsec_setup: Starting Openswan IPsec 2.3.0dr2... ipsec_setup: Using /lib/modules/ vs1.28/kernel/ipsec.o root@vpnl:/etc# /etc/rc.d/init.d/ipsec status IPsec running pluto pid tunnels up Il tunnel può anche essere attivato manualmente nel caso in cui nei file di configurazione non sia stata specificata la direttiva auto=start: Apertura di una connessione specificata in /etc/ipsec.conf ipsec auto -up nome_conn Chiusura di una connessione specificata in /etc/ipsec.conf ipsec auto -down nome_conn Esempio pratico:

8 Lato LEFT ipsec auto --up tunnel 112 "tunnel" #6: STATE_QUICK_I1: initiate 004 "tunnel" #6: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0xca68a7c5 <0x14b13e84} Lato RIGHT ipsec auto --up tunnel 112 "tunnel" #3: STATE_QUICK_I1: initiate 004 "tunnel" #3: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x14b13e83 <0xca68a7c4} Verifica della connessione Il controllo del tunnel e del traffico in transito può essere effettuato con il comando ipsec: root@vpnl:/etc# ipsec --help Usage: ipsec command argument... where command is one of: ipsec_pr.template auto barf calcgoo eroute ikeping klipsdebug livetest look mailkey manual newhostkey pf_key pluto ranbits rsasigkey secrets send-pr setup showdefaults showhostkey spi spigrp tncfg verify whack A questo punto è possibile usare i seguenti comandi di monitoraggio ipsec auto -status ci dà un report dello stato attivo ipsec look dà brevi informazioni sullo status del sistema ipsec barf al contrario del precedente da informazioni di debugging estese. Vediamo in pratica alcuni esempi: root@vpnr:~# ipsec auto --status 000 interface ipsec0/eth %myid = (none) 000 debug raw+crypt+parsing+emitting+control+lifecycle+klips+dns+oppo+controlmore+pfkey+nattraversal+x algorithm ESP encrypt: id=3, name=esp_3des, ivlen=64, keysizemin=168, keysizemax=168

9 000 algorithm ESP encrypt: id=12, name=esp_aes, ivlen=128, keysizemin=128, keysizemax= algorithm ESP auth attr: id=1, name=auth_algorithm_hmac_md5, keysizemin=128, keysizemax= algorithm ESP auth attr: id=2, name=auth_algorithm_hmac_sha1, keysizemin=160, keysizemax= algorithm IKE encrypt: id=7, name=oakley_aes_cbc, blocksize=16, keydeflen= algorithm IKE encrypt: id=5, name=oakley_3des_cbc, blocksize=8, keydeflen= algorithm IKE hash: id=2, name=oakley_sha, hashsize= algorithm IKE hash: id=1, name=oakley_md5, hashsize= algorithm IKE dh group: id=2, name=oakley_group_modp1024, bits= algorithm IKE dh group: id=5, name=oakley_group_modp1536, bits= algorithm IKE dh group: id=14, name=oakley_group_modp2048, bits= algorithm IKE dh group: id=15, name=oakley_group_modp3072, bits= algorithm IKE dh group: id=16, name=oakley_group_modp4096, bits= algorithm IKE dh group: id=17, name=oakley_group_modp6144, bits=6144 ipsec look vpnr Mon Oct 25 17:29:54 CEST /0 -> /0 => %trap (0) /32 -> /0 => %trap (69) /32 -> /32 => %pass (1) /24 -> /24 => (2) ipsec0->eth0 mtu=16260(1443)->1500 ESP_3DES_HMAC_MD5: dir=out src= iv_bits=64bits iv=0x7bfc80622eb9f1c2 ooowin=64 seq=2 alen=128 aklen=128 eklen=192 life(c,s,h)=bytes(272,0,0)addtime(242,0,0)usetime(56,0,0)packets(2,0,0) idle=55 refcount=4 ref=54 reftable=0 refentry=54 ESP_3DES_HMAC_MD5: dir=in src= iv_bits=64bits iv=0x7907af5af98174e6 ooowin=64 seq=2 bit=0x3 alen=128 aklen=128 eklen=192 life(c,s,h)=bytes(208,0,0)addtime(242,0,0)usetime(56,0,0)packets(2,0,0) idle=55 refcount=6 ref=49 reftable=0 refentry=49 IPIP: dir=in src= policy= /24-> /24 flags=0x8<> life(c,s,h)=bytes(208,0,0)addtime(242,0,0)usetime(56,0,0)packets(2,0,0) idle=55 refcount=4 ref=48 reftable=0 refentry=48 IPIP: dir=out src= life(c,s,h)=bytes(208,0,0)addtime(242,0,0)usetime(56,0,0)packets(2,0,0) idle=55 refcount=4 ref=53 reftable=0 refentry=53 Destination Gateway Genmask Flags MSS Window irtt Iface UG eth UG ipsec UG ipsec U eth U ipsec0 Verifica dai sistemi nei network Da un host mascherato dietro il tunnel provare a effettuare un ping e poi una connessione ssh. Con il comando tcpdump possiamo osservare il traffico sulla scheda di rete provieniente dall host alle spalle del tunnel: root@toshiba1:~# tcpdump -i eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 14:39: IP > : icmp 64: echo request seq 1 14:39: IP > : icmp 64: echo reply seq 1 14:39: IP > domain: PTR? in-addr.arpa. (44) 14:39: IP > : icmp 64: echo request seq 2 14:39: IP > : icmp 64: echo reply seq 2 14:39: IP > : icmp 64: echo request seq 3 14:39: IP > : icmp 64: echo reply seq 9 14:39: IP > domain: PTR? in-addr.arpa. (44) 14:39: IP > domain: PTR? in-addr.arpa. (44) 14:39: IP > domain: PTR? in-addr.arpa. (43) 14:39: IP > domain: PTR? in-addr.arpa. (43)

10 14:39: IP telefinder > ssh: S : (0) win 5840 <mss 1460,sackOK,timestamp ,nop,wscale 0> 14:39: IP ssh > telefinder: S : (0) ack win 5792 <mss 1460,sackOK,timestamp ,nop,wscale 0> 14:39: IP telefinder > ssh:. ack 1 win 5840 <nop,nop,timestamp > 14:39: IP ssh > telefinder: P 1:26(25) ack 1 win 5792 <nop,nop,timestamp > 14:39: IP telefinder > ssh:. ack 26 win 5840 <nop,nop,timestamp > 14:39: IP telefinder > ssh: P 1:25(24) ack 26 win 5840 <nop,nop,timestamp > 14:39: IP ssh > telefinder:. ack 25 win 5792 <nop,nop,timestamp > 14:39: IP ssh > telefinder: P 26:634(608) ack 25 win 5792 <nop,nop,timestamp > 14:39: IP telefinder > ssh: P 25:633(608) ack 26 win 5840 <nop,nop,timestamp > Tcpdump può consentirci di osservare il traffico sulle interfacce di rete proveniente da un host alle spalle del nostro tunnel. Amministrazione del Tunnel con Webmin FreeSWAN è un progetto vecchio per questo sono stati sviluppati un paio di moduli per poter gestire IPSEC attraverso Webmin. Questi moduli funzionano allo stesso modo con OpenSWAN, anche se conviene comunque farsi una copia delle proprie configurazioni prima di modificarle direttamente da questo ambiente. Il primo modulo è quello già presente in Webmin di default IPsec VPN Configuration, il secondo invece è il FreeS/WAN VPN module di Tim Niemueller. Sono simili ed entrambi in grado di riconoscere il tunnel impostato ed in grado di attivarlo o disattivarlo o di configurarlo. Il primo modulo permette una configurazione semplice ed immediata ed una gestione molto semplificata del tunnel e delle sue configurazioni.

11 Oltre a poter agire sulle impostazioni di default diventa molto semplice creare nuove connessioni ipsec da affiancare a quella da noi creata nell esercizio (tunnel). Prima di utilizzare il modulo accedere al pannello di configurazione e verificare che la configurazione sia corretta, soprattutto il percorso dei comandi necessari a fermare e a riavviare il tunnel. Anche il secondo modulo il FreeSWAN Module presenta funzionalità simili, anche se essendo sviluppato appositamente per questo primo metodo, ha presentato qualche inconveniente e qualche mancanza. In linea di massima, per motivi di compatibilità credo sia meglio utilizzare il primo più adatto a gestire connessioni IPSEC in genere. Questi strumenti sono molto utili e ci semplificano la vita, ma secondo me, sono da utilizzare solo dopo avere bene appreso il funzionamento del sistema ed aver imparato a configuralo manualmente. In alcuni casi possono essere utilizzati per consentire a terzi soggetti di effettuarne la gestione, senza per questo concedere loro l accesso diretto al sistema.

12 Note Finali Usare IPSEC su GNU/Linux attraverso OpenSWAN e prima FreeSWAN, non è sempre una cosa semplice ed immediata. Ho pensato di riepilogare la procedura semplice e diretta per mettere in piedi un tunnel diretto tra due VPN gateway, ma ovviamente il discorso non si esaurisce qui ed è molto più vasto. Non sono un esperto in materia, volevo solo fornire a chi come me ha litigato parecchio con questo argomento uno spunto utile per realizzare in modo rapido un tunnel tra due sistemi, usando quella che sembra essere una delle tecnologie più affermate. Per poter maneggiare con una certa sicurezza ipsec consiglio una lettura approfondita degli howto ufficali, che illustrano le altre funzionalità e approfondiscono gli argomenti inerenti alla sua sicurezza. Ci vuole un pò di pazienza e se possibile la struttura giusta per poter effettuare dei test di funzionamento, prima di spedire un dei due nodi VPN all esterno a fare il suo lavoro. In modo particolare bisogna fare attenzione alle chiavi che siano inserite (incollate) giuste all interno del file di configurazione. Non dimenticate di verificare per prima cosa che i due vpn gateway si raggiungano ed il traffico venga veicolato attraverso ipsec, questo si può fare semplicemente con un dump dell interfaccia ipsec0. Risorse Doc: openswan.pdf Dott. Paolo PAVAN [Netlink Sas] pavan@netlink.it Data: Settembre-Ottobre 2004 Note finali Il presente documento è a semplice scopo divulgativo L autore non si assume la responsabilità di eventuali danni diretti o indiretti derivanti dall'uso dei programmi, o dall applicazione delle configurazioni menzionate nel seguente articolo I marchi citati sono di proprietà dei rispettivi proprietari e sono stati utilizzati solo a scopo didattico o divulgativo. L uso o il riutilizzo del presente articolo è liberamente consentito per scopi didattici o informativi previa citazione della fonte Sono possibili errori o imprecisioni, segnalatemele a pavan@netlink.it Chi volesse integrare il presente documento, può scrivere a pavan@netlink.it.