- Mensajes
- 14,201
Introducción
Hoy os vengo a traer una evolución (o directamente sustitución) del manual para montar una VPN de tipo IKEv2. Después de probar más a fondo esta VPN, me he dado cuenta de que, si bien el manual original es muy sencillo de montar y juega mucho con la configuración por defecto del router, no es la mejor de las configuraciones ni la más estable que podemos montar para este tipo de VPN. Además de esto, quiero mostraros cómo montar no sólo una VPN de tipo road-warrior, sino también como unir dos sedes usando este tipo de VPN, que sinceramente creo es la mejor que podéis montar en un equipo de esta marca, a día de hoy.Como las presentaciones ya están hechas y sabéis de qué va el tema si habéis leído ya el otro manual, voy al grano.
Generación de certificados
Me baso en que tenéis un dominio propio, en mi caso y para el ejemplo será pericopalotes.com, el cual apunta a la IP pública de vuestra conexión con el sub-dominio router.pericopalotes.com, de la manera que creáis conveniente. No obstante, podéis hacer lo mismo con el dominio que os regala mikrotik, el cual podéis encontrar en IP -> Cloud, si activáis esa opción. Vamos a crear dos certificados, uno para un cliente road-warrior, un supuesto teléfono móvil y el otro para un cliente de tipo oficina, que conectaremos en remoto a nuestro HQ.
Código:
# Creaccion de los certificados
# Primero la CA
/certificate
add name=vpn-ca country=ES state=Tabarnia locality=Rivendel organization="Perico Palotes LTD"\
common-name="VPN CA" subject-alt-name=DNS:pericopalotes.com key-size=2048 days-valid=3650 trusted=yes\
key-usage=digital-signature,key-encipherment,data-encipherment,key-cert-sign,crl-sign
# Luego el certificado del servidor
add name=vpn-server country=ES state=Tabarnia locality=Rivendel organization="Perico Palotes LTD" unit=VPN\
common-name="VPN Server" subject-alt-name=DNS:router.pericopalotes.com key-size=2048 days-valid=1825\
key-usage=tls-server,key-encipherment,digital-signature
# Por ultimo una template para crear certificados cliente
add name=~vpn-client-template country=ES state=Tabarnia locality=Rivendel organization="Perico Palotes LTD"\
common-name="VPN Client XXX" subject-alt-name=email:xxx@router.pericopalotes.com key-size=2048\
days-valid=730 key-usage=tls-client
#Y los certificados de tipo cliente, copia de la template
add copy-from=~vpn-client-template name=vpn-client-mobile common-name="VPN Client Mobile"\
subject-alt-name=email:mobile@router.pericopalotes.com
add copy-from=~vpn-client-template name=vpn-client-branch common-name="VPN Client Branch"\
subject-alt-name=email:branch@router.pericopalotes.com
# Los firmamos
/certificate
sign vpn-ca
{:delay 5};
sign vpn-server ca=vpn-ca
sign vpn-client-mobile ca=vpn-ca
sign vpn-client-branch ca=vpn-ca
# Exportar la CA y los certificados cliente
/certificate
export-certificate vpn-ca file-name=ca
export-certificate vpn-client-mobile type=pkcs12 export-passphrase="MySuperVPN!" file-name=mobile
export-certificate vpn-client-branch type=pkcs12 export-passphrase="MySuperVPN!" file-name=branchA continuación, daremos de alta un pool para los clientes de tipo road-warrior. Abriremos un "hueco" en dicho pool, puesto que usaremos las primeras direcciones para las oficinas remotas en el modo site-to-site
Código:
/ip pool
add name=pool-vpn ranges=192.168.68.10-192.168.68.254Y ahora creamos toda la configuración para IPSec, auto explicada en sus comentarios
Código:
#Creamos dos configuraciones, una para road warrior, y otra para la oficina remota
/ip ipsec mode-config
add address-pool=pool-vpn address-prefix-length=32 name=ike2-conf-road-warrior split-include=0.0.0.0/0 system-dns=yes
add address=192.168.68.2 address-prefix-length=32 name=ike2-conf-branch system-dns=no
# Damos de alta un nuevo groupo para asociar a él las plantillas de configuración con los policies a usar
/ip ipsec policy group
add name=ike2-template-group
# Damos de alta el perfil de authenticación
/ip ipsec profile
add dh-group=modp2048,modp1536,modp1024 enc-algorithm=aes-256,aes-192,aes-128 hash-algorithm=sha256 name=ike2-profile
# Damos de alta el peer que escuchará las conexiones remotas, de tipo IKEv2
/ip ipsec peer
add exchange-mode=ike2 name=ike2-peer passive=yes profile=ike2-profile
# Damos de alta la propuesta de negociación para el intercambio de claves IKE y SAs
# Las claves tendrán una validez de 8h para evitar renegociaciones innecesarias y el pfs-group=none para
# aumentar la compatiblidad con dispositivos moviles, tipo Apple. Restringimos el proposal a tipo de encriptación AES
/ip ipsec proposal
add auth-algorithms=sha512,sha256,sha1 enc-algorithms=aes-256-cbc,aes-256-ctr,aes-256-gcm,aes-192-ctr,aes-192-gcm,aes-128-cbc,aes-128-ctr,aes-128-gcm lifetime=8h \
name=ike2-proposal pfs-group=none
# Damos de alta las identidades de los clientes que se van a conectar al router
# Por un lado el movil en modo road warrior, y por otro el router remoto en modo branch
# Cada uno apuntando a un mode-config distinto, y al nuevo grupo de plantillas que hemos creado
/ip ipsec identity
add auth-method=digital-signature certificate=vpn-server comment=mobile generate-policy=port-strict match-by=certificate mode-config=ike2-conf-road-warrior peer=ike2-peer \
policy-template-group=ike2-template-group remote-certificate=vpn-client-mobile
add auth-method=digital-signature certificate=vpn-server comment=router-branch generate-policy=port-strict match-by=certificate mode-config=ike2-conf-branch peer=\
ike2-peer policy-template-group=ike2-template-group remote-certificate=vpn-client-branch
# Creamos dos plantillas con las políticas pertinentes, ambas pertenecientes al nuevo grupo
# Suponemos 192.168.88.0/24 como LAN local del router de HQ, este que estamos configurando, y 192.168.98.0/24 como LAN local del router tipo branch remoto
# La 192.168.68.0/24 es nuestro segmento VPN para los equipos en modo road-warrior
/ip ipsec policy
add comment=road-warrior dst-address=192.168.68.0/24 group=ike2-template-group proposal=ike2-proposal src-address=0.0.0.0/0 template=yes
add comment=site-to-site dst-address=192.168.98.0/24 group=ike2-template-group proposal=ike2-proposal src-address=192.168.88.0/24 template=yesUna vez hecho esto, tenemos el router listo para admitir conexiones remotas, tanto de clientes que vengan de cualquier IP den modo road-warrior, como el cliente remoto que será nuestra oficina que conecta con este router como head-quarter. Estamos suponiendo que la oficina remota tiene una LAN distinta de la principal, en este caso la principal supones está en la 192.168.88.0/24 (la red por defecto del mikrotik) y la remota será la 192.168.98.0/24. Como veis, las plantillas de generación de políticas de ikev2 van asociadas a dichas IPs.
Configuración en modo road-warrior
En esta parte no me voy a parar, porque ya está explicada en el manual anterior. Exportáis los certificados CA y cliente (en este caso el mobile, que yo llamé "VPN Client iPhone") y los importáis en el dispositivo móvil que vayáis a usar, confiando ciegamente en la CA. El endpoint de conexión sería "router.pericopalotes.com" y la autenticación se haría por certificados, sin ninguna otra contraseña de por medio. Una vez conectados, navegaréis y tendréis los DNS del router principal. Un ejemplo de configuración en un iPhone, una vez hecha la importación de los certificados:Configuración en modo site-to-site
Esta conexión hay dos maneras de hacerla. O podemos montar un túnel IKEv2, exactamente del mismo modo que se conectaría cualquier cliente road-warrior, usando su perfil, para luego levantar sobre dicho túnel otro túnel IPIP, GRE, EoIP, etc y así hacer el enrutado, o podemos usar las policies de IPSec para enrutar el tráfico. Esta segunda manera no es trivial, puesto que no vamos a tener como tal una tabla de rutas donde podamos ver el caminio que seguiran los paquetes, sino que IKEv2 los tele-transportará usando las políticas de in-ipsec y out-ipsec. Me voy a centrar en esta segunda manera porque creo que es la manera correcta de hacerlo, y además vamos a obtener mucho mejor resultado en rendimiento, puesto que no vamos a generar overhead por el encapsulado de un túnel dentro de otro túnel. Si alguien quiere más detalle del setup de túnel sobre túnel, que pregunte, que lo puedo explicar también.Del lado del servidor lo tenemos todo listo (salvo ajustar la parte del firewall, que la veremos un pelín más tarde) para que un cliente remoto establezca la conexión, ya sea tipo road warrior (usará la primera template) o de tipo site-to-site (usará la segunda template). Podemos crear tantas templates como redes queramos transportar de un lado al otro usando IPSec.
Lo primero que haremos del lado cliente es importar los dos certificados, la CA y el certificado cliente. Una vez importados, podemos renombrarlos si queremos, y así ponerle un nombre más descriptivo. En mi caso, el certificado de tipo CA se va a llamar "ca" y el certificado cliente se llamará "vpn-client-branch". Hecho esto, damos de alta una configuración similar que en el router de la oficina principal, con la única salvedad que el peer apuntará a la URL del equipo que hace de servidor VPN (router.pericopalotes.com) y que crearemos una policy de tipo túnel, en lugar de template. En este caso el identity apuntará únicamente a nuestro certificado cliente (no hay certificado servidor como en el otro lado), y pediremos la configuración al remoto. Con esto, nos quedaría así la configuración del cliente de tipo oficina remota
Código:
# Nuevo template group, idéntico al del router HQ
/ip ipsec policy group
add name=ike2-template-group
# Perfil, idéntico al del servidor
/ip ipsec profile
add dh-group=modp2048,modp1536,modp1024 enc-algorithm=aes-256,aes-192,aes-128 \
hash-algorithm=sha256 name=ike2-profile
# Peer, apuntando a la dirección de nuestro dominio o IP estática del router HQ
/ip ipsec peer
add address=router.pericopalotes.com exchange-mode=ike2 name=ike2-hq-peer \
profile=ike2-profile
# Proposal, idéntico al del router de HQ
/ip ipsec proposal
add auth-algorithms=sha512,sha256,sha1 enc-algorithms="aes-256-cbc,aes-256-ctr,a\
es-256-gcm,aes-192-ctr,aes-192-gcm,aes-128-cbc,aes-128-ctr,aes-128-gcm" \
lifetime=8h name=ike2-proposal pfs-group=none
# Identity, en este caso especificando únicamente el certificado cliente
# Y, como configuración, indicamos "request-only" para pedirsela al remoto
/ip ipsec identity
add auth-method=digital-signature certificate=vpn-client-branch generate-policy=\
port-strict mode-config=request-only peer=ike2-hq-peer \
policy-template-group=ike2-template-group
# Policy, en este caso en modo túnel, no template
# Origen la LAN de nuestra oficina branch, destino la LAN del router HQ
/ip ipsec policy
add dst-address=192.168.88.0/24 level=unique peer=ike2-hq-peer proposal=\
ike2-proposal src-address=192.168.98.0/24 tunnel=yesSi todo ha ido bien, en el router cliente, el que hace de branch remota, tendremos una entrada tipo túnel en la pestaña de IPSec Policies, y en la columna PH2 State, veremos el mensaje "established". Dicha entrada habrá golpeado en el router remoto, en la template "site-to-site", y se habrá generado una entrada similar, creada por la plantilla de forma dinámica, con el mismo mensaje "established" en la columna PH2 State. Si navegamos en cualquiera de los dos routers a la pestaña "Installed SAs" podremos ver las claves de encriptado que se han generado en ambos extremos (autenticación sha512 y encriptado aes cbc de 256 bits) , y en la pestaña "Active Peers" podremos ver la conexión del cliente en sí. En este momento ambas LANs estarán conectadas y podremos lanzar un ping desde un cliente conectado al router de HQ hacia un cliente conectado al router de la branch y viceversa.
En el router cliente, veréis una nueva dirección 192.168.68.2 que ha aparecido de manera dinámica sobre ether1 (o la que sea vuestra interfaz WAN), lo cual podéis comprobar en IP -> Address.
Una cosa curiosa de este método es que nos permite conectividad incluso si el router de la oficina estuviera debajo de un NAT de otro router de operadora. Si además quisiéramos tener acceso desde al oficina HQ a dicho router que está por encima de nuestro mikrotik en la branch remota, bastaría con crear un nuevo túnel en el router de dicha oficina mandándole a la red remota la red de dicho equipo. Como ambos están conectados entre sí, podríamos incluso acceder a ese equipo que tenemos por encima.
Ajustando el firewall - Reglas de input y TCP MSS
En el firewall de ambos equipos necesitamos hacer un par de ajustes. Obviamente permitir el tráfico de IPSec en el chain de input (puertos 4500 y 500), permitiremos también el tráfico del protocolo 50 para ESP. En el router de tipo branch, además, permitiremos el tráfico de entrada encriptado, desde la red lan HQ, para administrar ese router de forma remota, una vez el túnel esté levantado.Fijaos que en ninguno de los dos lados nos hará falta una regla de masquerade como nos pasa con otro tipo de VPN's, puesto que la regla general que enmascara el tráfico que sale por la WAN ya lleva un tipo de policy "out,none" que nos evita tener que hacerlo. Del resto, se encargan las templates del apartado Policies en ambos lados de la conexión, auto-mágicamente.
Firewall -> Filter (Lado Servidor, HQ)
Código:
/ip firewall filter
add action=accept chain=input comment="allow ipsec" dst-port=500,4500 protocol=udp
add action=accept chain=input protocol=ipsec-espFirewall -> Filter (Lado Cliente, Branch). Permitimos también la administración remota desde la LAN de HQ.
Código:
/ip firewall filter
add action=accept chain=input comment="allow ipsec" dst-port=500,4500 protocol=udp
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=input comment="allow HQ access to router" ipsec-policy=in,ipsec src-address=192.168.88.0/24Por último nos queda ajustar el MSS de los paquetes TCP. Y diréis, ¿qué narices es eso? Pues bien, aunque tal y como está la conexión os va a dar un buen resultado, el tema se puede mejorar aún más si ajustamos el tamaño del paquete. Al estar trabajando con IPSec y con tráfico encriptado, no toda la información del los 1500bytes del tamaño de paquete la podemos usar para transportar información útil, puesto que el propio encapsulado y el encriptado se come parte de ese tamaño. Para evitar dicha fragmentación, lo que haremos será modificar el valor del tamaño del paquete para los mensajes que se intercambien como TPC SYN, tal que si un cliente remoto quiere enviarnos información, lo primero que hará será mandarnos ese paquete de sincronización, donde ya le estaremos advirtiendo de que nuestra capacidad de mandar información útil es algo menor que los 1500bytes del MTU. Esto es algo que en otras VPN que manejan interfaces es automático, puesto que llevan un flag llamado "Clamp TCP MSS", que por defecto ya viene marcado (mirad por ejemplo los túneles de tipo L2TP o EoIP), pero al estar trabajando sin interfaces e ir directamente por IP, no tenemos esa opción. Para esto crearemos las siguientes reglas de mangle, que harán exactamente lo mismo:
Mangle, en el router HQ, Servidor (2x road warrior + 1x de entrada por cada de LAN de oficina remota)
Código:
/ip firewall mangle
add action=change-mss chain=forward comment="ike2-road-warrior clamp tcp mss" ipsec-policy=in,ipsec new-mss=1360 passthrough=yes protocol=tcp src-address=192.168.68.0/24 \
tcp-flags=syn tcp-mss=!0-1360
add action=change-mss chain=forward dst-address=192.168.68.0/24 ipsec-policy=out,ipsec new-mss=1360 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=!0-1360
add action=change-mss chain=forward comment="ike2-branch clamp tcp mss" dst-address=192.168.88.0/24 ipsec-policy=in,ipsec new-mss=1360 passthrough=yes protocol=tcp \
src-address=192.168.98.0/24 tcp-flags=syn tcp-mss=!0-1360Mangle, en el router de la branch (una única entrada, para el tráfico de entrada al router HQ)
Código:
/ip firewall mangle
add action=change-mss chain=forward comment="ike2-hq clamp tcp mss" dst-address=192.168.98.0/24 \
ipsec-policy=in,ipsec new-mss=1360 passthrough=yes protocol=tcp src-address=192.168.88.0/24 tcp-flags=syn \
tcp-mss=!0-1360Y, con esto y un bizcocho, hemos terminado por hoy de afinar aún más las conexiones VPN de tipo IKEv2. Si alguien se anima a probar el túnel site-to-site, que me diga qué rendimiento le da.
Saludos, y que lo disfrutéis!
Última edición:
