WireGuard en Linux: verificar el túnel, las rutas y el DNS

Un cliente de WireGuard puede mostrar una interfaz wg0 activa mientras que sus paquetes continúan saliendo por la conexión habitual. Este caso ocurre a menudo después de importar un archivo de configuración en un sistema Debian o Ubuntu.

Antes de modificar el cliente, verifique la interfaz, el intercambio con el par y la ruta realmente elegida. Este control indica si el túnel transporta todo el tráfico o solo una red interna.

Distinguir un túnel ya activo de un cliente para importar

Mantenga una consola local o una segunda sesión SSH abierta si el archivo de WireGuard contiene una ruta por defecto. Una línea AllowedIPs = 0.0.0.0/0 puede hacer que el tráfico IPv4 pase por el túnel cuando ejecute wg-quick. Con ::/0, el mismo principio se aplica a IPv6.

Comience por ver si wg0 ya existe. Si la interfaz está presente, no reemplace su archivo y no vuelva a ejecutar wg-quick up. Vaya directamente a los comandos wg show y ip route get más abajo.

ip link show wg0
sudo wg show wg0

Si wg0 está ausente, verifique el nombre de la interfaz y los permisos del archivo proporcionado por su administrador o proveedor. Nunca copie una clave privada en un ticket, un repositorio Git o una captura de pantalla.

if sudo test -e /etc/wireguard/wg0.conf; then
  sudo cp -a /etc/wireguard/wg0.conf /etc/wireguard/wg0.conf.bak && sudo install -m 600 /ruta/client.conf /etc/wireguard/wg0.conf
else
  sudo install -m 600 /ruta/client.conf /etc/wireguard/wg0.conf
fi
sudo grep -E '^(Address|DNS|Endpoint|AllowedIPs)' /etc/wireguard/wg0.conf

El comando grep vuelve a leer los parámetros de red sin mostrar las claves. Verifique especialmente AllowedIPs. Un rango como 10.44.0.0/24 normalmente se dirige a la red remota. Una ruta 0.0.0.0/0 requiere un control más cuidadoso si está conectado al servidor por SSH.

Si el archivo debe reemplazar una configuración existente, mantenga el antiguo bajo un nombre fuera de /etc/wireguard/ o en su copia de seguridad administrativa. Yo elegiría probar primero desde la consola de una VM o una estación, en lugar de cambiar la ruta por defecto de un servidor remoto sin acceso de respaldo.

Activar WireGuard y leer el intercambio con el par

Si wg0 estaba ausente, active ahora la interfaz con wg-quick y mantenga su consola o su segunda sesión abierta hasta el final de los controles. Una dirección asignada a wg0 no confirma que el par remoto responda.

sudo wg-quick up wg0
ip -brief address show wg0
sudo wg show wg0

En la salida de wg show wg0, observe latest handshake y los contadores transfer. Una marca de tiempo reciente después de una consulta a la red remota y bytes recibidos indican que el par responde. La ausencia de un handshake sugiere un problema con el endpoint, el puerto UDP, el firewall o una clave que no coincide con el par esperado. La documentación WireGuard Quick Start describe los comandos wg y wg-quick utilizados aquí.

Para seguir el intercambio durante una prueba, puede volver a ejecutar el siguiente comando. Este evita modificar la configuración durante el diagnóstico.

watch -n 2 'sudo wg show wg0 latest-handshakes transfer'

Un ping puede ayudar si el servidor remoto permite ICMP, pero su ausencia de respuesta no es suficiente para condenar el túnel. Preferiblemente, realice una consulta a un servicio que su configuración se supone que debe hacer accesible, como un DNS interno o una aplicación administrativa.

Verificar la ruta elegida antes de concluir

Utilice ip route get para conocer el dispositivo que Linux elegiría para enviar un paquete a la meta. El comando no envía tráfico alguno.

ip route get 10.44.0.10
ip route get 1.1.1.1

Para un recurso interno, la primera salida debe mencionar dev wg0 si 10.44.0.10 pertenece a las redes declaradas en AllowedIPs. La segunda indica si la salida a Internet también pasa por wg0 o mantiene la interfaz habitual. Reemplace estas direcciones de documentación por una meta realmente prevista en su red.

Si el VPN proporciona un resolutor interno, pruébelo directamente solo si su dirección está presente en la documentación de su túnel y si Linux elige correctamente wg0 para alcanzarla. Instale dnsutils en Debian o Ubuntu si el comando dig está ausente:

ip route get 10.44.0.53
sudo apt install dnsutils
dig @10.44.0.53 intranet.ejemplo.lan
sudo wg show wg0 latest-handshakes transfer

El primer comando debe indicar dev wg0. La consulta DNS debe luego retornar una respuesta esperada y hacer avanzar el tráfico recibido o enviado. Si la ruta utiliza wg0 pero el handshake sigue ausente, el cliente está enviando correctamente hacia la interfaz local sin poder alcanzar al par remoto.

Para detener la prueba y restaurar las rutas agregadas por wg-quick, utilice sudo wg-quick down wg0. Este comando no repara una ruta configurada en otro lugar en NetworkManager o systemd-networkd. Solo retira la interfaz y los elementos que wg-quick ha instalado para este túnel.

Un túnel WireGuard válido se reconoce con tres pruebas: una interfaz presente, un handshake reciente y una ruta que apunta a wg0 para la meta esperada. Los artículos sobre ip addr, la ruta IP y dig detallan estos controles por separado cuando el problema va más allá del solo túnel.