Translation(s): Русский - Français


VPN — Dans les réseaux informatiques et les télécommunications, le réseau privé virtuel (Virtual Private Network en anglais, abrégé en VPN) est vu comme une extension des réseaux locaux et préserve la sécurité logique que l'on peut avoir à l'intérieur d'un réseau local. Il correspond en fait à une interconnexion de réseaux locaux via une technique de « tunnel ». On parle de VPN lorsqu'un organisme interconnecte ses sites via une infrastructure partagée avec d'autres organismes.

Introduction

En pratique c'est surtout utilisé pour se connecter au réseau interne de son entreprise depuis une connexion internel normale. On s'en sert aussi pour se connecter à des fournisseurs de VPN public permettant d'anonymiser sa connexion.

Installation du client


Pour établir ce genre de connexion il faut commencer par installer le paquet pptp-linux (PPTP Client), dépendant du paquet ppp (PPP: Point-to-Point Protocol - Protocole Point à Point):

# aptitude install pptp-linux

Vérifier la version de PPP

Cette étape peut être passée si vous êtes sur Debian GNU/Linux 4.0 Etch ou supérieur.

Si vous avez besoin du support MPPE (Microsoft Point-to-Point Encryption), alors vous devez vérifier que le paquet ppp est en version 2.4.2 ou supérieur. Debian Woody inclut la version 2.4.1 qui ne supporte pas le MPPE. Debian Sarge inclut la version 2.4.3 et Debian Etch inclut la version 2.4.4.

