Je vais vous parler ici de ce avec quoi on peut monter du VPN en Open Source, et j'aborderai dans d'autres articles les choses amusantes qu'on peut faire avec en termes de routage une fois qu'on se sera débarrassé ici des configurations de base.

J'ai essayé de conserver une cohérence dans les morceaux de configurations qui sont reproduits ci-dessous, mais ce sont des copies de configurations récoltées sur plusieurs jours, plusieurs tentatives et plusieurs machines, et tranformées pour retirer les adresses publiques… donc il est possible de des erreurs ce soient glissées : attention !

Les « Virtual Private Networks » (réseaux privés virtuels) sont un petit peu en vogue ces temps-ci dans le monde des particuliers, pour les mêmes raisons qu'ils le sont depuis plus longtemps dans les milieux professionnels : on s'en sert très souvent pour chiffrer un trafic que l'on veut transporter pour qu'il ne puisse pas être intercepté.

Mais bien souvent aussi c'est parfaitement superflu, la plupart des échanges qui sont chiffrés en utilisant des VPN n'ont aucun caractère de confidentialité supérieur par rapport à ce qui circule tous les jours sur internet. Et à l'inverse, transporter des données chiffrées, ça se fait très bien avec SSL (par exemple en utilisant HTTPS au lieu de HTTP) ou IPSec et ça n'est pas nécessaire de monter un VPN.

Donc les VPN ne servent pas à ça, en réalité : le chiffrement des données n'est qu'une de leurs fonctions. La véritable finalité d'un VPN est de créer un circuit virtuel par-dessus un ou plusieurs autres, de manière à ce les données puissent être acheminées d'un point source à un point destination via un réseau simple, en faisant abstraction du réseau beaucoup plus compliqué qui est en dessous. Bref, ça fait des tunnels, avec une ou plusieurs entrées/sorties.

Un VPN est donc un protocole qui crée un réseau par-dessus le réseau existant, lequel peut être géré par des protocoles divers de niveau 2, 3, 4, voire pire encore. Et naturellement les données qui circulent sur ce VPN se trouvent encapsulées par cette sur-couche de transport.

L'exemple évident, celui qu'une majorité d'entre nous utilise tous les jours, c'est celui qui permet de véhiculer le trafic d'une liaison dite « ADSL » entre le modem et le FAI, en masquant tout la complexité des protocoles et du réseau qui se trouvent entre les deux, et qui est ainsi masquée. Ce VPN est fait avec le protocole L2TP (layer 2 transport protocol). Son effet le plus manifeste, c'est que si vous faites un traceroute depuis chez vous après la première ligne (si vous avez un modem/routeur), vous allez avoir directement l'IP de passerelle de votre FAI, qui se trouve très certainement à des (dizaines ou centaines de) kilomêtres de là.

$ mtr --report -n www.free.fr
HOST: eugenie                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 10.0.0.253                    0.0%    10    5.6   2.3   0.9   5.6   1.5
  2. 82.229.150.254                0.0%    10   29.6  27.3  25.3  29.6   1.4
  3. 78.254.10.254                 0.0%    10   31.0  29.6  25.3  40.0   4.5
  4. 78.254.251.50                 0.0%    10   26.2  25.8  23.9  27.1   1.1
  5. 78.254.251.57                40.0%    10   25.9  27.4  25.9  30.1   1.6
  6. 212.27.50.13                  0.0%    10   26.3  27.5  26.3  30.1   1.2
  7. 212.27.50.6                   0.0%    10   32.8  28.3  25.7  33.2   2.7
  8. 212.27.48.10                  0.0%    10   26.7  27.4  25.7  29.4   1.2

Ainsi, aucun n'intermédiare n'apparait entre la ligne 1 et la ligne 2, et pourtant, je vous garantis, il y a de l'espace et du monde, comme en témoignent les 20 millisecondes de plus que met un paquet pour faire l'aller/retour.

Une autre application très intéressante, et pas encore très commune, c'est de libérer votre internet.

