OpenVPN : solution indépendante du système et libre

15 septembre 2006

Télécharger en PDF


Table des matières

I.Introduction 2

II.Fonctionnement 2

1.Principe général 2

2.Mode routed 2

a)Principe 2

b)Limitations dues à Windows 4

c)Donner accès au réseau du serveur ou des clients 5

3.Mode bridged 5

a)Ethernet Bridging 5

b)Principe 6

c)Fonctionnalités 7

d)Limitation de Windows 7

4.Analogie avec une liaison physique 7

5.Préauthentification 8

6.Avantages du Bridging 8

a)Inconvénients du Bridging 8

b)Avantages du Routing 8

c)Inconvénients du Routing 9

III.Mise en place 9

1.Configuration du noyau 9

2.Installation 9

3.Test 10

4.Génération des clés 10

5.Et si je met une passphrase pour crypter mes clés 12

6.Configuration du serveur en mode Routed 12

7.Configuration du serveur en mode Bridged 13

a)Script de démarrage supplémentaires 13

b)Configuration du serveur 15

8.Configuration du client 16

a)Configuration du client sous Linux 16

b)Configuration du client sous Windows 16

c)Configuration en mode Routed 16

d)Configuration en mode Bridged 17

9.Utilisation 18

10.Pare-feu serveur 18

a)Mode routed 18

i.Connexion sur le serveur 18

ii.Connexion au réseau interne derrière le serveur 19

b)Mode bridged 19

i.Si vous utilisez un noyau 2.4 19

ii.Règles de filtrage 19

c)Pare-feu client 20

d)Règles à éviter 21

11.Considération de sécurité 21

IV.Annexe : le protocole SSL et OpenSSL 21

1.Qu'est-ce qu'OpenSSL ? 21

2.Connexion SSL 21

V.Bibliographie 24


I.Introduction

OpenVPN est une solution qui se base sur SSL. Cela permet d'assurer deux choses à la fois, sans avoir besoin de beaucoup de logiciel côté client :



Il permet par exemple de résoudre les problèmes de NAT en offrant la même protection qu'IPSec mais sans les contraintes.

II.Fonctionnement

Il existe deux modes de fonctionnement de OpenVPN :



1.Principe général

Le principe général est de relier les /dev/tun ou /dev/tap du serveur et des clients par un canal sécurisé par OpenSSL.




2.Mode routed

a)Principe

Le principe général (sans tenir compte des sous réseaux /30) d'OpenVPN est le suivant :



Le serveur VPN a donc deux IP virtuelles (non pingables) ce qui lui permet de servir de passerelle antre la machine cliente qui a une IP réelle sur une interface virtuelle et la machine serveur qui a aussi une IP réelle sur une interface virtuelle (la machine, pas seulement le serveur OpenVPN).



Cela peut se résumer par le schéma suivant :




b)Limitations dues à Windows



OpenVPN est obligé d'allouer un sous réseau /30 pour chaque client qui se connecte en mode routed pour garder la compatibilité sur tous les OS. Ceci est dû aux limitation du mode d'émulation TUN du pilote TAP-Win32 sous Windows.

On peut néanmoins indiquer à OpenVPN de ne pas avoir ce comportement si l'on sait qu'il n'y a pas de clients Windows. On indique alors dans le fichier de configuration ifconfig-pool-linear.

Dans la version 2.0, le serveur peut accueillir plusieurs clients sur la même interface TUN. Cela se réalise de la façon suivante :



Si tous les OS pouvaient utiliser une vrai liaison point à point sur l'interface TUN, il suffirait d'avoir une adresse IP pour le serveur et une individuelle pour chaque client. Mais sous Windows, on ne peut pas. Cela génère une sorte de gâchie d'IP mais cela permet d'être portable puisque l'on permet 3 adresses sur 4. Il faut donc simuler une liaison point à point par un sous réseau de quatre IP :

Le pilote TAP-Win32 inclu un serveur DHCP virtuel qui assigne au client la seconde adresse IP du sous réseau /30 du client. On voit donc la première adresse IP comme ce serveur DHCP virtuel.



