Cualquier persona que utilice Wireguard con compañeros cuya dirección IP cambie (por ejemplo, porque están en una conexión DSL privada) debe comprobar regularmente la dirección IP.
El propio Wireguard sólo hace la resolución DNS cuando la interfaz se inicia para obtener la dirección IP actual del par. Sin embargo, si, por ejemplo, la dirección del servidor cambia, la conexión terminará por fallar.
Afortunadamente, esto puede ser interceptado con un pequeño guión, que se ejecuta, por ejemplo, cada 10 minutos. Un enfoque es el Guión en la documentación de Ubuntu para Wireguardque no funcionó en mi cliente de Debian (y también parecía un poco complicado).
#!/bin/bash
# Comprobar el estado de la interfaz
# wg0-cliente: Nombre de la interfaz a comprobar
# mypeer.dyndns.net: el nombre del par cuya IP debe ser comprobada
cip=$(wg show wg0-client endpoints | grep -E -o "([0-9]{1,3}[\.]){3}[0-9]{1,3}")
eco "$cip"
digIP=$(dig +short mypeer.dyndns.net) # La dirección del par debe ser ajustada
eco "$digIP"
si [ "$digIP" != "$cip" ]
entonces
eco "Los datos son diferentes"
/usr/sbin/service wg-quick@wg0-client restart
más
eco "Los datos son iguales"
1TP3Nada que hacer
fi
Los elementos principales del guión anterior: en la línea 6, utilizando las herramientas wireguard-tools y grep, se determina la dirección IP actual utilizada por la interfaz. En la línea 8 comprueba qué dirección IP tiene actualmente el par. Si estos dos valores difieren, se reinicia la interfaz wireguard en la línea 13 - entonces la dirección IP también se resuelve de nuevo y la conexión se establece de nuevo.
Puede que sea necesario ajustar el reinicio de la interfaz Wireguard en la línea 13, dependiendo de cómo se llame realmente la interfaz en su configuración.
Por supuesto, hay otros enfoques para la resolución de la IP, pero para mi configuración esta es una forma muy simple. Una desventaja: si hay varios pares, este enfoque no funciona tan fácilmente - entonces tendrías que determinar primero el par correcto a través de regex, y luego leer los datos correspondientes allí.
Este guión es necesario para mantener la conexión en mi Configuración de réplicas de FreeNASque ahora trabaja con Wireguard.
Incorporación: Comprobación de IP con múltiples pares
Si ha introducido varios pares en la configuración de su wireguard (por ejemplo, una conexión estática y una vez la marcación a través de un smartphone para una VPN), es posible que sólo quiera realizar la comprobación de IP descrita aquí para un solo par. La forma más fácil es comprobar adicionalmente si hay un par específico. A partir de la siguiente configuración de pares (cuyos valores no corresponden a un par real):
[Peer] PublicKey = mhzqblUOAzxVhOypkidxLnxp5rfYD7uRtvyj0sOi4GE= AllowedIPs = 0.0.0.0/0, ::/0 Punto final = mypeer.dyndns.net:51820
La primera línea en el guión de control debe ser ajustada en consecuencia:
cip=$(wg show wg0-client endpoints | grep -E "mhzqblUO" | grep -E -o "([0-9]{1,3}[\.]){3}[0-9]{1,3}")
Completamente se parece a esto:
#!/bin/bash
# Comprobar el estado de la interfaz
# wg0-cliente: Nombre de la interfaz a comprobar
# mypeer.dyndns.net: el nombre del par cuya IP debe ser comprobada
cip=$(wg show wg0-client endpoints | grep -E "mhzqblUO" | grep -E -o "([0-9]{1,3}[\.]){3}[0-9]{1,3}")
eco "$cip"
digIP=$(dig +short mypeer.dyndns.net) # La dirección del par debe ser ajustada
eco "$digIP"
si [ "$digIP" != "$cip" ]
entonces
eco "Los datos son diferentes"
/usr/sbin/service wg-quick@wg0-client restart
más
eco "Los datos son iguales"
1TP3Nada que hacer
fi
Es importante señalar que el guión de comprobación no funcionará en la variante con determinados pares si no se sustituye el valor correspondiente con el de su configuración. En mi configuración lo ejecuto cada 5 minutos, hasta ahora ha cumplido su propósito. Como sólo es una comparación pura de la dirección IP, también debería funcionar en una configuración IPv6 - pero como sigo usando una conexión de telecomunicaciones clásica con IPv4, no traté este tema en detalle. Si alguno de los lectores tiene alguna experiencia con esto (también con respecto a DynDNS e IPv6 en el Fritzbox) ¡no dude en dejar algo en los comentarios!
Español 
Deutsch 
English 
Français
¡Gracias por la contribución! También hay un guión preparado en el paquete de herramientas de vigilancia: https://wiki.archlinux.org/index.php/WireGuard#Endpoint_with_changing_IP
Para este sólo hay que cambiar el punto final (línea 40): ENPOINT="xyz.de:Port"; continuar ;;
El guión también está disponible para Debian, está entonces en
/usr/share/doc/wireguard-tools/examples/reresolve-dns/reresolve-dns.sh
(el camino es ligeramente diferente que bajo el Arco)
¿Tengo que mirar más de cerca otra vez? Cuando preparé esto hubo algún problema con el guión, que yo recuerde.
Esto debería ser más fácil de resolver con la opción "PersistentKeepalive =".
Inicio la conexión desde la carretera (por ejemplo desde el iPhone) a una dirección DynDNS. Gracias a Keepalive se envía un paquete al otro lado cada 25 segundos. Se puede asumir que es muy poco probable que la dirección de ambos lados cambie al mismo tiempo. Así que siempre se llega al menos a un lado del túnel.
Si el par respectivo recibe el paquete desde una dirección IP externa diferente, pero el enrutamiento de la clave de cifrado coincide de otra manera (combinación coherente de dirección IP privada y clave pública), la asignación de la IP externa del par se actualiza y las respuestas posteriores llegan correctamente de nuevo.
Tendría que forzar los cambios de dirección y probarlos explícitamente para poder decirlo con seguridad, pero en el uso diario nunca he tenido problemas con túneles rotos o muertos con iPhone/iPad, Linux o macOS.
Esto funciona porque las direcciones IP se sincronizan cuando se establece la conexión. Un dispositivo móvil se inicializa más a menudo, por ejemplo, si la recepción era demasiado mala, etc.
Si trabajas con una configuración de dos conexiones DSL fijas, es muy posible que uno de los extremos cambie sin que se restablezca la conexión. Entonces la resolución de la dirección DynDNS ya no cabe y la conexión va a una IP equivocada. Para esto necesitas ajustar la resolución, ya sea como se ha publicado aquí o con el guión de Michael.
Con el iPhone, tampoco tengo que hacer eso, pero la réplica será en vano a más tardar el tercer día.
Es sólo que no es ahora mismo. La dirección DynDNS que has almacenado en wg0.conf se utiliza para la configuración inicial de la conexión. Sin embargo, mientras se establece una conexión, la asignación de peer a public-IP se actualiza constantemente en el servidor por medio de paquetes recién llegados (véase https://www.wireguard.com/#cryptokey-routingsección "Itinerancia incorporada"; véase https://www.wireguard.com/papers/wireguard.pdfSección 2.1). Wireguard se comporta como un mosh y debe ser muy robusto cuando se trata de cambiar las direcciones IP. Sin embargo, lo que es realmente importante es que el compañero cuya dirección pública ha cambiado siempre inicia una comunicación con prontitud para informar a los demás sobre el cambio. De hecho, el servidor no debería hacer esto muy a menudo.
Lo que acabo de aprender es que el "keep-alive" sólo se envía cuando un compañero ha recibido paquetes, pero en realidad no necesita responder. Se envía un paquete de respuesta Wireguard vacío antes de que el temporizador KeepAlive expire. Así que el par debe enviar algo regularmente para que el mecanismo funcione de forma fiable. Por lo tanto, por sí sola no es adecuada para mantener permanentemente actualizadas las tablas de direcciones de los compañeros. Así que me equivoqué. Así que también tienes razón sobre el iPhone. Aquí, las conexiones son ciertamente a menudo completamente reestablecidas, por lo que el problema de cambiar las IPs de los servidores no es tan notorio. Pero parece que el túnel siempre está ahí mientras haya una conexión a Internet.
Sin embargo, si su configuración DSL-NAT con IP de servidor cambiante asegura que un mensaje sea enviado regularmente desde las redes de ambos pares, por ejemplo mediante pings regulares en ambos lados cada minuto (¿trabajo cron en los dos FreeNAS?!), entonces la conexión VPN no debe nunca o sólo brevemente morir, porque la dirección IP actual será conocida en breve. Qué tan rápido, eso depende de la frecuencia de los pings.
De esta manera no tienes que quitar regularmente la interfaz de la red y cambiar el enrutamiento. Esto se siente un poco más elegante (mi opinión).
Otro problema es que en el caso más estúpido de una configuración con dos conexiones DSL un par intenta resolver la IP del otro mientras se realiza la reconexión automática (lo que algunos proveedores todavía hacen) - Wireguard se rinde aquí bastante rápido: https://lists.zx2c4.com/pipermail/wireguard/2019-February/003866.html
Una vez que ha salido, el reinicio de la interfaz es bastante fiable para conseguir una conexión de nuevo. En mi caso, los datos sólo se transfieren una vez por hora.
Pero esa es la belleza de esto: dependiendo del propósito concreto de la aplicación, diferentes caminos conducen a la meta 😉
Hola,
También tengo este escenario exacto.
He instalado la aplicación Android en mi teléfono. En el archivo de confesión de este par están las DynDns de mi FritzBox. El servidor de Wireguard se encuentra en casa en la red detrás de la FritzBox en una frambuesa. En ambos KeepAlive está registrado con la 25ª aplicación iniciada y todo funciona bien.
Hasta la desconexión y reconexión forzada por el proveedor de DSL. El túnel está caído, no hay conexión, nada.
Configuré la unidad de tiempo con el guión anterior reresolve-dns.sh - sin éxito.
Estoy un poco confundido.
Saludos
Harald
Puedo confirmar la observación de Harald de esta manera.
IMHO el cliente Android tendría que probar y reiniciar la conectividad con la nueva resolución de los pares del "servidor". Así que tendríamos que tener una aplicación para Android que implemente lo que dijimos aquí en Ubuntu / Debian.
¿O estoy completamente equivocado? En cualquier caso, me parece que no podemos lograr un cambio de comportamiento sin cambiar la aplicación Android.
Saludos
Markus
Hola Falk, gracias por el guión! La penúltima línea no puede ser correcta, supongo que se supone que debe decir "eco 'Nada que hacer'". ¿O me estoy perdiendo algo? Saludos Philipp
Es sólo un comentario en la línea equivocada - por supuesto, puede hacer eco de un texto adicional, pero no es necesario.
Hola Falk,
Estaba enfrentando el problema con el cambio de direcciones IP y he leído algunos consejos / scripts. Todavía no tengo mucha experiencia en el área de Linux y la mayoría de los consejos eran totalmente confusos. Pero pude usar tu script con dos pequeños cambios en la Raspberry con pivpn y wireguard. Así que sólo quería dar las gracias una vez por tomarse la molestia de crear este post.
Simplemente se queda muy corto durante este tiempo. Te has salvado con unas cuantas canas 😉 .
Muchas gracias por esta entrada - Matthias
Pls fixe para el uso de docker 😉
Puente de moda
No es necesario reiniciar, es posible cambiar la dirección del punto final con :
wg set wg0 endpoint :
reajustar.
Con:
PUB=$(wg | grep peer | awk '{print $2}')
puede determinarse. Si la dirección es una dirección IPv6, debe ir encerrada entre '[' y ']'.