Newsgroup: it.comp.os.linux.sys
Titolo: Domanda su VPN & Firewall veramnete tosta!

Dovrei creare una VPN tra due uffici A e B.
Problematiche:
1) Non ho mai realizzato una VPN, qualche consiglio sul software da usare? 
Me la cavo rapidamente con IPCOP?
2) C'e' un grosso problema. l'ufficio A e' uno standa che si trova dentro un 
grosso mercato ortofrutticolo con un firewall centralizzato, e ad ogni stand 
arriva una presa ethernet per il collegamento ad internet. Siccome chi si 
occupa del firewall centralizzato non ha nessuna intenzione di collaborare 
mi chiedo come posso fare una vpn con il firewall di mezzo?
Dovete sapere che dentro lo stesso mercato ho un altro cliente che per 
fargli la teleassistenza lo faccio collegare in ssh su una macchina del mio 
ufficio, dato che il firewall centralizzato non filtra nula in uscita, con 
il comando ssh -R 3000:localhost:22 -l assistenza -N ip_della_mia macchina
Poi da mia_macchina faccio ssh -p 3000 -l assistenza localhost et volia... 
faccio teleassistenza.
Quindi vi chiedo, e' fantascentifico pensare di realizzare una vpn 
sfruttando una caratteristica simile con ssh? 

 solito e' una porta non-privilegiata.
Ok, che nel caso di OpenVPN dovrebbe essere la 1194 se non erro.
Mi piacerebbe leggere gli appunti di chi ha dovuto affrontare una 
probblematica similare, chi e' disposto a condividere il proprio know-how?
Grazie 1000. 

 OpenVPN, FreeSwan, CIPE....
Lascerei perdere CIPE.
Consiglio vivamente OpenVPN, nel caso in questione, dato che gi basta
una singola porta udp aperta in uscita, e per il resto passa indenne
attraverso circa qualsiasi cosa.
FreeSwan, come tutte le implementazioni IPSec, avrebbe enormi problemi
in assenza di collaborazione da parte del gestore del firewall.
Bye.

 in assenza di collaborazione da parte del gestore del firewall.
Non solo, sede B ha una connessione fastweb, e da quello che ho letto far 
andare ipsec su fastweb e' un bagno di sangue vero? 

 Grazie 1000. 
Be, non dovrebbe essere nulla di complicato.
Tu hai detto che il firewall non blocca nulla in uscita, di conseguenza 
dovrebbe anche accettare in ingresso pacchetti di ritorno a connessioni 
stabilite dall'interno, quindi se dall'interno del firewall fai partire 
una connessione openvpn sulla porta 1194 udp verso il server remoto non 
dovresti avere alcun problema.

 Perche'?
Perché OpenVPN è più pratico e versatile di CIPE.
-- 
Flavio Visentin
Membro del CICAP
Comitato Italiano per il Controllo delle Affermazioni di P4

 Consiglio vivamente OpenVPN, nel caso in questione, dato che gi basta
Sono perplesso.... con 20 minuti esatti, ho installato openvpn su una 
macchian con ubuntu in sede B, e poi openvpn sul portatile win xp su sede A, 
creato la chiave con openvpn --genkey --secret key.txt su ubuntu, copiata la 
chiave sul portatile creato la configurazione sia su ubunti che su xp come 
da manuale, fatto il nat sul firewall di sede B per traslare la porta 1194 e 
in men che non si dica le due reti si vedono perfettamente in tutto e per 
tutto.
Ma veramente e' cosi' semplice? :-)
Cmq, una cosa non ho ben capito, che differenza c'e' tra tun e tap?
Grazie 1000. 

 Cmq, una cosa non ho ben capito, che differenza c'e' tra tun e tap?
Tun -> routing
Tap -> bridging
Sempre consigliabile usare Tun salvo che non serva effettivamente Tap.


 Sempre consigliabile usare Tun salvo che non serva effettivamente Tap.
Riporto da 
http://guide.debianizzati.org/index.php/Openvpn
" dev
identifica il device utilizzato per il tunnel. I possibili device 
utilizzabili da openvpn sono tun e tap. La differenza tra i due device e' 
fondamentale, in quanto tun si adopera per la trasmissione di pacchetti IP 
(una specie di ppp) e tap invece per la trasmissione di frame ethernet (una 
specie di eth). Per la creazione di lan virtuali o per la condivisione di 
risorse come file-server, ftp-server, dobbiamo usare tap."
Perche' dici che e' consigliabile tun?

Mandi! Davide D'Amico
  In chel dí si favelave...
DDA> mi chiedo come posso fare una vpn con il firewall di mezzo?
Normalmente con UDP si, se il firewall non è configurato per filtrare
in uscita.
Basta che il peer dietro il firewall mantenga la connessione[1] viva, ad
esempio con un ping ogno 20/30 secondi. Nella documentazione di openvpn
ci sono informazoni ed esempi.
1: see, lo so, non è una connessione, ma è semplicemente il modo con
cui opera un firewall in presenza di connessioni udp, era tanto per
capirsi... ;)))
-- 
  But i still haven't found
  what i'm looking for					(U2)

 Perche' dici che e' consigliabile tun?
Perché se non è strettamente necessario lavorare a livello 2 (TAP), TUN
ha almeno questi vantaggi
* è più semplice gestirlo (non necessiti della parte bridge)
* è più semplice riconoscere eventuali problemi
* è più semplice filtrare il traffico (non hai di mezzo il bridge)
* consuma meno banda (non hai tutta la parte di livello2)
* si trova più documentazione
* a mio avviso è più versatile.
L'unico contro è che devi avere una classe IP a sè stante che devi
ruotare sulla tua rete, ma a fronte dei vantaggi questo è il minimo.


 Stessa cosa per CIPE.
Quanto a quello anche il buon vecchio vtund...
Solo che entrambi, analizzati da crittanalisti "veri" (Gutmann, se non
ricordo male, ma consiglio di cercare su google), sono stati
pesantemente criticati per la scarsa robustezza crittografica delle
soluzioni implementate.
La reazione del team di sviluppo, all'epoca, fu simile a "CIPE è figo lo
stesso. I crittanalisti han tutti la puzza sotto il naso".
Poesse che CIPE abbia nel frattempo attuato una reingegnerizzazione
pesante di tutto il sottosistema e risolto i problemi che gli vennero
contestati.
Tuttavia, il caso è un segnale del fatto che in fase di analisi forse
non si è prestata attenzione sufficiente all'ambito strettamente
crittanalitico, e che la componente teorica della crittografia sia stata
sottovalutata.
In questi termini, mi sento di consigliare più vivamente OpenVPN che non
CIPE; tantopiù che l'installazione dello stesso, come constatato
dall'OP, non è più complessa di CIPE...

 ruotare sulla tua rete, ma a fronte dei vantaggi questo è il minimo.
Quindi per intenderci, con il tap non vedrei per esempio i pc dentro risorse 
di rete giusto, a meno di non usare wins dato che non ho il broadcasting, 
sbaglio o e' cosi'?
Questa cosa della classe IP a se stante non l'ho capita, puoi spiegarti 
meglio? La classe ip me la scelgo io, 10.0.0.x per esempio per il tunnel e 
192.168.1.x per la rete A e 192.168.2.x per la rete B, sia se scelgo tun che 
tap o no? Forse non ho capito bene quello che volevi dirmi.
Ah un ultima domanda, se realizzo il tunnel utilizzando semplicemente la 
chiave (generata con openvpn --genkey --secret key.txt) senza utilizzare i 
certificati ssl a quali rischi vado in contro? 

 sbaglio o e' cosi'?
Non è vero:
guarda il mio firewall:
# ifconfig
tap0      Link encap:Ethernet  HWaddr 00:FF:0A:13:FD:08
           inet addr:192.168.254.254  Bcast:192.168.254.255 