c)Donner accès au réseau du serveur ou des clients



Pour autoriser les clients à accéder au réseau qui se trouve derrière le serveur, il faut indiquer au client que la passerelle pour accéder à ce réseau est l'IP du serveur dans le réseau /30 du client, donc l'adresse IP juste avant celle du client. Cela se fait par la directive push route dans le fichier de configuration.



3.Mode bridged

a)Ethernet Bridging



Ethernet Bridging désigne l'action de regrouper plusieurs interfaces physiques (cartes Ethernet) et/ou virtuelles (TAP) sur un même pont (bridge, une interface de remplacement/regroupement) gérée de manière logicielle afin de partager un même sous réseau sur plusieurs interfaces. C'est en quelque sorte, un switch logiciel qui écoute sur toutes les interfaces pontées et fait le tri, comme un switch pour dispatcher vers la bonne sortie (interface).

On pourrait représenter un pontage comme un aiguillage automatique (un switch) :






La configuration IP se fait alors sur l'interface Bridge et pas sur les interfaces physiques ou virtuelles bridgées. En effet, le bridge a pour effet d'effacer la configuration IP des interfaces qu'elle bridge pour les passer en Promiscious et donc faire un traitement logiciel des paquets entrants et sortant des interfaces bridgées.

Il faut donc toujours configurer l'interface Bridge avant d'ajouter des interfaces physiques ou virtuelles au bridge sans quoi la configuration IP est perdue.

b)Principe

Le principe du mode bridged est le suivant, par exemple si la carte réseau à bridger est eth0 :



Note : dans le cas du bridge, toutes les adresses IP sont réelles et peuvent donc être pinguées.

Cela peut donc se résumer par le schéma suivant :




c)Fonctionnalités

Le mode bridged permet d'obtenir les fonctionnalités d'Ethernet (niveau 2 de la pile IP) comme le transport natif des protocoles de niveau 3 comme NetBIOS ou IPX et pas seulement IP comme dans le mode routed. Cela permet aussi de faire des broadcast sur les deux réseaux relié. On configure (avec un utilitaire comme brctl sous Linux) le bridge sur la machine client et serveur ce qui permet de relier les deux réseaux qui sont derrières ces deux machines.

Le mode routed est plus simple dans le cas où l'on n'a pas besoin de ces fonctionnalités d'Ethernet.

On peut connecter des machines dans les deux modes pour créer des architectures relativement complexes mais cela n'est pas l'objet de ce guide.



d)Limitation de Windows

Toutes les versions de Windows peuvent servir pour un client. Pour faire un serveur OpenVPN avec Windows, il faut dans ce cas avoir XP, 2003 ou supérieur.

4.Analogie avec une liaison physique



Imaginons que l'on ait un cable directe entre deux ordinateurs A et B situés dans différents lieux. Sur chaque ordinateur, on aura dans la tradition UNIX, /dev/cableAB qui devrait être un périphérique réseau. Il suffirait alors de déclarer une route passant par ce périphérique et on pourrait s'en servir comme une interface réseau classique. Le cable relie les deux périphériques sur les deux ordinateurs.

Eh bien c'est ce que TUN et TAP font. C'est exactement comme notre hypothétique /dev/cableAB. Et le cable est le démon OpenVPN client et serveur. C'est lui qui sert de liason entre les deux /dev/tun. De plus, dans le cas de OpenVPN, le moyen de liaison entre l'ordinateur A et B peut être ce que l'on veut y compris Internet.

Et OpenVPN relie les deux /dev/tun en identifiant d'abord les deux ordinateurs puis en cryptant les données dans des paquets UDP entre ces deux entités. De plus, il récupère le traffic entrant dans /dev/tun sur A pour le faire sortir sur B et inversement. Enfin, cela est d'autant plus simple que les pilotes TUN et TAP ont été prévus pour être accessible par le niveau 3 (userland) autrement dit par des applications traditionnelles et PAS dans des modules niveau 0 (noyau). Cela permet donc d'être portable contrairement à IPSec qui nécessite de créer des modules noyaux donc différents entre les versions de Linux et pour Windows, je n'en parle même pas.



