/usr/share/doc/HOWTO/fr-html/VPN-HOWTO.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for HTML5 for Linux version 5.2.0">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.72">
<title>VPN HOWTO</title>
</head>
<body>
<h1>VPN HOWTO</h1>
<h2>Matthew D. Wilson, <a href=
"mailto:matthew@shinythings.com">matthew@shinythings.com</a>
Traduction française de Nicolas Prigent <a href=
"mailto:prigentn@thmulti.com">prigentn@thmulti.com</a></h2>
v 1.0, Dec 1999
<hr>
<em>Ce HOWTO décrit la manière de mettre en place un Réseau Privé
Virtuel (Virtual Private Network) avec Linux.</em>
<hr>
<h2><a name="Introduction"></a> <a name="s1">1.
Introduction</a></h2>
<h2><a name="ss1.1">1.1 Pourquoi ai-je écrit ce HOWTO</a></h2>
<p>Je travaille chez Real Network, et nous avions besoin d'un VPN.
C'était mon premier véritable projet, et j'en ai réellement appris
plus au sujet de Linux grâce à cela qu'avec n'importe quelle autre
tâche. Je me suis servi de l'expérience ainsi acquise pour rédiger
ce document, pour partager avec d'autres ce que j'avais appris,
pour qu'ils puissent eux aussi réaliser de super trucs avec
Linux.</p>
<h2><a name="ss1.2">1.2 Remerciements</a></h2>
<p>Je voudrais tout d'abord et surtout remercier mon épouse Julie,
sans qui je ne serais pas où j'en suis actuellement. Je voudrais
aussi remercier Arpad Magosanyi, l'auteur du premier VPN mini-howto
et de pty-redir, l'utilitaire qui a rendu tout cela possible.
Jerry, Rod, Glen, Mark V., Mark W., et David, vous êtes trop fort
les mecs. Merci pour votre aide.</p>
<h2><a name="ss1.3">1.3 Format de ce document</a></h2>
<p>Ce document est divisé en 5 sections.</p>
<dl>
<dt><b>Section 1: Introduction</b></dt>
<dd>
<p>Cette section</p>
</dd>
<dt><b>Section 2: Théorie</b></dt>
<dd>
<p>La théorie à la base des VPNs. Qu'est-ce qu'un VPN, et comment
fonctionne-t-il. Lisez cette partie si vous êtes néophyte en
matière de VPN.</p>
</dd>
<dt><b>Section 3: Serveur</b></dt>
<dd>
<p>Cette section décrit la mise en place d'un serveur de VPN.</p>
</dd>
<dt><b>Section 4: Client</b></dt>
<dd>
<p>Cette section décrit la mise en place d'un client de VPN.</p>
</dd>
<dt><b>Section 5: Implémentation</b></dt>
<dd>
<p>Une implémentation de VPN décrite pas à pas.</p>
</dd>
<dt><b>Section 6: Addenda</b></dt>
<dd>
<p>D'autres éléments d'information qui pourraient vous être
utiles.</p>
</dd>
</dl>
<h2><a name="ss1.4">1.4 Copyright et Avertissements</a></h2>
<p>Copyright (c) Matthew Wilson. Ce document ne peut être distribué
qu'en accord avec les termes et les conditions de la licence LDP
que vous trouverez a l'adresse <a href=
"http://www.linuxdoc.org/COPYRIGHT.html">http://www.linuxdoc.org/COPYRIGHT.html</a>,
excepté le fait que ce document ne doit pas être distribué sous une
forme altérée sans le consentement de son auteur.</p>
<p>Ni l'auteur, ni le traducteur n'assument une quelconque
responsabilité pour quoi que ce soit pouvant advenir suite a
l'utilisation de ce document, ni ne fournissent une quelconque
garantie, implicite ou explicite. Si vous cassez quelque chose,
nous ne sommes en rien responsable. Souvenez vous que ce que vous
allez faire ici pourrait créer d'énormes trous de sécurité sur
votre réseau. Vous aurez été prévenus.</p>
<h2><a name="ss1.5">1.5 Histoire de ce document</a></h2>
<p>Le VPN mini-HOWTO original a été écrit par <a href=
"mag@bunuel.tii.matav.hu">Arpad Magosanyi</a> en 1997. Il m'a
depuis autorisé à reprendre le document, et à l'étendre jusqu'à en
faire un HOWTO complet. Rien de ceci n'aurait été possible sans le
document original. Merci encore Arpad. :)</p>
<p>La version 1.0 de ce HOWTO a été terminée le 10 décembre
1999.</p>
<h2><a name="ss1.6">1.6 Documents associés</a></h2>
<ul>
<li><a href="/HOWTO/Networking-Overview-HOWTO.html">Networking
Overview HOWTO</a></li>
<li><a href="/HOWTO/NET3-4-HOWTO.html">Networking HOWTO</a></li>
<li><a href="/HOWTO/VPN-Masquerade-HOWTO.html">VPN-Masquerade
HOWTO</a></li>
</ul>
<h2><a name="s2">2. Théorie</a></h2>
<h2><a name="ss2.1">2.1 Qu'est-ce qu'un VPN?</a></h2>
<p>VPN est l'acronyme de Virtual Private Network, ou réseau privé
virtuel. Un VPN utilise l'Internet comme mécanisme de transport, en
maintenant la sécurité des données sur le VPN.</p>
<h3>Mais c'est quoi, en vrai, un VPN?</h3>
<p>Et bien il y a plusieurs réponses à cette question. Cela dépends
vraiment de l'apparence du réseau. En général, on dispose d'un
réseau principal unique, avec des noeuds distants qui utilisent le
VPN pour gagner un accès complet au réseau central. Les noeuds
distants sont généralement des bureaux éloignés, ou des employés
travaillant à partir de chez eux. Il est aussi possible de relier
deux réseaux plus petits (ou même plus grands!) pour former un seul
réseau encore plus grand.</p>
<h3>Alors, ça marche comment?</h3>
<p>Pour simplifier, pour réaliser un VPN, vous créez un tunnel
sécurisé entre deux réseaux et l'utilisez pour router les
datagrammes IP. Au cas ou vous seriez déjà perdu, vous devriez lire
<a href=
"http://www.linuxdoc.org/HOWTO/Networking-Overview-HOWTO.html">Le
Linux Networking Overview HOWTO</a> pour vous informer au sujet des
réseaux sous Linux.</p>
<p>Prière de ne pas m'en vouloir, mes schémas ASCII mériterait un
peu plus de travail.</p>
<pre>
                                 \          \
                 ---------       /          /      ---------
   Réseau ______| Routeur |______\ Internet \_____| Routeur |______ Réseau
   Distant      | Client  |      /          /     | Serveur |       Privé
                 ---------       \          \      ---------
                                 /          /


                         Routeur Client
               ----------------------------------------------------
              |   /-&gt;    10.0.0.0/255.0.0.0   \                    |
  Réseau      |  |--&gt;  172.16.0.0/255.240.0.0  |--&gt; Tunnel &gt;---\   |
  Distant &gt;---|--|--&gt; 192.168.0.0/255.255.0.0 /                 |--|----&gt; Internet
 192.168.12.0 |  |                                              |  |
              |   \-----&gt; 0.0.0.0/0.0.0.0 --&gt; Masquarade IP &gt;--/   |
               ----------------------------------------------------


                        Routeur Serveur
             ----------------------------------------------------
            |                   /-&gt;    10.0.0.0/255.0.0.0    \   |
            |   /--&gt; Tunnel &gt;--|--&gt;  172.16.0.0/255.240.0.0   |--|----&gt; Réseau
Internet &gt;--|--|                \--&gt; 192.168.0.0/255.255.0.0 /   |      Privé
            |  |                                                 |     172.16.0.0/12
            |   \-----&gt; 0.0.0.0/0.0.0.0 -----&gt; /dev/null         |    192.168.0.0/16
             ----------------------------------------------------
</pre>
<p>Le diagramme ci-dessus montre comment le réseau peut être mis en
place. Si vous ne savez pas ce qu'est la masquarade IP, vous ne
devriez probablement pas être ici. Allez lire <a href=
"/HOWTO/Networking-Overview-HOWTO.html">Le Linux Networking
Overview HOWTO</a> et revenez une fois informé.</p>
<p>Le routeur client est une machine Linux tenant le rôle de
passerelle/firewall pour le réseau distant. Comme vous pouvez le
voir, le réseau distant utilise le réseau local 192.168.12.0. Pour
plus de simplicité dans le diagramme, j'ai laissé les informations
de routage sur les routeurs. L'idée de base est de router le trafic
destiné aux réseaux privés (10.0.0.0, 172.16.0.0, et 192.168.0.0)
via le tunnel. L'installation montrée ici est une manière de le
faire. C'est à dire qu'alors que le réseau distant peut voir le
réseau privé, le réseau privé ne peut pas nécessairement voir le
réseau distant. Pour que ceci arrive, il faut spécifier que les
routes sont bidirectionnelles.</p>
<p>Vous devriez aussi remarquer sur le schéma que tout le trafic
sortant du routeur client apparaît comme en provenant, c'est à dire
qu'il porte toujours la même adresse IP. Vous pouvez router les
valeurs véritables de l'intérieur de votre réseau, mais cela induit
une grande diversité de problèmes de sécurité.</p>
<h2><a name="ss2.2">2.2 SSH et PPP</a></h2>
<p>Le système que je décris pour implémenter un VPN utilise SSH et
PPP. Schématiquement, je me sers de ssh pour créer une connexion
protégée par tunnel, puis utilise pppd pour y démarrer le trafic
TCP/IP. C'est ainsi que le tunnel est mis en place.</p>
<p>Le véritable truc pour faire fonctionner ssh et pppd ensemble
correctement est l'utilitaire écrit par Arpad Magosanyi qui permet
la redirection de l'entrée et de la sortie standard vers un pseudo
tty. Ceci permets à pppd de parler au travers de ssh comme s'il
s'agissait d'une liaison série. Du côté du serveur, pppd est lancé
comme interpreteur de commande utilisateur dans la session ssh,
complétant le lien. Après cela, tout ce qu'il reste a faire est de
réaliser le routage.</p>
<h2><a name="ss2.3">2.3 Systèmes VPN alternatifs</a></h2>
<p>Il y a bien sur d'autres moyens de mettre en place un VPN, dont
voici quelques exemples.</p>
<h3>PPTP</h3>
<p>PPTP est un protocole Microsoft pour les VPN. Il est supporté
sous Linux, mais est connu pour avoir de nombreux problèmes de
sécurité. Je ne décris pas ici la manière de l'utiliser, étant
donné que ce thème est couvert par <a href=
"http://www.linuxdoc.org/HOWTO/VPN-Masquerade-HOWTO.html">Linux VPN
Masquerade HOWTO</a>.</p>
<h3>IPSec</h3>
<p>IPSec est un ensemble de protocoles différents de SSH.
Franchement, je n'en connais pas énormément à son sujet. De fait,
si quelqu'un veut m'aider d'une description, je lui en serais très
reconnaissant. Encore une fois, je ne décris pas comment l'utiliser
étant donné que le <a href=
"http://www.linuxdoc.org/HOWTO/VPN-Masquerade-HOWTO.html">Linux VPN
Masquerade HOWTO</a> couvre le sujet.</p>
<h3>CIPE</h3>
<p>CIPE est un système de chiffrement au niveau noyau probablement
mieux adapté aux dispositifs d'entreprise. Vous pourrez en savoir
plus sur <a href=
"http://sites.inka.de/sites/bigred/devel/cipe.html">la page de
CIPE</a>. J'envisage de m'y intéresser plus sérieusement, et aurais
donc peut être plus d'informations à son sujet bientôt.</p>
<h2><a name="s3">3. Le serveur</a></h2>
<p>Cette section explique comment mettre en place l'aspect serveur
des choses. J'ai placé cette section en premier, étant donné que
sans serveur, un client est assez inutile.</p>
<h2><a name="ss3.1">3.1 La sécurité - garder les gens
dehors</a></h2>
<p>La sécurité est un aspect très important des VPNs. C'est pour ça
que vous êtes en train d'en monter un, non? Vous devez garder ces
quelques choses à l'esprit en mettant en place votre serveur.</p>
<h3>Préparez vos démons</h3>
<p>Etant donné que ce serveur va être des deux côtés du firewall et
qu'il va être mis en place pour transmettre le trafic sur votre
réseau, c'est une bonne idée de sécuriser la machine autant que
possible. Vous pourrez en apprendre plus sur la sécurité Linux dans
<a href="/HOWTO/Security-HOWTO.html">Linux Security HOWTO</a>. Pour
ma part, j'ai tué tous les services, excepté sshd et un serveur web
Roxen. J'utilise ce dernier pour télécharger quelques fichiers (mes
scripts, etc.) pour permettre à d'autres machines d'accéder au VPN.
Je n'utilise pas de serveur FTP étant donné qu'il est plus dur d'en
sécuriser un que de rendre quelques fichiers disponibles sur un
serveur web. De plus, j'ai seulement besoin de pouvoir récupérer
des fichiers. Si vous souhaitez réellement exécuter des serveurs
différents sur votre passerelle, vous pourriez vouloir envisager de
restreindre leur accès aux machines situées sur votre réseau
privé.</p>
<h3>Ne pas autoriser de mots de passe</h3>
<p>Effectivement, cela semble assez stupide, mais ça a retenu votre
attention non? Non, vous n'utilisez pas de mots de passe, vous les
désactivez complètement. Toute l'authentification nécessaire sur
cette machine devrait être faite via le système d'authentification
à clé publique de ssh. Ainsi, seul les entités dotées de clés
peuvent entrer, et il est pratiquement impossible de se rappeler
d'une clé binaire de 530 caractères.</p>
<p>Alors, comment faites-vous ça? Il faut éditer le fichier
/etc/passwd. Le second champ contient soit le résumé
cryptographique (hash) du mot de passe, ou un 'x' prévenant le
système d'authentification qu'il faut regarder dans le fichier
/etc/shadow. Vous devez changer ce champ en '*'. Ainsi le système
d'authentification est informé qu'il n'y a pas de mot de passe, et
qu'aucun ne devrait être autorisé.</p>
<p><a name="passwd"></a> Voila à quoi ressemble un fichier
/etc/passwd classique:</p>
<pre>
...
nobody:x:65534:100:nobody:/dev/null:
mwilson:x:1000:100:Matthew Wilson,,,:/home/mwilson:/bin/bash
joe:*:504:101:Joe Mode (home),,,:/home/vpn-users:/usr/sbin/pppd
bill:*:504:101:Bill Smith (home),,,:/home/vpn-users:/usr/sbin/pppd
frank:*:504:101:Frank Jones (home),,,:/home/vpn-users:/usr/sbin/pppd
...
</pre>
Remarquez que j'ai fait plus qu'éditer simplement le second champ.
J'en dirais plus sur les autres champs par la suite.
<h2><a name="ss3.2">3.2 Accès des utilisateur - les laisser
rentrer</a></h2>
<p>L'accès des utilisateurs est réalisé via le schéma
d'authentification de ssh. Comme je l'ai indiqué précédemment,
c'est ainsi que les utilisateurs peuvent accéder au système, tout
en maintenant un haut niveau de sécurité. Si vous n'êtes pas
familier de ssh, jetez un oeuil à <a href=
"http://www.ssh.org/">http://www.ssh.org/</a> Remarquez que
j'utilise la version 1 de ssh, pas la version 2. Il y a une grande
différence, particulièrement sur le fait que la version 1 est
libre, contrairement à la version 2.</p>
<h3>Configurer <code>sshd</code></h3>
<p>Vous aurez besoin de configurer sshd. Les options suivantes
devraient être présentes. L'idée est de désactiver
l'authentification par mot de passe, et les authentifications par
rhosts. Les options suivantes devraient être présentes dans votre
fichier <code>/etc/sshd_config</code>.</p>
<pre>
PermitRootLogin yes
IgnoreRhosts yes
StrictModes yes
QuietMode no
CheckMail no
IdleTimeout 3d
X11Forwarding no
PrintMotd no
KeepAlive yes
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
UseLogin no
</pre>
<h2><a name="ss3.3">3.3 Restreindre les possibilités des
utilisateurs</a></h2>
<p>Maintenant que vous maintenez les méchants à l'extérieur et ne
laissez entrer que les gentils, vous pourriez avoir besoin de vous
assurer que ces derniers se comportent correctement. La manière la
plus simple de le faire est de ne rien les laisser faire d'autre
que de lancer pppd. Ceci peut être, ou non, nécessaire. J'ai
restreins les possibilités des utilisateurs parce que le système
que je maintiens est dédié au VPN, et que les utilisateurs n'ont
aucune raison de faire quoique ce soir d'autre dessus.</p>
<h3>sudo ou pas sudo</h3>
<p>Il existe un petit programme propret appelé sudo qui permet à
l'administrateur d'un système Unix d'autoriser à certains
utilisateurs la possibilité de lancer certains programmes en tant
que root. C'est ici certainement le cas, étant donné que pppd doit
être lancé ainsi. Vous devrez utiliser cette méthode si vous
souhaitez autoriser les accès ligne de commande aux utilisateurs.
Référez-vous à la page man de sudo pour savoir comment mettre sudo
en place. Utiliser sudo est préférable sur les systèmes multi-usage
qui hébergent généralement un faible nombre d'utilisateurs de
confiance.</p>
<p>Si vous désirez ne pas autoriser les utilisateurs à disposer
d'un accès par ligne de commande, le meilleur moyen de le faire est
de faire que leur shell soit pppd. Ceci se fait dans le fichier
/etc/passwd. Vous pouvez voir <a href="#passwd">ci-dessous</a> que
c'est ce que j'ai fait pour les trois derniers utilisateurs. Le
dernier champ du fichier /etc/passwd est le shell de l'utilisateur.
Vous n'avez pas besoin de faire quoique ce soit de spécial à pppd
pour le faire fonctionner. Il est exécuté en tant que root lorsque
l'utilisateur se connecte. C'est certainement la mise en place la
plus simple possible, ainsi que la plus sûre. Elle est idéale pour
les systèmes industriels et à grande échelle. J'ai décris
exactement tout ce qu'il faut faire plus loin dans ce document.
Vous pouvez <a href="#user-accounts">y aller directement</a> si
vous le souhaitez.</p>
<h2><a name="ss3.4">3.4 Le réseau</a></h2>
<p>Maintenant que vos utilisateurs ont accès au système, nous
devons nous assurer qu'ils ont accès au réseau. Pour ce faire, nous
utilisons les règles du noyau Linux relatives au firewall et les
tables de routage. En nous servant des commandes <code>route</code>
et <code>ipfwadm</code>, nous pouvons configurer le noyau pour
gérer le trafic réseau de manière correcte. Pour plus d'information
sur <code>ipfwadm</code>, <code>ipchains</code> et
<code>route</code>, référez vous au <a href=
"http://www.linuxdoc.org/HOWTO/Linux-Networking-HOWTO.html">Linux
Networking HOWTO</a>.</p>
<h3>Le noyau</h3>
<p>Pour que cela fonctionne, votre noyau doit être configuré
correctement. Si vous ne savez pas comment créer votre propre
noyau, vous devriez lire le <a href=
"http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html">Kernel HOWTO</a>.
Vous devez vous assurer que les options suivantes sont activées, en
plus des options réseaux de base. J'utilise un noyau 2.0.38 sur mon
système.</p>
<p>Pour les noyaux 2.0:</p>
<ul>
<li>CONFIG_FIREWALL</li>
<li>CONFIG_IP_FORWARD</li>
<li>CONFIG_IP_FIREWALL</li>
<li>CONFIG_IP_ROUTER</li>
<li>CONFIG_IP_MASQUERADE (optionnel)</li>
<li>CONFIG_IP_MASQUERADE_ICMP (optionnel)</li>
<li>CONFIG_PPP</li>
</ul>
<p>Pour les noyaux 2.2:</p>
<ul>
<li>CONFIG_FIREWALL</li>
<li>CONFIG_IP_ADVANCED_ROUTER</li>
<li>CONFIG_IP_FIREWALL</li>
<li>CONFIG_IP_ROUTER</li>
<li>CONFIG_IP_MASQUERADE (optionnel)</li>
<li>CONFIG_IP_MASQUERADE_ICMP (optionnel)</li>
<li>CONFIG_PPP</li>
</ul>
<h3>Rêgles de filtrage</h3>
<p>Tout d'abord, nous devons écrire des règles de filtrage de
firewall qui permettent aux utilisateurs d'accéder à nos réseaux
internes, tout en leur interdisant d'accéder au réseau externe.
Cela peut sembler étrange, mais envisagez le sous cet angle: Ils
ont déjà accès à l'Internet, alors pourquoi les laisser utiliser le
tunnel pour y accéder? Cela gâche à la fois la bande passante et le
processeur.</p>
<p>Les règles de filtrage utilisées dépendent du réseau interne
utilisé. En gros, elle disent: "Autoriser le trafic venant de nos
VPNs et destiné à nos réseaux internes". Comment allons nous faire?
Comme toujours, ça dépends. Si vous utilisez un noyau 2.0, vous
devez vous servir d'un outil appelé <code>ipfwadm</code>, alors que
si vous utilisez un noyau 2.0, vous utiliserez
<code>ipchains</code>.</p>
<p>Pour mettre en place les règles avec <code>ipfwadm</code>,
lancez le avec les options suivantes:</p>
<pre>
# /sbin/ipchains -F forward
# /sbin/ipchains -P forward DENY
# /sbin/ipchains -A forward -j ACCEPT -s 192.168.13.0/24 -d 172.16.0.0/12
</pre>
<p>Pour les utilisateurs de noyau 2.2, se référer à <a href=
"#ipv4forwarding">ceci</a>.</p>
<h3>Routage</h3>
<p>Désormais, nos utilisateurs sont autorisés à accéder à nos
réseaux, et nous devons dire au noyau où envoyer les paquets. Sur
mon système, je dispose de deux ethernets : L'un d'entre eux est
relié au réseau externe, l'autre au réseau interne. Ceci aide à la
sécurisation, car le trafic extérieur est masqué par notre
passerelle, et n'importe quel trafic entrant est filtré et routé
par notre Cisco. Pour la plupart des dispositifs, le routage
devrait être une chose simple.</p>
<p>Nous routons l'intégralité du trafic destiné au réseaux privés
vers l'interface connectée au réseau interne, et le reste du trafic
vers l'interface externe. Les commandes de routage spécifiques
dépendent des réseaux internes que vous utilisez. Voici un exemple
de ce à quoi elles pourraient ressembler. Ces lignes sont bien sûr
ajoutées à vos règles de routages habituelles pour vos réseaux
locaux. Je doute que vous utilisiez les trois groupes d'adresses
privées.</p>
<pre>
En supposant que 172.16.254.254 est notre passerelle interne:

# /sbin/route add -net 10.0.0.0 netmask 255.0.0.0 gw 172.16.254.254 dev eth1
# /sbin/route add -net 172.16.0.0 netmask 255.240.0.0 gw 172.16.254.254 dev eth1
# /sbin/route add -net 192.168.0.0 netmask 255.255.0.0 gw 172.16.254.254 dev eth1
</pre>
<p>Encore une chose sur le routage. Si vous utilisez du routage
bidirectionnel, vous aurez alors besoin de réaliser une chose en
plus. Il vous faudra mettre en place les routes revenant vers le
client. La manière la plus simple de le faire est de lancer un cron
chaque minute qui va assigner les valeurs des routes. Ce n'est pas
très grave si le client n'est pas connecté, <code>route</code> va
simplement cracher une erreur (que vous aurez judicieusement
redirigé vers <code>/dev/null</code>).</p>
<h2><a name="s4">4. Le client</a></h2>
<p>Nous nous consacrons maintenant au client. En pratique,
lorsqu'elle est utilisé pour permettre l'accès à un réseau distant,
cette machine peut facilement servir de serveur Samba (réseau
Windows), DHCP, ou même web interne. L'aspect important dont il
faut se souvenir est que cette machine doit être aussi sécurisée
que possible, étant donnée qu'elle fait fonctionner tout votre
réseau distant.</p>
<h2><a name="ss4.1">4.1 Le noyau</a></h2>
<p>Commençons par le commencement. Vous devez disposer de ppp dans
votre noyau. Si vous souhaitez autoriser plusieurs machines à
utiliser le tunnel, il vous faut aussi les services de firewall et
de transmission (forwarding). Si le client consiste en une seule
machine, ppp est suffisant.</p>
<h2><a name="ss4.2">4.2 Réaliser la liaison</a></h2>
<p>La liaison est créée en lançant <code>pppd</code> à travers un
pseudo terminal lui-même créé par <code>pty-redir</code> et
connecté à <code>ssh</code>. C'est ce que réalise la séquence de
commande suivante.</p>
<pre>
# /usr/sbin/pty-redir /usr/bin/ssh -t -e none -o 'Batchmode yes' -c blowfish -i /root/.ssh/identity.vpn -l joe &gt; /tmp/vpn-device
# sleep 10

# /usr/sbin/pppd `cat /tmp/vpn-device`
# sleep 15