Mask:255.255.255.0
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:1849938 errors:0 dropped:0 overruns:0 frame:0
           TX packets:1631950 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:100
           RX bytes:177077236 (168.8 Mb)  TX bytes:1075488944 (1025.6 Mb)
Uso tap (perchè lo uso?!: Non lo so) e dal client windows vedo tutta la 
mia rete su risorse di rete.

 Non è vero:
Infatti, ho sbagliato a scrivere, voelvo dire:
"Quindi per intenderci, con il TUN non vedrei per esempio i pc dentro 
risorse.."
Infatti e' il tun che lavora in bridge mode, quindi scambio di dati di 
broadcast. 

 soluzioni implementate.
Il fatto che vi sia quel problema, non inficia un granché sulla
sicurezza della soluzione.
Non dimentichiamo che nel 99% dei casi quello che interessa non è il
fatto che la conversazione rimanga inattaccabile per 1000 anni, ma è
solo che la comunicazione non possa essere intercettata e decrittata al
volo.
Allo stato attuale nel 99.999% dei casi la scelta del tipo di VPN non ha
senso che venga basata sul parametro della robustezza matematica della
crittografia impiegata (purché ovviamente non si tratti di gzip :-),
quanto più alla semplicità di configurazione, alla flessibilità ecc.ecc.
ed in questo sicuramente OpenVPN è superiore a CIPE.


 broadcast. 
Viceversa... il TAP lavora in bridge


 certificati ssl a quali rischi vado in contro? 
Al fatto che se uno si impossessa della chiave hai tutta
l'infrastruttura compromessa.
Con i certificati, se ne perdi uno, basta revocarlo e non hai più problemi.


> ed in questo sicuramente OpenVPN è superiore a CIPE.
DB> Mi permetto di dissentire, con 150 VPN CIPE attive e 50 OpenVPN, trovo
DB> sempre CIPE mooooolto piu' semplice e flessibile di Open.
..nessuna intenzione di fare la punta al cazzo a questa cosa, ma ho
appena messo in piedi i miei primi tre link openvpn su una ventina
cipe.
Ovviamente per openvpn ho usato le static keys, anche perchè metere in
piedi una CA per dei link statici la trovo una idiozia, ma quello che
ho fatto è riportare paro paro le voci dei file di conf di cipe nel
.conf di openvpn, e per ogni opzione di cipe che ho usato c'era la
rispettiva opzione in openvpn.
Solo che, rispetto a cipe, openvpn ha:
+ userland, due palle ricompilare sempre i moduli cipe...
+ ha la compressione del link
+ mi pare che gestisca meglio i link dove il router non sa frammentare,
 o lo fa male: cipe ti permette di abbassare la mtu e basta, openvpn ti
 ha qualche parametro in più...
+ pare mie, ma mi ha sempre fatto cagare il mio script di setup del
 routing di cipe, mentre in openvpn è possibile mettere il routing nel
 file di configurazione.
Ovviamente non ho fatto un confronto prestazionale (ma la tecnologia
sottesa è la stessa, non mi aspetto grosse differenze) e di stabilità,
ma sono passato da uno al'altro e se non fosse che le interfacce ora
sono tunX e non cipcbX non mi accorgerei neanche...
-- 
  Don't be tempted by the shiny apple, don't you eat of a bitter fruit,
  hunger only for a taste of justice, hunger only for a world of truth,
  'cause all that you have is your soul			(Tracy Chapman)

> La reazione del team di sviluppo
DB> Il "team" e' una persona sola.
..e da due anni non reagisce a nulla, figurati al paper di Gutmann...
;)))
-- 
  Vendere no, non passa tra i miei rischi,
  non comprate i miei dischi e sputatemi addosso.	(F. Guccini)

 sono tunX e non cipcbX non mi accorgerei neanche...
Aggiungi alla tua conf le due linee
dev-type tun
dev cipcbX
e così non ti accorgi manco di quello :-)


