La configuration de Xl2tp se fait dans le fichier /etc/xl2tpd.conf.

Serveur :

[global]

# port d’écoute
port = 1701

# Adresse IP de l’interface d’écoute
listen-addr = 82.241.148.190

[lns default]
# Plage d’adresses libres attribuées aux clients
ip range = 192.168.0.64-192.168.0.70

# IP de l’interface virtuelle
local ip = 192.168.0.63

# Règles d’authentification
require chap = yes
refuse pap = yes
require authentication = yes
ppp debug = yes

# Fichier de configuration de PPP
pppoptfile = /etc/ppp/options.l2tpd
length bit = yes

Configuration de /etc/ppp/options.l2tpd :

ipcp-accept-local
ipcp-accept-remote
noipdefault
require-chap
connect-delay 5000
noccp
noauth
idle 1800
mtu 1410
mru 1410
nodefaultroute
debug
lock
proxyarp

# Commenter si vous n’utilisez pas de serveur Radius
plugin radius.so
Dans le cas où vous n’utilisez pas de serveur Radius, vous pouvez stocker les identifiants dans le fichier /etc/ppp/chap-secret pour une authentification chap.

toto * “montsupermotdepasse” *

Pour lancer le démon : xl2tpd -c /etc/xl2tpd/xl2tpd.conf -D

Client :

La configuration est sensiblement la même.

[global]
listen-addr = IP de l’interface d’écoute (l’IP publique dans la plupart des cas)

# port utilisé
port = 1701

[lac L2TP]
lns = IP du serveur distant
require chap = yes
refuse pap = yes
require authentication = yes

# l’identifiant de l’utilisateur
name = toto
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd.client
length bit = yes

Configuration de   /etc/ppp/options.l2tpd.client :

ipcp-accept-local
ipcp-accept-remote
noipdefault
noccp
auth # authentification requise
idle 1800
mtu 1410
mru 1410
nodefaultroute
debug
lock
proxyarp
connect-delay 5000

Le login et  Le mot de passe de l’utilisateur sont dans le fichier /etc/ppp/chap-secrets

toto    * “monsupermotdepasse” * 

La configuration est terminée.

Pour lancer le démon : xl2tpd -c /etc/xl2tpd/xl2tpd.conf -D

Pour lancer la connexion : echo “c L2TP” > /var/run/xl2tpd/l2tp-control

Pour se déconnecter : echo “d L2TP” > /var/run/xl2tpd/l2tp-control

Où L2TP est le nom donné dans le fichier xl2tp.conf

Par contre, ce type de VPN n’est pas très adapté pour les accès nomades car des firewalls ou autre dispositifs de filtrage peuvent bloquer ces accès. Contrairement à OpenVPN qui utilise le port 443, L2TP/IPSec nécessite que certains ports spécifiques soient ouverts. C’est pour cette raison que ces VPN sont souvent utilisés pour relier deux sites.

Voyons néanmoins sa configuration avec une authentification Radius, réalisée précédemment.

Nous avons utilisé le logiciel Strongswan, qui est une implémentation de IPSec pour Linux et qui support IKEv2. Ce dernier réduit le nombre d’échanges pour la gestion des clés et utilise notamment le NAT traversal pour passer le nattage.

Après avoir installer le paquet nous allons voir la configuration de IPSec.

Côté serveur :

Il faut copier les certificats créés ici dans le dossier /etc/ipsec.d

Certificat du serveur : RAS.pem dans /etc/ipsec.d/certs/

Certificat de l’autorité : caCertif.pem dans /etc/ipsec.d/cacerts/

Clé privée (avec les droits root) : RAS.key dans /etc/ipsec.d/private/

Modifier votre fichier /etc/ipsec.secrets qui va contenir votre mot de passe de la clé secrète.

: RSA /etc/ipsec.d/private/RAS.key “votremotdepasse”

Passons à la configuration de /etc/ipsec.conf proprement dite :
version 2
config setup

# active le nat traversal
nat_traversal=yes

conn L2TP
authby=secret
pfs=no
rekey=no
keyingtries=3