# /sbin/route add -net 172.16.0.0 gw vpn-internal.mycompany.com netmask 255.240.0.0
# /sbin/route add -net 192.168.0.0 gw vpn-internal.mycompany.com netmask 255.255.0.0
</pre>
<p>Clairement, on lance ssh, et on redirige ses entrées et sorties
vers pppd. Les options passées à ssh le configurent pour s'exécuter
sans caractère d'échappement (-e), en utilisant l'algorithme de
chiffrement blowfish (-i), en mode terminal (-l), avec les options
'Batchmode yes' (-o). Les commandes sleep sont utilisées pour
espacer les exécutions des commandes pour que chacune puisse
compléter son initialisation avant que la suivante ne soit
lancée.</p>
<h2><a name="ss4.3">4.3 Faire des scripts</a></h2>
<p>Bien sûr, vous ne souhaitez pas avoir à taper ces commandes à
chaque fois que vous souhaitez voir le tunnel fonctionner. J'ai
écrit un ensemble de scripts bash qui gardent le tunnel en état de
fonctionnement. Vous pouvez télécharger le package à partir
<a href="http://www.shinythings.com/vpnd/vpnd.tar.gz">d'ici</a>. Il
suffit de les télécharger et de les décompresser dans
/usr/local/vpn. Vous trouverez trois fichiers à l'intérieur:</p>
<ul>
<li>vpnd: le script qui contrôle la connexion du tunnel.</li>
<li>check-vpnd: un script qui sera lancé par le cron pour vérifier
que le VPN fonctionne toujours.</li>
<li>pty-redir: un petit exécutable requis pour l'initiation du
tunnel.</li>
</ul>
<p>Vous aurez besoin d'éditer le script <code>vpnd</code> pour
assigner quelques valeurs telles que le nom d'utilisateur du client
et le nom du serveur. Vous pourrez aussi avoir besoin de modifier
la section starttunnel du script pour spécifier le réseau utilisé.
Vous trouverez ci-dessous une copie du script pour le plaisir des
yeux. Remarquez que vous pouvez mettre le script dans un répertoire
différent, il suffit de changer la variable VPN_DIR.</p>
<p><a name="vpnd-script"></a></p>
<pre>

#! /bin/bash
#
# vpnd: Monitor the tunnel, bring it up and down as necessary
#

USERNAME=vpn-username
IDENTITY=/root/.ssh/identity.vpn

VPN_DIR=/usr/local/vpn
LOCK_DIR=/var/run
VPN_EXTERNAL=vpn.mycompany.com
VPN_INTERNAL=vpn-internal.mycompany.com
PTY_REDIR=${VPN_DIR}/pty-redir
SSH=${VPN_DIR}/${VPN_EXTERNAL}
PPPD=/usr/sbin/pppd
ROUTE=/sbin/route
CRYPTO=blowfish
PPP_OPTIONS="noipdefault ipcp-accept-local ipcp-accept-remote local noauth nocrtscts lock nodefaultroute"
ORIG_SSH=/usr/bin/ssh


starttunnel () {
   $PTY_REDIR $SSH -t -e none -o 'Batchmode yes' -c $CRYPTO -i $IDENTITY -l $USERNAME &gt; /tmp/vpn-device
   sleep 15

   $PPPD `cat /tmp/vpn-device` $PPP_OPTIONS
   sleep 15

   # Add routes (modify these lines as necessary)
   /sbin/route add -net 10.0.0.0 gw $VPN_INTERNAL netmask 255.0.0.0
   /sbin/route add -net 172.16.0.0 gw $VPN_INTERNAL netmask 255.240.0.0
   /sbin/route add -net 192.168.0.0 gw $VPN_INTERNAL netmask 255.255.0.0
}

stoptunnel () {
   kill `ps ax | grep $SSH | grep -v grep | awk '{print $1}'`
}

resettunnel () {
   echo "reseting tunnel."
   date &gt;&gt; ${VPN_DIR}/restart.log
   eval stoptunnel
   sleep 5
   eval starttunnel
}

checktunnel () {
   ping -c 4 $VPN_EXTERNAL 2&gt;/dev/null 1&gt;/dev/null

   if [ $? -eq 0 ]; then
      ping -c 4 $VPN_INTERNAL 2&gt;/dev/null 1&gt;/dev/null
      if [ $? -ne 0 ]; then
         eval resettunnel
      fi
   fi
}

settraps () {
   trap "eval stoptunnel; exit 0" INT TERM
   trap "eval resettunnel" HUP
   trap "eval checktunnel" USR1
}

runchecks () {
   if [ -f ${LOCK_DIR}/tunnel.pid ]; then
      OLD_PID=`cat ${LOCK_DIR}/vpnd.pid`
      if [ -d /proc/${OLD_PID} ]; then
         echo "vpnd is already running on process ${OLD_PID}."
         exit 1
      else
         echo "removing stale pid file."
         rm -rf ${LOCK_DIR}/vpnd.pid
         echo $$ &gt; ${LOCK_DIR}/vpnd.pid
         echo "checking tunnel state."
         eval checktunnel
      fi
   else
      echo $$ &gt; ${LOCK_DIR}/vpnd.pid
      eval starttunnel
   fi
}

case $1 in
    check)  if [ -d /proc/`cat ${LOCK_DIR}/vpnd.pid` ]; then
               kill -USR1 `cat ${LOCK_DIR}/vpnd.pid`
               exit 0
            else
               echo "vpnd is not running."
               exit 1
            fi ;;

    reset)  if [ -d /proc/`cat ${LOCK_DIR}/vpnd.pid` ]; then
               kill -HUP `cat ${LOCK_DIR}/vpnd.pid`
               exit 0
            else
               echo "vpnd is not running."
               exit 1
            fi ;;

   --help | -h)
            echo "Usage: vpnd [ check | reset ]"
            echo "Options:"
            echo "     check    Sends running vpnd a USR1 signal, telling it to check"
            echo "              the tunnel state, and restart if neccesary."
            echo "     reset    Sends running vpnd a HUP signal, telling it to reset"
            echo "              it's tunnel connection." ;; 
esac

ln -sf $ORIG_SSH $SSH
settraps
runchecks

while true; do
   i=0
   while [ $i -lt 600 ]; do
      i=((i+1))
      sleep 1
   done
   eval checktunnel
