Liens:

http://lehmann.free.fr/InstallOpenVPN.html
http://arnofear.free.fr/linux/openvpn-1.php
http://christian.caleca.free.fr/crypt/openssl.htm
http://yom.retiaire.org/doku.php?id=start:openvpn_how-to

Conseil:

Il est vivement recommandé d'utiliser un tunnel UDP à la place de TCP.

 # apt-get install openvpn

A la question “voulez-vous faire la mise a jour par le tunnel ?” (ou un truc approchant), dire NON !

S'assurer que 'liblzol“ existe…

 # dpkg -l | grep lzo
 ii  liblzo1                          1.08-3                      data compression library (old version)

Bizarre le commentaire quand même…

(Je n'ai pas vu la notion de client dans ce cas) Lien: http://lehmann.free.fr/InstallOpenVPN.html

Sur le poste A : (qui est accessoirement derriere un Firewall qui ferme tout en entrée)

 # openvpn --remote mon_ip_freebox --port 5300 --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 --comp-lzo --verb 5

Ma Freebox NAT le port 5300 vers la machiné voulu sur le port 5300 aussi.

Sur le poste B : (qui est donc derrière une Freebox configuré en mode routeur)

 # openvpn --remote mon_ip_public --port 5300 --dev tun1 --ifconfig 10.4.0.2 10.4.0.1 --comp-lzo --verb 5

A savoir: le port 5300 n'est pas accessible, car mon_ip_public est un firewall qui n'autorise pas les connexions entrante via ce port. Note: j'ai ajouté –float parce que pendant mes tests, la connexion ne remontait pas si elle tombait … (verifier les problème de sécurité induit)

Donc: 10.4.0.1 et 10.4.0.2 est un réseau point to point qu'utilise le tunnel tun1.

Normalement , ping 10.4.0.1 et ping 10.4.0.2 devrait fonctionner, mais comme j'ai un vague firewall en place, tous ce qui ressemble a une interface differente de eth0 est droppé, et donc j'ai:

 # ping 10.4.0.2
 PING 10.4.0.2 (10.4.0.2) 56(84) bytes of data.
 ping: sendmsg: Operation not permitted

Donc, on autorise:

 # iptables -A INPUT -i tun1 -j ACCEPT
 # iptables -A OUTPUT -o tun1 -j ACCEPT

Et le ping fonctionne… ou pas: car il faut bien faire quelque chose d'equivalent de chaque côté du tunnel, s'il y a un firewall a chaque bout ! Note: il peut être malin de mettre de regle de routage restrictive dés le tunnel…

Mais si l'on voit le bout du tunnel, on ne va pas au dela. Il faut router:

Mon IP sur la machine A: 10.20.0.20 Mon IP sur la machine B: 192.168.0.53

Il faut dire comment elles peuvent se trouver mutuellement… donc:

Sur la machine A:

 # route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.4.0.2

Note: a ce stade, la machine A peut se connecter a B, mais pas l'inverse !!!! L'IP de A sur B est 10.20.0.1 !!!? Sur la machine B:

 # route add -net 10.20.0.0 netmask 255.255.0.0 gw 10.4.0.1

Et voila, chacun peut se connecter aux services de l'autre… c'est beau et non crypté.

Avec openvpn, on peut aussi simplement ajouter en paramètre:

sur l'un:

1. -route 192.168.0.0 255.255.255.0 10.4.0.2

et sur l'autre:

1. -route 10.20.0.0 255.255.0.0 10.4.0.1

En passant: quand on arrete le tunnel (Control+C), les route vers tun1 disparaisse automatiquement.

Creer d'abord une clé:

 # openvpn --genkey --secret laclef.txt

C'est quoi dedans:

 # cat laclef.txt
 #
 # 2048 bit OpenVPN static key
 #
 -----BEGIN OpenVPN Static key V1-----
 634151add4e447b93ec38ba93aea7250
 ...snip...
 fa94c5bdab59655efcff09253d0e886b
 -----END OpenVPN Static key V1-----

Transferer le fichier laclef.txt sur l'autre machine.

Puis relancer le VPN sur chaque machine en précisant le cryptage a partir de la clé en fichier. Donc ajouter simplement:

1. -secret laclef.txt

Liens:

http://christian.caleca.free.fr/crypt/openssl.htm

Le fichier config (a ne pas toucher en fait): /etc/ssl/openssl.cnf

Et pourtant plus loin bas c'est /usr/lib/ssl/openssl.cnf, mais les fichiers sont identiques.

La machine “serveur” s'appelle “nin” La machine “client” s'appelle “k7-master”

Je m'autoproclame le maitre des clefs, donc:

 # openssl req -nodes -new -x509 -keyout nin-ca.key -out nin-ca.crt

Faire les clefs pour le serveur (nin): il faut se construire une clé privée et une demande de certificat:

 # openssl req -nodes -new -keyout nin.key -out nin.csr

nin.key sera la clé privée et nin.csr sera en fait un certificat à faire contresigner par l'autorité, par NIN lui-même, donc.

Dans /root/vpn (que j'ai créé):

 # mkdir demoCA
 # cd demoCA
 # touch index.txt
 # mkdir newcerts
 # echo "01" > serial

C'est a faire en suivant le modele donné par openssl.cnf

Certifier les clefs: (valide pour 7305 jours, soit 20 ans)

 # openssl ca -cert nin-ca.crt -keyfile nin-ca.key -out nin.crt -in nin.csr -days 7305
 Using configuration from /usr/lib/ssl/openssl.cnf
 Check that the request matches the signature
 Signature ok
 Certificate Details:
        Serial Number: 1 (0x1)
        Validity
            Not Before: Oct 19 09:39:02 2006 GMT
            Not After : Oct 19 09:39:02 2026 GMT
        Subject:
  ... snip ...
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Comment:
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier:
  ... snip ...
            X509v3 Authority Key Identifier:
  ... snip ...
 Certificate is to be certified until Oct 19 09:39:02 2026 GMT (7305 days)
 Sign the certificate? [y/n]:                                         

Approuver la certification des clés pour 20 ans:

 openssl ca ... -days 7305

Creer ses clefs privé/public:

 # openssl req -nodes -new -keyout k7-master.key -out k7-master.csr

Transmettre la partie public k7-master.csr au maitre des clefs nin.

Dans /root/vpn sur '''nin'

 # scp ...etc...
 ...
 # openssl ca -cert nin-ca.crt -keyfile nin-ca.key -out k7-master.crt -in k7-master.csr -days 7305

On obtient un fichier k7-master.crt. On renvoi ce fichier sur le client k7-master, ainsi que le fichier nin-ca.crt.

Retour sur k7-master:

 # la
 total 11
 drwx------  2 root root 1024 2006-10-19 12:21 .
 drwxr-xr-x 36 root root 2048 2006-10-19 12:11 ..
 -rw-r--r--  1 root root 3137 2006-10-19 12:20 k7-master.crt
 -rw-r--r--  1 root root  664 2006-10-19 12:13 k7-master.csr
 -rw-r--r--  1 root root  887 2006-10-19 12:13 k7-master.key
 -rw-r--r--  1 root root 1192 2006-10-19 12:21 nin-ca.crt

A ce stade, on pourrait simplement utilisé les clefs pour authentifier les extremités, mais je ne sais pas comment on fait et puis le but recherché est d'abort de crypté les données qui circulent.

Sur le “serveur” nin, et dans le répertoire /root/vpn, créer une clé de session pour un chiffrement symétrique des données dans le tunnel, pour les rendre confidentielles.

 # openssl dhparam -out dh1024.pem 1024

Etablir la connexion avec le client:

Sur le serveur:

 # openvpn --remote ip_du_client --port 5300 --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 --tls-server --dh dh1024.pem --ca nin-ca.crt --cert nin.crt --key nin.key --reneg-sec 3000 --comp-lzo --verb 5 --float

Sur le client:

 # openvpn --remote ip_du_serveur --port 5300 --dev tun1 --ifconfig 10.4.0.2 10.4.0.1 --tls-client --ca nin-ca.crt --cert k7-master.crt --key k7-master.key --reneg-sec 3000 --comp-lzo --verb 5 --float

Le –float est là parce que je fais passer la connexion par un firewall, et que je ne vois pas comment faire autrement.

Liens:

http://www.supinfo-projects.com/fr/2005/vpn%5Fssl%5Fopenvpn/3/

Vite dit:

Fichier /root/vpn/server.conf

 # Adresse d'ecoute du serveur VPN
 local 192.168.0.53

 # Port d'ecoute du serveur VPN
 port 5300

 # On définit que les packet seront encapsulé par le protocole UDP
 proto udp

 # On définit le type d'interface virtuelle
 dev tun

 # On définit ici le certificat de l'autorité, le certificat et la clé privée
 # d'OpenVPN
 ca nin-ca.crt
 cert k7-master.crt
 key k7-master.key

 # Parametre Diffie hellman
 dh dh1024.pem

 # Le VPN sera sur le réseau 10.0.0.0 de masque 255.255.255.0
 server 10.0.0.0 255.255.255.0

 # Fichier cache client <-> addresse IP virtuelle
 ifconfig-pool-persist ipp.txt

 # Cet directive permet d'ajouter sur les clients une route vers le réseau
 # local pour que ces derniers puissent y avoir accès
 push "route 10.20.2.0 255.255.255.0"

 # On informe ici que les nomades pourront communiquer entre eux.
 client-to-client

 # Directive keepalive utilisé pour vérifier si la connection est toujours
 # active. Le premier argument correspond à l'intervalle en seconde
 # pour les pings, et le second au timeout.
 keepalive 10 120

 # Alogorithme de cryptage utilisé pour le chiffrement symétrique
 cipher AES-128-CBC

 # Autoriser la compression
 comp-lzo

 # Nombre maximum de clients
 max-clients 5

 # Reduction des privileges du daemon openvpn pour plus de sécurité
 user nobody
 #group nobody
 group nogroup
 chroot /etc/openvpn

 # On définit ici un fichier qui permettra de savoir qui est connecté au
 # VPN
 status openvpn-status.log

 persist-key
 persist-tun

 # Niveau log
 verb 5

Et puis lancer ainsi dans /root/vpn:

 # openvpn --config server.conf

Le fichier /root/vpn/client.conf:

 # On specifie ici qu'on execute OpenVPN en tant que client
 client

 # On decrit le type d'interface virtuelle
 dev tun

 # On decrit que les packet seront encapsuléar le protocole UDP
 proto udp

 # On decrit ici l'adresse du serveur et le port sur lequel on veut se
 # connecter
 remote 192.168.0.53 5300

 #On decrit ici le certificat de l'autorite certificat et la cle du
 # client
 ca nin-ca.crt
 cert kubulap.crt
 key kubulap.key

 # Algorithme de cryptage a utiliser
 cipher AES-128-CBC

 # Authoriser la compression
 comp-lzo

 persist-key
 persist-tun

 # Niveau de log
 verb 5

Et puis (dans /root/vpn) :

 # openvpn --config client.conf

Sur le serveur:

 # cat ipp.txt
 KUBULAP,10.0.0.4

On recommence avec easy-rsa

 $ dpkg -S easy-rsa
 ...
 /usr/share/doc/openvpn/examples/easy-rsa/2.0/
 ...
 /usr/share/doc/openvpn/examples/easy-rsa

Utiliser la version 2.0 ou l'autre ? alors que:

 $ dpkg -l | grep vpn
 ii  openvpn                                2.0.6-1

Finalement, les 2 versions font l'affaire, mais a l'avenir, j'utiliserai la version 2 (dans easy-rsa/2.0). J'ai pris soin d'extraire le script central comme cela:

 # zcat pkitool.gz >pkitool
 # chmod a+x pkitool

C'est un mystere (pour moi) sur le pourquoi on doit faire ça…

Bref:

 # cd /usr/share/doc/openvpn/examples/
 # cp -R easy /etc/openvpn/

PKI = Public Key Infrastructure CA = Certificate Authority

Allons dans le bon répertoire:

 # cd /etc/openvpn/easyrsa

Personaliser le fichier vars: (Exemple)

 ...
 export KEY_COUNTRY=FR
 export KEY_PROVINCE=NA
 export KEY_CITY=PARIS
 export KEY_ORG="KK-TEAM"
 export KEY_EMAIL="mon_mail@mon_domain.fr"

NE FAIRE QU'UNE FOIS POUR INITIALISER Initialize the PKI

 # . ./vars
 # ./clean-all
 # ./build-ca

Pour la suite, il suffira de refaire . ./vars pour preparer l'environnement.

Remplir les champs necessaires:

 Common Name : NIN-CA

 ./build-key-server server
 Compagny : K6-TEAM
 Common Name : server

 ./build-key k7-home
 Compagny : K6-TEAM
 Common Name : K7-HOME

 ./build-key debcave
 Compagny : K6-TEAM
 Common Name : DEBCAVE

 ./build-dh

a ne faire qu'une fois bien sur!

Dans /etc/openvpn/easy-rsa/keys on a :

les clefs prives des clients, doivent être sur le poste du client, et uniquement.

 # cd /path/to/easy-rsa
 # . vars
 # ./revoke-full common-name

Attention

Tout ce qui est dans /etc/openvpn/ et se terminant par .conf est demarré automatiquement au moment de:

 /etc/init.d/openvpn start

(comprendre: au boot aussi)

Astuce: je créé les fichiers dans un sous repertoire, par exemple ./conf et je cree des liens symboliques lorsque je valide une configuration:

 # cd /etc/openvpn
 # ln -s conf/client.conf 
 ...

Un petit ps aux | grep vpn le montre, et aussi la dedans:

 /var/run/openvpn.(name).status
 /var/run/openvpn.(name).pid

Dans /etc/openvpn, on fait: (On recupere la config en exemple)

 # zcat /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz > k6-server.conf 

Puis on adapte k6-server.conf :

 ...
 ca easy-rsa/keys/ca.crt
 cert easy-rsa/keys/server.crt
 key easy-rsa/keys/server.key  # This file should be kept secret
 ...
 dh easy-rsa/keys/dh1024.pem
 ...
 push "route 172.16.0.0 255.255.255.0"
 ...
 user nobody
 group nogroup
 ...

On recuperer l'exemple et on adapte:

 # cd /etc/openvpn
 # cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf .
 # vi client.conf
 ...
 remote adresse_public_server 1194
 ...
 user nobody
 group nogroup
 ...
 ca keys/nin/ca.crt
 cert keys/nin/k7-home.crt
 key keys/k7-home.key

Et voila…

 # openvpn --config client.conf

ou

 # /etc/init.d/openvpn start 

A voir: http://blog.eglis.com/index.php/2005/09/09/23-openvpn-c-est-trippan

A partir du “Common name”, et si le fichier de config du serveur contient a truc du genre:

 client-config-dir ccd

Alors une config appellé “Common_name_du_client” est recherché dans ccd/. Dedans, on y insere une config specifique a ce client. (mais faut pas trop déliré…). Exemple:

 iroute 10.18.0.0 255.255.255.0

Cela dit au serveur vpn que lorsque le client (common named) est authentifié, appliquer le routage iroute vers ce client. (dans cette exemple, ce qui est destiné au 10.18.0.0/24 est routé vers ce client): toutefois, il ne faut pas oublier de specifier “route 10.18.0.0 255.255.255.0” dans le fichier principale, parce ce que: “iroute” configure de routage interne du VPN, alors que “route” applique le routage au niveau couche reseau du kernel.

 ifconfig-push 10.8.0.189 10.8.0.190

Force le client a avoir pour ip '…189' alors que le serveur aura '…190' … c'est pas trés utile et (je crois que) les couples d'IP client/serveur doivent repondre a certaines restrictions.

On peut voir les restrictions d'ip là:

http://www.urec.cnrs.fr/IMG/pdf/articles.05.OpenVPN.pdf

Exemple:

 [ 1, 2]   [ 5, 6]   [ 9, 10]  [ 13, 14] [ 17, 18]
 [ 21, 22] [ 25, 26] [ 29, 30] [ 33, 34] [ 37, 38]
 [ 41, 42] [ 45, 46] [ 49, 50] [ 53, 54] [ 57, 58]
 [ 61, 62] [ 65, 66] [ 69, 70] [ 73, 74] [ 77, 78]
 [ 81, 82] [ 85, 86] [ 89, 90] [ 93, 94] [ 97, 98]
 [101,102] [105,106] [109,110] [113,114] [117,118]
 [121,122] [125,126] [129,130] [133,134] [137,138]
 [141,142] [145,146] [149,150] [153,154] [157,158]
 [161,162] [165,166] [169,170] [173,174] [177,178]
 [181,182] [185,186] [189,190] [193,194] [197,198]
 [201,202] [205,206] [209,210] [213,214] [217,218]
 [221,222] [225,226] [229,230] [233,234] [237,238]
 [241,242] [245,246] [249,250] [253,254]

Exemple de serveur ayant un pool d'ip fixe et dynamique:
Dans le serveur et openvpn.conf, au lieu de faire:

 server 10.21.0.0 255.255.255.0

Faire ceci (par exemple):

 mode server
 tls-server
 ifconfig 10.21.0.1 10.21.0.2
 ifconfig-pool 10.21.0.128 10.21.0.254
 route 10.21.0.0 255.255.255.0
 push "route 10.21.0.0"

Cela a l'avantage de partager le reseau en 2 pool (en quelque sorte):
Entre les ip en .128 et .254, on aura les ip alloué dynamique (un peu comme avec dhcp).
Entre les ip en .0 et .127, on pourra definir des ip fixe, en etant sur que les ip dynamiques ne viendront pas foutre leur bordel !

Au niveau du client, par exemple:

 vi ccd/le_client
 ...
 ifconfig-push 10.21.0.65 10.21.0.66

Et voila le client vpn avec une IP fixe !

Lorsqu'on a fait des modifications sur le fichier de configuration specifique au client, il suffit de faire sur le client:

 # /etc/init.d/openvpn restart

Autre exemple:

 push "route 10.18.0.0 255.255.255.0"

Ce qui va injecter ce routage vers le vpn, dans le client.

Router par defaut:

 push "redirect-gateway"

Et voila… le client surfe via le tunnel VPN (notons que la connexion vers le VPN est correctement routé vers le serveur, qui est finalement la seule communication qui ne passe pas par le tunnel)

Pour demarrer un script juste aprés la creation du tunnel, ajouter dans openvpn.conf:

 up /etc/openvpn/scripts/mon_script-up

Et pour l'arret:

 down /etc/openvpn/scripts/mon_script-down
 down-pre

(down-pre demarre le scripte avant la fermeture du tunnel)

Mais hélas, ca ne fonctionne qu'en root, alors qu'on a choisit de faire fonctionne le vpn en nobody.
Pour forcer l'execution du script down avec les droits root, il faut utiliser le plugin down-root et apporter les modifications suivantes dans openvpn.conf.

 plugin /usr/lib/openvpn/openvpn-down-root.so "/etc/openvpn/scripts/mon_script-down"
 down-pre

On suppose 1 client vpn relié par VPN a un autre reseau local (VPN serveur). Sur notre reseau local (coté client donc), on aimerait bien atteindre les reseaux 172.16.0.* et 10.20.0.* par exemple, mais sans trop affecter les postes.

Simple:

router ces classes vers le client VPN:

 # route add -net 172.16.0.0 netmask 255.255.255.0 gw 192.168.0.50
 # route add -net 10.20.0.0 netmask 255.255.255.0 gw 192.168.0.50

Vous l'avez compris: ce client VPN a donc l'IP 192.168.0.50.

Sur ce client VPN, il faut appliquer quelques routages: si le serveur VPN est bien configuré, c'est fait automatiquement:

Fichier de conf du serveur VPN:

 ...
 push "route 172.16.0.0 255.255.255.0"
 push "route 10.20.0.0 255.255.0.0"
 ...

(Sinon, faire ça a la main.)

Avec IPTABLES:

 # rejeter les invalides
 /sbin/iptables -A FORWARD -o tun0 -m state --state INVALID -j REJECT
 # forwarder seulement s'il a la bonne mac
 /sbin/iptables -A FORWARD -o tun0 -m mac --mac-source 00:XX:XX:XX:XX:XX -j ACCEPT
 # ou s'il a la bonne classe d'adresse... (par exemple)
 /sbin/iptables -A FORWARD -o tun0 -s 212.27.35.0/24 -j ACCEPT
 ...
 # rejeter les autres (un DROP est trop vulgaire)
 /sbin/iptables -A FORWARD -o tun0 -j REJECT
 # en entrée, accepter seulement ce qui est deja en service, et pas de nouvelle connexion
 /sbin/iptables -A FORWARD -i tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT
 # etre certain de n'envoyer que vers les IP local de l'autre reseau
 # en appliquant un 'MASQUERADE' (l'adresse de 'tun0' etant variable, sinon
 # j'aurai utiliser 'SNAT')
 /sbin/iptables -A POSTROUTING -t nat -o tun0 -d 172.16.0.0/24 -j MASQUERADE
 /sbin/iptables -A POSTROUTING -t nat -o tun0 -d 10.20.0.0/24 -j MASQUERADE
 # si on veut que la machine elle même puisse aussi atteindre ce reseau:
 /sbin/iptables -A OUTPUT -o tun0 -m state --state '!' INVALID -j ACCEPT
 /sbin/iptables -A INPUT -i tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT

Et le reste va dans le DROP (cause this is the default policy)

Sur le serveur VPN, avec IPTABLES, il faut aussi lui expliquer comment traiter les connexions arrivant de son tun0.

 # les client VPN sont dans la classe d'adresse 10.8.0.0/24
 /sbin/iptables -A INPUT -i tun0 -s 10.8.0.0/24 -j ACCEPT
 /sbin/iptables -A OUTPUT -o tun0 -d 10.8.0.0/24 -j ACCEPT
 # on autorise globalement les forward
 /sbin/iptables -A FORWARD -i tun0 -j ACCEPT
 /sbin/iptables -A FORWARD -o tun0 -j ACCEPT
 # NATer les connexions avec les propres IP du serveur
 /sbin/iptables -A POSTROUTING -t nat -o eth0 -s 10.8.0.0/24 -d 172.16.0.0/24 -j SNAT --to 172.16.0.251
 /sbin/iptables -A POSTROUTING -t nat -o eth0 -s 10.8.0.0/24 -d 10.20.0.0/24 -j SNAT --to 10.20.0.251

Et voila, a partir d'un poste router vers un client VPN, on peut atteindre n'importe quel serveur a partir du serveur VPN:

 $ ping 172.16.0.35
 PING 172.16.0.35 (172.16.0.35) 56(84) bytes of data.
 64 bytes from 172.16.0.35: icmp_seq=1 ttl=126 time=51.3 ms

Le but est maintenant de permettre aux mêmes clients ci-dessus, d'atteindre l'Internet du côté du serveur VPN… C'est facile..

Sur le client, modifier la gateway par defaut:

 # route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.0.50

Puisque le fameux client VPN est en 192.168.0.50. Ne pas oublier de virer l'ancienne route par defaut.

Sur le client VPN, expliquer que les postes ayant tel ou tel IP, doivent être router vers le tunnel VPN, quelque soit leur destinataire.

Si necessaire, installer le package iproute et puis:

 # echo 200 gwvpn >> /etc/iproute2/rt_tables

Dire qu'on veut appliquer la regle gwvpn pour un paquet venant de l'ip ci-dessous:

 # ip rule add from 192.168.0.62 table gwvpn

Le but etant d'appliquer ce routage par defaut: (il n'est pas necessaire de preciser l'ip du tunnel)

 # ip route add default dev tun0 table gwvpn

Ok?

 # ip route show table gwvpn
 default dev tun0  scope link

Rappel:

Les commandes ip … ne survive pas a un reboot. Les modifications de routage peuvent avoir besoin d'une commande comme: ip route flush cache

Au niveau d'IPTABLES, ajouter:

 /sbin/iptables -A POSTROUTING -t nat -o tun0 -j MASQUERADE

Ce qui a pour simple effet de NAT tous ce qui sort vers tun0

Au niveau du serveur VPN, ajouter:

 /sbin/iptables -A POSTROUTING -t nat -o eth0 -s 10.8.0.0/24 -j SNAT --to 10.20.0.251

Ce qui va SNAT avec l'ip du serveur VPN.

Le serveur VPN etant routé par defaut vers le NET , tout ce qui vient d'un client routé vers le client VPN, est transmis au serveur VPN qui va lui même envoyer vers le NET.

J'ai eu ça:

Aug  4 11:15:28 netcave ovpn-client-ild-eko[2035]: Note: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)

La solution provisoire:

# mkdir /dev/net
# mknod /dev/net/tun c 10 200
# modprobe tun

En fait, “udev” n'etait pas installé, et c'est lui qui créé le “nod”.

# aptitude install udev

Pour le client (dans le ccd par exemple), ajouter:

push-reset
push "redirect-gateway"

Ce qui aura grossièrement l'effet de faire sur le client, une:

# route add default dev <tunnel>

Mais certaines configuration n'aime pas qu'on touche la “default gateway” ainsi.

push-reset
push "redirect-gateway def1"

Ce qui fera plutôt:

# route add -net 0.0.0.0/1 dev <tunnel>
# route add -net 128.0.0.0/1 dev <tunnel>

Ce qui est plus supportable… parfois.

En fait, je préfère jouer avec “iproute2” plutôt que de laisser “openvpn” defoncer ma route par defaut.

Pour la conf client (ccd?) ajouter:

iroute 0.0.0.0 0.0.0.0.0
push-reset

On autorise tout a passer, sans rien faire côté client.

Sur le client, on ajoute le routage vers la nouvelle gateway à la main.

Sans iptables, on peut faire un truc comme ça:

# route add -host <IP_DU_SERVEUR_VPN> gw <GATEWAY>

Et enfin:

# route add -net 0.0.0.0/1 dev <tunnel>
# route add -net 128.0.0.0/1 dev <tunnel>

Il faut regarder la doc sur la manière de marké le communication, et associés une route a une mark.

!