Newsgroup: it.comp.os.linux.iniziare
Titolo: vpn -- parte 2

alla fine sono riuscita a creare una vpn composta di tre pc ; un server 
fedora e due client windows. vi allego i files di configurazione del 
server e di un client
+++++++++
server
+++++++++
port 1194
proto udp
dev tap
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
keepalive 10 120
tls-auth /etc/openvpn/keys/ta.key 0
cipher BF-CBC
max-clients 10
status openvpn-status.log
log         openvpn.log
verb 3
====================================
++++++++++
client
++++++++++
client
proto udp
dev tap
remote ip_del_server 1194
resolv-retry infinite
nobind
ca ca.crt
cert client.crt
key client.key
tls-auth ta.key 1 
cipher BF-CBC 
comp-lzo
persist-key
persist-tun
verb 3 
la vpn ha luogo , ed i due client ottengono rispettivamente 10.8.0.2 e 
10.8.0.3 come indirizzo ip.
qui pero' sorge davvero un problema insormanotabile per me.
i pc non si pingano !! 
nulla da fare. credo che bisogni lavorare sul routing, ma qui siamo 
davvero troppo oltre le mie scarse conscenze. 
accetto aiuti.
grazie

 i pc non si pingano !! 
man openvpn
/--client-to-client
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 /--client-to-client
grazie per la risposta, tuttavia non e' cosi' semplice , e forse mi sono 
spiegata male. io riesco a creare la vpn composta da un server e 2 client,
ma non solo i client non si pingano tra loro, ma nessun client pinga il 
server , ed ovviamente il server non pinga nessun client.
non capisco dov'e' l'inghippo.
ciao a presto

 non capisco dov'e' l'inghippo.
Se le VPN sono UP (lo vedi dai log cercando "Peer") allora trattasi di 
firewall attivo.
Verifica con iptables -L -n -v


 Verifica con iptables -L -n -v
purtroppo nessun firewall attivo. 
mi accorgo ora che sul client windows ottengo la connessione corretta 
alla vpn, infatti in basso a destra ottengo l'icona verde di notifica, 
col messaggio "connected with ip address 10.8.0.2", tuttavia un cmd ---> 
ipconfig non mi da' nulla cone indirizzo ip 10.8.0.2. insomma non c'e'.
pare non sia stato assegnato.
incollo il log del client windows openvpn
Thu Feb 05 17:59:00 2009 Control Channel MTU parms [ L:1574 D:166 EF:66 
EB:0 ET:0 EL:0 ]
Thu Feb 05 17:59:00 2009 Data Channel MTU parms [ L:1574 D:1450 EF:42 
EB:135 ET:32 EL:0 AF:3/1 ]
Thu Feb 05 17:59:00 2009 Local Options hash (VER=V4): '13a273ba'
Thu Feb 05 17:59:00 2009 Expected Remote Options hash (VER=V4): '360696c5'
Thu Feb 05 17:59:00 2009 UDPv4 link local: [undef]
Thu Feb 05 17:59:00 2009 UDPv4 link remote: 
192.168.1.100:1194
 
Thu Feb 05 17:59:00 2009 TLS: Initial packet from 
192.168.1.100:1194
, 
sid=5b0c9b22 bf53fe76
Thu Feb 05 17:59:00 2009 VERIFY OK: depth=1, /C=it/ST=at/L=asti/O=studio/
CN=studio_CA/emailAddress=
stu...@studio.it
 
Thu Feb 05 17:59:00 2009 VERIFY OK: depth=0, /C=it/ST=at/L=asti/O=studio/
CN=server/emailAddress=
stu...@studio.it
 
Thu Feb 05 17:59:00 2009 WARNING: 'link-mtu' is used inconsistently, 
local='link-mtu 1574', remote='link-mtu 1573'
Thu Feb 05 17:59:00 2009 WARNING: 'comp-lzo' is present in local config 
but missing in remote config, local='comp-lzo'
Thu Feb 05 17:59:00 2009 Data Channel Encrypt: Cipher 'BF-CBC' 
initialized with 128 bit key
Thu Feb 05 17:59:00 2009 Data Channel Encrypt: Using 160 bit message hash 
'SHA1' for HMAC authentication
Thu Feb 05 17:59:00 2009 Data Channel Decrypt: Cipher 'BF-CBC' 
initialized with 128 bit key
Thu Feb 05 17:59:00 2009 Data Channel Decrypt: Using 160 bit message hash 
'SHA1' for HMAC authentication
Thu Feb 05 17:59:00 2009 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-
RSA-AES256-SHA, 1024 bit RSA
Thu Feb 05 17:59:00 2009 [server] Peer Connection Initiated with 
192.168.1.100:1194
 
