Cuando un cliente de acceso remoto debe actuar como puerta de enlace de sucursal
Reenviar una subred de sucursal mediante un cliente de acceso remoto es un contrato de enrutamiento. Confirme que el producto admite ese rol y después asuma el direccionamiento y la recuperación.
Un portátil conectado a una VPN puede llegar a la sede central. La impresora y el servidor de archivos del mismo escritorio no pueden, porque nada reenvía sus paquetes a ese túnel ni devuelve las respuestas. Convertir el cliente en una puerta de enlace de sucursal es una decisión de enrutamiento y de propiedad antes que una decisión de configuración. El nombre del protocolo en la caja no responde si ese rol está admitido.
Lo que la etiqueta del protocolo no le dice
OpenVPN documenta un diseño de sitio a sitio en el que un conector reenvía toda una subred, y Access Server lo implementa con un rol de puerta de enlace y enrutamiento explícito. Otro producto comercializado como VPN SSL puede ofrecer solo funciones de usuario remoto, sin ninguna forma admitida de anunciar una red detrás del cliente. La versión también importa, porque una función presente en una edición no es una promesa sobre otra. Lea la implementación que realmente ejecuta y trate una receta escrita para otro producto como una pista, no como un diseño.
La pregunta que hay que resolver primero es si el propietario de la VPN admite siquiera el rol de reenvío. Si no, ningún enrutamiento del lado del cliente lo vuelve admitido.
El contrato tiene dos lados: sucursal y sede central
En el lado de la sucursal, un solo host se encarga del reenvío, el filtrado y la recuperación. Necesita una ruta deliberada desde cada dispositivo de la sucursal, y la conexión VPN exterior debe seguir siendo alcanzable a través de la red subyacente incluso mientras el túnel está caído. En el lado de la sede, alguien debe definir la subred de la sucursal, aceptar la identidad de la puerta de enlace y permitir recursos concretos. Ninguna mitad funciona sola.
La ruta de vuelta es la parte que se omite. Una dirección de túnel para el cliente no anuncia la subred que hay detrás, así que los enrutadores de la sede necesitan una ruta que apunte a la puerta de enlace VPN para ese prefijo.
En un diseño enrutado, el concentrador reenvía los paquetes del prefijo de la sucursal y el enrutamiento de la LAN superior sabe devolver las respuestas. En un diseño traducido, la fuente que ve la sede se reescribe, lo que puede eliminar la necesidad de una ruta de vuelta mientras oculta qué máquina de la sucursal envió el tráfico. Ese compromiso pertenece al documento de diseño, porque los registros de aplicaciones y las reglas de acceso pierden la identidad por dispositivo en cuanto entra en juego la traducción.
Enrutado o traducido: elija la ruta de vuelta a conciencia
Elija enrutado cuando importen la identidad por dispositivo y la política por host y pueda mantener la ruta de vuelta en cada enrutador relevante.
Elija traducido cuando no pueda añadir rutas pero acepte que la sede vea una sola dirección de origen. Existen diseños mixtos y son más difíciles de razonar, así que anote qué prefijos van enrutados y cuáles traducidos. Después verifique la elección con una captura en ambos extremos en lugar de confiar en el estado del túnel.
Una comprobación útil es asimétrica: solicite un recurso desde un dispositivo de la sucursal y luego confirme que la respuesta sale de la sede hacia el prefijo de la sucursal. traceroute -n 10.60.4.20 desde un host de la sede muestra si esa ruta pasa por la puerta de enlace VPN.
Opérelo como infraestructura, no como un inicio de sesión
Decida cómo arranca, se autentica, se actualiza y se recupera la puerta de enlace sin nadie conectado. La renovación de credenciales, los avisos multifactor, el comportamiento en reposo y quién responde cuando la sucursal pierde el acceso se convierten en cuestiones operativas. Varias personas que comparten una ruta de red no deben heredar los privilegios personales del usuario de la puerta de enlace, así que la autorización de recursos, el alcance del registro y la política de fallo necesitan un propietario con nombre. Compartir una cuenta para evitar el alta de cada dispositivo no es un diseño.
Compare la solución con una puerta de enlace de sitio admitida bajo los mismos requisitos antes de comprometerse. Reutilizar un escritorio viejo no elimina el mantenimiento ni la recuperación, y el precio de segunda mano no describe el coste operativo.
Valide las aplicaciones de sucursal previstas, su tráfico de vuelta y un destino denegado bajo un plan aprobado. El éxito se parece a un servicio de red propio con una identidad de sucursal con nombre y una política explícita, no a una ventana de cliente que dice Conectado.