La différence entre un périphérique TUN et TAP est simple. TUN est un périphérique qui crée une liaison virtuelle IP point à point qui peut donc gérer seulement 2 IP. TAP est un périphérique Ethernet virtuel qui peut donc gérer un réseau virtuel. Si l'on reprend notre /dev/cableAB, un TUN revient à voir une liaison T1 par exemple connectée entre le PC A et le PC B. Un TAP revient alors à avoir une réseau Ethernet reliant les deux ordinateurs A et B.

5.Préauthentification



OpenVPN utilise OpenSSL pour créer le canal crypté.



Le fichier ta.key (tls-auth) permet d'éviter les attaques par Deny of Service. Cela peut se produire lorsque le serveur reçoit énormément de demande d'authentification (qui demande de la mémoire et du temps processeur). En effet, lorsqu'il est configurer pour utiliser cette clé, le client qui n'est encore authentifié par le handshake de TLS (avec les certificats clients et serveur) doit signer ses paquets avec la clé ta.key sans quoi le serveur le supprime sans chercher à aller plus loin dans l'authentification. C'est donc une clé qui est partagée entre les clients et le serveur. Un attaquant qui, par définition, n'a pas la clé ta.key ne peut pas commencer son authentification sur le serveur et donc ne pourra pas lui faire consommer le temps CPU nécessaire à un faux début de handshake TLS. Cela est donc un contrôle avant l'authentification pour ne pas chercher à authentifier une machine dont on est sûr qu'elle ne réussira pas l'authentification.

6.Avantages du Bridging

a)Inconvénients du Bridging

b)Avantages du Routing

c)Inconvénients du Routing



III.Mise en place

1.Configuration du noyau



Il peut être utile de mettre en place le patch GRSecurity pour votre noyau.



OpenVPN utilise le périphérique TAP/TUN comme interface.

Il faut donc l'avoir activé dans la noyau :

Network device support -> Universal TUN/TAP device driver support



Pour vérifier si ce périphérique est inclu dans le noyau ou dans un module de celui-ci :

cat /boot/config-`uname-r` |grep TUN

Doit renvoyer au moins une ligne telle que : CONFIG_TUN=y ou CONFIG_TUN=m



Normalement, il devrait y avoir un device /dev/net/tun, sinon, il faut le créer par :

[root]# mkdir /dev/net/ && mknod /dev/net/tun c 10 200

2.Installation



OpenVPN dépend de :



L'installation peut se faire comme d'habitude :

Dans le premier cas, tous les dossiers mentionnés sont dans le répertoire des sources de OpenVPN. Dans le second cas, elles sont dans le dossier /usr/share/doc/openvpn-2.0/.



Il sera alors possible de lancer openvpn par /etc/init.d/openvpn start.



Vous pouvez utilisez le script de démarrage que vous trouverez dans le dossier sample-config-files.

Pour un démarrage automatique d'OpenVPN à chaque redémarrage taper :

chmod 755 /etc/init.d/openvpn
ln -s /etc/init.d/openvpn /etc/rc3.d/S90openvpn
ln -s /etc/init.d/openvpn /etc/rc6.d/K90openvpn

3.Test

Une fois l'installation terminée, rendez vous dans le dossier d'installation d'OpenVPN et taper :

./openvpn --genkey --secret key
./openvpn --test-crypto --secret key

./openvpn --config sample-config-files/loopback-server

Dans une autre console taper :

./openvpn --config sample-config-files/loopback-client

Si tout ce passe bien, la connexion devrait se terminer au bout d'une ou deux minutes sans messages d'erreurs.

4.Génération des clés



OpenVPN nécessite un certain nombre de clés :



Note : les fichiers .key (ou .pem contenant une clé privée) doivent absolument avoir au maximum les droits 600 et appartenir à l'utilisateur qui s'en sert.