Comme vous le savez bien souvent un fournisseur d'accès ne vous donne qu'une adresse IP, et vous êtes obligé de NATer derrière un modem/routeur, ce qui fait qu'à part cette maigrichonne machine, personne dans votre foyer n'a un accès direct, plein et entier à internet. Pire, certains fournisseurs bloquent sans vergogne des ports comme le 25 (SMTP) ce qui vous prive d'une partie d'internet.

Pour libérer votre accès de ces fléaux, vous pouvez utiliser des VPNs pour apporter de la vraie adresse IP libre et publique à la maison, héberger votre serveur, participer à internet pour de vrai sans vous laisser enfermer dans un rôle de simple consommateur.

Attention : avoir une machine directement en prise avec Internet, ça veut dire assumer qu'elle sera attaquée ; elle le sera n'en doutez pas, évitez de le faire si vous ne la maitrisez pas parfaitement.

Pour ça il vous faut un hébergeur sympathique (et je vous le conseille associatif, comme Gixe) qui soit hébergera votre serveur VPN, soit fera cet office pour vous. Et pour avoir davantage d'adresses IP vous les demandez soit à ce gentil hébergeur qui aussi saura les router jusqu'à vous, soit si vous avez besoin de beaucoup d'adresses à un sympathique LIR comme Opdop.

Nous avons la chance de disposer pour commencer à expérimenter, d'un logiciel fort riche et Open Source, qui permet de monter des tunnels entre deux machines assez facilement, il s'agit de OpenVPN. L'une de ses forces réside dans sa capacité à établir un réseau routé (donc avec des adresses IP pour le routage) ou un réseau commuté, c'est à dire à propager un réseau ethernet.

OpenVPN est facilement disponible sur votre distribution Linux préférée, et même FreeBSD, et même Windows.

Sur une debian, distribution à partir de laquelle sont faites ces expérimentations :

sudo aptitude install openvpn

Il suffit de l'invoquer sans lui passer d'arguments pour s'apercevoir de la richesse de ses options, qui vont bien nous servir.

OpenVPN installe sa configuration dans /etc/openvpn, glisse un script de démarrage dans /etc/init.d/openvpn et /etc/default/openvpn qui vous permet de lui préciser quels tunnels démarrer et quand.

Passons très vite sur les étapes de configuration générale, qui sont si bien documentées ailleurs. Je vous recommande d'utiliser les excellents scripts easy-rsa pour vous manoeuvrer la petite PKI qui va générer des clés et des certificats pour votre serveur et son (ou ses) clients.

sudo cp -ar /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/easy-rsa
sudo chmod -R $USER /etc/openvpn/easy-rsa

Ensuite rendez-vous dans ce répertoire, aménagez les valeurs par défaut du fichier vars, sourcez-les dans le SHELL (avec source vars ou . vars). Et ensuite

cd /etc/openvpn/easy-rsa
. vars
./clean-all
./build-dh
./pkitool --initca
./pkitool --server server

