OpenBSD FAQ: Virtual Private Networks (VPN) : (v1.18)
— [ FAQ Index ] ~ Traduction française de la FAQ OpenBSD : Réseau Privé Virtuel (VPN) —
OpenBSD est fourni avec iked(8), un serveur IKEv2 moderne, avec séparation des privilèges. Il peut agir à la fois comme répondeur, p. ex. un serveur recevant des requêtes de connexion, ou initiateur, p. ex. un client demandant une connexion à un répondeur. L'utilitaire ikectl(8) est utilisé pour contrôler le serveur, qui a sa configuration dans le fichier iked.conf(8).
L'utilitaire ikectl(8) permet aussi de maintenir un simple certificat d'autorité X.509 (CA) pour les pairs IKEv2.
Un serveur IKEv1 (isakmpd(8)) est aussi disponible, et couplé avec npppd(8), permet de construire un VPN IKEv1/L2TP là où IKEv2 ne peut être déployé.
La prise en charge native de WireGuard est aussi disponible via le périphérique wg(4). Ainsi que l'explique la page de manuel, il peut être configuré de la même manière que pour toutes les autres interfaces réseaux dans OpenBSD.
iked(8) prend en charge les méthodes d'authentification suivantes :
Par défaut, une clé RSA est générée au démarrage dans /etc/iked/local.pub
, avec la clé privée enregistrée dans etc/iked/private/local.key
.
Cela peut être réalisé par l'échange des clés publiques RSA fournies par défaut : la clé /etc/iked/local.pub
du premier système (“server1”) devra être copiée vers /etc/iked/pubkeys/fqdn/server1.domain
du second système (“server2”). Ensuite, la clé /etc/iked/local.pub
du second système devra être copiée vers /etc/iked/pubkeys/fqdn/server2.domain
du premier. Remplacez “serverX.domain” par votre propre FQDN.
À partir de ce point, nous assumerons le fait que le server1 a l'adresse IP publique 192.0.2.1
et un réseau interne 10.0.1.0/24
, et que le server2 a une adresse IP publique 198.51.100.1
et un réseau internet 10.0.2.0/24
.
Pour permettre à l'initiateur d'atteindre le répondeur, le port UDP isakmp
devra être ouvert sur le répondeur. Si un des pairs est derrière un NAT, le port UDP ipsec-nat-t
devra aussi être ouvert sur le répondeur. Si les deux pairs ont des adresses IP publiques alors le protocole ESP devra être permis.
pass in log on $ext_if proto udp from 198.51.100.1 to 192.0.2.1 port {isakmp, ipsec-nat-t} tag IKED pass in log on $ext_if proto esp from 198.51.100.1 to 192.0.2.1 tag IKED
Un exemple de configuration du fichier /etc/iked.conf
pour le server1 (agissant comme répondeur) pourrait ressembler à cela :
ikev2 'server1_rsa' passive esp \ from 10.0.1.0/24 to 10.0.2.0/24 \ local 192.0.2.1 peer 198.51.100.1 \ srcid server1.domain \
Et une simple configuration pour le server2 comme initiateur :
ikev2 'server2_rsa' active esp \ from 10.0.2.0/24 to 10.0.1.0/24 \ peer 192.0.2.1 \ srcid server2.domain
Utiliser iked -dv
peut vous aider à comprendre l'échange. Dans cet exemple, le répondeur est derrière un NAT :
server1# iked -dv ... ikev2_recv: IKE_SA_INIT request from initiator 198.51.100.1:500 to 192.0.2.1:500 policy 'server1_rsa' id 0, 510 bytes ikev2_msg_send: IKE_SA_INIT response from 192.0.2.1:500 to 198.51.100.1:500 msgid 0, 451 bytes ikev2_recv: IKE_AUTH request from initiator 198.51.100.1:4500 to 192.0.2.1:4500 policy 'server1_rsa' id 1, 800 bytes ikev2_msg_send: IKE_AUTH response from 192.0.2.1:4500 to 198.51.100.1:4500 msgid 1, 720 bytes, NAT-T
Du côté de l'initiateur :
server2# iked -dv ... ikev2_msg_send: IKE_SA_INIT request from 0.0.0.0:500 to 192.0.2.1:500 msgid 0, 510 bytes ikev2_recv: IKE_SA_INIT response from responder 192.0.2.1:500 to 198.51.100.1:500 policy 'server2_rsa' id 0, 451 bytes ikev2_msg_send: IKE_AUTH request from 198.51.100.1:4500 to 192.0.2.1:4500 msgid 1, 800 bytes, NAT-T ikev2_recv: IKE_AUTH response from responder 192.0.2.1:4500 to 198.51.100.1:4500 policy 'server2_rsa' id 1, 720 bytes sa_state: VALID -> ESTABLISHED from 192.0.2.1:4500 to 198.51.100.1:4500 policy 'server2_rsa'
Les flux IPSec peuvent être vus avec ipsecctl(8) :
server1# ipsecctl -sa FLOWS: flow esp in from 10.0.2.0/24 to 10.0.1.0/24 peer 198.51.100.1 srcid FQDN/server1.domain dstid FQDN/server2.domain type use flow esp out from 10.0.1.0/24 to 10.0.2.0/24 peer 198.51.100.1 srcid FQDN/server1.domain dstid FQDN/server2.domain type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 192.0.2.1 to 198.51.100.1 spi 0xabb5968a auth hmac-sha2-256 enc aes-256 esp tunnel from 198.51.100.1 to 192.0.2.1 spi 0xb1fc90b8 auth hmac-sha2-256 enc aes-256 server2# ipsecctl -sa FLOWS: flow esp in from 10.0.1.0/24 to 10.0.2.0/24 peer 192.0.2.1 srcid FQDN/server2.domain dstid FQDN/server1.domain type use flow esp out from 10.0.2.0/24 to 10.0.1.0/24 peer 192.0.2.1 srcid FQDN/server2.domain dstid FQDN/server1.domain type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 192.0.2.1 to 198.51.100.1 spi 0xabb5968a auth hmac-sha2-256 enc aes-256 esp tunnel from 198.51.100.1 to 192.0.2.1 spi 0xb1fc90b8 auth hmac-sha2-256 enc aes-256
Avec cela, les deux réseaux internes devraient être capables de s'atteindre l'un l'autre. Le trafic entre eux devrait apparaître après décapsulation de l'interface enc0
, et peut ainsi être filtré. Dans cet exemple, le tag
VPN a été ajouté à la politique :
# pfctl -vvsr|grep VPN @16 pass log on enc0 tagged VPN # tcpdump -nei pflog0 rnr 16 00:03:26.793522 rule 16/(match) pass in on enc0: 10.0.2.24 > 10.0.1.13: icmp: echo request
Quelques mots d'attention :
srcid
, alors iked essayera d'utiliser la clé correspondant à son FQDN par défautlocal
, il doit juste s'assurer qu' iked
écoute sur l'interface correcte. peer
, il doit juste s'assurer que les connexions viennent bien de l'adresse IP de confiance. Si les points terminaux des VPN ont besoin d'atteindre le réseau interne à distance, ou que le réseau interne à besoin d'atteindre le point terminal VPN, les flux additionnels doivent être paramétrés des deux côtés :
La configuration du répondeur pourrait ressembler à celle-ci :
ikev2 'server1_rsa' passive esp \ from 10.0.1.0/24 to 10.0.2.0/24 \ from 10.0.1.0/24 to 198.51.100.1 \ from 192.0.2.1 to 10.0.2.0/24 \ local 192.0.2.1 peer 198.51.100.1 \ srcid server1.domain
Et, celle de l'initiateur pourrait être :
ikev2 'server2_rsa' active esp \ from 10.0.2.0/24 to 10.0.1.0/24 \ from 10.0.2.0/24 to 192.0.2.1 \ from 198.51.100.1 to 10.0.1.0/24 \ peer 192.0.2.1 \ srcid server2.domain
Se connecter à un VPN IKEv2 en tant que road warrior est similaire au cas précédent, excepté que l'initiateur envisage généralement d'acheminer son trafic Internet via le répondeur, qui agira comme NAT, ainsi le trafic de l'initiateur apparaîtra venir de l'adresse IP publique du répondeur.
Selon ce cas d'utilisation, comme tout le trafic passera au-travers du répondeur, il faut s'assurer que l'initiateur soit configuré pour utiliser un serveur DNS qu'il peut atteindre (éventuellement un sur le répondeur)
Dans nos exemples, le réseau 10.0.5.0/24
est utilisé pour supporter le VPN. L'adresse IP interne actuelle sera automatiquement installée par iked sur l'interface vether0. Nous assumerons le fait que l'adresse IP publique du client est 203.0.113.2
.
Comme dans l'exemple précédent, l'échange des clés publiques RSA fournies par défaut est suffisant pour paramétrer une simple authentification entre le répondeur et l'initiateur : /etc/iked/local.pub
du premier système (“server1”) devra être copié vers /etc/iked/pubkeys/fqdn/server1.domain
du second système (“roadwarrior”). Ensuite /etc/iked/local.pub
du système roadwarrior devra être copié vers /etc/iked/pubkeys/fqdn/roadwarrior
du premier. Remplacez “serverX.domain” avec votre propre FQDN.
Le répondeur iked.conf(5) crée les flux depuis toute destination au baux d'IP dynamique venant du pool d'adresses, qui sera décidé au démarrage, et étiquette les paquets avec ROADW :
ikev2 'responder_rsa' passive esp \ from any to dynamic \ local 192.0.2.1 peer any \ srcid server1.domain \ config address 10.0.5.0/24 \ tag "ROADW"
Le répondeur a besoin de fournir une adresse IP à l'initiateur. Ce qui est réalisé par les directives de configuration. Par l'utilisation de l'option config address
, to dynamic
sera remplacé par l'adresse IP dynamique assignée.
Il a aussi besoin d'allouer IPSec depuis tout hôte (puisque les clients peuvent se connecter de n'importe où), permettre le trafic étiqueté ROADW sur enc0
et d'appliquer la NAT :
pass in log on $ext_if proto udp from any to 192.0.2.1 port {isakmp, ipsec-nat-t} tag IKED pass in log on $ext_if proto esp from any to 192.0.2.1 tag IKED pass log on enc0 tagged ROADW match out log on $ext_if inet tagged ROADW nat-to $ext_if
L'initiateur configure un flux global pour envoyer tout son trafic au répondeur, lui demandant de s'identifier avec la clé nommée “roadwarrior” :
ikev2 'roadwarrior' active esp \ from dynamic to any \ peer 192.0.2.1 \ srcid roadwarrior \ dstid server1.domain \ request address any \ iface vether0
L'initiateur utilise l'adresse l'opotion request address any
pour demander une adresse IP dynamique au répondeur. L'option iface vether0
spécifie l'interface qui reçoit l'adresse et les routes correspondantes seront installées. Le répondeur doit avoir une configuration NAT appropriée pour le client road warrior.
Arrêter correctement le VPN sur l'initiateur peut être réalisé en utilisant ikectl decouple
(iked
est toujours fonctionnel, attendant ikectl couple
afin de se reconnecter au répondeur) ou avec ikectl reset sa && rcctl stop iked
pour arrêter définitivement iked
et s'assurer qu'il n'y ait plus de flux.
Le client VPN par défaut d'Android supporte seulement IKEv1. Pour utiliser IKEv2, strongSwan est une option.
Il est aussi requis de paramétrer un PKI et des certificats X.509 ainsi l'initiateur pourra valider le certificat émis par le répondeur :
server1# ikectl ca vpn create server1# ikectl ca vpn install certificate for CA 'vpn' installed into /etc/iked/ca/ca.crt CRL for CA 'vpn' installed to /etc/iked/crls/ca.crl server1# ikectl ca vpn certificate server1.domain create server1# ikectl ca vpn certificate server1.domain install writing RSA key server1# cp /etc/iked/ca/ca.crt /var/www/htdocs/
Sur le périphérique Android, allez sur http://192.0.2.1/ca.crt
et importez le certificat CA dans le client strongSwan. À partir de là, il y a plusieurs manières d'authentifier l'initiateur au répondeur :
La configuration du répondeur a besoin de spécifier une liste de noms d'utilisateurs et mots de passe, et utilisera eap “mschap-v2”
(qui est la seule méthode EAP prise en charge actuellement), telle que :
user 'android' 'password' ikev2 'responder_eap' passive esp \ from any to dynamic \ local 192.0.2.1 peer any \ srcid server1.domain \ eap "mschap-v2" \ config address 10.0.5.0/24 \ config name-server 192.0.2.1 \ tag "ROADW"
Sur le client strongSwan, un nouveau profil est configuré en utilisant :
CN=VPN
pour le champ CA certificate client1.domain
pour le champ User identity server1.domain
pour le champ Server identity (dans les paramètres avancés : 'advanced settings')
Avec cela, le périphérique Android peut se connecter au répondeur, authentifier le certificat du répondeur avec le certificat CA, s'authentifier au répondeur avec le couple de connexion EAP, obtenir une adresse dans le réseau 10.0.5.0/24
, et tout son trafic passant au-travers du VPN, utilisant 192.0.2.1
comme étant son serveur DNS.
Pour cette méthode, un certificat est généré pour le client, installé dans iked ca
, exporté comme une archive ; le fichier .pfx devra être rendu disponible en ligne afin que le client puisse l'installer. Le fichier .pfx comprend :
server1# ikectl ca vpn certificate client1.domain create server1# cp /etc/ssl/vpn/client1.domain.crt /etc/iked/certs/ server1# ikectl ca vpn certificate client1.domain export server1# tar -C /tmp -xzf client1.domain.tgz *pfx server1# cp /tmp/export/client1.domain.pfx /var/www/htdocs/client1.domain.pfx
Le certificat public CA et le certificat du client ont été importés dans le client strongSwan lors de la configuration du nouveau profil.
La configuration du répondeur est légèrement plus simple puisqu'il n'y a pas besoin de spécifier eap
ni de paramétrer un nom utilisateur et mot de passe.
ikev2 'responder_x509' passive esp \ from any to dynamic \ local 192.0.2.1 peer any \ srcid server1.domain \ config address 10.0.5.0/24 \ config name-server 192.0.2.1 \ tag "ROADW"
Dans le client strongSwan, un nouveau profil est configuré, utilisant :
192.0.2.1
pour le champ server CN=client1.domain
pour le champ User certificate client1.domain
pour le champ User identity server1.domain
dans le champ Server identity (dans les paramètres avancés : 'advanced settings') Tel que dans le cas EAP, le périphérique Android peut maintenant se connecter au répondeur et utiliser le VPN.
Windows 7 et supérieur fournit un initiateur IKEv2 qui requiert aussi l'utilisation des certificats X.509, qui a besoin d'être exporté en tant que .pfx/.p12 et importé dans le magasin de certificats de la machine locale (non pas dans le compte utilisateur), à la fois pour la CA et pour le client, soit en utilisant la console de gestion Microsoft - MMC (écrivez mmc
dans une ligne de commande et ajoutez les certificats comme compte d'ordinateur) ou avec la commande certutil dans Windows 10. Importez ca.crt
dans le magasin de certificats d'autorité, et ClientIP.p12
dans le magasin personnel. Le projet StrongSwan a une bonne documentation à ce propos, avec des captures d'écrans.
Windows ne facilite pas le paramétrage srcid
pour le client ; le champ CN du certificat client doit correspondre avec le client FQDN envoyé par le répondeur, ou son adresse IP par défaut. Il est aussi requis que srcid
sur le répondeur corresponde avec le FQDN du répondeur (ou son adresse IP, s'il n'utilise pas FQDN) - autrement vous expérimenterez l'erreur redoutée error 3801
. Le projet Libreswan a de précieuses précisions sur ces prérequis.
Une fois que les certificats ont été importés, configurez une nouvelle connexion VPN, avec :
IKEv2
pour le type dans l'onglet security Le fichier de configuration du répondeur sera très similaire au cas Android.
user 'windows' 'password' ikev2 'responder_eap' passive esp \ from any to dynamic \ local 192.0.2.1 peer any \ srcid server1.domain.fqdn \ eap "mschap-v2" \ config address 10.0.5.0/24 \ config name-server 192.0.2.1 \ tag "ROADW"
Par défaut, tout le trafic windows passera au-travers du VPN IKEv2.
Au moment de l'écriture de ce tutoriel, les versions actuelles de Windows utilisent un faible chiffrement par défaut (3DES/SHA1). Cela peut être corrigé avec la commande PowerShell Set-VpnConnectionIPsecConfiguration
.
Parfois, on ne contrôle pas le serveur VPN, et le seul choix donné est de se connecter à un serveur IKEv1. Dans ce cas, le paquet tierce xl2tpd
est nécessaire pour agir en tant que client L2TP.
Il est premièrement requis d'activer les services isakmpd(8) et ipsec
, ainsi les démons seront actifs et le fichier de configuration ipsec.conf(5) sera chargé au démarrage :
# rcctl enable ipsec # rcctl enable isakmpd # rcctl set isakmpd flags -K
La configuration ipsec.conf(5) suivante devrait permettre de se connecter à un serveur IKEv1 à A.B.C.D
avec un PSK fourni, permettant seulement le port UDP 1701 pour L2TP :
ike dynamic esp transport proto udp from egress to A.B.C.D port l2tp \ psk mekmitasdigoat
Démarrer isakmpd(8) et charger ipsec.conf(5) en utilisant ipsecctl(8) devrait vous permettre de visualiser les Associations de Sécurité (SAs) configurées et les flux :
# rcctl start isakmpd # ipsecctl -f /etc/ipsec.conf # ipsecctl -sa FLOWS: flow esp in proto udp from A.B.C.D port l2tp to W.X.Y.Z peer A.B.C.D srcid my.client.fqdn dstid A.B.C.D/32 type use flow esp out proto udp from W.X.Y.Z to A.B.C.D port l2tp peer A.B.C.D srcid my.client.fqdn dstid A.B.C.D/32 type require SAD: esp transport from A.B.C.D to W.X.Y.Z spi 0x0d16ad1c auth hmac-sha1 enc aes esp transport from W.X.Y.Z to A.B.C.D spi 0xcd0549ba auth hmac-sha1 enc aes
Si ce n'est pas le cas, il peut être utile d'ajuster les paramètres de phase 1 (Main) et phase 2 (Quick), quand les deux parties échangent les paramètres de chiffrement afin d'agréer la meilleure combinaison disponible. Idéalement, ces paramètres devraient être fournis par l'administrateur système à distance, et devraient être utilisés dans ipsec.conf(5) :
ike dynamic esp transport proto udp from egress to A.B.C.D port l2tp \ main auth "hmac-sha1" enc "3des" group modp1024 \ quick auth "hmac-sha1" enc "aes" \ psk mekmitasdigoat
Une fois que le tunnel IKEv1 est monté et fonctionnel, le tunnel L2TP a besoin d'être configuré. OpenBSD ne fournit pas de client L2TP par défaut, ainsi l'installation de xl2tpd
est requise :
# pkg_add xl2tpd
Référez-vous au fichier /usr/local/share/doc/pkg-readmes/xl2tpd
pour les instructions sur comment paramétrer proprement le client L2TP.
Cette page est la traduction officieuse de la page FAQ - Virtual Private Networks (VPN) de la FAQ officielle d'OpenBSD.
En cas de doute, merci de vous y référer !
Si vous voulez participer à l'effort de traduction, merci de lire ce topic.
Contribut(rice|eur)s :