Heureusement, OpenVPN fournit un script pour faire cela de façon beaucoup plus simple. Pour cela, allez dans le dossier easy-rsa puis :

export D=/usr/share/doc/openvpn-2.0/easy-rsa
export KEY_CONFIG=$D/openssl.cnf
export KEY_DIR=$D/keys
export KEY_SIZE=1024
export KEY_COUNTRY=FR
export KEY_PROVINCE=Département
export KEY_CITY=Ville
export KEY_ORG="Nom serveur VPN"
export KEY_EMAIL="email_administrateur"
source ./vars
mkdir keys
touch keys/index.txt
echo 01 > keys/serial

Il faut utiliser des Common Name (CN) unique pour chacun des clients et du serveur sinon votre serveur ne fonctionnera pas ! Il faut aussi un Organization Name (ON) commun au serveur et aux clients (c'est le nom de votre VPN). Pour les autres renseignements, la valeur par défaut est indiquée entre [] et correspond à ce que vous avez mis dans le fichier vars. Lorsque l'on vous demande si les certificats doivent être signés répondez y.

./build-dh
./build-ca
./build-key-server nom_serveur
./build-key nom_unique_client 

Il est important que les fichiers .key contenant les clés privées des clients soient transmises par un canal sûr comme SSH. En effet, toute la sécurité de OpenVPN repose sur la bonne transmission de ces fichiers clés. Les fichier .crt ne nécessitent pas une vigilence particulière car ils ne contiennent que des informations publiques.

../openvpn --genkey --secret keys/ta.key
mv keys/ /etc/openvpn/keys && chown -R nobody:nobody /etc/openvpn/keys

5.Et si je met une passphrase pour crypter mes clés



Cela est possible mais dans ce cas vous devrait utiliser la commande askpass dans les fichiers de configuration. Il y a deux solutions :

6.Configuration du serveur en mode Routed

Dans le fichier /etc/openvpn/server.conf :

#socket en écoute sur IP_publique:numero_port en UDP

local IP_ou_nom_DNS_publique

port 1194 #numéro de port enregistré à l'IANA

proto udp #ou tcp

#précise la connexion Routed (/dev/tun)

dev tun

#serveur

mode server

tls-server

#taille max des paquets passant par l'interface /dev/tun

tun-mtu 1500

mssfix

#fichier contenant le certificat de la CA créée

ca keys/ca.crt

#fichier contenant la clé privée et le certificat du serveur

cert keys/nom_serveur.crt

key keys/nom_serveur.key # This file should be kept secret (600)

#paramètres Diffie-Hellman

dh keys/dh1024.pem

#fichier pour empêcher le man-in-the-middle

tls-auth keys/ta.key 0 # This file is secret, 0 = serveur


#adresse du réseau VPN dans lequel vont se trouver les clients et le serveur

#ce réseau ne doit ni être ceux autour du client ni du serveur

#le serveur prendra la première adresse libre de la plage du pool

server adresse_réseau_vpn masque_reseau_vpn

# ou plage des adresses clients dans le VPN

#ifconfig-pool première_adresse_IP_allouable dernière_adresse_IP_allouable


#ajoute la route au serveur pour qu'il puisse accéder au VPN

route adresse_réseau_vpn masque_reseau_vpn

#ajoute la route au client pour qu'il puisse accéder au VPN

push "route adresse_réseau_vpn masque_reseau_vpn"


#ajoute une route au client pour qu'il puisse accéder à un réseau

# se trouvant derrière le serveur

push "route adresse_réseau_serveur masque_reseau_serveur"


#autorise les clients à se voir entre eux sur le VPN

client-to-client


keepalive 10 120

cipher BF-CBC

comp-lzo


#nombre maximum de clients sur le VPN

max-clients nb_max_client


#utilisateur et groupe

user nobody

group nobody #ou nogroup sous debian


#jail dans /usr/local/openvpn

#chroot /usr/local/openvpn

#les logs (mkdir /var/log/openvpn)

status /var/log/openvpn/status.log

log-append /var/log/openvpn/openvpn.log


#niveau de log pas encore trop bavard

verb 4

#ne pas répéter les messages de logs identiques plus de 10 fois

mute 10


#si l'interface d'écoute à une IP dynamique :

#float

#persist-tun #ne pas fermer le tunnel en cas de changement IP

#persist-remote-ip #ne pas changer l'IP des clients

#persist-key #le serveur ne relie pas les clés si nobody

7.Configuration du serveur en mode Bridged

a)Script de démarrage supplémentaires

