Mise en place d’un VPN Linux

Mise en place d’un VPN Linux – Linux

Entre le site professionnel et le Domicile

Remarques sur une expérience :

Le site société est équipé d’un frontal / firewall configuré comme suit

- Processeur Pentium III

- Linux mandrake 9.0

- Firewall basé sur iptables, configuré avec l’outil FwBuilder

- Une liaison ADSL Pro ( 1 Mb descendant, 256 Kb montant ) IP fixe

- Un réseau local 100 Mb, avec 12 machines ( serveurs Unix, Windows 2000, postes Windows 2000 et XP )

- Réseau local en 192.168.0.x / 23 bits de masque

- Domaine de type Windows 2000 server

Mon domicile est équipé de :

- frontal / firewall Linux Mandrake 9.0, AMD 350 Mhz

o firewall basé sur iptables, configuré avec FwBuilder

o Liaison ADSL ( 512 Kb descendant, 128 Kb montant ), IP dynamique

- Réseau local 10 Mbs

- 1 PC Pentium IV 2,66 Mhz, Windows XP Home édition

- Réseau local en 192.168.2.x / 24 bits de masque

- Workgroup local ( pas de serveur de domaine )

Objectif :

Relier les deux réseaux locaux, afin que chaque utilisateur habilité de chacun des réseaux puisse accéder aux ressources autorisées de l’autre réseau.

Netbios ( Windows à Windows )

VNC ( prise de contrôle à distance )

telnet vers serveurs Unix / Linux

Messagerie

Logiciels mis en œuvre :

Postes Windows : rien de particulier, sauf mise en place de VNC server et viewer sur les postes appelés à s’inter-connecter en prise de contrôle à distance.

Frontaux Linux : Outils pptpd ( serveur ) et pptp (client ) proposés en standard avec Mandrake 9.0

Création d’un nom de domaine dynamique sur http://www.dyndns.org , et utilisation de l’outil ez-ipupdate sous Linux pour mettre à jour ce nom DNS à chaque changement d’adresse IP de mon domicile (voir note concernant dyndns.org )

J’ai décidé de positionner mon domicile en serveur, et le site professionnel en client, car :

- Le bureau disposant d’une IP fixe, il m’était possible de configurer le firewall du domicile pour n’autoriser les appels VPN entrants que de ce site

- L’inverse ne me semblait pas possible, ce qui à mon avis représentait une faille importante de sécurité, d’autant plus que les ressources internes du bureau deviennent disponibles à un aboutissant du tunnel.

Mise en œuvre du VPN :

Les premières tentatives se sont avérées infructueuses, ce qui justifie la présente note .

1- Par défaut, le protocole GRE ( 47 ) n’est pas disponible sur ces noyaux Linux 2.4

2- Chaque tentative donnait lieu à une erreur dans /var/log/messages, de type :

…. (GRE )….. : Protocole not available

Sur chaque machine, tant client que serveur, il est nécessaire d’effectuer la commande suivante :

insmod ip_gre

Vous pouvez ensuite contrôler, grâce à la commande

lsmod

que le module ip_gre.o est bien installé , sur chaque machine

Configurations :

Vous trouverez ci-après les configurations de fichiers sur la base desquels j’ai pu faire fonctionner le VPN

Dès que je mettais en activité l’option « require-chap », le client disait qu’il était incapable de s’authentifier vis à vis du serveur ????

Attention : Toute modification de la configuration serveur nécessite d’arrêter le daemon et de le relancer avant nouvel essai !

kill pid_du_process_pptpd

pptdp

- Config serveur :

serveur : fichier /etc/ppp/pap-secrets : définit l’identification tunnel autorisée, depuis où !

# Secrets for authentication using PAP

# client server secret IP addresses

# Creation VPN en entree ( en tant que serveur )

monvpn * monpassword 195.146.234.150

# Ma connexion ADSL

mon_FAI_id * passwd_FAI *

Note : sur le serveur, on n’autorise que l’adresse 195.146.234.150 à se connecter avec cet identifiant « monvpn » : il s’agit de l’IP fixe du client ( le bureau, qui appelle )

serveur : fichier /etc/options.pptp : définit le mode de travail de pptp

# Lock the port

lock

# To log all traffic & errors into /var/log/daemons/….. ( ! performances )

#debug

# We need the tunnel server to authenticate itself

noauth

#require-chap

