Clientes descendentes detrás de una VPN superior: ¿ruta o NAT?

Una puerta de enlace ejecuta WireGuard para tus propios dispositivos y un cliente OpenVPN hacia la red de otra persona. El reenvío entre las dos interfaces internas funciona, y es fácil concluir que la subred descendente ya forma parte del servicio superior. No lo es. Una ruta que el cliente extrae le dice a tu puerta de enlace dónde enviar las peticiones; no dice nada sobre cómo la red remota devuelve el tráfico a dispositivos de los que nunca ha oído hablar. Elige un modelo de retorno que el servicio superior admita de verdad antes de añadir una sola regla.

Decide el modelo de retorno antes de tocar el enrutamiento

En este recorrido, los clientes descendentes usan 10.90.0.0/24, la dirección del túnel superior asignada a la puerta de enlace es 10.80.0.6, y el recurso remoto aprobado es 172.20.0.30. Dos modelos encajan en esa forma: conservar el origen descendente y lograr que el lado remoto lo enrute, o traducir el origen a la dirección del túnel de la propia puerta de enlace. Todo lo posterior a esta decisión es mecánico, y la decisión en sí necesita al propietario del servicio. Una de las filas de arriba es un acuerdo de enrutamiento con el lado remoto; la otra es un cambio de política local que puedes hacer por tu cuenta. Confundir las dos es lo que convierte un cambio de diez minutos en una negociación.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

Elige una fila y comprométete con ella. Las filas son alternativas, no pasos, y mezclarlas produce un diseño que nadie puede explicar en la revisión.

Conservación del origen con enrutamiento

El lado remoto recibe una petición de una dirección descendente, así que necesita una ruta admitida y la propiedad del peer para esa subred, además de autorización para aceptarla. Son ajustes remotos, y ninguna ruta local de Linux los crea. Pídelos de forma explícita y por escrito, con el prefijo y el peer del túnel que la transportará, y espera que la respuesta dependa de si el servicio admite o no arreglos de sitio a sitio.

Si la respuesta es sí, la configuración local es pequeña: reenvío activado, los allowed-ips del peer de WireGuard que cubren el rango descendente, y una política de cortafuegos que permite el cruce en ambos sentidos.

Traducción de origen deliberada

Si el servicio solo devuelve el tráfico a la dirección del cliente conectado, traduce el origen a esa dirección a la salida y conserva el estado de conntrack que la invierte para las respuestas. Limita la regla a los orígenes descendentes previstos, los destinos remotos previstos y la interfaz superior. Una regla que traduce todo lo que sale de cada interfaz es una política mucho mayor que este requisito, y te sorprenderá más adelante.

IPv6 necesita su propio diseño; copiar una línea de masquerade de IPv4 no es una arquitectura. Prueba la ruta traducida con una conexión nueva en lugar de una en caché.

La ruta de datos local todavía tiene que funcionar

La traducción no elimina el trabajo local: la puerta de enlace sigue necesitando una ruta para los destinos descendentes, la propiedad correcta del origen del peer de WireGuard, el reenvío activado y una política de cortafuegos estrecha entre interfaces. Una petición generada en la propia puerta de enlace no ejerce ninguno de esos permisos, y por eso las pruebas locales en la puerta de enlace pasan y los dispositivos descendentes siguen fallando.

Prueba desde un dispositivo descendente real, no desde la puerta de enlace. La dirección de origen es todo el sentido del ejercicio.

Un origen significa una identidad de sesión

El servicio remoto ve la sesión autenticada de la puerta de enlace y su dirección traducida, no una autenticación independiente para cada dispositivo descendente. Mantén explícitos los permisos por dispositivo y las identidades de aplicación, y confirma con el propietario del servicio que una puerta de enlace que actúa por varios dispositivos está permitida. La traducción no es una forma de saltarse un requisito de alta por dispositivo; si el servicio exige que cada dispositivo se dé de alta, usa ese modelo o negocia un arreglo de sitio a sitio.

Escribe esa confirmación en el runbook junto a la regla, porque el siguiente revisor preguntará si el diseño fue aprobado o solo conveniente.

Define el estado desconectado y luego prueba tres peticiones

Decide qué ocurre cuando cae el túnel superior. El tráfico remoto autorizado no debería seguir en silencio un respaldo WAN ordinario donde eso está prohibido, así que la política de cortafuegos que permite el cruce también debe fallar cerrada. Después prueba tres casos desde un dispositivo descendente real: una petición permitida que funciona, una petición no permitida que falla, y un fallo superior que detiene la permitida.

Registra la reversión en una línea por regla, para que el cambio pueda deshacerse sin reconstruir la intención.