Ceci est une ancienne révision du document !
Table des matières
OpenVPN
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.
Installer:
# 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…
VPN sans cryptage
(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:
- -route 192.168.0.0 255.255.255.0 10.4.0.2
et sur l'autre:
- -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.
VPN avec clef symetrique
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:
- -secret laclef.txt
OpenSSL
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.
Maitre des clefs
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
Les clefs du client ("k7-master")
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
====== connexion authentifié et crypté ======
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.
===== Client nomade =====
Liens:
http://www.supinfo-projects.com/fr/2005/vpn%5Fssl%5Fopenvpn/3/
Vite dit:
==== Serveur ====
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
==== Les clients ====
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
==== Au mis parcours ====
Sur le serveur:
# cat ipp.txt
KUBULAP,10.0.0.4
====== easy-rsa ======
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
===== Generate the master Certificate Authority (CA) certificate & key =====
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
==== Generate certificate & key server ====
./build-key-server server
Compagny : K6-TEAM
Common Name : server
==== Generate certificate & key for client ====
./build-key k7-home
Compagny : K6-TEAM
Common Name : K7-HOME
==== Generate certificate & key for client ====
./build-key debcave
Compagny : K6-TEAM
Common Name : DEBCAVE
==== Generate Diffie Hellman parameters ====
./build-dh
a ne faire qu'une fois bien sur!
==== Au final ====
Dans /etc/openvpn/easy-rsa/keys on a :
| dh1024.pem | Diffie Hellman parameters |
| ca.crt | root CA certificate |
| ca.key | root _private_ CA key |
| server.crt | server certificate |
| server.key | _private_ server key |
| *.crt | client certificate |
| *.key | _private_ client key |
les clefs prives des clients, doivent être sur le poste du client, et uniquement.
===== revocation =====
# cd /path/to/easy-rsa
# . vars
# ./revoke-full common-name
====== VPN configuration ======
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
===== Server =====
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
…
===== Client =====
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
===== Client special =====
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.
===== IP fixe pour un client =====
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)
====== VPN et tips ======
===== up et down-root =====
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
===== VPN et partage reseau =====
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
===== VPN et partage Internet =====
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.
===== /dev/net/tun : No such file … ====
==== Problème ====
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
==== solution ====
En fait, “udev” n'etait pas installé, et c'est lui qui créé le “nod”.
# aptitude install udev
===== Redirect gateway =====
==== Automatique ====
=== methode 1 ===
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>
( en gros de chez gros: route add -net 0.0.0.0/0 dev <tunnel> )
Mais certaines configuration n'aime pas qu'on touche la “default gateway” ainsi.
=== methode 2 ===
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.
==== A la main ====
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.
=== Avec route ===
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>
=== Avec IpTables ===
Il faut regarder la doc sur la manière de marké le communication, et associés une route a une mark.
!