
strongswan v6.1.0
strongSwan - IPsec-basiertes VPN
strongSwan-Konfiguration
Übersicht
strongSwan ist eine Open-Source-IPsec-basierte VPN-Lösung.
Dieses Dokument ist nur eine kurze Einführung in den swanctl-Befehl von strongSwan, der die moderne vici Versatile IKE Configuration Interface verwendet. Der veraltete ipsec-Befehl mit der älteren stroke-Konfigurationsschnittstelle wird hier beschrieben. Für detailliertere Informationen konsultieren Sie die Manpages, unsere neue Dokumentationsseite und das alte Wiki.
Schnellstart
Zertifikate für Benutzer, Hosts und Gateways werden von einer fiktiven
strongSwan-CA ausgestellt. In unseren Beispielszenarien muss das
CA-Zertifikat strongswanCert.pem auf allen VPN-Endpunkten vorhanden sein,
um die Peers authentifizieren zu können. Für Ihre spezielle VPN-Anwendung
können Sie entweder Zertifikate einer beliebigen Drittanbieter-CA verwenden
oder die benötigten privaten Schlüssel und Zertifikate selbst mit dem
strongSwan-pki-Werkzeug erzeugen, dessen Verwendung in einem der
folgenden Abschnitte erläutert wird.
Site-to-Site-Szenario
In diesem Szenario verbinden zwei Sicherheits-Gateways moon und sun die beiden Subnetze moon-net und sun-net über einen zwischen den beiden Gateways aufgebauten VPN-Tunnel miteinander:
10.1.0.0/16 -- | 192.168.0.1 | === | 192.168.0.2 | -- 10.2.0.0/16
moon-net moon sun sun-net
Konfiguration auf Gateway 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
}
}
}
}
Konfiguration auf Gateway 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
}
}
}
}
Die in diesem Szenario verwendeten lokalen und entfernten Identitäten sind die subjectDistinguishedNames, die in den Endentitätszertifikaten enthalten sind. Die Zertifikate und privaten Schlüssel werden mit dem Befehl
swanctl --load-creds
in den charon-Daemon geladen, während
swanctl --load-conns
die in swanctl.conf definierten Verbindungen lädt. Mit start_action = trap
wird die IPsec-Verbindung automatisch mit dem ersten unverschlüsselten
IP-Paket aufgebaut, das durch den Tunnel geleitet werden soll.
Host-zu-Host-Szenario
Dies ist ein Aufbau zwischen zwei einzelnen Hosts, hinter denen sich kein Subnetz befindet. Obwohl der IPsec-Transportmodus für Host-zu-Host-Verbindungen ausreichen würde, verwenden wir den standardmäßigen IPsec-Tunnelmodus.
| 192.168.0.1 | === | 192.168.0.2 |
moon sun
Konfiguration auf Host 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
}
}
}
}
Konfiguration auf Host 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
}
}
}
}
Roadwarrior-Szenario
Dies ist ein sehr häufiger Fall, bei dem ein strongSwan-Gateway einer beliebigen Anzahl von Remote-VPN-Clients dient, die normalerweise dynamische IP-Adressen haben.
10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x |
moon-net moon carol
Konfiguration auf Gateway 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
}
}
}
}
Konfiguration auf 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
}
}
}
}
Für remote_addrs wurde der Hostname moon.strongswan.org gewählt, der zur
Laufzeit von DNS in die entsprechende IP-Zieladresse aufgelöst wird.
In diesem Szenario ist die Identität des Roadwarriors carol die E-Mail-Adresse
[email protected], die als subjectAlternativeName in das
Roadwarrior-Zertifikat carolCert.pem aufgenommen werden muss.
Roadwarrior-Szenario mit virtueller IP
Roadwarrior haben normalerweise dynamische IP-Adressen, die vom jeweiligen ISP zugewiesen werden. Um das Routing von moon-net zurück zum Remote-Access-Client carol zu vereinfachen, wäre es wünschenswert, wenn der Roadwarrior eine innere IP-Adresse aus einem vordefinierten Pool hätte.
10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x | -- 10.3.0.1
moon-net moon carol virtuelle IP
In unserem Beispiel wird die virtuelle IP-Adresse aus dem Adresspool
10.3.0.0/16 gewählt, der durch Hinzufügen des Abschnitts
pools {
rw_pool {
addrs = 10.3.0.0/16
}
}
zur swanctl.conf des Gateways konfiguriert werden kann, von wo sie mit dem
Befehl
swanctl --load-pools
in den charon-Daemon geladen werden.
Um eine IP-Adresse aus diesem Pool anzufordern, kann ein Roadwarrior die IKEv1-Mode-Config oder IKEv2-Konfigurations-Payloads verwenden. Die Konfiguration ist für beide gleich:
vips = 0.0.0.0
Konfiguration auf Gateway 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
}
}
Konfiguration auf 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
}
}
}
}
Roadwarrior-Szenario mit EAP-Authentifizierung
Dies ist ein sehr häufiger Fall, bei dem ein strongSwan-Gateway einer beliebigen Anzahl von Remote-VPN-Clients dient, die sich über ein passwortbasiertes Extended Authentication Protocol wie z. B. EAP-MD5 oder EAP-MSCHAPv2 authentifizieren.
10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x |
moon-net moon carol
Konfiguration auf Gateway 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
}
}
Die Datei swanctl.conf enthält zusätzlich einen secrets-Abschnitt, der
alle Client-Anmeldedaten definiert:
secrets {
eap-carol {
id = [email protected]
secret = Ar3etTnp
}
eap-dave {
id = [email protected]
secret = W7R0g3do
}
}
Konfiguration auf 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
}
}
Roadwarrior-Szenario mit EAP-Identität
Oft wird eine Client-EAP-Identität über EAP ausgetauscht, die sich von der externen IKEv2-Identität unterscheidet. In diesem Beispiel wird die IKEv2-Identität standardmäßig auf die IPv4-Adresse des Clients gesetzt.
10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x |
moon-net moon carol
Konfiguration auf Gateway 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
}
}
Konfiguration auf 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
}
}
Generieren von Zertifikaten und CRLs
Dieser Abschnitt ist kein ausführliches Tutorial zur Verwendung des strongSwan-pki-Werkzeugs. Er listet nur einige Punkte auf, die relevant sind, wenn Sie eigene Zertifikate und CRLs für die Verwendung mit strongSwan erzeugen möchten.
Generieren eines CA-Zertifikats
Die pki-Anweisung
pki --gen --type ed25519 --outform pem > strongswanKey.pem
erzeugt einen elliptischen Edwards-Curve-Schlüssel mit einer kryptografischen Stärke von 128 Bit. Der zugehörige öffentliche Schlüssel wird in ein selbstsigniertes CA-Zertifikat mit einer Lebensdauer von 10 Jahren (3652 Tagen) verpackt:
pki --self --ca --lifetime 3652 --in strongswanKey.pem \
--dn "C=CH, O=strongSwan, CN=strongSwan Root CA" \
--outform pem > strongswanCert.pem
Dieses kann mit dem Befehl
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
Wenn Sie den CA-privaten Schlüssel und das X.509-Zertifikat im binären
DER-Format bevorzugen, lassen Sie einfach die Option --outform pem weg. Das
Verzeichnis /etc/swanctl/x509ca enthält alle erforderlichen CA-Zertifikate
entweder im binären DER- oder im Base64-PEM-Format. Unabhängig von der
Dateiendung wird das korrekte Format von strongSwan automatisch ermittelt.
Generieren eines Host- oder Benutzer-Endentitätszertifikats
Auch hier verwenden wir den Befehl
pki --gen --type ed25519 --outform pem > moonKey.pem
um einen privaten Ed25519-Schlüssel für den Host moon zu erzeugen.
Alternativ können Sie
pki --gen --type rsa --size 3072 > moonKey.der
eingeben, um einen traditionellen 3072-Bit-RSA-Schlüssel zu erzeugen und im binären DER-Format zu speichern. Als Alternative kann ein TPM 2.0 Trusted Platform Module, das auf jeder aktuellen Intel-Plattform verfügbar ist, als virtuelle Smartcard verwendet werden, um einen RSA- oder ECDSA-privaten Schlüssel sicher zu speichern. Details finden Sie im TPM-2.0- HOWTO.
Im nächsten Schritt erzeugt der Befehl
pki --req --type priv --in moonKey.pem \
--dn "C=CH, O=strongswan, CN=moon.strongswan.org" \
--san moon.strongswan.org --outform pem > moonReq.pem
eine PKCS#10-Zertifikatsanforderung, die von der CA signiert werden muss.
Durch die [mehrfache] Verwendung des Parameters --san kann eine beliebige
Anzahl gewünschter subjectAlternativeNames zur Anforderung hinzugefügt
werden. Diese können die folgende Form haben:
--san sun.strongswan.org # voll qualifizierter Hostname
--san [email protected] # RFC822-Benutzer-E-Mail-Adresse
--san 192.168.0.1 # IPv4-Adresse
--san fec0::1 # IPv6-Adresse
Basierend auf der Zertifikatsanforderung stellt die CA mit dem folgenden Befehl ein signiertes Endentitätszertifikat aus:
pki --issue --cacert strongswanCert.pem --cakey strongswanKey.pem \
--type pkcs10 --in moonReq.pem --serial 01 --lifetime 1826 \
--outform pem > moonCert.pem
Wenn der Parameter --serial mit einem hexadezimalen Argument weggelassen
wird, wird eine zufällige Seriennummer erzeugt. Einige Drittanbieter-VPN-Clients
verlangen, dass ein VPN-Gateway-Zertifikat das Flag TLS Server Authentication
Extended Key Usage (EKU) enthält, das mit der folgenden Option aufgenommen
werden kann:
--flag serverAuth
Wenn Sie die in einem der folgenden Abschnitte beschriebene Funktion zum
dynamischen Abrufen von CRLs verwenden möchten, können Sie mit dem Parameter
--crl einen oder mehrere crlDistributionPoints in Ihre
Endentitätszertifikate aufnehmen:
--crl http://crl.strongswan.org/strongswan.crl
--crl "ldap://ldap.strongswan.org/cn=strongSwan Root CA, o=strongSwan,c=CH?certificateRevocationList"
Das ausgestellte Host-Zertifikat kann mit folgendem Befehl aufgelistet werden:
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
Normalerweise benötigt ein VPN-Client auf Windows-, OSX-, Android- oder iOS-Basis seinen privaten Schlüssel, sein Host- oder Benutzerzertifikat und das CA-Zertifikat. Der bequemste Weg, diese Informationen zu laden, besteht darin, alles in einen PKCS#12-Container zu packen:
openssl pkcs12 -export -inkey carolKey.pem \
-in carolCert.pem -name "carol" \
-certfile strongswanCert.pem -caname "strongSwan Root CA" \
-out carolCert.p12
Das strongSwan-pki-Werkzeug kann derzeit keine PKCS#12-Container erstellen, daher muss openssl verwendet werden.
Generieren einer CRL
Eine leere, von der CA signierte CRL kann mit dem Befehl
pki --signcrl --cacert strongswanCert.pem --cakey strongswanKey.pem \
--lifetime 30 > strongswan.crl
erzeugt werden. Wenn Sie die Option --lifetime weglassen, wird der
Standardwert von 15 Tagen verwendet. CRLs können entweder auf einen HTTP- oder
LDAP-Server hochgeladen oder im binären DER- oder Base64-PEM-Format in das
Verzeichnis /etc/swanctl/x509crl gelegt werden, von wo sie mit dem Befehl
swanctl --load-creds
in den charon-Daemon geladen werden.### Widerruf eines Zertifikats ###
Ein bestimmtes End-Entity-Zertifikat wird mit folgendem Befehl widerrufen:
pki --signcrl --cacert strongswanCert.pem --cakey strongswanKey.pem \
--lifetime 30 --lastcrl strongswan.crl \
--reason key-compromise --cert moonCert.pem > new.crl
Anstelle der Zertifikatsdatei (in unserem Beispiel moonCert.pem) kann die Seriennummer des zu widerrufenden Zertifikats über den Parameter --serial angegeben werden. Der Befehl pki --signcrl --help dokumentiert alle möglichen Widerrufsgründe, der Parameter --reason kann jedoch auch weggelassen werden. Der Inhalt der neuen CRL-Datei kann mit dem folgenden Befehl aufgelistet werden:
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
Lokales Zwischenspeichern von CRLs
Die Option strongswan.conf
charon {
cache_crls = yes
}
aktiviert das lokale Zwischenspeichern von CRLs, die dynamisch von einem HTTP- oder LDAP-Server abgerufen wurden. Zwischengespeicherte Kopien werden unter /etc/swanctl/x509crl mit einem eindeutigen Dateinamen gespeichert, der aus dem subjectKeyIdentifier des Ausstellers und der Endung .crl gebildet wird.
Mit der zwischengespeicherten Kopie ist die CRL unmittelbar nach dem Start verfügbar. Wenn die lokale Kopie veraltet ist, wird bei der nächsten IKEv2-Authentifizierung automatisch eine aktualisierte CRL von einem der definierten CRL-Verteilungspunkte abgerufen.