El handshake de WireGuard funciona, el servicio no

El handshake se completa, el cliente muestra un contador de transferencia reciente y, aun así, una petición a un servicio del mismo servidor falla. Esa combinación desconcierta porque el túnel funciona de forma demostrable. Lo que no se ha demostrado es la entrega local: el paquete llegó al host, y el host todavía tiene que aceptarlo en el socket correcto y pasarlo a un proceso con permiso para responder. Recorra esos tres puntos de control en orden.

Deténgase en el primero que no se cumpla y no añada reglas para los demás.

El handshake solo demuestra el túnel

El handshake de WireGuard establece claves entre pares y autoriza el tráfico para los rangos que cada par enumeró. No dice nada sobre qué procesos escuchan en el servidor ni sobre si el cortafuegos del host acepta paquetes dirigidos a una de sus propias direcciones.

Esa última distinción es la que más se pasa por alto: el tráfico hacia el propio host es entrada local, mientras que el tráfico que atraviesa el host hacia otro destino es reenvío. Los manejan cadenas de cortafuegos distintas y ajustes distintos. Comprobar la cadena equivocada hace perder una tarde y devuelve contadores que parecen inocentes.

Lea el listener y la ruta

En el cliente, confirme que la dirección del túnel del servidor se enruta hacia el túnel. En el servidor, confirme que existe un socket en la dirección que usa el cliente y que el proceso que hay detrás es el que pretendía.

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

Un listener en 127.0.0.1 nunca responderá a una petición dirigida a 10.66.0.1, haga lo que haga el cortafuegos. Un listener en la dirección comodín sí lo hará, salvo que una regla lo bloquee. La lista de sockets resuelve, por tanto, la mitad de los casos antes de examinar ninguna regla. El puerto y la dirección juntos deciden si una petición puede llegar.

Compare la dirección que usa el cliente con la dirección que el servidor posee realmente en la interfaz del túnel. Una configuración obsoleta en cualquiera de los dos lados produce una petición enrutada correctamente hacia un par que no tiene esa dirección.

Aplique reglas para la entrada local, no para el reenvío

Si el paquete llega y el socket existe, la frontera restante es la política de entrada. Una regla que permite el reenvío no permite la entrega local, y una regla limitada a una interfaz puede no coincidir con el nombre de la interfaz del túnel que espera.

Pruebe con un único puerto permitido hacia el servicio previsto en lugar de abrir el host. Luego compruebe la autorización propia de la aplicación: una lista de permitidos, un requisito de cuenta o un enlace a un nombre de host concreto pueden rechazar una petición que la red entregó correctamente.

Mantenga las comprobaciones de certificado. Una identidad de certificado inesperada es información sobre qué host respondió, no un obstáculo que haya que saltarse. Hacer clic a través de ella oculta la única pista que identifica el servicio equivocado.

Separe los fallos de nombre, tamaño e identidad

Un servicio que funciona por dirección pero falla por nombre es un problema de DNS, y la corrección pertenece a la configuración del resolutor que se envía al cliente, no al cortafuegos. Un servicio que responde a peticiones pequeñas pero se atasca en respuestas mayores apunta al tamaño de paquete y a la MTU, que es una investigación completamente distinta.

Un error HTTPS que nombra el host equivocado suele significar que la petición llegó a otro servicio, a menudo porque un proxy u otro listener posee ese puerto. Lea el sujeto del certificado y compárelo con el host al que quería llegar. Esa comparación no cuesta nada y a menudo termina la investigación.

Anote qué punto de control falló: socket, regla de entrada o política de la aplicación. Esa sola línea distingue un fallo de red de una decisión de autorización. También evita que la siguiente persona abra puertos que nunca fueron el problema.