strongswan v6.1.0
strongSwan - VPN basé sur IPsec
Configuration de strongSwan
Vue d'ensemble
strongSwan est une solution VPN OpenSource basée sur IPsec.
Ce document n'est qu'une brève introduction de la commande swanctl de strongSwan, qui utilise la moderne vici Versatile IKE Configuration Interface (interface polyvalente de configuration IKE). La commande ipsec obsolète, utilisant l'ancienne interface de configuration stroke, est décrite ici. Pour des informations plus détaillées, consultez les pages de manuel, notre nouveau site de documentation et l'ancien wiki.
Démarrage rapide
Les certificats pour les utilisateurs, les hôtes et les passerelles sont émis
par une autorité de certification (CA) strongSwan fictive. Dans nos scénarios
d'exemple, le certificat CA strongswanCert.pem doit être présent sur tous les
points d'extrémité VPN afin de pouvoir authentifier les pairs. Pour votre
application VPN particulière, vous pouvez soit utiliser des certificats d'une
CA tierce, soit générer vous-même les clés privées et les certificats
nécessaires à l'aide de l'outil pki de strongSwan, dont l'utilisation sera
expliquée dans l'une des sections ci-dessous.
Cas site à site
Dans ce scénario, deux passerelles de sécurité moon et sun connectent les deux sous-réseaux moon-net et sun-net l'un à l'autre via un tunnel VPN établi entre les deux passerelles :
10.1.0.0/16 -- | 192.168.0.1 | === | 192.168.0.2 | -- 10.2.0.0/16
moon-net moon sun sun-net
Configuration sur la passerelle moon :
/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/x509/moonCert.pem
/etc/swanctl/private/moonKey.pem
/etc/swanctl/swanctl.conf:
connections {
net-net {
remote_addrs = 192.168.0.2
local {
auth = pubkey
certs = moonCert.pem
}
remote {
auth = pubkey
id = "C=CH, O=strongSwan, CN=sun.strongswan.org"
}
children {
net-net {
local_ts = 10.1.0.0/16
remote_ts = 10.2.0.0/16
start_action = trap
}
}
}
}
Configuration sur la passerelle sun :
/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/x509/sunCert.pem
/etc/swanctl/private/sunKey.pem
/etc/swanctl/swanctl.conf:
connections {
net-net {
remote_addrs = 192.168.0.1
local {
auth = pubkey
certs = sunCert.pem
}
remote {
auth = pubkey
id = "C=CH, O=strongSwan, CN=moon.strongswan.org"
}
children {
net-net {
local_ts = 10.2.0.0/16
remote_ts = 10.1.0.0/16
start_action = trap
}
}
}
}
Les identités locales et distantes utilisées dans ce scénario sont les subjectDistinguishedNames contenus dans les certificats d'entité finale. Les certificats et les clés privées sont chargés dans le démon charon avec la commande
swanctl --load-creds
tandis que
swanctl --load-conns
charge les connexions définies dans swanctl.conf. Avec start_action = trap,
la connexion IPsec est automatiquement établie dès le premier paquet IP de
charge utile en clair souhaitant traverser le tunnel.
Cas hôte à hôte
Il s'agit d'une configuration entre deux hôtes uniques qui n'ont pas de sous-réseau derrière eux. Bien que le mode transport IPsec serait suffisant pour les connexions hôte à hôte, nous utiliserons le mode tunnel IPsec par défaut.
| 192.168.0.1 | === | 192.168.0.2 |
moon sun
Configuration sur l'hôte moon :
/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/x509/moonCert.pem
/etc/swanctl/private/moonKey.pem
/etc/swanctl/swanctl.conf:
connections {
host-host {
remote_addrs = 192.168.0.2
local {
auth=pubkey
certs = moonCert.pem
}
remote {
auth = pubkey
id = "C=CH, O=strongSwan, CN=sun.strongswan.org"
}
children {
net-net {
start_action = trap
}
}
}
}
Configuration sur l'hôte sun :
/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/x509/sunCert.pem
/etc/swanctl/private/sunKey.pem
/etc/swanctl/swanctl.conf:
connections {
host-host {
remote_addrs = 192.168.0.1
local {
auth = pubkey
certs = sunCert.pem
}
remote {
auth = pubkey
id = "C=CH, O=strongSwan, CN=moon.strongswan.org"
}
children {
host-host {
start_action = trap
}
}
}
}
Cas Roadwarrior
C'est un cas très courant où une passerelle strongSwan dessert un nombre quelconque de clients VPN distants ayant généralement des adresses IP dynamiques.
10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x |
moon-net moon carol
Configuration sur la passerelle moon :
/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/x509/moonCert.pem
/etc/swanctl/private/moonKey.pem
/etc/swanctl/swanctl.conf:
connections {
rw {
local {
auth = pubkey
certs = moonCert.pem
id = moon.strongswan.org
}
remote {
auth = pubkey
}
children {
net-net {
local_ts = 10.1.0.0/16
}
}
}
}
Configuration sur le roadwarrior carol :
/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/x509/carolCert.pem
/etc/swanctl/private/carolKey.pem
/etc/swanctl/swanctl.conf:
connections {
home {
remote_addrs = moon.strongswan.org
local {
auth = pubkey
certs = carolCert.pem
id = [email protected]
}
remote {
auth = pubkey
id = moon.strongswan.org
}
children {
home {
local_ts = 10.1.0.0/16
start_action = start
}
}
}
}
Pour remote_addrs, le nom d'hôte moon.strongswan.org a été choisi ; il sera
résolu par DNS au moment de l'exécution vers l'adresse IP de destination
correspondante. Dans ce scénario, l'identité du roadwarrior carol est
l'adresse e-mail [email protected], qui doit être incluse en tant que
subjectAlternativeName dans le certificat du roadwarrior carolCert.pem.
Cas Roadwarrior avec IP virtuelle
Les roadwarriors ont généralement des adresses IP dynamiques attribuées par le FAI auquel ils sont actuellement connectés. Afin de simplifier le routage de moon-net vers le client d'accès distant carol, il serait souhaitable que le roadwarrior dispose d'une adresse IP interne choisie dans un pool prédéfini.
10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x | -- 10.3.0.1
moon-net moon carol virtual IP
Dans notre exemple, l'adresse IP virtuelle est choisie dans le pool d'adresses
10.3.0.0/16, qui peut être configuré en ajoutant la section
pools {
rw_pool {
addrs = 10.3.0.0/16
}
}
au swanctl.conf de la passerelle, d'où elles sont chargées dans le démon
charon à l'aide de la commande
swanctl --load-pools
Pour demander une adresse IP depuis ce pool, un roadwarrior peut utiliser la configuration de mode IKEv1 ou les charges utiles de configuration IKEv2. La configuration est la même pour les deux
vips = 0.0.0.0
Configuration sur la passerelle moon :
/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/x509/moonCert.pem
/etc/swanctl/private/moonKey.pem
/etc/swanctl/swanctl.conf:
connections {
rw {
pools = rw_pool
local {
auth = pubkey
certs = moonCert.pem
id = moon.strongswan.org
}
remote {
auth = pubkey
}
children {
net-net {
local_ts = 10.1.0.0/16
}
}
}
}
pools {
rw_pool {
addrs = 10.30.0.0/16
}
}
Configuration sur le roadwarrior carol :
/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/x509/carolCert.pem
/etc/swanctl/private/carolKey.pem
/etc/swanctl/swanctl.conf:
connections {
home {
remote_addrs = moon.strongswan.org
vips = 0.0.0.0
local {
auth = pubkey
certs = carolCert.pem
id = [email protected]
}
remote {
auth = pubkey
id = moon.strongswan.org
}
children {
home {
local_ts = 10.1.0.0/16
start_action = start
}
}
}
}
Cas Roadwarrior avec authentification EAP
C'est un cas très courant où une passerelle strongSwan dessert un nombre quelconque de clients VPN distants qui s'authentifient via un Extended Authentication Protocol (protocole d'authentification étendu) basé sur un mot de passe, par exemple EAP-MD5 ou EAP-MSCHAPv2.
10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x |
moon-net moon carol
Configuration sur la passerelle moon :
/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/x509/moonCert.pem
/etc/swanctl/private/moonKey.pem
/etc/swanctl/swanctl.conf:
connections {
rw {
local {
auth = pubkey
certs = moonCert.pem
id = moon.strongswan.org
}
remote {
auth = eap-md5
}
children {
net-net {
local_ts = 10.1.0.0/16
}
}
send_certreq = no
}
}
Le fichier swanctl.conf contient en outre une section secrets définissant
toutes les informations d'identification des clients
secrets {
eap-carol {
id = [email protected]
secret = Ar3etTnp
}
eap-dave {
id = [email protected]
secret = W7R0g3do
}
}
Configuration sur le roadwarrior carol :
/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/swanctl.conf:
connections {
home {
remote_addrs = moon.strongswan.org
local {
auth = eap
id = [email protected]
}
remote {
auth = pubkey
id = moon.strongswan.org
}
children {
home {
local_ts = 10.1.0.0/16
start_action = start
}
}
}
}
secrets {
eap-carol {
id = [email protected]
secret = Ar3etTnp
}
}
Cas Roadwarrior avec identité EAP
Souvent, une identité EAP de client est échangée via EAP, laquelle diffère de l'identité IKEv2 externe. Dans cet exemple, l'identité IKEv2 est par défaut l'adresse IPv4 du client.
10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x |
moon-net moon carol
Configuration sur la passerelle moon :
/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/x509/moonCert.pem
/etc/swanctl/private/moonKey.pem
/etc/swanctl/swanctl.conf:
connections {
rw {
local {
auth = pubkey
certs = moonCert.pem
id = moon.strongswan.org
}
remote {
auth = eap-md5
eap_id = %any
}
children {
net-net {
local_ts = 10.1.0.0/16
}
}
send_certreq = no
}
}
secrets {
eap-carol {
id = carol
secret = Ar3etTnp
}
eap-dave {
id = dave
secret = W7R0g3do
}
}
Configuration sur le roadwarrior carol :
/etc/swanctl/x509ca/strongswanCert.pem
/etc/swanctl/swanctl.conf:
connections {
home {
remote_addrs = moon.strongswan.org
local {
auth = eap
eap_id = carol
}
remote {
auth = pubkey
id = moon.strongswan.org
}
children {
home {
local_ts = 10.1.0.0/16
start_action = start
}
}
}
}
secrets {
eap-carol {
id = carol
secret = Ar3etTnp
}
}
Génération de certificats et de CRL
Cette section n'est pas un tutoriel complet sur l'utilisation de l'outil pki de strongSwan. Elle énumère simplement quelques points pertinents si vous souhaitez générer vos propres certificats et CRL pour une utilisation avec strongSwan.
Génération d'un certificat CA
L'instruction pki
pki --gen --type ed25519 --outform pem > strongswanKey.pem
génère une clé elliptique de courbe d'Edwards avec une force cryptographique de 128 bits. La clé publique correspondante est intégrée dans un certificat CA auto-signé avec une durée de vie de 10 ans (3652 jours)
pki --self --ca --lifetime 3652 --in strongswanKey.pem \
--dn "C=CH, O=strongSwan, CN=strongSwan Root CA" \
--outform pem > strongswanCert.pem
qui peut être listé avec la commande
pki --print --in strongswanCert.pem
subject: "C=CH, O=strongSwan, CN=strongSwan Root CA"
issuer: "C=CH, O=strongSwan, CN=strongSwan Root CA"
validity: not before May 18 08:32:06 2017, ok
not after May 18 08:32:06 2027, ok (expires in 3651 days)
serial: 57:e0:6b:3a:9a:eb:c6:e0
flags: CA CRLSign self-signed
subjkeyId: 2b:95:14:5b:c3:22:87:de:d1:42:91:88:63:b3:d5:c1:92:7a:0f:5d
pubkey: ED25519 256 bits
keyid: a7:e1:6a:3f:e7:6f:08:9d:89:ec:23:92:a9:a1:14:3c:78:a8:7a:f7
subjkey: 2b:95:14:5b:c3:22:87:de:d1:42:91:88:63:b3:d5:c1:92:7a:0f:5d
Si vous préférez que la clé privée CA et le certificat X.509 soient au format
binaire DER, il suffit d'omettre l'option --outform pem. Le répertoire
/etc/swanctl/x509ca contient tous les certificats CA requis, soit au format
DER binaire, soit au format PEM Base64. Quel que soit le suffixe du fichier, le
format correct sera déterminé automatiquement par strongSwan.
Génération d'un certificat d'entité finale d'hôte ou d'utilisateur
Nous utilisons à nouveau la commande
pki --gen --type ed25519 --outform pem > moonKey.pem
pour générer une clé privée Ed25519 pour l'hôte moon. Vous pouvez également
saisir
pki --gen --type rsa --size 3072 > moonKey.der
pour générer une clé RSA traditionnelle de 3072 bits et la stocker au format DER binaire. Une alternative : un TPM 2.0 Trusted Platform Module (module de plateforme de confiance), disponible sur toutes les plateformes Intel récentes, pourrait être utilisé comme carte à puce virtuelle pour stocker de manière sécurisée une clé privée RSA ou ECDSA. Pour plus de détails, reportez-vous au HOWTO TPM 2.0.
Dans une étape suivante, la commande
pki --req --type priv --in moonKey.pem \
--dn "C=CH, O=strongswan, CN=moon.strongswan.org" \
--san moon.strongswan.org --outform pem > moonReq.pem
crée une demande de certificat PKCS#10 qui doit être signée par la CA. Grâce à
l'utilisation [multiple] du paramètre --san, n'importe quel nombre de
subjectAlternativeNames (noms alternatifs de sujet) souhaités peut être
ajouté à la demande. Ceux-ci peuvent être de la forme
--san sun.strongswan.org # fully qualified host name
--san [email protected] # RFC822 user email address
--san 192.168.0.1 # IPv4 address
--san fec0::1 # IPv6 address
Sur la base de la demande de certificat, la CA émet un certificat d'entité finale signé avec la commande suivante
pki --issue --cacert strongswanCert.pem --cakey strongswanKey.pem \
--type pkcs10 --in moonReq.pem --serial 01 --lifetime 1826 \
--outform pem > moonCert.pem
Si le paramètre --serial avec un argument hexadécimal est omis, un numéro de
série aléatoire est généré. Certains clients VPN tiers exigent que le
certificat d'une passerelle VPN contienne l'indicateur TLS Server
Authentication Extended Key Usage (EKU), qui peut être inclus avec l'option
suivante
--flag serverAuth
Si vous souhaitez utiliser la fonctionnalité de récupération dynamique des CRL
décrite dans l'une des sections suivantes, vous pouvez inclure un ou plusieurs
crlDistributionPoints (points de distribution CRL) dans vos certificats
d'entité finale à l'aide du paramètre --crl
--crl http://crl.strongswan.org/strongswan.crl
--crl "ldap://ldap.strongswan.org/cn=strongSwan Root CA, o=strongSwan,c=CH?certificateRevocationList"
Le certificat d'hôte émis peut être listé avec
pki --print --in moonCert.pem
subject: "C=CH, O=strongSwan, CN=moon.strongswan.org"
issuer: "C=CH, O=strongSwan, CN=strongSwan Root CA"
validity: not before May 19 10:28:19 2017, ok
not after May 19 10:28:19 2022, ok (expires in 1825 days)
serial: 01
altNames: moon.strongswan.org
flags: serverAuth
CRL URIs: http://crl.strongswan.org/strongswan.crl
authkeyId: 2b:95:14:5b:c3:22:87:de:d1:42:91:88:63:b3:d5:c1:92:7a:0f:5d
subjkeyId: 60:9d:de:30:a6:ca:b9:8e:87:bb:33:23:61:19:18:b8:c4:7e:23:8f
pubkey: ED25519 256 bits
keyid: 39:1b:b3:c2:34:72:1a:01:08:40:ce:97:75:b8:be:ce:24:30:26:29
subjkey: 60:9d:de:30:a6:ca:b9:8e:87:bb:33:23:61:19:18:b8:c4:7e:23:8f
En général, un client VPN basé sur Windows, OSX, Android ou iOS a besoin de sa clé privée, de son certificat d'hôte ou d'utilisateur et du certificat CA. Le moyen le plus pratique de charger ces informations est de tout placer dans un conteneur PKCS#12 :
openssl pkcs12 -export -inkey carolKey.pem \
-in carolCert.pem -name "carol" \
-certfile strongswanCert.pem -caname "strongSwan Root CA" \
-out carolCert.p12
L'outil pki de strongSwan n'est actuellement pas capable de créer des conteneurs PKCS#12 ; openssl doit donc être utilisé.
Génération d'une CRL
Une CRL vide signée par la CA peut être générée avec la commande
pki --signcrl --cacert strongswanCert.pem --cakey strongswanKey.pem \
--lifetime 30 > strongswan.crl
Si vous omettez l'option --lifetime, la valeur par défaut de 15 jours est
utilisée. Les CRL peuvent être téléchargées sur un serveur HTTP ou LDAP, ou
placées au format DER binaire ou PEM Base64 dans le répertoire
/etc/swanctl/x509crl, d'où elles sont chargées dans le démon charon avec
la commande
swanctl --load-creds### Révoquer un certificat ###
Un certificat d'entité finale spécifique est révoqué avec la commande
pki --signcrl --cacert strongswanCert.pem --cakey strongswanKey.pem \
--lifetime 30 --lastcrl strongswan.crl \
--reason key-compromise --cert moonCert.pem > new.crl
Au lieu du fichier de certificat (dans notre exemple moonCert.pem), le numéro de série
du certificat à révoquer peut être indiqué à l'aide du paramètre --serial.
La commande pki --signcrl --help documente toutes les raisons de révocation
possibles mais le paramètre --reason peut également être omis. Le contenu du nouveau
fichier CRL peut être listé avec la commande
pki --print --type crl --in new.crl
issuer: "C=CH, O=strongSwan, CN=strongSwan Root CA"
update: this on May 19 11:13:01 2017, ok
next on Jun 18 11:13:01 2017, ok (expires in 29 days)
serial: 02
authKeyId: 2b:95:14:5b:c3:22:87:de:d1:42:91:88:63:b3:d5:c1:92:7a:0f:5d
1 revoked certificate:
01: May 19 11:13:01 2017, key compromise
Cache local des CRL
L'option strongswan.conf
charon {
cache_crls = yes
}
active le cache local des CRL qui ont été récupérées dynamiquement depuis un
serveur HTTP ou LDAP. Les copies mises en cache sont stockées dans /etc/swanctl/x509crl en utilisant
un nom de fichier unique formé à partir du subjectKeyIdentifier de l'émetteur et du
suffixe .crl.
Grâce à la copie mise en cache, la CRL est immédiatement disponible après le démarrage. Lorsque la copie locale est devenue obsolète, une CRL mise à jour est automatiquement récupérée depuis l'un des points de distribution de CRL définis lors de la prochaine authentification IKEv2.