# defaultroute est la route par défaut. Dans le cas où la passerelle dispose de plusieurs interfaces, il faut remplacer defaultroute par l'interface correspondante.
left=%defaultroute
leftprotoport=17/1701

# Si on autorise la connexion que d'une seule IP.
# right= IP

# Connexion de n'importe quelle adresse IP
right=%any
rightprotoport=17/%any

# adresse du sous réseau
leftsubnet=192.168.0.0/24

# On active la configuration.
auto=add

Côté client :

La procédure est la même que pour le serveur :

Certificat du client : clientCertif.pem dans /etc/ipsec.d/certs/

Certificat de l’autorité : caCertif.pem dans /etc/ipsec.d/cacerts/

Clé privée (avec les droits root) : client.key dans /etc/ipsec.d/private/

Comme pour le serveur :

Modifier votre fichier /etc/ipsec.secrets qui va contenir votre mot de passe de la clé secrète.

: RSA /etc/ipsec.d/private/client.key “votremotdepasse”

Fichier /etc/ipsec.conf :

version 2.0
config setup
nat_traversal=yes

# L’ interface ppp0 est l’interface relié à Internet.
interfaces=”ipsec0=ppp0″

# connection IPSec Pur
conn ipsec
left=IP du client

# nom du certificat du client
leftcert=client.pem

# IP distante du serveur
right=IPDistante

# adresse du sous réseau distant
rightsubnet=192.168.0.0/24

# Champ du certificat
rightid=”C=FR, ST=France, O=M2IRCOMS, OU=Serveur, CN=Serveur”

auto=add

# Connection avec L2TP
conn l2tp
left=IPDistante leftcert=client.pem
leftprotoport=17/1701
right=IPServeur
rightsubnet=192.168.0.0/24
rightid=”C=FR, ST=France, O=M2IRCOMS, OU=Serveur, CN=Serveur”
rightprotoport=17/1701
auto=add

Il faut relancer IPSec sur le serveur et le client. Sur le client, tapez ipsec up l2tp ou ipsec up ipsec pour établir la connection.

Il faut auparavant créer une clé de 2048 pour l’échange Diffie-Hellman (uniquement sur le serveur).

openssl dhparam -out dh 2048.pem 2048

On peut utiliser un mécanisme de sécurité supplémentaire nommé tls-auth. Cela protège contre ls attaques DoS, le flooding du port UDP, du scan de ports pour découvrir le port d’écoute sur le serveur et des vulnérabilités du buffer overflow.

Pour cela, il suffit de créer une clé sur le serveur et le client et de la mettre dans /etc/openvpn/:

openvpn –genkey –secret ta.key

Ensuit, il faut ajouter dans le fichier de configuration :

tls-auth ta.key 0 pour le serveur;

tls-auth ta.key 1 pour le client.

Voici le fichier de configuration détaillé pour le serveur :

# port et protocole d’openvpn
port 443
proto udp

# tunnel de niveau 2
dev tap

# clés et certificats du serveur et de l’autorité
ca caCertif.pem
cert RAS.pem
key RAS.key

# fonction PFS avec Diffie Hellman
dh dh2048.pem

# authentification tls
tls-auth ta.key 0

# plage d’adresses pour les clients
server 10.8.0.0 255.255.255.0

# routage
push “route 192.168.0.0 255.255.255.0″

# défini la route par défaut
push “redirect-gateway def1

ifconfig-pool-persist ipp.txt

# on utilise le même certificat pour tous les clients
duplicate-cn

keepalive 10 120

# compression
comp-lzo

user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3

# authentification radius
plugin /usr/lib/openvpn/openvpn-auth-pam.so openvpn
username-as-common-name

Pour le client, la configuration est sensiblement la même :

# fonctionnement en mode client
client

# interface de niveau 2
dev tap
proto udp

# adresse IP du serveur
remote IPDistante
resolv-retry infinite
nobind
persist-key
persist-tun

# clés et certificats
ca caCertif.pem
cert clientCertif.pem
key client.key

# authentification tls
tls-auth ta.key 1

comp-lzo
verb 1

# authentification Radius
auth-user-pass

