¿NAT en el servidor VPN o en el router? Ambas opciones pueden funcionar

Marcar una conexión como ruta predeterminada en un portátil es el paso que todo el mundo recuerda, y es justo el que no cambia nada en la puerta de enlace. Ahora el cliente envía las solicitudes de Internet al túnel; si salen del edificio depende del reenvío, de un punto de traducción y de una ruta de vuelta que llegue a la dirección privada del cliente. Dos disposiciones pueden aportar las tres cosas, colocan el trabajo en lugares distintos y ambas fallan de la misma manera silenciosa cuando nadie se hace cargo de la dirección de la respuesta. Elegir entre ellas es una cuestión de quién debe ver el grupo de clientes.

El mito: una ruta de cliente construye la salida

El tunneling forzado es una política del lado del cliente: decide que el tráfico va al adaptador VPN en lugar del físico. La documentación de enrutamiento VPN de Microsoft describe ese comportamiento de separación y de forzado, y es una afirmación sobre la tabla de rutas del cliente, no sobre las reglas de reenvío del servidor. Desde el punto de vista del cliente, el túnel es donde vive Internet; desde el punto de vista de la puerta de enlace, un paquete llegó desde una dirección que nadie aguas arriba ha oído nunca. Ninguno de los dos lados está mal configurado por sí solo, y por eso el fallo parece un servidor roto para la persona que está en el portátil.

Ese desajuste es todo el problema que resuelve el resto de este artículo. Algo tiene que hacer que la dirección privada del cliente sea retornable, y la elección es dónde.

Dibuje primero el camino de vuelta

Escriba el camino con direcciones reales antes de tocar ningún ajuste, y marque en él los dos puntos de traducción candidatos. Este laboratorio usa un grupo VPN de 10.70.0.0/24 con un cliente en 10.70.0.37, una dirección LAN del servidor de 172.16.40.10, un router en 172.16.40.1 y una salida pública de 203.0.113.40.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

El servidor que ya navega por Internet solo demuestra su propio camino. Un paquete reenviado en nombre de un cliente es una decisión distinta, tomada por la política de reenvío en la misma máquina, y es la que suele faltar. Marcar los tres puntos de decisión en el diagrama mantiene la conversación sobre uno de ellos a la vez.

Opción A: traducir en el servidor VPN

Aquí el servidor traduce el origen del cliente a su propia dirección LAN antes de entregar el paquete al router, y el router aplica su traducción habitual a la salida. En la respuesta, la asignación del router restaura la dirección del servidor y la asignación del servidor restaura la dirección del cliente. Dos traducciones con estado en serie son normales y viables, siempre que ambas queden registradas; el router nunca necesita una ruta al grupo, que es el atractivo de esta disposición.

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

Use estas lecturas para ver qué tiene ya el servidor en lugar de suponer que hay un NAT. Una regla de masquerade de Linux copiada de un blog no es una configuración de Windows, y un permiso en el cortafuegos del host para el escucha VPN no es la misma política que el permiso para reenviar la solicitud de un cliente más allá. Confirme el papel de reenvío del servidor desde su propia superficie de administración, y luego mire la traducción por separado, porque las dos cosas suelen habilitarse desde partes distintas de un despliegue.

Opción B: llevar el grupo al router

En la segunda disposición el servidor reenvía la dirección de origen real del cliente, y el router la traduce. Eso mantiene el grupo de clientes visible en el borde, lo que ayuda si el router es donde viven la política de tráfico, el registro o la inspección. También significa que el router necesita una ruta de vuelta para 10.70.0.0/24 que apunte a 172.16.40.10, además de una política de Internet que incluya realmente ese prefijo; una regla escrita para la subred LAN no se extiende en silencio al grupo.

Elija esta opción cuando el dispositivo de borde sea el responsable previsto de la política y pueda aceptar otro prefijo en sus tablas de enrutamiento y traducción. Elija la traducción del lado del servidor cuando el grupo deba quedar invisible aguas arriba y el router no lo administre el mismo equipo. Ninguna de las dos opciones se deduce de ninguna casilla del cliente, y ninguna es más segura en general; colocan la visibilidad y el mantenimiento en lugares distintos.

Haga explícitos el DNS, el IPv6 y la aceptación

La traducción de direcciones no arregla la resolución de nombres. El cliente puede usar un resolutor entregado con el perfil VPN, un resolutor privado para espacios de nombres concretos o uno público aprobado, y un resolutor inalcanzable bajo esa política seguirá fallando después de que el enrutamiento funcione. Pruebe un nombre y una dirección por separado para que los dos fallos nunca se fundan en un solo informe.

El IPv6 necesita su propio párrafo en el diseño. Una traducción IPv4 que funcione no dice nada sobre si los clientes IPv6 tienen ruta, una fuente pública válida o una política que los bloquee cuando el túnel caiga. Dejar eso sin decir significa que la mitad de los clientes evita la puerta de enlace en silencio mientras la otra mitad funciona.

Para la aceptación, siga una solicitud de cliente permitida y su respuesta por las dos fronteras, y anote qué dirección debería ver cada frontera en ese momento. Ese registro es lo que convierte el siguiente cambio de grupo en una edición de cinco minutos en lugar de una discusión sobre quién posee la ruta de vuelta que falta. Guarde el registro con el perfil del cliente en lugar de en un tique, ya que el perfil es lo que el siguiente ingeniero encontrará primero.