(Le paquet pptp-linux ne dépend pas d'une version supérieure ou égale à 2.4.2 de ppp car il est possible de configurer un tunnel sans l'encryption MPPE. Il ne faut pas utiliser la version 2.4.1 de ppp même si elle a été patchée pour le support MPPE car tous les correctifs testés ne sont pas compatibles avec le support MPPE ajouté aux noyaux des versions Etch et supérieures.

Configuration manuelle


Voici les informations nécessaires pour configurer un tunnel. Ces informations devraient vous être fournies par l'administrateur du serveur VPN ou le fournisseur.

Dans la suite de la documentation, remplacez ces variables par les valeurs.

Pour la suite, on considère que votre réseau est configuré correctement et que le serveur VPN est accessible. Si ce n'est pas le cas, allez voir NetworkConfiguration

Configuration du fichier de base

Les fichiers de configuration avec lesquels nous allons travailler sont tous situés dans le répertoire /etc/ppp pour des raisons de commodité rendez-vous dans ce répertoire :

# cd /etc/ppp/

Voilà les fichiers qui nous intéressent :

/etc/ppp/options.pptp


Il s'agit ici des paramètres par défaut qui seront utilisés par tous les tunnels. Normalement vous ne devriez pas avoir besoin de modifier ce fichier. Normalement vous avez les options suivantes en standard

lock noauth nobsdcomp nodeflate

/etc/ppp/chap-secrets


Ce fichier contient les informations de connexion de votre tunnel. Vous devez l'éditer :

# gedit /etc/ppp/chap-secrets

Et y ajouter une ligne comme suit :

#     client          server          secret      IP addresses
$DOMAIN\\$USERNAME     PPTP          $PASSWORD         *

Note : Si le serveur PPTP ne nécessite pas de domaine, ne mettez que le $USERNAME, sans le domaine et sans le slash. Note : Si le mot de passe contient des caractères spéciaux, voir la documentation officielle de pppd.

/etc/ppp/peers/$TUNNEL


Créez un fichier /etc/ppp/peers/$TUNNEL :

# gedit /etc/ppp/peers/$TUNNEL

Ajoutez les paramètres de configuration par exemple :

pty "pptp $SERVER --nolaunchpppd"
name $DOMAIN\\$USERNAME
remotename PPTP
require-mppe-128
file /etc/ppp/options.pptp
ipparam $TUNNEL

La deuxième ligne, name correspond à l'identifiant de connexion avec le domaine s'il y en a un. Sa valeur doit correspondre à celle de la ligne ajoutée dans /etc/ppp/chap-secrets.

Ouverture/fermeture de la connexion VPN

Une fois le fichier configuré, pour ouvrir la connexion VPN il suffit de taper la commande :

# pon $TUNNEL

En cas d'erreur, rajouter les options suivantes permettra de faciliter le diagnostic :

pon $TUNNEL debug dump logfd 2 nodetach

Pour fermer la connexion VPN taper la commande :

poff $TUNNEL

Routing (routage)


Une fois votre connexion VPN établi, vérifier que vous pouvez bien accéder aux machines de l'autre coté du tunnel.

Client -> Serveur

Pour les connexions client/server, c'est simple, chacun a sa propre IP et peut contacter l'autre dès la connexion établie. http://pptpclient.sourceforge.net/images/routing_clientlan1.png

Client -> LAN

C'est plus compliqué si vous voulez accéder à un réseau situé derrière le serveur VPN. Dans ce cas il vous faut configurer des routes une fois que la connexion est établie. http://pptpclient.sourceforge.net/images/routing_clientlan2.png

Dans l'exemple ci-dessus :

Donc après que la connexion est établie il faut créer une route comme suit :

# route add -net 192.168.10.0 netmask 255.255.255.0 dev ppp0

Et pour tester :

# traceroute 192.168.10.127
traceroute to 192.168.10.127 (192.168.10.127), 30 hops max, 38 byte packets
1 192.168.10.114 (192.168.10.114) 48.176 ms 48.115 ms 93.816 ms
2 192.168.10.127 (192.168.10.127) 46.554 ms 48.138 ms 48.443 ms

Les paquets destinés au serveur de mail transitent bien par le tunnel. Les paquets destinés au serveur VPN lui-même utilisent aussi la route qui vient d'être créée.

LAN -> LAN

Si vous avez un autre ordinateur connecté au vôtre dans un réseau local, il se peut que vous vouliez faire ceci : http://pptpclient.sourceforge.net/images/routing_lanlan1.png

Si vous souhaitez que n'importe quel ordinateur du réseau distant puisse discuter avec n'importe quel ordinateur de votre réseau local, il faut que vous établissiez une route sur le réseau distant ou que vous utilisiez ipchains ou iptable pour traduire les adresses.

http://pptpclient.sourceforge.net/images/routing_lanlan2.png Dans le schéma ci-dessus, les informations importantes sont :

La solution dépend du votre noyau.

Kernel 2.4.x (Iptable)

# route add -net 192.168.0.0 netmask 255.255.0.0 dev ppp0
# iptables --insert OUTPUT 1 --source 0.0.0.0/0.0.0.0 \
--destination 192.168.0.0/16 --jump ACCEPT --out-interface ppp0
# iptables --insert INPUT 1 --source 192.168.0.0/16 \
--destination 0.0.0.0/0.0.0.0 --jump ACCEPT --in-interface ppp0
# iptables --insert FORWARD 1 --source 0.0.0.0/0.0.0.0 \
--destination 192.168.0.0/16 --jump ACCEPT --out-interface ppp0
# iptables --insert FORWARD 1 --source 192.168.0.0/16 \
--destination 0.0.0.0/0.0.0.0 --jump ACCEPT
# iptables --table nat --append POSTROUTING --out-interface ppp0 \
--jump MASQUERADE
# iptables --append FORWARD --protocol tcp \
--tcp-flags SYN,RST SYN --jump TCPMSS --clamp-mss-to-pmtu

La dernière ligne résout le problème du chemin MTU

Kernel 2.2.x (Ipchains)

# route add -net 192.168.0.0 netmask 255.255.0.0 dev ppp0
# ipchains -I output 1 -s 0.0.0.0/0.0.0.0 -d 192.168.0.0/16 \
-i ppp0 -j ACCEPT
# ipchains -I forward 1 -s 192.168.0.0/16 -d 0.0.0.0/0.0.0.0 \
-i ppp0 -j MASQ -b
# ipchains -I input 1 -s 192.168.0.0/16 -d 0.0.0.0/0.0.0.0 \
-i ppp0 -j ACCEPT

Pour tester, depuis un autre ordinateur de votre réseau :

# traceroute mail
traceroute to mail (192.168.0.7), 30 hops max, 38 byte packets
1 client (10.0.1.1) 0.980 ms 0.312 ms 0.225 ms
2 server (10.20.0.1) 48.079 ms 48.758 ms 47.708 ms
3 mail (192.168.0.7) 50.250 ms 46.662 ms 48.299 ms

Le flèches rouges sur le schéma ci-dessous montre le cheminement des paquets : http://pptpclient.sourceforge.net/images/routing_lanlan3.png

Liens



CategoryNetwork CategoryNetwork