Page suivante - Page précédente - Table des matières

5. Implémentation

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.

5.1 Organisation

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.

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.

Nous n'avons pas besoin de connaître explicitement les adresses externes. Vous devriez avoir les vôtres, fournies par votre FAI.

5.2 Rassembler les outils

Nous allons avoir besoin de quelques logiciels. Récupérez les packages suivants, et installez les à l'endroit indiqué.

Pour le serveur :

  • pppd (version 2.3 ou supérieure)
  • ssh (version 1.2.26 ou supérieure)

Pour le client :

  • pppd (la même version que le serveur)
  • ssh
  • pty-redir

5.3 Serveur: Compiler le noyau

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 Kernel HOWTO.

Pour les noyaux 2.0 :

  • CONFIG_FIREWALL
  • CONFIG_IP_FORWARD
  • CONFIG_IP_FIREWALL
  • CONFIG_IP_ROUTER
  • CONFIG_PPP

Pour les noyaux 2.2 :

  • CONFIG_FIREWALL
  • CONFIG_IP_ADVANCED_ROUTER
  • CONFIG_IP_FIREWALL
  • CONFIG_IP_ROUTER
  • CONFIG_PPP

5.4 Serveur: Configurer les paramètres réseaux

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.

Configurer les interfaces

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 Networking HOWTO

Occupons nous maintenant de l'interface interne. Selon la numérotation que nous avons choisi, elle dispose de l'adresse 192.168.40.254.

Pour les noyaux 2.0, utilisez les commandes suivantes :

# /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

Pour les noyaux 2.2, utilisez la commande suivante :

# /sbin/ifconfig eth1 192.168.40.254 netmask 255.255.255.0 broadcast 192.168.40.255

Cela active nos interfaces. Vous pouvez maintenant communiquer avec les machines situées sur les deux réseaux connectés localement au serveur.

Mettre les routes en place

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 : 

# /sbin/route add -net 192.168.0.0 gw 192.168.254.254 netmask 255.255.0.0 dev eth1

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.

Mettre en place les règles de filtrage

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.

Pour mettre en place les règles avec ipfwadm, lancez le ainsi :

# /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

Pour mettre en place les règles avec ipchains, lancez le ainsi :

# /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

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.

Le routage

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 route 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. 

/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

5.5 Serveur: Configurer pppd

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.

/etc/ppp/

Ce répertoire peut contenir de nombreux fichiers. Vous disposez déjà probablement d'un fichier appelé options. Ce fichier contient toutes les options globales pour pppd. Elles ne peuvent être surchargées par l'utilisation de pppd en ligne de commande.

/etc/ppp/options

Votre fichier options devrait au moins contenir les paramètres suivants :

ipcp-accept-local
ipcp-accept-remote
proxyarp
noauth

Les deux premières lignes indiquent à pppd 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.

La troisième ligne est très importante. Selon la page man de pppd :

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.

C'est une option importante, car si elle n'est pas utilisée, le trafic local ne pourra pas revenir par le tunnel.

La dernière ligne est toute aussi importante. Elle informe pppd 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 sshd.

Eviter les conflits

Si vous gérez d'autres services avec pppd, vous devez considérer que les configurations respectives de ces autres services peuvent être différentes de celle requise par le VPN. pppd est conçu pour que les options du fichier d'options principal /etc/ppp/options 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 pppd est lancée.

5.6 Serveur: Configurer sshd

Voici a quoi ressemble mon fichier /etc/sshd_config, et à quoi devrait approximativement ressembler le votre :

# 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

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 pppd 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é.

5.7 Serveur: Mettre en place les comptes utilisateurs

Nous allons maintenant mettre en place les comptes utilisateurs.

Ajouter un groupe vpn-users

lancez simplement:

# /usr/sbin/groupadd vpn-users

Faites maintenant un cat du fichier /etc/group 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.

Créer le répertoire domicile des vpn-users

Nous utiliserons un seul répertoire domicile pour tous les utilisateurs. Lancez simplement :

# mkdir /home/vpn-users

Le répertoire .ssh

Créez maintenant le répertoire .ssh dans le répertoire domicile des vpn-users.

# mkdir /home/vpn-users/.ssh

Ajouter des utilisateurs

Ca devient amusant. Nous allons éditer le fichier /etc/passwd à 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 /etc/passwd et regardons ce qu'il contient. Voici un exemple de ce que vous pourriez trouver:

...
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
...

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 /home/vpn-users, et le shell en /usr/sbin/pppd. 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.

5.8 Serveur: Administration

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:

who

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.

w

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 w pour plus d'information.

last [nom_utilisateur]

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 grep ou head, grâce à un pipe, pour découvrir exactement ce que vous souhaitez.

Vous pouvez aussi contrôler quels utilisateurs sont autorisés à se connecter en modifiant le fichier /home/vpn-users/.ssh/authorized_keys. Si vous en retirez la ligne contenant la clé publique d'un utilisateur, il ne sera plus capable de se reconnecter.

5.9 Client: Compiler le noyau

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 Kernel HOWTO.

Pour les noyaux 2.0:

  • CONFIG_PPP
  • CONFIG_FIREWALL
  • CONFIG_IP_FORWARD
  • CONFIG_IP_FIREWALL
  • CONFIG_IP_ROUTER
  • CONFIG_IP_MASQUERADE
  • CONFIG_IP_MASQUERADE_ICMP

Pour les noyaux 2.2:

  • CONFIG_PPP
  • CONFIG_FIREWALL
  • CONFIG_IP_ADVANCED_ROUTER
  • CONFIG_IP_FIREWALL
  • CONFIG_IP_ROUTER
  • CONFIG_IP_MASQUERADE
  • CONFIG_IP_MASQUERADE_ICMP

5.10 Client: Configurer les paramètres réseaux

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.

Interface

Nous devons tout d'abord configurer l'interface réseau interne. Pour ce faire, ajoutez les lignes suivantes à votre fichier /etc/rc.d/rc.inet1 (ou équivalent):

Pour les noyaux 2.0 : 

/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

Pour les noyaux 2.2 : 

/sbin/ifconfig eth1 192.168.10.253 broadcast 192.168.10.255 netmask 255.255.255.0

Règles de filtrage

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 /etc/rc.d/rc.inet1 ou équivalent:

Pour les noyaux 2.0 :

/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

Pour les noyaux 2.2 :

/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

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.

Routage

Les seules deux routes supplémentaires nécessaires sont crées par le script qui met en place le tunnel.

5.11 Client: Configurer pppd

Vous n'aurez peut-être pas besoin d'éditer le fichier /etc/ppp/options 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 /etc/ppp/options 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 pppd pour rien d'autre.

5.12 Client: Configurer ssh

En tant que root, exécutez les lignes suivantes sur le client:

# mkdir /root/.ssh
# ssh-keygen -f /root/.ssh/identity.vpn -P ""

Ces commandes vont créer deux fichiers, identity.vpn et identity.vpn.pub dans le répertoire .ssh. Le premier est votre clé privée, et devrait le rester. NE L'ENVOYEZ JAMAIS SUR LE RESEAU, à 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é : 

1024 35 1430723736674162619588314275167.......250872101150654839 root@vpn-client.mycompany.com

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 /home/vpn-users/.ssh/authorized_keys 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.

5.13 Client: mettre en place la connexion

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 ssh pour réaliser la moindre connexion. Exécutez ceci:

# ssh vpn.mycompany.com

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.

# /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> /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

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 section Problèmes.

5.14 Client: Définir les routes

Définissez maintenant la route pour envoyer le trafic au travers du tunnel. Lancez simplement cette commande :

# /sbin/route add -net 192.168.0.0 gw vpn-internal.mycompany.com netmask 255.255.0.0

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 ping et traceroute 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.

5.15 Client: Faire des scripts

Utilisez le script vpnd que je montre <@@ref>vpn-scriptici. Vous n'avez qu'à le modifier un petit peu. Faites les changements suivants:

  • 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...
  • Ligne 27: ajoutez les adresses IP locales et distantes avant $PPP_OPTIONS
  • Ligne 31: changez cette ligne, et les deux suivantes pour configurer les routes pour votre réseau interne.

Le maintenir en état de fonctionnement

Même si les scripts bash sont généralement stables, il sont connus pour planter parfois. Pour s'assurer que le script vpnd continue à tourner, ajoutez une entrée dans la contab du client qui exécute le script check-vpnd. Je lance le mien toute les cinq minutes à peu près. Si vpnd tourne réellement, check-vpnd n'utilise pas beaucoup de puissance de calcul.

Page suivante - Page précédente - Table des matières