El peer de WireGuard sale por la WAN equivocada: cinco comprobaciones en orden

Dos enlaces ascendentes, una puerta de enlace y un peer de WireGuard cuyo tráfico no deja de aparecer en la línea de respaldo. El handshake se mantiene sano todo el tiempo. Por eso el síntoma se lee fácilmente mal como una falla de WireGuard en lugar de una falla de enrutamiento.

Realice las comprobaciones siguientes en orden. Cada una tiene una condición de parada, y adelantarse suele producir una respuesta equivocada y segura.

Separe el handshake del flujo reenviado

El intercambio cifrado con el peer tiene una ruta de punto final hacia la dirección pública del servidor. El tráfico reenviado del cliente tiene otro destino y puede seleccionarse mediante marcas o reglas de política. Son dos decisiones de enrutamiento que comparten una interfaz. Tratar una como prueba de la otra es el primer error.

Deténgase en cuanto se sorprenda razonando a partir del handshake. Solo es prueba sobre la ruta al punto final.

Lea la regla de política, no la tabla predeterminada

Una tabla predeterminada muestra qué ocurre cuando ninguna regla de política coincide. En una puerta de enlace que enruta por origen, marca o destino, la regla decisiva vive en otro lugar. La tabla simple puede parecer del todo razonable mientras la elección real se toma por encima de ella.

ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2

Lea las reglas de política y las tablas a las que apuntan. Después confirme qué regla coincide con su flujo de prueba. Una regla que hace referencia a una interfaz que ya no transporta el enlace ascendente previsto es un hallazgo, no un detalle. La consulta de ruta del final muestra la respuesta mucho más rápido que leer una tabla y adivinar.

Compruebe la marca y la traducción juntas

El enrutamiento por política se basa en una marca de paquete establecida antes en la cadena. Si la regla de marcado no alcanza su tráfico, el flujo cae en la tabla principal y sale por el valor predeterminado que haya allí. Los paquetes reenviados suelen saltarse cadenas escritas para tráfico generado localmente.

nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1

La traducción debe concordar con el enlace ascendente que transporta el flujo. Una regla que traduce a la dirección primaria mientras el paquete sale por la línea de respaldo produce respuestas dirigidas a una interfaz que el flujo nunca usó. Compruebe la condición de interfaz de la propia regla de traducción. Una regla incondicional funciona hasta que se usa el segundo enlace ascendente, y entonces falla de una manera que parece intermitente.

Observe qué interfaz transporta la respuesta

Capture en ambos enlaces ascendentes mientras se ejecuta una solicitud. Anote qué interfaz transporta la solicitud y cuál la respuesta. Las rutas asimétricas son mucho más fáciles de ver que de predecir.

Si la respuesta llega por el enlace ascendente equivocado, el problema se ha trasladado de WireGuard al seguimiento de conexiones o a la traducción. Ningún cambio en la configuración del peer lo arreglará.

Cambie una sola cosa con un camino de vuelta

Mantenga acceso por consola o fuera de banda antes de editar reglas de política en una puerta de enlace. Haga un solo cambio, pruebe el mismo destino autorizado, luego vuelva a conectarse y confirme que el handshake sigue usando la ruta prevista al punto final. Añada una prueba numérica en la segunda familia de direcciones, porque una política solo para v4 deja el mismo error disponible.

Anote qué enlace ascendente usó cada flujo. Ese registro convierte el siguiente informe en una comprobación de dos minutos en lugar de una tarde entera. las notas de WireGuard sobre espacios de nombres y enrutamiento describen cómo separar deliberadamente la ruta al punto final del tráfico tunelizado, lo que suele ser más limpio que copiar un rodeo con ruta predeterminada.