done
</pre>
<h2><a name="ss4.4">4.4 LRP - Projet de Routeur Linux (Linux Router
Project)</a></h2>
<p>J'ai lancé cette installation sur un Pentium 90 exécutant la
distribution LRP de Linux. LRP est une distribution de Linux qui
tient et se charge sur une seule disquette. Vous en apprendrez plus
sur <a href=
"http://www.linuxrouter.org/">http://www.linuxrouter.org/</a>. Vous
pouvez télécharger <a href=
"http://www.shinythings.com/vpnd/vpnd.lrp">ici</a> mon package LRP
pour le client VPN. Vous aurez aussi besoin des packages ppp et ssh
du sîte LRP.</p>
<h2><a name="s5">5. Implémentation</a></h2>
<p>Dans cette section, j'explique pas à pas comment mettre en place
votre système VPN. Je commencerais par le serveur, et poursuivrais
avec le client. Pour les besoins de l'exemple, j'inventerais une
situation qui nécessitera différentes mise en place de VPN.</p>
<h2><a name="ss5.1">5.1 Organisation</a></h2>
<p>Imaginons que nous ayons une entreprise, appelée
monentreprise.com. Au siège, nous utilisons l'adresse réseau
réservée 192.168.0.0, et séparons le réseau de classe B en 256
réseaux de classe C pour permettre le routage. Nous venons de
mettre en place deux petits bureaux distants, et souhaitons les
ajouter à notre réseau. Nous souhaitons aussi permettre aux
employés travaillant chez eux d'utiliser leurs connexions câble ou
DSL plutôt que de leur faire utiliser une communication directe par
modem. Pour commencer, nous devons organiser quelques peu les
choses.</p>
<p>J'ai décidé que je voulais donner à chaque bureau distant une
plage d'adresse de classe C pour leur permettre de s'étendre si
cela devait être nécessaire. J'ai donc réservé les réseaux
192.168.10.0 et 192.168.11.0. J'ai aussi décidé que pour les
utilisateur se connectant depuis leur domicile, je disposais de
suffisamment d'adresses et que je n'avais donc pas besoin de leur
appliquer de masquarade du côté du serveur VPN. Chaque client
dispose de sa propre adresse IP interne. J'ai donc eu besoin de
réserver une autre adresse réseau de classe C pour cela, disons
192.168.40.0. La seule chose que j'ai alors du faire fut d'ajouter
ces espaces d'adresse à mon routeur. Imaginons que notre entreprise
possède un petit Cisco (192.168.254.254) qui gère tout le trafic
via notre OC1. Nous n'avons alors qu'à ajouter les routes sur le
Cisco de telle manière que le trafic dirigé vers ces réseaux
réservés soit dirigé vers notre serveur VPN (192.168.40.254). J'ai
considéré que le serveur VPN appartenait au réseau de l'utilisateur
se connectant depuis son domicile pour une raison qui sera plus
claire tout à l'heure. Nous appellerons l'interface externe du
serveur vpn.monentreprise.com, et l'interface interne
vpn-interne.monentreprise.com.</p>
<p>Nous n'avons pas besoin de connaître explicitement les adresses
externes. Vous devriez avoir les vôtres, fournies par votre
FAI.</p>
<h2><a name="ss5.2">5.2 Rassembler les outils</a></h2>
<p>Nous allons avoir besoin de quelques logiciels. Récupérez les
packages suivants, et installez les à l'endroit indiqué.</p>
<h3>Pour le serveur :</h3>
<ul>
<li>pppd (version 2.3 ou supérieure)</li>
<li>ssh (version 1.2.26 ou supérieure)</li>
</ul>
<h3>Pour le client :</h3>
<ul>
<li>pppd (la même version que le serveur)</li>
<li>ssh</li>
<li><a href=
"ftp://ftp.vein.hu/ssa/contrib/mag/pty-redir-0.1.tar.gz">pty-redir</a></li>
</ul>
<h2><a name="ss5.3">5.3 Serveur: Compiler le noyau</a></h2>
<p>Pour commencer, vous aurez probablement besoin de recompiler le
noyau pour le serveur. Il faut vous assurer que les options
suivantes du noyau sont activées, en plus des option réseaux de
base, et de toutes celles dont vous avez besoin. Si vous n'avez
jamais compilé de noyau, référez vous au <a href=
"/HOWTO/Kernel-HOWTO.html">Kernel HOWTO</a>.</p>
<p>Pour les noyaux 2.0 :</p>
<ul>
<li>CONFIG_FIREWALL</li>
<li>CONFIG_IP_FORWARD</li>
<li>CONFIG_IP_FIREWALL</li>
<li>CONFIG_IP_ROUTER</li>
<li>CONFIG_PPP</li>
</ul>
<p>Pour les noyaux 2.2 :</p>
<ul>
<li>CONFIG_FIREWALL</li>
<li>CONFIG_IP_ADVANCED_ROUTER</li>
<li>CONFIG_IP_FIREWALL</li>
<li>CONFIG_IP_ROUTER</li>
<li>CONFIG_PPP</li>
</ul>
<h2><a name="ss5.4">5.4 Serveur: Configurer les paramètres
réseaux</a></h2>
<p>Si vous préparez un serveur ne disposant que d'une carte réseau,
je vous suggère d'envisager d'en acheter une autre, et de refaire
la connectique de votre réseau. La meilleure méthode pour garder
votre réseau privé est encore de le doter de ses propres câbles. Si
vous avez deux cartes réseaux, vous aurez besoin de savoir les
configurer. Nous nous servirons de eth0 comme interface externe, et
de eth1 comme interface interne.</p>
<h3>Configurer les interfaces</h3>
<p>Nous devons tout d'abord configurer l'interface externe du
serveur. Vous êtes censé savoir le faire, et l'avez probablement
déjà fait. Si ce n'est pas le cas, faites le. Si vous ne savez pas
le faire, référez vous au <a href=
"/HOWTO/NET3-4-HOWTO.html">Networking HOWTO</a></p>
<p>Occupons nous maintenant de l'interface interne. Selon la
numérotation que nous avons choisi, elle dispose de l'adresse
192.168.40.254.</p>
<p>Pour les noyaux 2.0, utilisez les commandes suivantes :</p>
<pre>
# /sbin/ifconfig eth1 192.168.40.254 netmask 255.255.255.0 broadcast 192.168.40.255
# /sbin/route add -net 192.168.40.0 netmask 255.255.255.0 dev eth1
</pre>
<p>Pour les noyaux 2.2, utilisez la commande suivante :</p>
<pre>
# /sbin/ifconfig eth1 192.168.40.254 netmask 255.255.255.0 broadcast 192.168.40.255
</pre>
<p>Cela active nos interfaces. Vous pouvez maintenant communiquer
avec les machines situées sur les deux réseaux connectés localement
au serveur.</p>
<h3>Mettre les routes en place</h3>
<p>Nous pouvons parler aux machines situées sur nos réseaux locaux,
mais ne pouvons accéder au reste de notre réseau interne. Ceci
nécessite quelques lignes de code supplémentaires. Pour pouvoir
atteindre les machines situées sur les autres sous-réseaux, nous
devons avoir une route envoyant le trafic vers le routeur Cisco.
C'est ce que fait la commande suivante :</p>
<pre>
# /sbin/route add -net 192.168.0.0 gw 192.168.254.254 netmask 255.255.0.0 dev eth1
</pre>
<p>Cette ligne indique au noyau que le trafic destiné au réseau
192.168.0.0 devrait être envoyé par eth1, et transmis au Cisco. Le
trafic pour notre réseau local va toujours où il est supposé aller
puisque les tables de routage sont ordonnées par taille de masque
de sous-réseau. Si nous devions avoir d'autres réseaux internes
dans notre réseau, nous devrions avoir une ligne comme celle-ci
pour chacun d'entre eux.</p>
<h3>Mettre en place les règles de filtrage</h3>
<p>Très bien, nous pouvons donc atteindre toutes les machines que
nous voulons. Nous devons maintenant écrire les règles de filtrage
du firewall qui autorise ou refuse l'accès au via le serveur
VPN.</p>
<p>Pour mettre en place les règles avec <code>ipfwadm</code>,
lancez le ainsi :</p>
<pre>
# /sbin/ipfwadm -F -f
# /sbin/ipfwadm -F -p deny
# /sbin/ipfwadm -F -a accept -S 192.168.40.0/24 -D 192.168.0.0/16
# /sbin/ipfwadm -F -a accept -b -S 192.168.10.0/24 -D 192.168.0.0/16
# /sbin/ipfwadm -F -a accept -b -S 192.168.11.0/24 -D 192.168.0.0/16
</pre>
<p>Pour mettre en place les règles avec <code>ipchains</code>,
lancez le ainsi :</p>
<pre>
# /sbin/ipchains -F forward
# /sbin/ipchains -P forward DENY
# /sbin/ipchains -A forward -j ACCEPT -s 192.168.40.0/24 -d 192.168.0.0/16
# /sbin/ipchains -A forward -j ACCEPT -b -s 192.168.10.0/24 -d 192.168.0.0/16
# /sbin/ipchains -A forward -j ACCEPT -b -s 192.168.11.0/24 -d 192.168.0.0/16
</pre>
<p>Cela dit au noyau de refuser tout trafic, excepté celui
provenant du réseau 192.168.40.0/24 et destiné au réseau
192.168.0.0/16. Le trafic est autorisé entre les réseaux
192.168.10.0/24 et 192.168.0.0/16, de même que pour le réseau
192.168.11.0. Ces deux dernières règles sont bi-directionnelles, ce
qui est important pour obtenir un routage fonctionnant dans les
deux sens.</p>
<h3>Le routage</h3>
<p>Pour les utilisateurs souhaitant se connecter depuis leur
domicile, tout fonctionnera parfaitement à partir de maintenant.
Toutefois, pour les bureaux distants, nous devons réaliser un peu
de routage. Nous devons tout d'abord dire au routeur principal que
les bureaux distants sont derrière le serveur VPN, et donc lui
spécifier des routes indiquant d'envoyer le trafic destiné aux
bureaux distants au VPN. Ceci fait, il faut indiquer au serveur VPN
ce qu'il doit faire de ce trafic. Pour ce faire, il faut lancer la
commande <code>route</code> sur le serveur. Le seul problème est
que pour que celle-ci fonctionne, la liaison doit fonctionner. Si
celle-ci tombe, la route sera perdue. La solution consiste à
ajouter les routes quand les clients se connectent, ou, plus
simplement, à lancer la commande route fréquemment, étant donné
qu'il n'est pas grave de l'utiliser plus que nécessaire. De fait,
créez un script contenant les lignes suivantes, et ajoutez le à
votre crontab pour qu'il soit lancé toutes les quelques
minutes.</p>
<pre>
/sbin/route add -net 192.168.11.0 gw 192.168.10.253 netmask 255.255.255.0
/sbin/route add -net 192.168.10.0 gw 192.168.11.253 netmask 255.255.255.0
</pre>
<h2><a name="ss5.5">5.5 Serveur: Configurer
<code>pppd</code></a></h2>
<p>Nous allons maintenant configurer pppd sur le serveur pour gérer
les connections au VPN. Si vous utilisez déjà ce serveur pour gérer
des utilisateurs accédant au réseau par modem, ou que vous même
vous servez d'un modem pour sortir du réseau, sachez que ces
modifications peuvent affecter ces services. J'expliquerais comment
éviter les conflits à la fin de cette section.</p>
<h3><code>/etc/ppp/</code></h3>
<p>Ce répertoire peut contenir de nombreux fichiers. Vous disposez
déjà probablement d'un fichier appelé <code>options</code>. Ce
fichier contient toutes les options globales pour
<code>pppd</code>. Elles ne peuvent être surchargées par
l'utilisation de <code>pppd</code> en ligne de commande.</p>
<h3><code>/etc/ppp/options</code></h3>
<p>Votre fichier <code>options</code> devrait au moins contenir les
paramètres suivants :</p>
<pre>
ipcp-accept-local
ipcp-accept-remote
proxyarp
noauth
</pre>
<p>Les deux premières lignes indiquent à <code>pppd</code>
d'accepter que l'autre côté spécifie les adresses IP. Ces options
sont nécessaires lorsque l'on se connecte avec des bureaux
distants, mais peut être désactivée si l'on ne la fait qu'avec des
travailleurs à domicile. Les laisser activées ne pose pas de
problèmes, étant donné qu'elles n'empêchent pas le serveur
d'assigner une adresse, mais informe simplement celui-ci que le
client a le droit d'en proposer une.</p>
<p>La troisième ligne est très importante. Selon la page man de
<code>pppd</code> :</p>
<pre>
proxyarp
        Ajoute une entrée à la table ARP [Address Resolution
        Protocol] de ce système avec l'adresse IP du pair
        et l'adresse Ethernet de ce système. Cela aura pour 
        effet de faire croire aux autres systèmes que
        le pair est situé sur l'ethernet local.
