Cómo respaldar tu túnel IKEv2 con dos dominios DDNS mediante un script
Debido a las caídas de los DDNS de Mikrotik, he buscado la forma de poder tener un respaldo para que mi túnel IKEv2 pueda seguir levantado en caso de que vuelvan a caer.
Las pruebas las he realizado en un túnel que tengo en producción tipo IKEv2 (con varias LANs interconectadas y un túnel EoIP) entre mi casa (Despacho), que sería la parte HQ del enlace y un apartamento que visito con regularidad por temas de trabajo aparte de la época vacacional, este último sería la parte Branch del enlace.
Esta es la configuración:
Lado HQ
Partimos que ya existe un túnel IPSec/IKEv2 funcionando con Certificados tipo
*.sn.mynetname.net.
Ver este post para más información sobre este tipo de túnel:
https://www.adslzone.net/foro/mikrotik.199/manual-mikrotik-ikev2-vpn-fondo.570958/
Creamos en HQ un segundo pack de Certificados:
CA, VPN Server y Cliente, configurado con un DDNS distinto al *.sn.mynetname.net. En mi caso voy añadir un DDNS tipo NoIP (
*.sytes.net).
Creamos un nuevo Identity:
Bash:
/ip ipsec identity
add auth-method=digital-signature certificate=vpn-server-noip comment=router-branch-noip \
generate-policy=port-strict match-by=certificate mode-config=ike2-conf-branch \
peer=ike2-peer policy-template-group=ike2-template-group\
remote-certificate=c1@prueba.sytes.net
Con esto ya hemos terminado en el lado HQ.
Lado Branch
Sobre el nuevo pack de Certificados creados y exportados en HQ, importamos
Certificados CA y Cliente.
Creamos nuevo
Peer y nueva
Identity:
Bash:
# Creamos un nuevo peer que apunta al dominio DDNS creado.
/ip ipsec peer
add address=prueba.sytes.net exchange-mode=ike2 name=ike2-noip-peer profile=ike2-profile
# Nueva Identity con el certificado cliente de DDNS NoIP
/ip ipsec identity
add auth-method=digital-signature certificate=vpn-client-noip generate-policy=port-strict \
mode-config=request-only peer=ike2-noip-peer policy-template-group=ike2-template-group
Para conmutar manualmente, primero desactivas el
Peer de <*.sn.mynetname.net> y después desactivas la
Identity correspondiente.
Ahora vamos a activar, primero la
Identity de <prueba.sytes.net> y después el
Peer (el peer inicia la conexión desde este lado).
Si en algún momento vemos que alguna de las
policies existentes no pasan a estado "established" solo hay que desactivarlas y volverlas a activar individualmente. Con esto quedan levantadas.
Bueno, para rizar el rizo, he creado un script totalmente funcional para automatizar la tarea de conmutar los
Peers y las
Identities de cada proveedor y así
en caso de caída de uno de ellos, el script lo detectaría y lo cambiaría al proveedor que estuviera online. De esta forma el tunel IKEv2 levanta solito y las
Policies las resetea para levanten igualmente.
Aparte de lo expuesto anteriormente, he creado en el lado "Branch" del túnel nuevas
Policies para que apunten a cada dominio (cada Peer apunta a un dominio diferente), es decir, habría que crearlas por duplicado, tal como está en la imagen siguiente, y además etiquetar cada
Policy para mejorar la funcionalidad del script.
Bash:
{
# Dirección IP del cualquier host activo del lado HQ
:local HOST "192.168.88.247"
# DDNS del router Mikrotik
:local DDNSMK "dXXXXXXXXXX9.sn.mynetname.net"
# Otro DDNS de respaldo
:local DDNSNOIP "prueba.sytes.net"
:local LOCATION "Despacho"
# Obtener el Peer activo
:local PEER [/ip ipsec active-peers get 0 id];
# Interface de la Red remota
:local GW "bridge-local"
# Tiempo de espera del ping. Aumente o disminuya según sea necesario
:local TIMEOUT "100ms"
# Número de pings a enviar
:local COUNT "10"
# Número de respuestas requeridas
:local LESSTHAN "8"
:log info "IKEv2: Tunnel Check Started"
:log info "IKEv2: Looking for $HOST at $LOCATION"
# Hacemos ping a una IP de la LAN del router HQ para comprobar si el túnel está levantado
# Si está caído ejecuta dos condicionales "IF".
:if ([/ping interface=$GW $HOST interval=$TIMEOUT count=$COUNT]<$LESSTHAN) do={
log error "IKEv2: Tunnel with $LOCATION is down, modifying DDNS...";
# Primera condición: comprueba si hay conectividad con el DDNS de Mikrotik.
# Si está levantado, omite esta condifión "IF" y pasa a la segunda.
# Si está caído ejecuta los siguientes comandos para conmutar al DDNS No-IP.
:if ([/ping $DDNSMK interval=$TIMEOUT count=$COUNT]<$LESSTHAN) do={
log info "IKEv2: Peer & Identity changed to <$DDNSNOIP>";
/ip ipsec peer disable 0
:delay 1s
/ip ipsec identity disable 0
:delay 2s
/ip ipsec identity enable 1
:delay 1s
/ip ipsec peer enable 1
:delay 5s
log info "IKEv2: Reset Policies...";
# A veces al conmutar de Peer e Identity, algunos Policies quedan en "no phase2"
# Reseteamos sólo los policies activos
foreach i in=[/ip ipsec policy find ph2-state!=established !template !invalid] do={
ip ipsec policy disable number=$i
delay 10
ip ipsec policy enable number=$i
}
# START Send Telegram Module
:local MessageText "\E2\9A\A0 <b>Apartamento:</b> IKEv2 tunnel is Down%0APeer & Identity changed to:%0A$DDNSNOIP";
:local SendTelegramMessage [:parse [/system script get MyTGBotSendMessage source]];
$SendTelegramMessage MessageText=$MessageText;
#END Send Telegram Module
}
# Segunda condición: comprueba si hay conectividad con el DDNS de No-IP.
# Si está levantado, omite esta condifión "IF".
# Si está caído ejecuta los siguientes comandos para conmutar al DDNS Mikrotik.
:if ([/ping $DDNSNOIP interval=$TIMEOUT count=$COUNT]<$LESSTHAN) do={
log info "IKEv2: Peer & Identity changed to <$DDNSMK>";
/ip ipsec peer disable 1
:delay 1s
/ip ipsec identity disable 1
:delay 2s
/ip ipsec identity enable 0
:delay 1s
/ip ipsec peer enable 0
:delay 5s
log info "IKEv2: Reset Policies...";
# A veces al conmutar de Peer e Identity, algunos Policies quedan en "no phase2"
# Reseteamos sólo los policies activos
foreach i in=[/ip ipsec policy find ph2-state!=established !template !invalid] do={
ip ipsec policy disable number=$i
delay 10
ip ipsec policy enable number=$i
}
# START Send Telegram Module
:local MessageText "\E2\9A\A0 <b>Apartamento:</b> IKEv2 tunnel is Down%0APeer & Identiy changed to:%0A$DDNSMK";
:local SendTelegramMessage [:parse [/system script get MyTGBotSendMessage source]];
$SendTelegramMessage MessageText=$MessageText;
#END Send Telegram Module
}
log info "IKEv2: Ready!";
} else {
:log warning "IKEv2: tunnel to $LOCATION is OK. Nothing to do";
/ip ipsec active-peers print
# START Send Telegram Module
:local MessageText "\E2\9C\85 <b>Apartamento:</b> IKEv2 tunnel is UP%0AActive Peer:%0A$PEER";
:local SendTelegramMessage [:parse [/system script get MyTGBotSendMessage source]];
$SendTelegramMessage MessageText=$MessageText;
#END Send Telegram Module
}
}
Y eso es todo, espero que esta aportación le ayude a alguien si se encuentra en la misma situación, o simplemente quieres asegurar que el DDNS de Mikrotik no nos vuelve a dejar unos días sin acceso a nuestros "chacharros". No todo el mundo puede permitirse tener dos operadoras en casa/oficina o bien pagarse una IP fija.
S@lu2.