# Turn off transmission protocols we know won't be used

nobsdcomp

nodeflate

# We want MPPE

mppe-40

mppe-128

mppe-stateless

# We want a sane mtu/mru

mtu 1000

mru 1000

# Time this thing out of it goes poof

lcp-echo-failure 10

lcp-echo-interval 10

serveur : fichier /etc/pptpd.conf :

# Config pour pptp ( voir fichier précédent… )

option /etc/ppp/options.pptp

# le serveur présentera l’adresse 192.168.2.100 à son client

localip 192.168.2.100

# le serveur distribuera les adresses 101 à 103 au fur et à mesure des connexions

remoteip 192.168.2.101-103

- Config client :

client : fichier /etc/ppp/pap-secrets : définit l’identification tunnel vis à vis du serveur

# Secrets for authentication using PAP

# client server secret IP addresses

# ACCES vers domicile

monvpn dambrain.fr monpasswd *

Note : « monvpn » est un identifiant unique quelconque, identique sur client & serveur

Bien entendu, les passwords et identifiants ne sont pas les valeurs réelles : il s’agit d’exemples

« dambrain.fr » représente le nom DNS du serveur ( adresse IP dynamique maintenue par le DNS de dyndns.org )

client : fichier /etc/options.pptp : exactement la même chose que sur serveur ! (voir ci-avant )

Pour ma part, n’ayant pas compris toutes les subtilités de CHAP/PAP, j’ai préféré opter pour l’outil pptp-command afin de configurer le poste client ( en l’occurrence ici, la machine du bureau )

Dans mon exemple, lorsqu’il m’a demandé :

Nom du tunnel :

monvpn

Nom ou adresse IP du serveur (1):

dambrain.fr

Identifiant remote

monvpn

Mot de passe :

monpasswd

Identifiant local

Domaine\user ( je ne sais pas pourquoi ! !! )

Route a ajouter apres creation du tunnel (2) :

route add –net 192.168.2.0 netmask 255.255.255.0 dev DEV_TUNNEL

notes : (1) je ne peux utiliser qu’un nom DNS, car l’adresse IP du serveur est dynamique

(2) Le réseau côté serveur est de type 192.168.2.0 / 24 bits : on définit ici la route vers ce sous-réseau , pour toutes les machines utilisant ce routeur (client du VPN) !

(2) Attention : Si vous mettez ce sous-réseau en ‘route par défaut’, TOUT LE TRAFFIC de ce réseau local (client ) vers Internet va transiter par le serveur distant pour finalement atteindre Internet via l’ADSL du serveur distant ! Je ne pense pas que cela soit souhaitable, car le client a lui aussi un accès ADSL ( souvent ppp0, celui qui sert à établir le présent VPN ! )

Démarrage :

- serveur

o Démarrer le daemon pptpd

Il tournera en ‘background’, sans autre intervention….

- Client

o Lancer pptp-command start monvpn

Ceci devrait établir le tunnel et la route correspondante vers le réseau distant.

En général, ppp0 est déjà utilisé par la liaison ADSL permanente

Chaque nouveau tunnel portera les identifiants ppp1, ppp2,…. Pppn

Vous pouvez vérifier :

- que le tunnel est actif : ifconfig

- Que la route a bien été créée : netstat –r –n

Notes : le serveur est protégé de connexions sauvages par le fait qu’il précise quelles adresses IP clientes sont autorisées

Le firewall doit aussi être configuré pour ne laisser entrer que les appels GRE de ce client précis

Le protocole d’authentification CHAP n’a pas fonctionné, et le lien s’établit donc en protocole PAP. Ne me demandez pas l’intérêt de l’un sur l’autre, je ne sais pas !

Post-lancement :

Ne pas oublier, sur le serveur ( qui accepte les demandes VPN entrantes ) d’établir aussi une route vers le réseau distant ( voir ‘Touche finale’ pour automatiser ce processus )

Rappelez-vous que le réseau de mon bureau est de type 192.168.0.0 / 255.255.254.0

Et que le VPN utilise l’interface ppp1 , sur ce serveur

route add –net 192.168.0.0 netmask 255.255.254.0 dev ppp1

Firewall iptables :

Pour que tous les accès fonctionnent bien dans les deux sens ( Netbios, telnet, FTP, VNC, etc.. ) j’ai été amené à ouvrir, sur les deux firewalls, tous les flux , de tous les protocoles :