> piedi una CA per dei link statici la trovo una idiozia,
Direi che dipende di che realtà parliamo.
Se la realtà è sufficientemente grossa (e se si hanno un centinaio di
link forse lo è) e si ha già una CA interna (il che non è più cosa
rara), potrebbe avere *molto* senso.

>> piedi una CA per dei link statici la trovo una idiozia,
S> Direi che dipende di che realtà parliamo.
S> Se la realtà è sufficientemente grossa (e se si hanno un centinaio di
S> link forse lo è) e si ha già una CA interna (il che non è più cosa
S> rara), potrebbe avere *molto* senso.
..inisistoa non vederne l'utilità. Usare una PKI per me ha senso per
gestire clienti mobili, o comunque computer singoli in sedi minori, ma
per mettere in piedi una rete con link ben definiti e soprattutto
immutabili non vedo che vantaggi possa avere.
Ma sarà anche che io odio le PKI. ;)
-- 
  Chi crede che una crescita esponenziale possa continuare all'infinito in
  un mondo finito è un folle, oppure un economista.
							(?!)

> e di stabilità,
TZ> Su questo garantisco. Uso OpenVPN in produzione (oltre 100 vpn
TZ> costantemente attive) da + di due anni e non ho MAI avuto un crash
TZ> dell'applicazione.
Mi chiedo una cosa: essendo cipe in kernel space, forse nei casi limite
si comporta meglio? Una volta avevo un fw che aveva gravi problemi
hardware (un disco che faceva tlink-tlak ;).
Ormai non andava più una pippa (ssh, post mortem ho veificato che se ne
era andato anche syslogd ;), a parte cipe che, essendo in kernel space,
non veniva mai rilocato e quindi sopravviveva.
Non so openvpn come si comporterebbe in questo caso... credo che cipe
possa restare una ottima soluzione per chi ha realmente bisogno di una
soluzione minimale e totalmente affidabile. Su kernel 2.4. ;)
Invece un'altra cosa pro-openvpn è che ti permette di nominare
esplicitamente i link: se mi moriva un link cipe, logcheck mi avvisava,
ma solo con il PID del processo; dovevo ogni volta fare ssh nel fw, e
vedere a che interfaccia afferiva.
Da classificare alla voce ``pelo nell'uovo'', visto che se muore un
link comunque mi devo collegare al fw per riattivarlo, ma...
TZ> Aggiungi alla tua conf le due linee
TZ> dev-type tun
TZ> dev cipcbX
..diabolico... ;)))
-- 
  Non sara` il canto delle sirene che ci innamorera`
  noi lo conosciamo bene, l'abbiamo sentito gia`	(F. De Gregori)

 Non so openvpn come si comporterebbe in questo caso...
A me è capitato (più volte) che il disco sia andato a donne di facili
costumi (in genere overheating), e openvpn è sempre rimasto up&running.
Il problema è che ssh in questi casi cessa di essere disponibile, quindi
dell'openvpn attivo te ne fai poco :-). Qualche volta sono riuscito
comunque ad attivare una SysRq tramite /proc/sysrq-trigger e far
ripartire la macchina da remoto, ma nel 90% dei casi è stato necessario
l'intervento in loco.


 gestire clienti mobili
Beh, hai detto niente.
Openvpn per roadwarrior è a dir poco fenomenale e quasi a prova di
idiota, grazie anche all'openvpn-gui per windows...
-- 
Chaos A.D.		|	Raging crowd
Tanks on the streets	|	Burning cars
Confronting police	|	Bloodshed starts
Bleeding the Plebs	|	Who'll be alive?

 
Confermo.....
Uso quotidianamente openvpn windows come roadwarrior e basta portasi 
dietro 2 file, la config e la chiave (o il certificato) ed ovunque vai 
hai il tuo vpn bello e fatto.
Metti i 2 file su una chiave usb insieme all'installazione di openvpn 
gui per windows, installi e usi la vpn da qualunque computer.