Wireguard: Comprobación de la IP de los compañeros

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 [email protected] 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 [email protected] 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!

10 pensamientos sobre "Wireguard: Peer-IP-Check"

    1. 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.

  1. 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.

  2. 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.

  3. 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).

    1. 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 😉

  4. 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

    1. 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

  5. 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

Deje un comentario

Su dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

es_ESEspañol
Ir arriba