Conexión Strongswan ikev2, ¿cómo hacer que el nombre de usuario corresponda con la dirección IP asignada?
Actualmente, los únicos clientes que soportan IKEv2 parecen ser Openswan/Strongswan, que es totalmente compatible con Windows 7 y Windows Server 2008 R2 (Vista sólo soporta IKEv1).
La razón por la que usamos IKEv2 en lugar de IKEv1 es porque actualmente no existe ningún complemento/cliente de código abierto para que IKEv1 se conecte con Radius, y la solución más cercana es XAuth-PAM pam_radius. La solución más cercana es el radio XAuth-PAM, pero pam tiene una resistencia débil a los ataques DoS, por lo que no es una solución particularmente buena. Además, Openswan no incluye xauthpam de forma predeterminada al compilar, lo que dificulta el uso de servidores de administración de paquetes binarios. La configuración se vuelve más complicada.
IKEv2 requiere que el servidor utilice un certificado para demostrar su identidad, incluso si el cliente está utilizando autenticación MSCHAPv2 (nombre de usuario y contraseña). Por tanto, el primer paso es generar el certificado utilizado por el servidor:
ipsec pki --gen --outform pem gt; caKey.pem
ipsec pki --self -- en caKey. pem --dn "C=CH, O=strongSwan, CN=strongSwan CA" --ca --outform pem gt; caCert.pem
Este paso generará el certificado de CA, que generará se instalará más tarde Certificado para el cliente, donde el valor de CN (Nombre común) es muy importante, debe ser el nombre de dominio/dirección IP del servidor y el mismo valor que se le dio al cliente. Por ejemplo, si desea que los clientes se conecten a 1.2.3.4, entonces CN=1.2.3.4. No puede ser un nombre de dominio por un lado y una dirección IP por el otro.
ipsec pki --gen --outform pem gt; serverKey.pem
ipsec pki --pub --in ipsec pki --issue --cacert caCert. pem --cakey caKey.pem
--dn "C=CH, O=strongSwan, CN=vpn.strongswan.org" --flag serverAuth --outform pem gt serverCert.pem
El valor CN del certificado de servidor generado en este paso debe ser coherente con el valor CN del paso anterior. El valor CN debe ser el mismo que en el paso anterior y los clientes de Windows deben usar --flag serverAuth para indicar el propósito de este certificado (autenticación).
Finalmente, agregue:
:
Finalmente, en /etc/ipsec.secrets, agregue:
: RSA serverKey.pem
En este punto, se completa la preparación del certificado del lado del servidor.
Agregar en la sección charon:
dns1 = 8.8.8.8
dns2 = 208.67.222.222
Luego en el complemento sección (sección Charon) agregue:
eap-radius {
servidores {
vpnserver {
secreto = yourfreeradiussecret
dirección = radio.servidor.dirección
}
}
}
De esta manera Strongswan puede conocer la dirección del servidor Radius y contraseña.
A continuación modifique /etc/ipsec.conf:
conn IPSec-IKEv2
keyexchange=ikev2
auto=add
left=server.ip.address
leftsubnet=0.0.0.0/0
leftauth=pubkey
leftcert=serverCert.pem
right=cualquier
rightsourceip=vpn.ip.address.range
rightauth=eap-radius
rightendcert=never
eap_identity=any
Explique el significado de los elementos anteriores: leftsubnet es el rango de IP que determina la IP utilizada para pasar el túnel, 0.0. Rights source IP es el rango de direcciones virtuales asignado por la VPN. es decir, cuando el cliente inicia sesión. El rango de IP obtenido, por ejemplo, 192.168.1.0/24 significa 192.168.1.0/24. rightauth=eap-radius significa reenviar la solicitud de autenticación EAP del cliente a Radius para su procesamiento y cualquier medio para aceptar cualquier tipo de solicitud EAP.
¿Configuración completada? Después de ver este mensaje, el cliente de Windows mostrará un error 812, porque Windows usa EAP-MSCHAPv2 de forma predeterminada y la configuración predeterminada de Freeradius es EAP-md5. Esto puede ser un error de Windows. Mi solución actual es usar Freeradius. eap Cambie default_eap_type en .conf a mschapv2, si hay una manera mejor, dígame.
Esto creará un túnel IPSec IKEv2. De forma predeterminada, el método de cifrado utiliza 3DES, pero puede modificar el algoritmo de cifrado si es necesario agregando ike= y esp= en la sección de configuración de IPSec.