Puerta de enlace VPN de Windows: tres tareas, tres responsables

Tres funciones se agrupan cada vez que alguien dice servidor VPN: terminar el túnel cifrado, mover paquetes entre redes y, de forma opcional, reescribir direcciones. En Windows viven en partes distintas de la pila, incluso cuando un solo equipo las hace todas. Cada una tiene sus propias entradas y su propia forma de fallar, y cada una puede entregarse a un producto distinto. Separarlas sobre el papel es la forma más barata de mantener comprensible un despliegue pequeño.

Un diseño legible nombra al responsable de cada flujo en lugar de describir el equipo como un rol.

Terminar, reenviar, traducir

RRAS se encarga del túnel en el caso nativo de Windows: autentica al usuario, asigna una dirección de un grupo y decide qué destinos están permitidos. Un producto VPN distinto puede poseer el receptor y el adaptador virtual, y dejar que Windows reenvíe los paquetes descifrados. La documentación de Remote Access de Microsoft separa los roles de VPN, sitio a sitio y enrutamiento, e instalar el rol de enrutamiento no crea una segunda identidad VPN. Añadir otra aplicación VPN tampoco entrega su adaptador a todas las funciones de puerta de enlace existentes.

La traducción es la tercera tarea y la más opcional. Va después del reenvío y cambia la dirección de origen que ve la red remota. Si la necesita depende de lo que la red de destino acepte como origen, no de que el equipo se llame puerta de enlace VPN.

Quién es dueño del adaptador y del grupo

Cuando varios productos comparten el host, cuatro cosas necesitan un único dueño cada una: los puertos de escucha, la vida del adaptador, el grupo de direcciones de clientes y las rutas. El adaptador es el incómodo, porque un servicio VPN puede crearlo de forma dinámica y destruirlo al desconectar. Tratar esa interfaz como una tarjeta de red con nombre permanente y escribir reglas contra su nombre funciona hasta la siguiente reconexión. Use el punto de integración soportado por el producto en lugar de codificar el nombre de una interfaz.

El grupo de direcciones es la segunda colisión. Dos productos que reparten rangos superpuestos producen un enrutamiento que parece correcto y no entrega nada. Mantenga los grupos en el mismo documento que las rutas, para que un cambio en uno sea visible frente al otro.

Conservar el origen o reescribirlo

Conservar la dirección de origen del cliente mantiene la visibilidad por usuario: los registros, las cuotas y las reglas del cortafuegos pueden distinguir a un usuario de otro. El precio es que la LAN de destino necesita una ruta de retorno hacia la puerta de enlace, y alguien tiene que mantenerla. Reescribir el origen con NAT elimina ese requisito y elimina la visibilidad con él. Elija a conciencia y anote qué información oculta la reescritura.

El acceso a la red privada, la salida a internet y las conexiones que terminan en la propia puerta de enlace son tres caminos distintos. No todos necesitan el mismo trato.

Describir el flujo en una frase

Una frase debería describir el diseño: qué clientes admite este servicio, qué recursos concede esa política de reenvío y cómo el camino de vuelta completa el flujo. Si la frase necesita una segunda capa de NAT para ser cierta, suele ser señal de que las piezas anteriores no estaban resueltas. El host también es una frontera compartida de fallo y de confianza, así que un cambio de enrutamiento puede afectar tanto al acceso de los usuarios como a la administración. Mantenga un camino de recuperación independiente para esta última.

Mantenga un inventario de roles junto a la configuración: qué producto termina, cuál reenvía, cuál traduce y quién puede cambiar cada uno. Esa lista es lo que hace revisable el siguiente cambio.

Cuando la frase se vuelve confusa, añadir otra capa de traducción rara vez la aclara. Quitar una suele hacerlo.