- destinés au réseau distant

- venant du réseau distant

tant sur l’interface externe, que sur le réseau local, et l’interface loopback

Faute de quoi, le tunnel était inexploitable

Il y a probablement une explication plus précise à obtenir, mais le fait d’utiliser l’outil FwBuilder pour configurer iptables dissimule des fonctions et des détails.

Je pense que quoi qu’il en soit, le niveau de sécurité reste très convenable, si l’on considère que les machines Linux aux deux bouts sont quand même mieux ‘blindées’ qu’un Windows !

Touche finale :

Compte-tenu que de temps en temps, mon serveur ( domicile ) change d’adresse IP, cela a pour conséquence de rompre le VPN.

Ce pourquoi j’ai implémenté différents shell scripts côté serveur ( domicile ) et client ( bureau )

Sur le serveur :

Lorsqu’une interface ( telle que ppp1 ) est activée par le processus pptpd, le script /etc/ppp/ip-up vérifie s’il existe un script /etc/ppp/ip-up.local executable.

Si oui, il l’active.

Il suffit de créer ce script, le rendre executable ( chmod 755 ) , et le tour est joué !

Exemple de script implémenté sur le serveur ( le paramètre $1 définit l’interface, et je considère que si c’est ppp1, il s’agit du VPN avec le bureau )

# !/bin/bash

# file /etc/ppp/ip-up.local

# Script to add route to VPN client, when interface goes up

locdate=`date`

echo "-----------------------------" >>/tmp/monvpn

echo "/etc/ppp/ip-up.local started at : $locdate" >>/tmp/monvpn

echo "variables : <$@>" >>/tmp/vpnrldt

case $1 in

"ppp1" )

# cela semble une reconnexion du bureau

/sbin/route add -net 192.168.0.0 netmask 255.255.254.0 dev ppp1 2>&1 >>/tmp/monvpn

sleep 1

;;

* )

# autres VPN

echo " $1 is connecting : Nothing to do" >>/tmp/monvpn

;;

esac

ifconfig >>/tmp/monvpn

netstat -r -n >>/tmp/monvpn

echo "-----------------------------" >>/tmp/monvpn

exit 0

Lorsque le bureau se connecte, cela ajoute la route vers celui-ci !

Sur le client :

Lorsqu’une interface tombe ( telle que ppp1 ), le script /etc/ppp/ip-down vérifie s’il existe un script /etc/ppp/ip-down.local executable.

Si oui, il l’active.

Il suffit de créer ce script, le rendre executable ( chmod 755 ) , et le tour est joué !

Dans ce script implémenté sur client, le paramètre $1 définit l’interface, et je considère que si c’est ppp1, il s’agit du VPN avec le bureau qui vient de tomber.

Il me suffit alors de patienter 1 seconde, pour être sûr que l’interface est bien stabilisée, puis lancer par nohup et en background un script qui réactive le VPN ‘monvpn’ : Ceci permet de laisser se terminer le ip-down, stabiliser le système, et au final, après 6 secondes, le VPN se réactive automatiquement.

File /etc/ppp/ip-down.local

#!/bin/bash

locdate=`date`

echo "-----------------------------" >>/tmp/monvpn

echo "/etc/ppp/ip-down.local started at : $locdate" >>/tmp/monvpn

echo "variables : <$@>" >>/tmp/monvpn

case $1 in

"ppp1" )

# cela semble une deconnexion du VPN domicile

sleep 1

nohup /my_scripts/start_monvpn &

;;

* )

# autres VPN

echo "Disconnecting $1 : Nothing to do" >>/tmp/monvpn

;;

esac

echo "End of script /etc/ppp/ip-down.local" >>/tmp/monvpn

echo "------------------------------------" >>/tmp/monvpn

exit 0

# Script de réactivation /my_scripts/start_monvpn:

Sleep 5

pptp-command start monvpn 2>&1 >>/tmp/monvpn

exit 0

Côté client, cela ajoute implicitement la route si la connexion a correctement été définie via pptp-command.

Le serveur, lui, comme décrit ci-avant, va ajouter la route par déclenchement de ip-up !

A l’heure actuelle, ces mécanismes me satisfont pleinement.

Ces scripts ( délivrés tels quels, pour info ) vous seront envoyés sur simple demande à :

domi@dambrain.fr

Bonne chance, et vive Linux et sa communauté !