</pre>
<p>C'est une option importante, car si elle n'est pas utilisée, le
trafic local ne pourra pas revenir par le tunnel.</p>
<p>La dernière ligne est toute aussi importante. Elle informe
<code>pppd</code> qu'il faut autoriser les connections sans nom
d'utilisateur ni mot de passe. Cette méthode ne nuit pas à la
sécurité, puisque l'authentification est déjà réalisée par
<code>sshd</code>.</p>
<h3>Eviter les conflits</h3>
<p>Si vous gérez d'autres services avec <code>pppd</code>, vous
devez considérer que les configurations respectives de ces autres
services peuvent être différentes de celle requise par le VPN.
<code>pppd</code> est conçu pour que les options du fichier
d'options principal <code>/etc/ppp/options</code> ne puissent pas
être surchargées par les options spécifiées au moment de
l'exécution, et ceci pour des raisons de sécurité. Afin d'éviter
les conflits, déterminez les options qui en sont à l'origine, et
déplacez les du fichier principal vers un fichier d'option
distinct, chargé lorsque l'application appropriée de
<code>pppd</code> est lancée.</p>
<h2><a name="ss5.6">5.6 Serveur: Configurer
<code>sshd</code></a></h2>
<p>Voici a quoi ressemble mon fichier
<code>/etc/sshd_config</code>, et à quoi devrait approximativement
ressembler le votre :</p>
<pre>
# Fichier de configuration ssh du serveur

