strongswan v6.1.0
strongSwan - VPN basada en IPsec
Configuración de strongSwan
Resumen
strongSwan es una solución VPN de código abierto basada en IPsec.
Este documento es solo una breve introducción al comando swanctl de strongSwan, que utiliza la moderna vici Versatile IKE Configuration Interface. El comando obsoleto ipsec, que utiliza la interfaz de configuración stroke heredada, se describe aquí. Para obtener información más detallada, consulte las páginas man, nuestro nuevo sitio de documentación y la wiki heredada.
Inicio rápido
Los certificados para usuarios, hosts y pasarelas son emitidos por una CA strongSwan ficticia. En nuestros escenarios de ejemplo, el certificado de CA strongswanCert.pem debe estar presente en todos los extremos VPN para poder autenticar a los peers. Para su aplicación VPN particular, puede utilizar certificados de cualquier CA de terceros o generar las claves privadas y los certificados necesarios usted mismo con la herramienta pki de strongSwan, cuyo uso se explicará en una de las secciones siguientes.
Caso sitio a sitio
En este escenario, dos pasarelas de seguridad moon y sun conectarán las dos subredes moon-net y sun-net entre sí a través de un túnel VPN establecido entre las dos pasarelas:
10.1.0.0/16 -- | 192.168.0.1 | === | 192.168.0.2 | -- 10.2.0.0/16
moon-net moon sun sun-net
Configuración en la pasarela 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
}
}
}
}
Configuración en la pasarela 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
}
}
}
}
Las identidades locales y remotas utilizadas en este escenario son los subjectDistinguishedNames contenidos en los certificados de entidad final. Los certificados y las claves privadas se cargan en el demonio charon con el comando
swanctl --load-creds
mientras que
swanctl --load-conns
carga las conexiones definidas en swanctl.conf. Con start_action = trap, la conexión IPsec se establece automáticamente con el primer paquete IP de carga útil en texto plano que desee atravesar el túnel.
Caso de host a host
Esta es una configuración entre dos hosts individuales que no tienen una subred detrás. Aunque el modo transporte IPsec sería suficiente para conexiones host a host, utilizaremos el modo túnel IPsec predeterminado.
| 192.168.0.1 | === | 192.168.0.2 |
moon sun
Configuración en el 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
}
}
}
}
Configuración en el 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
}
}
}
}
Caso roadwarrior
Este es un caso muy común en el que una pasarela strongSwan atiende a un número arbitrario de clientes VPN remotos que normalmente tienen direcciones IP dinámicas.
10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x |
moon-net moon carol
Configuración en la pasarela 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
}
}
}
}
Configuración en el 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
}
}
}
}
Para remote_addrs se eligió el nombre de host moon.strongswan.org, que será resuelto por DNS en tiempo de ejecución a la dirección IP de destino correspondiente. En este escenario, la identidad del roadwarrior carol es la dirección de correo electrónico [email protected], que debe incluirse como subjectAlternativeName en el certificado del roadwarrior carolCert.pem.
Caso roadwarrior con IP virtual
Los roadwarriors normalmente tienen direcciones IP dinámicas asignadas por el ISP al que están conectados actualmente. Para simplificar el enrutamiento desde moon-net de vuelta al cliente de acceso remoto carol, sería deseable que el roadwarrior tuviera una dirección IP interna elegida de un pool predefinido.
10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x | -- 10.3.0.1
moon-net moon carol virtual IP
En nuestro ejemplo, la dirección IP virtual se elige del pool de direcciones 10.3.0.0/16, que se puede configurar añadiendo la sección
pools {
rw_pool {
addrs = 10.3.0.0/16
}
}
al swanctl.conf de la pasarela, desde donde se cargan en el demonio charon mediante el comando
swanctl --load-pools
Para solicitar una dirección IP de este pool, un roadwarrior puede usar mode config de IKEv1 o payloads de configuración de IKEv2. La configuración para ambos es la misma
vips = 0.0.0.0
Configuración en la pasarela 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
}
}
Configuración en el 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
}
}
}
}
Caso roadwarrior con autenticación EAP
Este es un caso muy común en el que una pasarela strongSwan atiende a un número arbitrario de clientes VPN remotos que se autentican mediante un Extended Authentication Protocol (Protocolo de Autenticación Extendido) basado en contraseña, como por ejemplo EAP-MD5 o EAP-MSCHAPv2.
10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x |
moon-net moon carol
Configuración en la pasarela 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
}
}
El archivo swanctl.conf contiene además una sección secrets que define todas las credenciales de los clientes
secrets {
eap-carol {
id = [email protected]
secret = Ar3etTnp
}
eap-dave {
id = [email protected]
secret = W7R0g3do
}
}
Configuración en el 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
}
}
Caso roadwarrior con identidad EAP
A menudo, una identidad EAP de cliente se intercambia mediante EAP, que difiere de la identidad IKEv2 externa. En este ejemplo, la identidad IKEv2 por defecto es la dirección IPv4 del cliente.
10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x |
moon-net moon carol
Configuración en la pasarela 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
}
}
Configuración en el 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
}
}
Generación de certificados y CRLs
Esta sección no es un tutorial completo sobre cómo usar la herramienta pki de strongSwan. Simplemente enumera algunos puntos relevantes si desea generar sus propios certificados y CRLs para usar con strongSwan.
Generación de un certificado de CA
La declaración pki
pki --gen --type ed25519 --outform pem > strongswanKey.pem
genera una clave elíptica Edwards-Curve con una fortaleza criptográfica de 128 bits. La clave pública correspondiente se empaqueta en un certificado de CA autofirmado con una validez de 10 años (3652 días)
pki --self --ca --lifetime 3652 --in strongswanKey.pem \
--dn "C=CH, O=strongSwan, CN=strongSwan Root CA" \
--outform pem > strongswanCert.pem
que se puede listar con el comando
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 prefiere que la clave privada de la CA y el certificado X.509 estén en formato binario DER, simplemente omita la opción --outform pem. El directorio /etc/swanctl/x509ca contiene todos los certificados de CA necesarios, ya sea en formato DER binario o PEM Base64. Independientemente del sufijo del archivo, strongSwan determinará automágicamente el formato correcto.
Generación de un certificado de entidad final de host o usuario
De nuevo usamos el comando
pki --gen --type ed25519 --outform pem > moonKey.pem
para generar una clave privada Ed25519 para el host moon. Alternativamente, puede escribir
pki --gen --type rsa --size 3072 > moonKey.der
para generar una clave RSA tradicional de 3072 bits y almacenarla en formato DER binario. Como alternativa, un TPM 2.0 Trusted Platform Module (Módulo de Plataforma Confiable) disponible en todas las plataformas Intel recientes podría utilizarse como una tarjeta inteligente virtual para almacenar de forma segura una clave privada RSA o ECDSA. Para más detalles, consulte el HOWTO de TPM 2.0.
En el siguiente paso, el comando
pki --req --type priv --in moonKey.pem \
--dn "C=CH, O=strongswan, CN=moon.strongswan.org" \
--san moon.strongswan.org --outform pem > moonReq.pem
crea una solicitud de certificado PKCS#10 que debe ser firmada por la CA. Mediante el uso [múltiple] del parámetro --san, se puede añadir a la solicitud cualquier número de subjectAlternativeNames deseadas. Estas pueden tener la forma
--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
Basándose en la solicitud de certificado, la CA emite un certificado de entidad final firmado con el siguiente comando
pki --issue --cacert strongswanCert.pem --cakey strongswanKey.pem \
--type pkcs10 --in moonReq.pem --serial 01 --lifetime 1826 \
--outform pem > moonCert.pem
Si se omite el parámetro --serial con un argumento hexadecimal, se genera un número de serie aleatorio. Algunos clientes VPN de terceros requieren que un certificado de pasarela VPN contenga el flag TLS Server Authentication de Extended Key Usage (EKU), que se puede incluir con la siguiente opción
--flag serverAuth
Si desea utilizar la función de obtención dinámica de CRL descrita en una de las secciones siguientes, puede incluir uno o varios crlDistributionPoints en sus certificados de entidad final mediante el parámetro --crl
--crl http://crl.strongswan.org/strongswan.crl
--crl "ldap://ldap.strongswan.org/cn=strongSwan Root CA, o=strongSwan,c=CH?certificateRevocationList"
El certificado de host emitido se puede listar con
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
Normalmente, un cliente VPN basado en Windows, OSX, Android o iOS necesita su clave privada, su certificado de host o usuario y el certificado de CA. La forma más conveniente de cargar esta información es poner todo en un contenedor PKCS#12:
openssl pkcs12 -export -inkey carolKey.pem \
-in carolCert.pem -name "carol" \
-certfile strongswanCert.pem -caname "strongSwan Root CA" \
-out carolCert.p12
La herramienta pki de strongSwan actualmente no puede crear contenedores PKCS#12, por lo que se debe usar openssl.
Generación de una CRL
Se puede generar una CRL vacía firmada por la CA con el comando
pki --signcrl --cacert strongswanCert.pem --cakey strongswanKey.pem \
--lifetime 30 > strongswan.crl
Si se omite la opción --lifetime, se utiliza el valor predeterminado de 15 días. Las CRL se pueden subir a un servidor HTTP o LDAP, o colocar en formato DER binario o PEM Base64 en el directorio /etc/swanctl/x509crl, desde donde se cargan en el demonio charon con el comando
swanctl --load-creds### Revocación de un Certificado ###
Un certificado de entidad final específico se revoca con el comando
pki --signcrl --cacert strongswanCert.pem --cakey strongswanKey.pem \
--lifetime 30 --lastcrl strongswan.crl \
--reason key-compromise --cert moonCert.pem > new.crl
En lugar del archivo de certificado (en nuestro ejemplo moonCert.pem), el número de serie
del certificado que se va a revocar se puede indicar mediante el parámetro --serial.
El comando pki --signcrl --help documenta todos los motivos de revocación
posibles, pero el parámetro --reason también puede omitirse. El contenido del nuevo
archivo CRL se puede listar con el comando
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
Almacenamiento en Caché Local de CRLs
La opción de strongswan.conf
charon {
cache_crls = yes
}
activa el almacenamiento en caché local de las CRL que se obtienen dinámicamente de un
servidor HTTP o LDAP. Las copias en caché se almacenan en /etc/swanctl/x509crl con un
nombre de archivo único formado por el subjectKeyIdentifier del emisor y el
sufijo .crl.
Con la copia en caché, la CRL está disponible inmediatamente después del inicio. Cuando la copia local queda obsoleta, se obtiene automáticamente una CRL actualizada desde uno de los puntos de distribución de CRL definidos durante la siguiente autenticación IKEv2.