On obtient par défaut des clés de 1024 bits et des certificats valables 10 ans (y compris celui de l'autorité de certification).

cd /etc/openvpn/easy-rsa/keys
sudo cp ca.crt server.crt server.key dh1024.pem ../../

On ajoute quelques options dans /etc/default/openvpn :

OPTARGS="--mode server --tls-server --topology subnet"

Et on crée une configuration minimale pour le serveur :

server.conf

local 192.168.0.1
proto udp
port 1194
dev tun

server 172.16.0.0 255.255.255.240

ca ca.crt
cert server.crt
key server.key
dh dh1024.pem

keepalive 10 120
persist-key
persist-tun
client-config-dir ccd

verb 3
mute 20
status openvpn-status.log
; log-append /var/log/openvpn.log

Il faut éventuellement créer le répertoire ccd s'il est manquant.

La dernière ligne est commentée (avec un point-virgule en début de ligne) pour avoir les messages du démon quand il sera lancé à la main pour tester son fonctionnement.

On va le tester manuellement avec la commande sudo openvpn server.conf, et si tout se passe bien, l'arrêter avec CTRL-C, décommenter la dernière ligne, et le relancer avec service openvpn start ou /etc/init.d/openvpn start. On pourra alors dédier un autre terminal à nous donner les dernières nouvelles avec :

sudo tail -f /var/log/openvpn.log

On peut forcer des adresses statiquement pour les clients, en allant modifier les valeurs qui sont cachées dans le répertoire ccd.

Notes :

• ici leclient est la chaine de caractère qui aura été utilisée dans le certificat généré pour le client…
• le serveur va s'octroyer tout seul la première IP du subnet spécifié par la directive server (1, donc la seconde en fait)

On utilise encore easy-rsa pour générer une clé et un certificat au client, et puis on met tout ça dans une petite archive qu'on transfèrera sur le client.

cd /etc/openvpn/easy-rsa
./build-key leclient
cd keys
tar cvfz client.tgz leclient.* ca.crt

Sur le client à présent,

sudo aptitude install openvpn
cd /etc/openvpn
# récupérez client.tgz sur le serveur (avec scp ?)
sudo tar xvfz client.tgz

Voici une configuration minimale pour le client

client.conf

client
dev tun
proto udp
remote 192.168.0.1 1194

topology subnet

ca ca.crt
cert leclient.crt
key leclient.key

nobind
persist-key
persist-tun
comp-lzo
verb 3
;log-append /var/log/openvpn.log

Même procédure que sur le serveur pour tester.

Ces configurations sont assez simplistes (quoique, on aurait même pu faire sans certificats côté client) parce que le but est juste de monter un tunnel.

En particulier :

• il n'y a pas d'algorithme de chiffrement (cipher)
• il n'y a pas des configuration pour manipuler les routes (ajouter ou remplacer une route par défaut vers internet, par exemple)
• on ne fait pas appel à des mécanismes externes d'authentification, ni pour récupérer l'IP du client dans une basen ni pour lui indiquer les DNS…
• on utilise ici udp pour transporter les paquets parce que à priori ce n'est pas une bonne idée d'encapsuler TCP dans TCP (deux fois le contrôle, c'est trop).

Il m'est arrivé d'avoir des soucis pour monter l'interface tun0 (ou tap0 sur d'autres configurations), ce qui traduisait dans le log d'openvpn par un message signalant que /dev/net/tun n'existait pas.

J'ai résolu ce problème en rajoutant ce petit bout de script dans /etc/default/openvpn pour m'assurer que le device existait bien lorsque le script de démarrage était appelé :

if [ ! -c /dev/net/tun ]; then
  mkdir -p /dev/net
  mknod /dev/net/tun c 10 200
  chmod 600 /dev/net/tun
fi

Régalez-vous de la manpage de OpenVPN pour en apprécier les très nombreuses options. Il nous donne beaucoup de facilités pour monter des configurations locales, ajouter des routes sur le serveur ou en pousser vers la machine cliente.

On peut notamment aussi déclencher des scripts avec client-connect et client-disconnect ce qui nous sera utile pour l'interfacer avec d'autres composants.

Plus bas on a une configuration simple de freeradius, alors ce serait bien de pouvoir s'en servir ici.

Vous pouvez aussi sauter cette section pour y revenir plus tard (quand freeradius aura été configuré) et passer directement à la section sur L2TP.

Il existe un plugin pour faire s'interfacer OpenVPN avec un serveur radius. Hélas sous Debian le plugin n'est disponible qu'en testing ou unstable. Solution : récupérer le source, lire le README dedans qui vous explique grosso modo de 1) lancer make, 2) copier radiusplugin.so dans /usr/lib/openvpn, 3) compléter vos configurations :

Retirez les deux lignes ifconfig-pool et ifconfig-pool-persist, et ajouter dans le fichier serveur.conf :

username-as-common-name
plugin /usr/lib/openvpn/radiusplugin.so /etc/openvpn/radiusplugin.cnf

Ensuite, éditer la configuration du plugin dont voici un court exemple pour notre cas :

radiusplugin.cnf

NAS-Identifier=lns
Service-Type=5
Framed-Protocol=1
NAS-Port-Type=5
NAS-IP-Address=127.0.0.1
subnet=255.255.255.240

OpenVPNConfig=/etc/openvpn/serveur.conf

server
{
        acctport=1813
        authport=1812
        name=127.0.0.1
        retry=1
        wait=1
        sharedsecret=testing123
}

A rajouter dans client.conf :

auth-user-pass /etc/openvpn/credentials

Ce fichier contient un identifiant et un mot de passe sur les deux premières lignes.

credentials

monuser
sonpass

Et relancer openvpn des deux côtés.

Ca marche ? Arrêtez tout, on va passer à L2TP.

« Layer 2 Tunneling Protocol » est un standard décrit par la RFC 2661. Il est fait pour transporter des sessions PPP dans des tunnels, qui sont propagés sur une couche routée (dans le cas d'IP, c'est en UDP et a priori sur le port 1701). Le client, souvent appelé LAC (L2tp Access Concentrator) et le serveur appelé LNS (L2tp Network Server) sont moins «grand public» qu'OpenVPN, mais aussi mieux dotés pour s'interfacer avec les outils classiques des fournisseurs de services internet.

Côté serveur l2tpns est disponible, mais il se sait faire «que» LNS. On a aussi openl2tp, qui, lui, sait jouer le rôle de LAC aussi bien que celui de LNS (avec une possibilité de diversifier ses configurations qui peut être très utile). Je vous aurais volontier parlé aussi de xl2tpd (fork de l2tpd, qui a été abandonné) si seulement j'avais trouvé un peu de documentation quelque part. Tous ces outils sont Open Source.

Beaucoup de petits routeurs Cisco intègrent la capacité de se comporter comme des LNS, qui doivent en 2012 se trouver d'occasion pour quelques euros, hélas ils sont parfois aussi très limités en capacité, plus vendus, et plus supportés.

Enfin il faut noter qu'il existe de nombreux clients sur toutes sortes de « terminaux » : en standard dans la configuration VPN sous Windows, ou bien sous Android, sur iPhone… ce qui peut sembler surprenant (trouve-t-on des services de LNS ouverts au plublic ?)

Avant de vous lancer dans les configurations de tunnel L2TP, veillez à avoir éteint un tunnel que vous auriez préalablement monté avec OpenVPN.

On le trouve dans les paquets debian.

aptitude install l2tpns

Une configuration de base est très simple, et il y a une manpage pour le fichier startup-config

startup-config

set hostname "l2tpns"
set log_file syslog:daemon
set pid_file "/var/run/l2tpns.pid"
set accounting_dir "/var/run/l2tpns/acct"

set l2tp_secret <secret>

set bind_address <ip>

set cluster_interface lo

#set debug 2
set debug 2

L'adresse de « bind » servira à accrocher le service pour attendre les connexions clientes. Mais les adresses des clients pourront être prises dans des subnets auxquels cette adresse n'appartient pas. l2tpns pourra en attribuer dynamiquement depuis les pools listés dans ip_pool, ou bien interroger un radius. C'est peer_address qui permettra de leur spécifier une adresse de gateway.

Ici non plus, les options d'interfaçages avec radius, ou pour spécifier des informations de routage ou de services (comme le DNS) ne sont pas indiquées, mais existent.

A noter des options très « pro » comme la capacité de monter le service en cluster, d'utiliser le protocole BGP pour router dynamiquement avec son environnement, ou de prendre des commandes en live par telnet (et son fameux show banana).

Pour en savoir plus sur l2tpns voici un lien vers sa documentation.

On trouve des paquets Debian pour openl2tp et une documentation maintenue (ce qui est rare avec les outils qui s'occupent de L2TP) en allant soir sur le site http://www.openl2tp.org, profitons-en.

cd /tmp
wget ftp://ftp.openl2tp.org/releases/openl2tp-1.8/debian-squeeze/openl2tp_1.8-1_i386.deb
sudo aptitude install ppp portmap
sudo dpkg -i openl2tp_1.8-1_i386.deb

openl2tp fonctionne en client et en serveur, ici on va inhiber le serveur, et configurer statiquement le nécessaire pour une connexion vers notre LNS. Il faut mettre ça dans /etc/openl2tp.conf et spécifier ce nom dans la variable OPENL2TPD_CONFIG_FILE de /etc/default/openl2tp.

openl2tp.conf

system modify deny_remote_tunnel_creates=yes

ppp profile modify profile_name=default \
        auth_eap=no auth_mschapv1=no auth_mschapv2=no

tunnel create tunnel_name=montunnel dest_ipaddr=192.168.0.5 \
        persist=yes

session create tunnel_name=montunnel \
        session_name=masession \
        user_name=monuser \
        user_password=sonpass

L'IP du LNS indiquée ci-dessus entre crochets est l'adresse IP passée sous la direction bind_address, votre machine cliente doit pouvoir l'atteindre.

Avant de lancer le client, vérifier deux choses :

• le service portmap doit être actif car openl2tp s'enregistre comme RPC et l2tpconfig en a besoin pour le joindre ;
• sous Linux, le module pppol2tpdoit être présent dans le noyau pour que ppp puisse monter sa session

Ensuite relancer le service :

sudo service openl2tp restart

L'établissement du tunnel se fait ici sans même avoir spécifié le secret partagé (mais on pourrait durcir les configurations à cet égard). La session qui fait référence au tunnel, monte aussi.

C'est alors que côté serveur on voit l2tpns s'apercevoir qu'il n'a pas de radius configuré pour identifier l'utilisateur et lui attribuer une IP. Il essaie en vain, et finit par faire tomber la session. Evidement openl2tp réessaiera de la faire remonter, indéfiniment.

Si openl2tp vous a séduit vous aurez peut-être envie de le configurer comme serveur tout à l'heure.

Cette authentification on aurait pu le faire simplement avec openl2tp, mais l2tpns lui, a besoin d'un radius…

freeradius est un de ces outils open source qui sont parvenus à se faire une place dans la cour des grands, au point d'être utilisés par des professionnels (et pas des moindres) du secteur des télécoms.

Il peut effrayer par le nombre de ses fichiers de configuration, et le volume de documentation à lire. Mais on peut aussi s'en servir avec un minimum de changements, tant qu'on veut rester une configuration de base.

Debian nous fournit un package qui s'installe comme un charme, et nous met à disposition une configuration fonctionnelle.

sudo aptitude install freeradius
cd /etc/freeradius

Nous allons nous intéresser au fichier « clients.conf » qui sert à autoriser des clients à interroger freeradius. A pririo vous avez déjà une section qui contient les informations suivantes :

client localhost {
  ipaddr = 127.0.0.1
  secret = testing123
  require_message_authenticator = no
  nastype = other
}

Ceci permettra à l2tpns d'interroger le radius, mais pour cela nous rajoutons ces trois lignes dans /etc/l2tpns/startup-config :

set primary_radius 127.0.0.1
set primary_radius_port 1812
set radius_secret "testing123"

Et on redémarre l2tpns.

Ensuite il faut que freeradius sache associer cette adresse à un groupe, ce qui se fait dans le fichier huntgroups en rajoutant la ligne suivante :

lns     NAS-IP-Address == 127.0.0.1

Enfin nous allons rajouter des informations d'indentification pour une session dans le fichier users ; mettons ça au début du fichier pour éviter toutes les règles par défaut qui se trouvent ensuite :

monuser    Cleartext-Password := "sonpass"
        Service-Type = Framed-User,
        Framed-Protocol = PPP,
        Framed-IP-Address = 172.16.0.2
        Framed-IP-Netmask = 255.255.255.255

Un outil très pratique pour tester rapidement notre configuration est radtest, sur-couche de raclient. radtest nous permet de tester en une seule ligne la réponse de freeradius. Pour l'utiliser au mieux, on arrête le démon et on le relance en mode débug (-X) et en foreground (-f) :

sudo /etc/init.d/freeradius stop
sudo /usr/sbin/freeradius -f -X

freeradius nous raconte toute sa vie, et éventuellement rouspète sur les erreurs rencontrées. Si tout se passe bien, on peut l'interroger avec :

# radtest <user> <pass> <server> <nas port> <secret>
radtest monuser sonpass localhost testing123

On obtient :

Sending Access-Request of id 115 to 127.0.0.1 port 1812
        User-Name = "monuser"
        User-Password = "sonpass"
        NAS-IP-Address = 192.168.0.3
        NAS-Port = 1
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=115, length=44
        Service-Type = Framed-User
        Framed-Protocol = PPP
        Framed-IP-Address = 172.16.0.2
        Framed-IP-Netmask = 255.255.255.255

La première partie est la requête qui a été envoyée (il a récupéré l'adresse du NAS tout seul car elle n'est pas dans la configuration), la seconde est la réponse. Très facilement quand on démarre et qu'on édite le fichiers users on fait des erreurs entre les ==, les := et les = (et bien d'autres), mais aussi sur les endroits où placer des virgules. Recopier une configuration donnée en exemple et la changer à minima est une bonne manière de se simplifier la vie. Sinon, la documentation explique tout ça très bien (man 5 users).

A présent ça marche ? Arrêtons le démon avec CTRL-C et relançons-le normalement.

On peut relancer l2tpns pour qu'il interroge freeradius, et on a de bonnes chances que soudain sa fonctionne.

On devrait voir apparaitre, dans le fichier journal de l2tpns :

2012-06-20 15:51:36 00/01 Route add 172.16.0.2/255.255.255.255
2012-06-20 15:51:36 02/01 Login by monuser at 172.16.0.2 from 192.168.0.3 (machine-client)

et quand on interroge l2tpns, voir le tunnel monté et la session aussi :

telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

vpn> enable

vpn# show tunnel
 TID             Hostname                   IP  State Sessions
   2              eugenie       A.B.C.D   Open      1

vpn# show session 
  SID  TID Username                         IP              I T G 6     opened downloaded   uploaded idle LAC             CLI
    1    2 monuser                             172.16.0.2   N N N N       2491          0          0   34 192.168.0.3  *

vpn# exiConnection closed by foreign host.
bash# 

Appréciez comme tout ceci est peu sécurisé…

Côté client avec openl2tp ont peut aussi vérifier l'état du tunnel et de la session :

bash$ l2tpconfig

l2tp> system show status
L2TP service status:-
  tunnels: 1, sessions: 1

l2tp> tunnel list
   TunId             Peer            Local  PeerTId ConfigId            State
    6951    192.168.0.5         192.168.0.3        1        1      ESTABLISHED

l2tp> session show tunnel_name=montunnel session_name=masession
Session 28614 on tunnel 38258:-
  type: LAC Incoming Call, state: ESTABLISHED
  created at:  Jun 20 17:24:45 2012
  administrative name: masession
  created by admin: YES, peer session id: 1
  ppp user name: monuser
  ppp user password: sonpass
  ppp interface name: ppp0
  data sequencing required: OFF
  use data sequence numbers: OFF
  trace flags: NONE
  framing types: SYNC ASYNC
  bearer types: DIGITAL ANALOG
  call serial number: 1
  connect speed: 1000000
  use ppp proxy: NO

  Peer configuration data:-
    data sequencing required: OFF
    framing types:
    bearer types:
    call serial number: 1
  data rx packets: 0, rx bytes: 0, rx errors: 0
  data tx packets: 0, tx bytes: 0, tx errors: 0

J'ai découvert openl2tp en écrivant cet article, et je vous avoue que ça m'a donné envie de m'en servir côté serveur aussi, pour voir. Essayons.

Quand openl2tp opère en tant que serveur, il peut tirer les IPs pour ses clients de trois sources :

• une configuration statique
• un pool d'adresses, dans lequel il va piocher
• un radius

La première configuration se fait ainsi dans /etc/openl2tp.conf:

ppp profile create profile_name=telprofilppp \
	local_ipaddr=172.16.0.6 \
	remote_ipaddr=172.16.0.100

peer profile create profile_name=monlac \
	peer_ipaddr=192.168.0.3 \
	ppp_profile_name=telprofilppp

Un peu fasitidieux et problématique quand on ne connait pas l'adresse du NAS (le LAC, donc le client L2TP).

Notez qu'on utilise ici une commande create pour créer de nouveaux profils, on aurait aussi pu utiliser les profils par défaut et les modifier.

Ce qui nous amène à la seconde piste : utiliser un pool d'adresses, mais on a alors peu de contrôle sur quelle IP va à qui, je vous le laisse en exercice : il faut installer un démon ippool supplénentaire depuis le site de openl2tp, rajouter une configuration pour celui-ci :

ippool.conf

pool create pool_name=monpool first_addr=172.16.0.100 num_addrs=150

Et dans la configuration du serveur openl2tpd.conf:

ppp profile modify profile_name=default \
	ip_pool_name=monpool

Nous y voilà. Modifions le profil qui avait été créé plus haut.

ppp profile modify profile_name=telprofilppp \
	local_ipaddr=172.16.0.6 \
	use_radius=yes \
	radius_hint=/etc/radiusclient/radiusclient.conf

Malheureusement on ne peut pas configurer l'adresse de passerelle pour la session PPP dans le radius, il faut donc la spécifier ici (conserver local_ipaddr). Pour changer utiliser une autre passerelle il faudra donc écrire un autre profil ppp.

A présent au tunnel et à la session de se monter, ça ne durera pas si PPP ne parvient pas à établir lui aussi une session. Et pour que cela fonctionne, il faut s'assurer

• que le module pppol2tp est bien chargé dans le noyau de côté aussi ;

sudo modprobe pppol2tp

• que ppp pourra authentifier le client.

Pour cela, on peut utiliser les mécanismes classique de ppp (voir dans /etc/ppp/), pour faire simple j'ai utilisé un compte Unix pour associer l'identifiant (monuser) à un mot de passe (sonpass), et rajouté dans pap-secrets une ligne :

monuser * "" *

Si vous faites ça depuis chez vous (si vous essayer de libérer votre accès) et qu'il y a un NAT entre votre machine LAC et votre LNS à 'extérieur, cela peut poser des soucis à L2TP qui fonctionne en UDP.

Plusieurs solutions.

• transformer votre routeur en simple passerelle (mode bridge), et confier à votre machine la fonction de routeur, ce qui lui permettra de prendre directement l'IP publique de votre connexion (et ainsi de recevoir en direct la session L2TP) ; pour faire ça vous aurez probablement besoin, sous Linux, de PPPOE.

• faire passer votre session L2TP dans un tunnel (IPsec, openvpn) qui vous fera traverser le NAT (oui, c'est le serpent qui se mord la queue)

• forcer openl2tp à utiliser le port UDP 1701 pour répondre au client ce qui se fait en rajoutant ceci dans la configuration du tunnel :

        our_udp_port=1701

Oui, l2tpns faisait cela par défaut.

Après ce panorama qui par la force des choses est resté superficiel (on n'a fait que monter un tunnel avec deux IPs jusqu'ici) il reste beaucoup de choses à faire.

• apprendre à manipuler des routes, pour que la ou les machines de part et d'autres sachent comment se joindre
• sécuriser non pas des tunnels mais des données qui transitent dessus, avec le chiffrement,
• interconnecter les tunnels entre eux,
• sécuriser les tunnels cette fois, avec une redondance (failover)

Pour apprendre à faire il faudra être encore un petit peu patient le temps qu'on écrive sur le sujet, ou bien rejoindre gixe et le faire avec nous, ce qui est la meilleure manière d'apprendre.