Thu Feb 05 17:59:01 2009 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Thu Feb 05 17:59:01 2009 PUSH: Received control message: 
'PUSH_REPLY,route-gateway 10.8.0.1,ping 10,ping-restart 120,ifconfig 
10.8.0.2 255.255.255.0'
Thu Feb 05 17:59:01 2009 OPTIONS IMPORT: timers and/or timeouts modified
Thu Feb 05 17:59:01 2009 OPTIONS IMPORT: --ifconfig/up options modified
Thu Feb 05 17:59:01 2009 OPTIONS IMPORT: route options modified
Thu Feb 05 17:59:01 2009 TAP-WIN32 device [NULL] opened: \\.\Global
\{B7C09F0E-7774-4AAB-8124-5C7E5DE97F03}.tap
Thu Feb 05 17:59:01 2009 TAP-Win32 Driver Version 8.4 
Thu Feb 05 17:59:01 2009 TAP-Win32 MTU=1500
Thu Feb 05 17:59:01 2009 Notified TAP-Win32 driver to set a DHCP IP/
netmask of 
10.8.0.2/255.255.255.0
 on interface 
{B7C09F0E-7774-4AAB-8124-5C7E5DE97F03} [DHCP-serv: 10.8.0.0, lease-time: 
31536000]
Thu Feb 05 17:59:01 2009 NOTE: FlushIpNetTable failed on interface [2] 
{B7C09F0E-7774-4AAB-8124-5C7E5DE97F03} (status=1413) : Indice non 
valido.  
Thu Feb 05 17:59:02 2009 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/
d=down
Thu Feb 05 17:59:02 2009 Route: Waiting for TUN/TAP interface to come 
up...
Thu Feb 05 17:59:04 2009 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/
d=down
Thu Feb 05 17:59:04 2009 Route: Waiting for TUN/TAP interface to come 
up...
Thu Feb 05 17:59:05 2009 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/
d=down
Thu Feb 05 17:59:05 2009 Route: Waiting for TUN/TAP interface to come 
up...
Thu Feb 05 17:59:06 2009 TEST ROUTES: 0/0 succeeded len=-1 ret=1 a=0 u/
d=up
Thu Feb 05 17:59:06 2009 Initialization Sequence Completed
Thu Feb 05 17:59:11 2009 Bad LZO decompression header byte: 42
Thu Feb 05 17:59:22 2009 Bad LZO decompression header byte: 42
ancora grazie,

 ancora grazie,
controlla l'esatta corrispondenza delle opzioni su ambo i lati della vpn.
insomma, es
proto tcp-client --> sul client
proto tcp-server --> sul server
vi sono diverse opzioni che deveno essere dichiarate su ambo i lati in modo
inverso. 
-- 
--------------------------------
linux slackware
tutto il resto e' inutile
--------------------------------

 Thu Feb 05 17:59:22 2009 Bad LZO decompression header byte: 42
Questo parrebbe l'effetto della mancanza di compressione.
Ti commento alcune voci di configurazione:
Lato server:
============
port 1194
proto udp
*** E' il default, puoi ometterle.
dev tap
*** Perché tap? Ti serve realmente? Normalmente l'uso di tun da meno 
problemi, anche se ovviamente devi dare una classe IP separata e ruotarla 
(cosa ovviamente banale)
tls-auth /etc/openvpn/keys/ta.key 0
*** Ti serve?
cipher BF-CBC
*** C'è un motivo per cui AES di default non ti va bene?
verb 3
*** Consiglio di metterlo a 4
Lato client:
============
proto udp
*** Default
dev tap
*** Vedi sopra
remote ip_del_server 1194
*** La porta è superflua
resolv-retry infinite
*** Se metti l'IP del server non risolvi nulla e la direttiva è superflua 
oltreché essere così di default
nobind
*** Ti serve? In genere è superfluo
cipher BF-CBC
*** Vedi sopra
comp-lzo
*** Se la usi sul client devi usarla anche sul server e viceversa.
verb 3
*** Anche qui consiglio di mettere 4
Inoltre hai problemi di MTU che non so da dove derivino ma che ti 
consiglierei di approfondire.


 consiglierei di approfondire.