Port 22
ListenAddress 0.0.0.0
HostKey /etc/ssh_host_key
RandomSeed /etc/ssh_random_seed
ServerKeyBits 768
LoginGraceTime 600
KeyRegenerationInterval 3600
PermitRootLogin yes
IgnoreRhosts yes
StrictModes yes
QuietMode no
FascistLogging yes
CheckMail no
IdleTimeout 3d
X11Forwarding no
PrintMotd no
KeepAlive yes
SyslogFacility DAEMON
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
UseLogin no
</pre>
<p>Il est important de remarquer que l'authentification par mot de
passe a été désactivée, tout comme tous les autres services "r".
J'ai aussi désactivé la notification de mail, et le message du
jour, étant donné qu'il peuvent désorienter <code>pppd</code> du
côté client. J'autorise toujours la connexion en tant que root, qui
reste sûre étant donné qu'elle requiert l'utilisation d'une
clé.</p>
<h2><a name="user-accounts"></a> <a name="ss5.7">5.7 Serveur:
Mettre en place les comptes utilisateurs</a></h2>
<p>Nous allons maintenant mettre en place les comptes
utilisateurs.</p>
<h3>Ajouter un groupe <code>vpn-users</code></h3>
<p>lancez simplement:</p>
<pre>
# /usr/sbin/groupadd vpn-users
</pre>
<p>Faites maintenant un cat du fichier <code>/etc/group</code> et
regardez la dernière ligne. Il doit s'agir de l'entrée pour le
groupe vpn-users. Remarquez le troisième champ. Il s'agit de
l'identifiant du groupe (Group ID ou GID). Notez le, étant donné
que nous allons en avoir besoin sous peu. Dans notre exemple, GID
vaut 101.</p>
<h3>Créer le répertoire domicile des <code>vpn-users</code></h3>
<p>Nous utiliserons un seul répertoire domicile pour tous les
utilisateurs. Lancez simplement :</p>
<pre>
# mkdir /home/vpn-users
</pre>
<h3>Le répertoire <code>.ssh</code></h3>
<p>Créez maintenant le répertoire <code>.ssh</code> dans le
répertoire domicile des <code>vpn-users</code>.</p>
<pre>
# mkdir /home/vpn-users/.ssh
</pre>
<h3>Ajouter des utilisateurs</h3>
<p>Ca devient amusant. Nous allons éditer le fichier
<code>/etc/passwd</code> à la main :) . Normalement, vous laissez
le système gérer ce fichier, mais pour une installation aussi
étrange que celle-ci, il est plus simple de le faire vous même.
Pour commencer, ouvrons le fichier <code>/etc/passwd</code> et
regardons ce qu'il contient. Voici un exemple de ce que vous
pourriez trouver:</p>
<pre>
...
nobody:x:65534:100:nobody:/dev/null:
mwilson:x:1000:100:Matthew Wilson,,,:/home/mwilson:/bin/bash
joe:*:1020:101:Joe Mode (home),,,:/home/vpn-users:/usr/sbin/pppd
bill:*:1020:101:Bill Smith (home),,,:/home/vpn-users:/usr/sbin/pppd
frank:*:1020:101:Frank Jones (home),,,:/home/vpn-users:/usr/sbin/pppd
...
</pre>
<p>Vous trouverez le premier utilisateur sur la plupart des
systèmes. Le suivant, c'est moi :). Après viennent quelques
vpn-users que j'ai créé. Le premier champ est le nom d'utilisateur,
le second le mot de passe. Le troisième est l'identifiant
d'utilisateur (User ID ou UID), et le quatrième l'identifiant de
groupe. Après viennent certaines infos sur l'identité de
l'utilisateur (dans le cinquième champ). Le sixième est le
répertoire domicile de l'utilisateur, et le dernier son shell.
Comme vous pouvez le voir, chaque champ est séparé par une deux
points. Regardez les trois dernières lignes. La seule différence
existant entre eux est le nom d'utilisateur du premier champ et
l'information sur l'utilisateur dans le cinquième. Nous souhaitons
créer une ligne comme celles-ci pour chaque utilisateur. Evitez
d'utiliser un seul utilisateur pour toutes les connections, faute
de quoi il vous sera impossible de les différencier par la suite.
Donc, copiez la dernière ligne du fichier, et éditez la afin de
qu'elle ressemble à notre exemple. Assurez vous que le second champ
contient une astérisque. Le troisième champ devrait être unique par
rapport à tous les autres identifiants dans le fichier. J'ai
utilisé 1020. Vous devriez utiliser un nombre supérieur à 1000,
étant donné que les nombres inférieurs à 1000 sont généralement
réservés pour le système. Le quatrième champ devrait être
l'identifiant du groupe vpn-users. Je vous ai dit tout à l'heure de
l'écrire, c'est maintenant qu'il faut s'en servir. Donc, mettez ici
l'identifiant du groupe. Enfin, changez le répertoire domicile en
<code>/home/vpn-users</code>, et le shell en
<code>/usr/sbin/pppd</code>. C'est fait. Maintenant, copiez celle
ligne pour créer plus d'utilisateurs. Editez simplement le premier
et le dernier champ, et c'est fait.</p>
<h2><a name="ss5.8">5.8 Serveur: Administration</a></h2>
<p>Un des avantages de l'utilisation de ce systèmes pour les
comptes utilisateurs est que l'on peut bénéficier des commandes
d'administrations d'utilisateur UNIX. Comme chaque client est
connecté en tant qu'utilisateur, on peut utiliser les méthodes
standards pour obtenir les statistiques des utilisateurs. Voici
quelques commandes que j'aime utiliser pour voir ce qui se
passe:</p>
<dl>
<dt><b>who</b></dt>
<dd>
<p>Affiche les utilisateurs connectés actuellement, ainsi que le
moment où ils se sont connectés, de quelle machines (par le nom de
celle-ci ou son adresse IP), et sur quel port.</p>
</dd>
<dt><b>w</b></dt>
<dd>
<p>Cette commande affiche une description plus exhaustive des
entités actuellement connectées. Il fournit aussi le temps écoulé
depuis la mise en fonctionnement du système, ainsi que sa charge.
De même, il liste les processus des utilisateurs (qui devraient
être -pppd pout les client VPN) qui tournent, le temps processeur
non utilisé (idle time), et l'utilisation faite du processeur, pour
chacun des processus et pour le processus courant. Référez vous à
la page man <code>w</code> pour plus d'information.</p>
</dd>
<dt><b>last [nom_utilisateur]</b></dt>
<dd>
<p>Cette commande fournit l'historique pour l'utilisateur spécifié,
et pour tout les utilisateurs si aucun nom_utilisateur n'est
fourni. Elle est particulièrement utile pour s'assurer que les
tunnels fonctionnent bien, car elle affiche le temps écoulé depuis
la connexion de l'utilisateur, et donne la liste des utilisateur
connectés. Je dois vous prévenir que sur un système qui n'a pas été
redémarré depuis longtemps, cette liste peut devenir extrêmement
longue. Je vous conseille donc de l'utiliser conjointement avec
<code>grep</code> ou <code>head</code>, grâce à un pipe, pour
découvrir exactement ce que vous souhaitez.</p>
</dd>
</dl>
<p>Vous pouvez aussi contrôler quels utilisateurs sont autorisés à
se connecter en modifiant le fichier
<code>/home/vpn-users/.ssh/authorized_keys</code>. Si vous en
retirez la ligne contenant la clé publique d'un utilisateur, il ne
sera plus capable de se reconnecter.</p>
<h2><a name="ss5.9">5.9 Client: Compiler le noyau</a></h2>
<p>Nous nous intéressons maintenant au client. Nous devons tout
d'abord recompiler le noyau pour qu'il contienne toutes les
fonctionnalités nécessaires. Il faut au minimum disposer de ppp
dans le noyau. Après cela, il nous faudra les fonctions de
forwarding, de firewall, et de passerelle, mais seulement si vous
comptez autoriser d'autres machines à accéder au tunnel. Dans cet
exemple, je configurerais une des machines du bureau distant.
Ajoutez les options ci-dessous à votre noyau. Une fois encore, si
vous n'avez jamais recompilé de noyau, référez vous au <a href=
"/HOWTO/Kernel-HOWTO.html">Kernel HOWTO</a>.</p>
<p>Pour les noyaux 2.0:</p>
<ul>
<li>CONFIG_PPP</li>
<li>CONFIG_FIREWALL</li>
<li>CONFIG_IP_FORWARD</li>
<li>CONFIG_IP_FIREWALL</li>
<li>CONFIG_IP_ROUTER</li>
<li>CONFIG_IP_MASQUERADE</li>
<li>CONFIG_IP_MASQUERADE_ICMP</li>
</ul>
<p>Pour les noyaux 2.2:</p>
<ul>
<li>CONFIG_PPP</li>
<li>CONFIG_FIREWALL</li>
<li>CONFIG_IP_ADVANCED_ROUTER</li>
<li>CONFIG_IP_FIREWALL</li>
<li>CONFIG_IP_ROUTER</li>
<li>CONFIG_IP_MASQUERADE</li>
<li>CONFIG_IP_MASQUERADE_ICMP</li>
</ul>
<h2><a name="ss5.10">5.10 Client: Configurer les paramètres
réseaux</a></h2>
<p>Nous devons maintenant configurer les paramètres réseaux sur
notre client. Considérons que tout fonctionne correctement avec le
réseau externe. Nous allons maintenant mettre en place l'interface
interne du client notre intranet.</p>
<h3>Interface</h3>
<p>Nous devons tout d'abord configurer l'interface réseau interne.
Pour ce faire, ajoutez les lignes suivantes à votre fichier
<code>/etc/rc.d/rc.inet1</code> (ou équivalent):</p>
<p>Pour les noyaux 2.0 :</p>
<pre>
/sbin/ifconfig eth1 192.168.10.253 broadcast 192.168.10.255 netmask 255.255.255.0
/sbin/route add -net 192.168.10.0 netmask 255.255.255.0 dev eth1
</pre>
<p>Pour les noyaux 2.2 :</p>
<pre>
/sbin/ifconfig eth1 192.168.10.253 broadcast 192.168.10.255 netmask 255.255.255.0
</pre>
<h3>Règles de filtrage</h3>
<p>Pour configurer le bureau distant, nous voulons mettre en place
des règles de filtrage qui permettent au trafic d'emprunter le
tunnel dans les deux directions. Ajoutez pour cela les lignes
suivantes à votre fichier <code>/etc/rc.d/rc.inet1</code> ou
équivalent:</p>
<p>Pour les noyaux 2.0 :</p>
<pre>
/sbin/ipfwadm -F -f
/sbin/ipfwadm -F -p deny
/sbin/ipfwadm -F -a accept -b -S 192.168.10.0/24 -D 192.168.0.0/16
</pre>
<p>Pour les noyaux 2.2 :</p>
<pre>
/sbin/ipchains -F forward
/sbin/ipchains -P forward DENY
/sbin/ipchains -A forward -j ACCEPT -b -s 192.168.10.0/24 -d 192.168.0.0/16
</pre>
<p>Vous avez peut-être remarqué que ces lignes ressemblent à celles
que nous avons sur le serveur. C'est parce qu'elles sont
identiques. Elles décrivent simplement où le trafic est autorisé à
aller, c'est à dire entre les deux réseaux.</p>
<h3>Routage</h3>
<p>Les seules deux routes supplémentaires nécessaires sont crées
par le script qui met en place le tunnel.</p>
<h2><a name="ss5.11">5.11 Client: Configurer
<code>pppd</code></a></h2>
<p>Vous n'aurez peut-être pas besoin d'éditer le fichier
<code>/etc/ppp/options</code> du client. Ce ne sera nécessaire que
si l'option "auth" ou certaines autres options sont présentes.
Essayez, et si ça ne marche pas, un fichier
<code>/etc/ppp/options</code> vide fonctionnera. Continuez
simplement à ajouter les options de l'ancien fichier pour savoir
laquelle pose problème (si ce n'est pas évident), et regardez si
vous pouvez vous en passer. Peut-être est-ce le cas, notamment si
vous ne vous servez de <code>pppd</code> pour rien d'autre.</p>
<h2><a name="ss5.12">5.12 Client: Configurer
<code>ssh</code></a></h2>
<p>En tant que root, exécutez les lignes suivantes sur le
client:</p>
<pre>
# mkdir /root/.ssh
# ssh-keygen -f /root/.ssh/identity.vpn -P ""
</pre>
<p>Ces commandes vont créer deux fichiers,
<code>identity.vpn</code> et <code>identity.vpn.pub</code> dans le
répertoire <code>.ssh</code>. Le premier est votre clé privée, et
devrait le rester. <em>NE L'ENVOYEZ JAMAIS SUR LE RESEAU</em>, à
moins que ce ne soit au travers d'un transfert chiffrée. Le second
fichier est votre clé publique, et vous pouvez l'envoyer où vous
voulez, il ne sert qu'à vous autoriser l'accès aux autres systèmes,
et ne peut être utilisé pour pénétrer le votre. Il s'agit d'un
fichier texte d'une ligne, codant votre clé. A la fin de la ligne
se trouve le champ commentaire, que vous pouvez modifier sans
craindre de briser la clé. Voici un exemple de clé :</p>
<pre>
1024 35 1430723736674162619588314275167.......250872101150654839 root@vpn-client.mycompany.com
</pre>
<p>C'est en fait beaucoup plus long que cela, mais ça ne tiendrait
pas sur une page si je montrais la totalité de la chose. Copiez
votre clé dans le fichier
<code>/home/vpn-users/.ssh/authorized_keys</code> sur le serveur.
Assurez vous qu'il s'agit de la seule clé de la ligne, et que
chaque clé n'est pas séparée sur de multiples lignes. Vous pouvez
modifier le champ de commentaire comme vous voulez pour vous
rappeler quelle clé corresponds à quel utilisateur. Je vous le
recommande fortement.</p>
<h2><a name="ss5.13">5.13 Client: mettre en place la
connexion</a></h2>
<p>Nous allons maintenant essayer de réaliser la connexion au
serveur VPN. Tout d'abord, nous avons besoin d'éditer le fichier
known_hosts de <code>ssh</code> pour réaliser la moindre connexion.
Exécutez ceci:</p>
<pre>
# ssh vpn.mycompany.com
</pre>
<p>Répondez par l'affirmative lorsqu'il vous est demandé si vous
souhaitez continuer à vous connecter. Le serveur va répondre
''permission denied'', mais c'est normal. Il est important que vous
utilisiez le même nom pour le serveur que celui que vous utilisez
pour vos scripts de connexion. Exécutez maintenant les lignes
suivantes. Vous aurez évidement besoin de changer la plupart des
options pour correspondre à votre installation.</p>
<pre>
# /usr/sbin/pty-redir /usr/bin/ssh -t -e none -o 'Batchmode yes' -c blowfish -i /root/.ssh/identity.vpn -l vpn-user vpn.mycompany.com &gt; /tmp/vpn-device

        (Maintenant, attendez à peu près 10 secondes)

# /usr/sbin/pppd `cat /tmp/vpn-device` 192.168.10.254:192.168.40.254
</pre>
<p>Remarquez les adresses IP spécifiées dans la ligne pppd. La
première est l'adresse du client à l'autre bout du tunnel. La
seconde est l'adresse de l'issue du tunnel coté serveur, mise à la
valeur de l'adresse interne du serveur. Si tout semble fonctionner,
continuez. Si non, vérifiez que vous avez bien toutes les options,
et qu'elles sont correctement entrée. Si les problèmes persistent,
vérifiez la <a href="#pitfalls">section Problèmes</a>.</p>
<h2><a name="ss5.14">5.14 Client: Définir les routes</a></h2>
<p>Définissez maintenant la route pour envoyer le trafic au travers
du tunnel. Lancez simplement cette commande :</p>
<pre>
# /sbin/route add -net 192.168.0.0 gw vpn-internal.mycompany.com netmask 255.255.0.0
</pre>
<p>Vous devriez maintenant être capable de communiquer avec les
machines de l'autre côté du tunnel. Faites un essais... Nickel,
hein? Si ça ne fonctionne pas, essayez d'utiliser <code>ping</code>
et <code>traceroute</code> pour découvrir où se situe le problème.
Si en fait ça fonctionne réellement, continuez en mettant en place
des scripts qui feront le travail pour vous.</p>
<h2><a name="ss5.15">5.15 Client: Faire des scripts</a></h2>
<p>Utilisez le script vpnd que je montre
&lt;@@ref&gt;vpn-scriptici. Vous n'avez qu'à le modifier un petit
peu. Faites les changements suivants:</p>
<ul>
<li>Changez les variables du début pour correspondre à votre
configuration. La plupart sont probablement corrects, mais vous
pouvez les changer si vous en avez besoin...</li>
<li>Ligne 27: ajoutez les adresses IP locales et distantes avant
$PPP_OPTIONS</li>
<li>Ligne 31: changez cette ligne, et les deux suivantes pour
configurer les routes pour votre réseau interne.</li>
</ul>
<h3>Le maintenir en état de fonctionnement</h3>
<p>Même si les scripts bash sont généralement stables, il sont
connus pour planter parfois. Pour s'assurer que le script
<code>vpnd</code> continue à tourner, ajoutez une entrée dans la
contab du client qui exécute le script <code>check-vpnd</code>. Je
lance le mien toute les cinq minutes à peu près. Si
<code>vpnd</code> tourne réellement, <code>check-vpnd</code>
n'utilise pas beaucoup de puissance de calcul.</p>
<h2><a name="s6">6. Annexes</a></h2>
<h2><a name="pitfalls"></a> <a name="ss6.1">6.1 Problèmes</a></h2>
<p>Voici quelques-uns des problèmes que j'ai rencontré alors que
j'utilisais ce système. Je les ai indiqués ici dans l'espoir que
vous puissiez les éviter. Si vous rencontrez un problème que je ne
décris pas ici, envoyez moi un <a href=
"mailto:matthew@shinythings.com">courrier électronique</a> pour que
je puisse le référencer et permettre aux autres de l'éviter.</p>
<h3>Lecture : erreur d'entrée/sortie</h3>
<p>Cette erreur vient apparemment de pppd. C'est du à l'utilisation
d'une mauvaise version de pppd. Si cela vous arrive, essayez de
mettre à jour les deux côtés de la connexion avec la dernière
version de pppd. J'ai découvert que la version 2.2 pose problème,
et utilise les versions 2.3.7 ou 2.3.8 à la place.</p>
<h3>SIOCADDRT: Le réseau est non-atteignable</h3>
<p>Cette erreur est générée par <code>route</code>. Je l'ai vu se
produire quand le temps d'attente entre <code>ssh</code> et
<code>pppd</code> n'est pas assez grand. Si vous rencontrez cette
erreur, lancez <code>ifconfig</code>, il se peut que vous vous
aperceviez qu'il n'y a pas d'interface pppX. Cela signifie que
<code>ssh</code> n'avait pas fini l'authentification avant que
<code>pppd</code> ne soit lancé, et que <code>pppd</code> n'ait
donc pu réaliser la connexion. Augmentez simplement le délai
d'attente, et vos problèmes seront résolus.</p>
<p>Je me demande toutefois s'il n'existe pas une option pppd qui
règlerait ce problème.</p>
<h3><a name="ipv4forwarding"></a> Transmission IPv4 et les noyaux
2.2</h3>
<p>Dans les nouveaux noyaux 2.2, vous devez spécifier que vous
installez le forwarding IPv4 dans le noyau au démarrage. Ce qui se
fait avec la commande suivante:</p>
<pre>
# echo 1 &gt; /proc/sys/net/ipv4/ip_forward
</pre>
<p>Sans cela, le noyau ne transmettra aucun datagramme, et le
serveur ne fonctionnera donc pas, pas plus qu'aucun des clients
passerelles.</p>
<h3>Routage</h3>
<p>Cela va sans dire, mais faites attention quand vous routez des
adresses réelles que vous ne routez pas le trafic destiné aux
adresses externes du serveur VPN au travers du tunnel. Ca ne le
fera pas (Oui, il s'agit <em>vraiment</em> d'une expérience
personnelle).</p>
<h2><a name="ss6.2">6.2 Configuration minimale matérielle et
logicielle</a></h2>
<h3>Configuration matérielle minimale</h3>
<p>Croyez le ou pas, ce système a été exécuté sur un 486SX33 avec 8
Mo de RAM. Ca ne marchait toutefois pas très bien, car il avait des
problèmes à gérer le gros trafic.</p>
<p>Ca n'a cependant pas été trop dur de le faire fonctionner. Ce
système marche très bien sur un Pentium 75 avec 16 Mo de RAM,
utilisant une distribution LRP sur disquette, avec 6 Mo de ramdisk,
et 10 Mo de mémoire principale. J'ai testé cette configuration en
faisant passer un flux RealVideo à 700Kbits au travers pendant plus
d'une heure.</p>
<p>Je le fait maintenant fonctionner en général sur des Pentium 90,
étant donné que leur fréquence d'horloge fonctionne mieux avec les
cartes Ethernet à 100Mbits/sec.</p>
<h3>Configuration logicielle minimale</h3>
<p>Ce système fonctionne tant avec les noyaux 2.0 qu'avec les 2.2.
Le script permettant de garder le tunnel en fonctionnement demande
un bash raisonnablement moderne. J'ai toutefois remarqué que les
versions de bash que l'on trouve sur certaines distributions ne
fonctionnent pas très bien avec le script.</p>
<p>De fait, si quelqu'un pouvait m'aider à améliorer mes scripts
(ou même à écrire un exécutable?), ça m'aiderait beaucoup. Je ne
suis pas certains de savoir pourquoi, mais même mon propre bash ne
suit pas les règles et ne semble pas interpréter les signaux
correctement. Si vous faites des améliorations, envoyez moi un
courrier électronique à <a href=
"mailto:matthew@shinythings.com">matthew@shinythings.com</a> s'il
vous plait.</p>
</body>
</html>
doc-linux-fr-html 2013.01-3ubuntu1 / usr / share / doc / HOWTO / fr-html / VPN-HOWTO.html