Si vous souhaitez utiliser un serveur OpenVPN et bridger votre interface locale, un script de bridging peut vous être utile. Il faut d'abord installer brctl.

Fichier /etc/init.d/bridge-start :

#!/bin/bash

#################################
# Set up Ethernet bridge on Linux
# Requires: bridge-utils
#################################

# Define Bridge Interface
br="br0"

# Define list of TAP interfaces to be bridged,
# for example tap="tap0 tap1 tap2".
tap="tap0"

# Define physical ethernet interface to be bridged
# with TAP interface(s) above.
eth="interface_eth_à_bridger"
eth_ip="IP_interface_à_bridger"
eth_netmask="masque_interface_à_bridger"
eth_broadcast="adresse_broadcast_interface_à_bridger"

# construit des tunnels persistants pour que brctl ne perde pas ses TAP quand 
# openvpn redémarre les tunnels (restart par inactivité...)
for t in $tap; do
    openvpn --mktun --dev $t
done


#crée l'interface du bridge
brctl addbr $br
#ajoute l'interface physique Ethernet au bridge 
# (pour ne pas perdre les entrées sorties autres que le VPN)
brctl addif $br $eth

#ajoute les TAPs au bridge (pour faire sortir le tunnel VPN sur le réseau)
for t in $tap; do
    brctl addif $br $t
done

# c'est l'interface du bridge $br 
# qui fait le routing des paquets reçus sur la carte réseau 
# à la place de celle-ci (mode promiscious)

#configure les TAPs pour écouter (et recevoir) tous les paquets
# et faire le tri de façon logicielle : 
# cela permet d'avoir autant d'IPs que l'on veut sur la même carte Ethernet
for t in $tap; do
    ifconfig $t 0.0.0.0 promisc up
done

#configure l'interface physique Ethernet du bridge pour écouter tous les paquets
# et faire le tri de façon logicielle
ifconfig $eth 0.0.0.0 promisc up

#configure le bridge pour se mettre à la place 
# de l'interface Ethernet physique bridgée
ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast

Fichier /etc/init.d/bridge-stop :

#!/bin/bash

####################################
# Tear Down Ethernet bridge on Linux
####################################

# Define Bridge Interface
br="br0"

# Define list of TAP interfaces to be bridged together
tap="tap0"

#désactiver l'interface du bridge
ifconfig $br down
#supprimer l'interface du bridge dans le logiciel de bridging
brctl delbr $br

#retirer les TAPs persistant puisque l'on arrête le bridge
for t in $tap; do
    openvpn --rmtun --dev $t
done

#note : cela ne remet pas en place l'interface physique Ethernet bridgée

Faire un chmod 755 sur /etc/init.d/bridge-st*. Si vous souhaitez le démarrer automatiquement, c'est même le principe qu'avec le fichier /etc/init.d/openvpn, faites des liens symboliques dans /etc/rc.d/rc3.d ou /etc/rc.d/rc5.d.

On lance d'abord le bridge puis openvpn. On stoppe d'abord openvpn puis le bridge.

Attention : l'interface bridgée ne doit pas être l'interface de connexion des clients au serveur Vpn (par exemple sur le port 5000) sans quoi vous tourneriez en rond avec les routes mise en place. Ce ne doit pas être un interface de connexion directe à Internet car cela causerait un énorme trou de sécurité.

b)Configuration du serveur

Pour un serveur bridgé, voici une configuration.
Fichier /etc/openvpn/server.conf :

#écoute sur IP_publique_serveur:1194 en UDP
local IP_publique_serveur
port 1194
proto udp

