Cómo construir una prueba de WireGuard con dos pares que demuestra una sola ruta

Una prueba de WireGuard que lleva una ruta por defecto, un prefijo LAN, DNS y una excepción de cortafuegos no puede decirte cuál de ellas se rompió. Redúcela a dos pares, un par de direcciones y un servicio permitido, y el fallo no tendrá dónde esconderse. La base aburrida es el diagnóstico. Constrúyela primero; tarda quince minutos y te ahorra la tarde que de otro modo pasarías adivinando.

Lo que demuestra la base es más estrecho de lo que la mayoría espera. Demuestra que dos identidades coinciden, que UDP llega al puerto de escucha y que un destino permitido transporta una petición. El reenvío, el NAT, las rutas LAN y el DNS son funciones separadas que se añaden después, una a la vez.

Claves, direcciones y el único endpoint

Genera un par de claves en cada sistema y mueve entre ellos solo las mitades públicas. wg genkey | tee privatekey | wg pubkey > publickey es la orden documentada de una sola línea, y deja la clave privada en un archivo que luego puedes proteger. Elige direcciones de túnel de un rango que no aparezca en ninguna otra configuración tuya, como 10.99.0.1/24 y 10.99.0.2/24. Anota qué dirección pertenece a qué máquina, porque cada comprobación posterior depende de esa correspondencia.

Las claves privadas nunca viajan. Si una prueba necesita una copiada al otro lado, la prueba ya ha salido mal. Cuando los dos sistemas están detrás de NAT, al menos uno necesita un puerto UDP alcanzable mientras el otro lleva un Endpoint que apunta a él, y la dirección pública y el puerto pertenecen a tus notas, no a tus suposiciones sobre el 51820.

Un reenvío de puerto que asigna un puerto externo distinto funciona bien siempre que el Endpoint coincida con él. Las discrepancias aquí producen silencio en lugar de errores, y por eso vale la pena comprobarlas sobre el papel antes de depurar sobre el cable.

Los campos que pertenecen a wg y los que no

El conjunto de campos básicos es pequeño: PrivateKey y ListenPort bajo Interface, PublicKey, AllowedIPs y Endpoint bajo Peer. Address y DNS pertenecen a wg-quick y no a wg mismo, y esa distinción muerde en el momento en que la misma configuración pasa a otra herramienta.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs lleva dos tareas a la vez. Selecciona qué destinos entran en el túnel, y autoriza al par a usar esas direcciones de origen a su llegada. Por eso la entrada espejo del otro lado tiene que nombrar exactamente la dirección de tu túnel; un /32 para el par equivocado se lee como un problema de enrutamiento y se comporta como uno de autorización. El inicio rápido de WireGuard muestra la misma forma de dos pares con la redacción canónica si quieres comparar nombres de campos.

Leer el handshake en lugar del icono

Levanta la interfaz a través de lo que la posea y luego lee el estado en lugar de una luz de estado. wg show imprime el último handshake por par junto con los contadores de bytes, y un handshake en los últimos minutos significa que las claves, el endpoint y la ruta UDP funcionan todos. Un contador que solo sube en una dirección es su propia respuesta, y no es el mismo fallo que un handshake que nunca ocurre.

Los dos fallos implican investigaciones distintas. La ausencia total de handshake apunta a una discrepancia de claves, un Endpoint equivocado, UDP bloqueado o un cortafuegos que descarta el handshake mismo. Un handshake que tiene éxito mientras los datos no van a ningún lado apunta a AllowedIPs, a un servicio que no escucha en la dirección del túnel o a un cortafuegos del anfitrión que acepta el puerto para la LAN pero no para la interfaz del túnel. Son mitades distintas del sistema, y la base las separa antes de que empieces a cambiar reglas.

Demostrar un servicio permitido y luego lo contrario

Haz una petición a la dirección de túnel del otro par en un servicio que deba responder, y elige algo mejor que ping. Una respuesta ICMP ausente puede ser filtrado del anfitrión y no una falla del túnel, así que un ping silencioso no demuestra ninguna dirección. Una conexión TCP a un puerto que sabes abierto, o una petición que devuelve datos, te da una respuesta que puedes interpretar.

Ejecuta la dirección inversa como una prueba separada con su propio resultado, porque las dos direcciones tienen entradas separadas de cortafuegos y AllowedIPs y pueden fallar de forma independiente. Si el handshake funciona y la petición no, el problema está en la ruta de datos y no en el túnel: AllowedIPs, el servicio que escucha o un cortafuegos del anfitrión. Arregla eso antes de añadir reenvío, NAT o DNS, o pasarás la tarde depurando una función que nunca tuvo la culpa.

Mantener la base como referencia

Guarda la topología que funciona y la fuente del perfil en un lugar desde el que puedas restaurar, y mantenlos fuera de cualquier directorio que se sincronice con un servicio público. Luego añade una función a la vez, repitiendo la petición original después de cada una: reenvío, NAT, una ruta LAN y solo después DNS. Cada adición que rompe la prueba ahora es identificable, porque nada más se movió.

Una base que solo pone un icono verde no te ha dicho nada sobre qué adición causó el siguiente fallo. Mantén la única ruta permitida funcionando como referencia, y cada cambio posterior se mide contra ella.