mi sone messa di puntiglio ed ora funziona. innanzitutto avevo omesso la 
compressione lato server, piu' altre inesattezze . ora la vpn si attiva 
tra il server linux e 2 client windows. provato stanotte alle 2.00 . ti 
incollo i file di configurazione
server.conf 
port 1194
proto tcp
dev tap
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
keepalive 10 120
comp-lzo
tls-auth /etc/openvpn/keys/ta.key 0
cipher BF-CBC
max-clients 10
status openvpn-status.log
log         openvpn.log
verb 3
client.conf
client
proto tcp
dev tap
remote ip_del_server 1194
resolv-retry infinite
nobind
ca ca.crt
cert client.crt
key client.key
tls-auth ta.key 1 
cipher BF-CBC 
comp-lzo
persist-key
persist-tun
verb 3 
non saprei se ho ancora problemi di mtu. come posso fare per capirlo ?
entro martedi' provero' la vpn realmente, cioe' tra due sedi distanti tra 
loro. cmq qui in locale tra 3 pc differenti e' andato tutto ok.
inoltre non ho capito la differenza tra tun e tap. 
io devo solo unire un server in una citta' con 3 client in un'altra 
citta'. se funzionano sia tap che tun allora prediligo tap visto che il 
file di config mi funziona.
grazie per la risposta, e grazie anche a claudio.

 file di config mi funziona.
Non deve essere questa la discriminante perché sono due approcci diversi che 
hanno scopi diversi e problemi diversi. Quando si fa qualcosa bisogna 
innanzitutto sapere COSA si vuole fare, poi bisogna LEGGERE la 
documentazione, poi decidere COME si vuole farla e poi FARLA.
Il primo punto è chiaro, ma la mia idea è che tu abbia saltato completamente 
il secondo ed il terzo. Ti consiglio di provvedere prima di fare il quarto.
http://openvpn.net/


 
http://openvpn.net/
ho davvero provato con tutte le mie forze. 
cmq grazie.

 dovrebbe funzionare ,credo
E questa situazione è acquisita già da prima.
Ma i 3 client:
- Dovranno avere indirizzo 192.168.0.x o puoi metterli su una classe IP diversa?
- Devono prendere un indirizzo da un DHCP aziendale?
- Devono registrarsi sul DNS?
- I client della rete devono potersi collegare ai client remoti?
- Il Server è anche il default gateway di quella rete (al 99% sì)?
- Devi gestire regole di firewalling tra i client e la rete?


 gestire regole di firewalling tra i client e la rete?
solo qualche regola di iptables che metta qualche barriera su eth_1 del 
server che voglio pubblicare. magari un port knocking. il server che deve 
essere raggiungibile esporta un applicativo. per utilizzare questo 
applicativo occorre sui 3 client connettere un'unita' di rete la cui 
lettera e' obbligatoriamente Z . questo e' l'unico compito del server.
 quindi lo schema e' il seguente:
rete_mia
server  eth0 = 192.168.0.244  
	eth1 = ip_pubblico
	tap0 = 10.10.10.1 (ipotetico)
---------- 15 km di distanza ------------
rete_lontana
client 1 eth0 = 192.168.0.X
	 tap0 = 10.0.0.2 (ipotetico)
client 2 eth0 = 192.168.0.X
	 tap0 = 10.0.0.3 (ipotetico)
client 3 eth0 = 192.168.0.X
	 tap0 = 10.0.0.4 (ipotetico)
spinta dalla curiosita' ho provato qst sera lo schema di cui qui sopra, 
con entrambi i device, tap e tun. l'applicativo ha sempre funzionato, per 
fortuna, quindi dovrei farcela. ovviamente il server e' in uffcio ed io 
sono a casa mia. la cena l'ho saltata e mio marito ha provveduto da solo 
:-) .
Grazie ancora per le risposte, sto' imparando + da qst 3d che dagli how 
to.