Newsgroup: it.tlc.gestori.fastweb
Titolo: VPN tramite OpenVPN

Ciao a tutti!
Chiedo scusa se per caso non è il NG adatto ma ho trovato alcuni post vecchi
in cui si parlava di OpenVPN... se avete qualche NG "più corretto" per
OpenVPN fatemi sapere così rigiro la domanda :)
Ho provato ad utilizzare OpenVPN per creare una VPN con altri utenti e il
tutto funziona alla perfezione, nel senso che riusciamo a vedere senza
problemi i 2 PC che entrano "in VPN".
Ora però avrei la necessita di poter vedere anche la sottorete e non solo il
PC "singolo"... mi spiego:
PC-A (10.0.0.2) in vpn con PC-B (10.0.0.1)
PC-B in rete con altri PC (192.168.0.x)
Tramite OpenVPN A e B si vedono senza problemi mentre il PC-A non riesce a
vedere gli altri PC della rete "B" (ho provato a mettere il PC-B come
gateway... i pacchetti arrivano - ovviamente - fino al PC-B ma poi sembra
che lui "non li inoltri" nella sua sottorete)
Come posso fare per vedere gli altri PC della rete "B"?
Devo per forza andare in OpenVPN utilizzando 192.168.0.x?
Grazie a tutti per l'aiuto!
Ciauz! :)
--
Virtual

 routing, questa parola sconosciuta.
Gią, ma sotto windows 2000 pro non sono ancora stato in grado di farlo.
Sotto 2003 e xp puoi impostare il bridging tra la scheda di rete TAP (mi
pare di aver capito che virtual usi questo metodo) e quella della rete che
vuoi condividere (selezionale entrambe e scegli bridge connections).
Sotto 2000 manca l'opzione, quindi Ti sarei grato poeta se tu potessi
illustrarmi qualche verso illuminante a riguardo:
PC A: IP EXT.1.2.3
PC B: IP FWB.1.2.3
Il pc b č in fastweb.
Usando una riga di comando del genere:
Lato client fastweb(niente chiavi e protezione)
       openvpn --dev tun --ifconfig EXT.1.2.4 EXT.1.2.5 --proto udp --remote
EXT.1.2.3
Lato server su rete EXT.1.2.*
openvpn --dev tun --ifconfig EXT.1.2.5 EXT.1.2.4 --proto udp
Si riesce senza problemi a far si che PCA e PCB si vedano a vicenda
attraverso il tunnel con gli indirizzi EXT.1.2.4 EXT.1.2.5
Come dicevo non sono stato in grado (come virtual, ma il server gira sotto
2000Pro) di far si che EXT.1.2.4 acceda alla rete EXT.1.2.*
se non configurando un altro ip su PCA (mettiamo EXT.1.2.10) e mappando
manualmente le porte (un routing molto "alla buona :)"  )

 routing, questa parola sconosciuta.
Ho provato ad aggiungere delle route ma con scarso successo... altrimenti
mica avrei postato il messaggio se ci fossi già riuscito da solo!! :-/
Ciauz! :)
--
Virtual

 route 172.16.200.0 255.255.255.0 172.16.101.1
Grazie, Giŕ provato :(
dal client do:
ping 172.16.100.23 , non ricevo risposta,
la route funziona perchč se do dal client:
tracert 172.16.100.23 il pacchetto passa per 172.16.101.1 ma non procede
oltre.
Ho immaginato che ci fosse un problema con l'inoltro dei pacchetti tra le 2
schede di rete (reale e virtuale), quindi ho abilitato "IPENABLEROUTER" nei
parametri tcpip nel registro di Win2K, ma non ho risolto nulla.
Per escludere problemi di SO, ho montato Openvpn (lato server) su una
macchina linux e abilitato il forward sotto /proc.
Con una route di prova su eth0 ho verificato che l'inoltro funzionasse, ma
il risultato con tun0 non č cambiato.
Il quesito principale immagino sia diventato questo: "come faccio ad
inoltrare pacchetti tra tun0 e eth0 ?"
Qualche idea ?

 il risultato con tun0 non è cambiato.
Infatti non è un problema di SO: il problema è capire
cosa sta avvenendo.
E tu non ti sei sforzato molto, oserei dire. :)
Il routing non funziona per magia, ma perchè qualcuno mette
qualcosa nelle tabelle di routing.
Se tu non istruisci altrimenti il tuo kernel, i pacchetti di
risposta non potranno che essere instradati verso il default
gateway.
Ergo, olio di gomito, LARTC ed iptables...;)
-- 
No more tradition's chains shall bind us;
Arise, ye slaves! No more in thrall!
The Earth shall stand on new foundations;
We have been naught - We shall be All!

 Quindi o natti o bridgi.
E da qui ritorniamo al principio, win2kpro non supporta il bridging o io non
so come farlo andare :(


Le route fungono, il pacchetto viene instradato correttamente dal client in
fastweb fino all'endpoint tun0 sull'host remoto.
Adesso io non so come fare per far si che il pacchetto venga inoltrato da
tun0 sull'host remoto a eth0.
Pensando ad un problema con le subnet ho anche assegnato ip nella stessa
sottorete ai device tun e eth0, i pacchetti non vengono inoltrati, e non
riesco ad immaginare una route che potrebbe risolvere...

 io non so come farlo andare :(
Sotto Windows2000 puoi usare quanto su :
==
- 
http://www.ntkernel.com/utilities/etherbridge.shtml
==
se vuoi realizzare un network bridge L2.
Per quanto riguarda la questione OpenVPN, se non fai bridging tra le
interfacce di rete, verifica che sia abilitato sul peer W2000 l'IP
Forwarding nel registro di sistema :
==
- Hive ..: HKEY_LOCAL_MACHINE
- Chiave : SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
- Nome ..: IPEnableRouter
- Tipo ..: REG_DWORD
- Valore : 1
==
e controlla che i client (o il gateway predefinito) abbiano le route
apposite per gestire le connessioni attraverso il tunnel con la subnet
remota.
-- 
|Ż \/Ż | /Ż\ /Ż__/Ż__|<|> *FAX/Mail Server  : 
+39 - 02700426582
 <|
|Ż|\/|Ż|/Ż_Ż\|(__\__ \<|> *Casella Vocale   : 
+39 - 0230312251
  <|
|_|  |_/_/ \_\___|___/<|> *FAQ ITGF 
http://plany.fasthosting.it
 <|
|>- RST FAQ 2.0 ITGF -<|> *FAQ GCN  
http://faq.news.nic.it/
 ____<|

 se vuoi realizzare un network bridge L2.
GRAZIE MACS !!!!!

 tun0 sull'host remoto a eth0.
Il pacchetto viene inoltrato, visto che hai abilitato il forwarding.
Sono i pacchetti "di ritorno" che non ti tornano indietro.
Il perchè è molto semplice: prendono la strada del default gateway, come
è naturale che sia, visto che non hai detto di fare altrimenti.
 
Te lo dico con cognizione di causa, visto che sto scrivendo da una
macchina che è in fastweb usando VNC, passando prima in un tunnel
ssh e poi in un tunnel openvpn.


 è naturale che sia, visto che non hai detto di fare altrimenti.
Grazie per la spiegazione ;)