#mode bridgé
dev tap0 #il vaut mieux indiquer tap0 que tap car sinon ca marche moins bien

#serveur
mode server

tls-server
tun-mtu 1500
mssfix
persist-key
persist-tun

#les clés et certificats
ca keys/ca.crt
cert keys/certificat-serveur.crt
key keys/certificat-serveur .key  # This file should be kept secret
dh keys/dh1024.pem
tls-auth keys/ta.key 0 # This file is secret too, 0 = serveur

#adresse du bridging
#la première et la dernière IP devrait être les adresses de début 
# et de fin d'un sous réseau (par ex: x.y.z.129 x.y.z.254) 
# afin de simplifier le filtrage IPTABLES des clients 
# (par ex: -s/-d x.y.z.128/25)
server-bridge IP_serveur_sur_réseau_bridge masque_réseau_bridge première_IP_allouable_dans_rés_bridge dernière_IP_allouable_dans_rés_bridge

#les clients se voient entre eux
client-to-client
keepalive 10 120
cipher BF-CBC
comp-lzo

#nombre max de clients qui peuvent se connecter
max-clients 15

#utilisateur sous lequel tourne OpenVPN
user nobody
group nobody

#les logs
status /var/log/openvpn/status.log
log-append /var/log/openvpn/openvpn.log

verb 4
mute 10

8.Configuration du client

a)Configuration du client sous Linux

L'installation se fait comme pour le serveur.

b)Configuration du client sous Windows

Il vous faut télécharger :

http://prdownloads.sourceforge.net/openvpn/ et l'installer

Vous devez ensuite mettre un fichier openvpn.ovpn (contenant la configuration du client), les fichiers ta.key, ca.crt, nom_client.key et nom_client.crt (générer avec le script build-key et la clé ca.key) dans le répertoire config. (Généralement c:\program files\openvpn\config). Lors que le VPN est lancé, vous devriez voir s'activer une seconde connexion réseau sur l'interface TAP-Win32.

c)Configuration en mode Routed

#indique le mode client
client
#indique le mode routed
dev tun 
#indique le protocole de connexion au serveur
proto udp #ou tcp

#le serveur auquel on se connecte
remote nom_DNS_ou_IP_serveur port_serveur
#essayer indéfiniment de résoudre le nom DNS du serveur (par ex IP dynamique)
resolv-retry infinite

#choisir dynamiquement le port côté client
nobind


tls-client

#préserve les états entre deux connexions
persist-key
persist-tun

#le fichier du certificat de la CA
ca keys/ca.crt
#le certificat du client
cert keys/nom_client.crt
#la clé privée du client (600)
key keys/nom_client.key

ns-cert-type server
tls-auth keys/ta.key 1 #1 = client
cipher BF-CBC

#oblige le client à demander sa configuration au serveur
pull

#compression LZO
comp-lzo


verb 2
mute 5

d)Configuration en mode Bridged



#indique le mode client
client
#indique le mode bridged
dev tap 
#indique le protocole de connexion au serveur
proto udp #ou tcp

#le serveur auquel on se connecte
remote nom_DNS_ou_IP_serveur port_serveur
#essayer indéfiniment de résoudre le nom DNS du serveur (par ex IP dynamique)
resolv-retry infinite

#choisir dynamiquement le port côté client
nobind


tls-client

#préserve les états entre deux connexions
persist-key
persist-tun

#le fichier du certificat de la CA
ca keys/ca.crt
#le certificat du client
cert keys/nom_client.crt
#la clé privée du client (600)
key keys/nom_client.key

ns-cert-type server
tls-auth keys/ta.key 1 #1 = client
cipher BF-CBC

#oblige le client à demander sa configuration au serveur
pull

#compression LZO
comp-lzo


verb 2
mute 5

Le client a donc besoin de son fichier de config, du fichier ta.key, du certificat de la CA (ca.crt), de sa clef privé (nom_client.key) et de son certificat (nom_client.crt).