Il faut penser à relancer OpenVPN sur le serveur et client et lors de la connexion du client, un login et mot de passe sera demandé ainsi que le mot de passe pour la clé secrète. Avec cette configuration, l’utilisateur itinérant peut accéder à la machine 192.168.0.1 de façon sécurisée.

Vérifier la configuration :

openvpn –config fichier_de_configuration

Connexion d’un client :

openvpn /etc/openvpn/client.conf

Il faut vérifier que le paquet freeradius est installé sur le serveur.

Il faut ajouter les utilisateurs dans le fichier “/etc/freeradius/users” :

“utilisateur1″ Auth-Type := EAP, User-Password ==”topsecret”
“utilisateur2″ Auth-Type := Local, User-Password ==”monmotdepasse”
“utilisateur3″ Auth-Type := CHAP, User-Password ==”monmotdepasse”

L’utilisateur1 s’authentifie en utilisant la méthode EAP et l’utilisateur2 est utilisé pour se connecter localement durant les tests.

Le second fichier a modifié est “/etc/freeradius/radiusd.conf“. Il faut veiller qu’il contient les paramètres suivants :

pam {
pam_auth = radius # on appelle le fichier /etc/pam.d/radius
}

authorize { # on définit l’autorisation chap, mschap et eap
preprocess
chap
mschap
suffix
eap
files # on lit le fichier users
}

authenticate {
eap # authentification eap
}

Par manque de moyens techniques, nos serveurs radius et VPN sont sur la même machine. Dans la plupart des cas, ils sont situés sur des serveurs distincts. Il convient donc de spécifier l’adresse IP du client (serveur VPN) dans le fichier clients.conf de Freeradius.

client 127.0.0.1 { # adresse IP du serveur
secret = testing123
shortname = localhost
nastype = other
}

Afin que les utilisateurs puissent authentifier le serveur en eap-tls, il faut configurer le fichier eap.conf :

eap {

    tls {

            private_key_password = monmotdepasse
private_key_file = ${raddbdir}/certs/radius.key 

            CA_file = ${raddbdir}/certs/certificatdelautorite.pem 

            dh_file = /dev/null
random_file = /dev/urandom

        }}

Il ne faut pas oublier de redémarrer le service freeradius pour prendre en compte les changements.

Voici l’architecture de notre réseau :

Pour cela, dans un premier temps, nous devons créer ces certificats.

Nous avons utilisé la distribution OpenSuse mais toute autre distribution convient parfaitement.

Avant de continuer, vérifier que Openssl est installé. Dans le cas contraire, allez faire un tour dans Yast !

Nous allons commencer par créer une autorité de certification autosignée qui signera tous les certificats.

Placez-vous dans un répertoire de travail quelconque pour exécuter ces commandes. Par exemple, créez un dossier ssl dans votre répertoire personnel.

Cette commande permet de créer une clé privée de taille 2048 (caKey.key) et un certificat autosigné (caCertif.pem) valable 10 ans.

# openssl req -x509 -days 3650 -newkey rsa:2048 -keyout caKey.key -out caCertif.pem

Pour afficher le certificat :

# openssl x509 -in caCertif.pem -text -noout

Une fois notre autorité créée, passons au certificat pour la passerelle VPN.

On créé une clé privée et un certificat valable 1 an :

# openssl req -newkey rsa:2048 -keyout RAS.key -out RASReq.pem

On signe le certificat par l’autorité :

# openssl ca -in RASReq.pem -days 365 -out RAS.pem -notext -cert caCertif.pem -keyfile caKey.key

Si on veut afficher le certificat :

# openssl x509 -in RAS.pem -text -noout

La procédure est identique pour un client.

# openssl req -newkey rsa:2048 -keyout client.key -out clientReq.pem
# openssl ca -in clientReq.pem -days 365 -out clientCertif.pem -notext -cert caCertif.pem -keyfile caKey.key

Certificat et clé pour que le serveur Radius puisse être identifié par les clients :

# openssl req -newkey rsa:2048 -keyout radius.key -out radiusReq.pem
# openssl ca -in radiusReq.pem -days 365 -out radiusCertif.pem -notext -cert caCertif.pem -keyfile caKey.key

La mise en place et configuration du VPN SSL se fera dans un prochain billet.