Newsgroup: it.comp.os.win.xp
Titolo: openvpn

 ciao,
ho installato openvpn (su XP) e sembra funzioną abbastanza...solo che quando
provo a mettere l'opzione push " route xxx.xxx.xxx.xxx XXX.XXX.XXX.XXX" come
per magilla non funge piu un cavolo...mi spiego:
faccio partire open vpn lato server e client ping gli indirizzi 10.8.0.1
(server) e 10.8.0.X (client) l'uno con l'altro e funge poi disconnetto
entrambeci butto l'opzione dove gli specifico la subnet 172.16.0.0
255.255.255.0 faccio risalire il tutto e sembra risalire bene lato client
vedo la rotta che gli ho specificato ma non pingo piu nulla manco
10.8.0.1....del 172.16.0.1 manco a parlarne...lato server che č un xp home
ho abilitato dal regedit il routing come da howto..ma in effetti mi
meraviglia che manco si pinghino piu dall'interfaccia tunnel....qulacuno mi
sa suggerire come abilitare st'opzione in modo che veda l'intera subnet +
chiaramente gli indirizzi di tunnell?
ciao e grazie
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 per magilla non funge piu un cavolo...mi spiego:
Se posti i due file di configurazione (senza ovviamente i certificati e
gli ip pubblici) forse scopriamo l'inghippo.
-- 
Flavio Visentin
Membro del CICAP
Comitato Italiano per il Controllo delle Affermazioni di P4


ciao,
intanto grazie....
eco le conf gli ip sono privati e i certificati con nomi standard...per ora
la minitopologia è questa pcvpnclient -- chechpointGW -- altro pcvpnserver
ma nulla cambierà dietro router (chi ospita il server farà pat o redirection
il client invece avrà la porta XXXXXX permessa nelle acl lato fastthernet in
usita o IN se usi cisco per la WAN metterò altre acl che chiaramente non
impediscano traffico di ritorno...) cmq
client:
client
dev tun
proto udp
remote 172.16.0.2 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert pippo1.crt
key pippo1.key
ns-cert-type server
tls-auth ta.key 1
cipher AES-128-CBC
comp-lzo
verb 3
server:
local 172.16.0.2
proto udp
dev tun
ca C:\\Programmi\\OpenVPN\\easy-rsa\\keys\\ca.crt
cert C:\\Programmi\\OpenVPN\\easy-rsa\\keys\\server.crt
key C:\\Programmi\\OpenVPN\\easy-rsa\\keys\\server.key # This file should be
kept secret
dh C:\\Programmi\\OpenVPN\\easy-rsa\\keys\\dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 172.16.0.0 255.255.255.0"
keepalive 10 120
tls-auth C:\\Programmi\\OpenVPN\\easy-rsa\\keys\\ta.key 0 # This file is
secret
cipher AES-128-CBC # AES
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
su checkpoint le regole sono queste:
accept udp 1194 e icmp tra nodo check point (2 interfacce), vpn server, vpn
client e ip virtuale 10.8.0.1 (altrimenti quando dal client pingo checkpoint
mi fa il drop visto che si presenta tramite gateway vpn)
ma in effetti la cosa che mi lascia perplesso è questa, tutto funge se metto
l'opzione "redirect-gateway"....chiaramente sui server che pingo nella
176.16.x.x dalla 10.8.0.X metto una rotta di ritorno per 10.8.0.0 verso la
macchina che fa da concentratore VPN però in effetti io non vorrei
redirigere tutto il traffico verso il server VPN cioè quella cavolo di
opzione mi sembra non saggia per i miei scopi...
poi secondo te posso migliorare un po il lato sicurezza? la cosa che ho
fatto cmq è tolgiere la ca.key dal server e metterla su 3 floppini...


 176.16.x.x dalla 10.8.0.X metto una rotta di ritorno per 10.8.0.0 verso la
Ovvio. :-)
Tu ti colleghi al server sulla classe 
172.16.0.0/24
, quindi significa
che quella classe è già raggiungibile in routing dal client vpn
attraverso il suo default gateway.
Se poi tu gli aggiungi una rotta specificando che la rete 
172.16.0.0/24
deve essere dirottata nella vpn, il client non riuscirà più a
raggiungere il server VPN perché dovrebbe passare attraverso il tunnel
anche per instaurare il tunnel (cosa ovviamente impossibile).
Per ovviare basta aggiungere prima una rotta che specifica come
raggiungere il server VPN, attraverso il tuo default gateway (che è
quello che fa la direttiva redirect gateway, solo che quest'ultima, in
più, cambia anche il default gateway).
La soluzione quindi è quella di aggiungere questa riga:
push "route 172.16.0.2 255.255.255.255 net_gateway"
prima dell'altra rotta da pushare.



che testuggine che sono.....la stessa cosa mi era successa instaurando una
interfaccia tunnel su dei cisco e dava dei log di routing
ricorsivo.......minkiazzola tengo la capacità d'associazione di un paguro in
sti tempi ahahhah
cmq grazie molte dell'aiutissimoooo