Il faut les copier dans c:\program files\openvpn\config si pour le fichier de configuration ci-dessus.

9.Utilisation

/etc/init.d/openvpn start ou /etc/init.d/openvpn stop

double cliquer sur le fichier de configuration .ovpn.

10.Pare-feu serveur



Il faut d'abord autoriser les clients à se connecter au serveur en UDP ou TCP :

iptables -A INPUT -i interface_publique -p udp --dport 1194 -j ACCEPT

iptables -A OUTPUT -o interface_publique -p udp --sport 1194 -j ACCEPT

a)Mode routed

i.Connexion sur le serveur



# autorise les connexions VPN à faire des connexions sur le serveur VPN

# un service TCP sur le port n

iptables -A INPUT -p tcp --dport n -d première_IP_réseau_VPN -s réseau_VPN -i tun+ -j ACCEPT

iptables -A OUTPUT -p tcp --sport n -s première_IP_réseau_VPN -d réseau_VPN -o tun+ -j ACCEPT

# ping

iptables -A INPUT -p icmp -i tun+ -d première_IP_réseau_VPN -s réseau_VPN -j ACCEPT

iptables -A OUTPUT -p icmp -o tun+ -s première_IP_réseau_VPN -d réseau_VPN -j ACCEPT



ii.Connexion au réseau interne derrière le serveur



# autorise les connexions VPN à traverser le serveur VPN

# un service TCP sur le port n

iptables -A FORWARD -p tcp --dport n -i tun+ -d réseau_interne -s réseau_VPN -j ACCEPT

iptables -A FORWARD -p tcp --sport n -o tun+ -s réseau_interne -d réseau_VPN -j ACCEPT

# ping

iptables -A FORWARD -p icmp -i tun+ -d réseau_interne -s réseau_VPN -j ACCEPT

iptables -A FORWARD -p icmp -o tun+ -s réseau_interne -d réseau_VPN -j ACCEPT



# effectuer la NAT des paquets traversant

iptables -t nat -A POSTROUTING -s adresse_reseau_VPN -d adresse_reseau_interne -o interface_reseau_interne -j SNAT --to-source IP_interne



#active le forwarding

echo 1 > /proc/sys/net/ipv4/ip_forward



De plus, vous devez configurer un client ou le serveur pour servir de passerelle pour accéder au réseau qui est autour de lui. Pour cela, il faut autoriser l'IP forwarding :

	echo 1 > /proc/sys/net/ipv4/ip_forward



b)Mode bridged

i.Si vous utilisez un noyau 2.4

http://ebtables.sourceforge.net/

ii.Règles de filtrage

Il faut faire le filtrage sur les périphériques physiques. On sait, par exemple, que pour aller du réseau interne au VPN, on va de interf_res_interne à tap0 et inversement. Cela permet de de filtrer par phys-in et phys-out.

#autorise le traffic dans les deux sens : clients <--> machines res interne
iptables -A FORWARD -m physdev --physdev-in interf_res_interne --physdev-out tap0 -j ACCEPT
iptables -A FORWARD -m physdev --physdev-in tap0 --physdev-out interf_res_interne -j ACCEPT

#autorise le ping des machines internes par les clients mais pas inverse
iptables -A FORWARD -p icmp --icmp-type echo-reply -d plage_IP_client -m physdev --physdev-in interf_res_interne --physdev-out tap0 -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type echo-request -s plage_IP_client -m physdev --physdev-in tap0 --physdev-out interf_res_interne -j
ACCEPT


#autorise le  telnet sur les machines internes par les clients mais pas inverse
iptables -A FORWARD -p tcp --sport 23 -d plage_IP_client -m physdev --physdev-in interf_res_interne --physdev-out tap0 -j ACCEPT
iptables -A FORWARD -p tcp --dport 23 -s plage_IP_client -m physdev --physdev-in tap0 --physdev-out interf_res_interne -j ACCEPT


#autorise le ping sur le serveur VPN par les clients mais pas inverse
iptables -A OUTPUT -p icmp --icmp-type echo-reply -d plage_IP_client -m physdev --physdev-out tap0 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -s plage_IP_client -m physdev --physdev-in tap0 -j ACCEPT


#autorise les machines du réseau interne à se connecter sur 80 du serveur
iptables -A OUTPUT -p tcp --sport 80 -d plage_IP_res_interne -m physdev --physdev-out interf_res_interne -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -s plage_IP_res_interne -m physdev --physdev-in interf_res_interne -j ACCEPT

c)Pare-feu client

On peut partir du principe que l'interface du VPN est relativement sûr, ce qui n'est toutefois pas toujours vrai.

Dans tous les cas, il faut s'autoriser à se connecter au serveur OpenVPN sur le port 1194 sur lequel est véhiculé le canal sécurisé.


#autoriser à se connecter au serveur OpenVPN

iptables -A INPUT -p udp --sport 1194 -m state --state RELATED,ESTABLISHED -j ACCEPT

iptables -A OUTPUT -p udp --dport 1194 -j ACCEPT


Dans le cas d'un VPN routé, on pourra mettre en place les règles suivantes :


#autoriser les paquets à passer dans le tunnel routé

iptables -A INPUT -i tun+ -j ACCEPT

iptables -A OUTPUT -o tun+ -j ACCEPT


Dans le cas d'un VPN bridgé, on pourra mettre en place les règles suivantes :


#ou autoriser les paquets à passer dans le tunnel bridgé

iptables -A INPUT -i tap+ -j ACCEPT

iptables -A OUTPUT -o tap+ -j ACCEPT


Si l'on veut peut être plus restrictif et n'autoriser que les logiciels clients sur la machine client et ne pas autoriser les machines du réseau interne du serveur à se connecter en SSH (par exemple) sur le client, on pourra ajouter -m state --state RELATED,ESTABLISHED au règles précédentes pour INPUT sur tun+ ou tap+.

d)Règles à éviter

iptables -A INPUT -f -j DROP

Elles droppent les paquets fragmentés, ce qui peut être TRES problématiques dans le cadre d'un VPN...

11.Considération de sécurité

Le seul problème d'OpenVPN est que si un client se fait voler sa clé privée, le voleur peut alors se connecter au VPN et accéder à toutes les machines internes à celui-ci. Il est donc nécessaire que les clients du VPN soient muni (pour les Windows) d'un antivirus et antispyware afin de ne pas se faire subtiliser ses clés privées et d'éviter la propagation rapide d'un virus à toutes les machines du VPN. De plus, un filtrage/pare-feu des clients et du serveur est nécessaire afin de ne pas laisser la possibilité à un vers de passer dans tous les sens.



IV.Annexe : le protocole SSL et OpenSSL

1.Qu'est-ce qu'OpenSSL ?

SSL a été à l'origine développé par Netscape.

OpenSSL est un version libre du protocole SSL (Secure Sockets Layer version 1 et 2) et TLS (Transport Layer Security = SSL version 3). Il permet de crypter toutes les données échangées entre le client et le serveur de façon à ce que seul le serveur puisse décrypter ce qui vient du client et inversement. Un éventuel pirate ne peut pas, dans un temps raisonnable, décrypter les informations.

SSL sert de support :


SSL a trois buts :

2.Connexion SSL

Les étapes d'une connexion SSL sont les suivantes (du moins ) :

  1. établissement de la connexion : choix de la méthode de cryptage



  1. authentification du serveur



  1. authentification facultative du client (si le serveur est configurer pour)



  1. échange de la clé de session (dans le cas de la méthode RSA)



  1. échanges cryptés


V.Bibliographie

Ethernet-Bridging :

http://www.tldp.org/HOWTO/Ethernet-Bridge-netfilter-HOWTO.html

http://www.tldp.org/HOWTO/BRIDGE-STP-HOWTO/index.html

OpenVPN :

OpenVPN - An Open Source SSL VPN Solution by James Yonan

OpenVPN 2.0 HOWTO

OpenVPN 2 HOWTO français

Installation d'une passerelle Linux

sharevb