EC2 Windows: ¿cliente VPN, servidor VPN o puerta de enlace AWS?
Una instancia EC2 de Windows puede ejecutar software VPN, pero un cliente, un servidor autogestionado y una puerta de enlace AWS son roles distintos con propietarios distintos.
Un equipo necesita conectividad VPN para una aplicación que se ejecuta en una instancia EC2 de Windows, encuentra software cliente compatible, lo instala y luego pregunta por qué el resto de la VPC no puede usarlo. La instalación funcionó; el rol nunca se decidió. El software que se ejecuta dentro de un invitado puede ser un cliente que se une a la red de otra persona, un servidor que acepta otros clientes, o ninguno de los dos productos VPN gestionados por AWS, y cada rol deja un trabajo distinto en sus manos.
El síntoma suele ser el rol equivocado
El síntoma habitual es un túnel que funciona y resuelve el problema equivocado. Un cliente dentro de la máquina virtual da a esa máquina una ruta de salida; no da a su portátil, su oficina ni otra subred una forma de entrar. Un servidor dentro de la máquina virtual da a otros una forma de entrar, pero ahora usted es dueño del receptor, la autenticación y el reenvío.
Los servicios gestionados trasladan la operación del servicio a AWS y le dejan el diseño. Site-to-Site VPN conecta redes mediante una puerta de enlace de cliente y una puerta de enlace AWS, y Client VPN da a los dispositivos remotos un punto de conexión gestionado. En ambos casos las rutas, las reglas de autorización y el origen de identidad son su configuración, y ninguno de los productos instala un cliente de propósito general dentro de un invitado Windows.
Hay cuatro formas posibles, y la tabla las separa por qué se conecta con qué y quién soporta la carga operativa.
| Role | What connects | Who owns the VPN software |
|---|---|---|
| Client in the Windows VM | This VM dials out into someone else's network | You, plus the software vendor |
| Server in the Windows VM | Inbound clients and sites attach to this VM | You, end to end |
| AWS Site-to-Site VPN | Two networks meet through a customer gateway and an AWS gateway | AWS operates the tunnels; you own the peer and route design |
| AWS Client VPN | User devices attach to an endpoint AWS operates | AWS operates it; you own the access rules |
Lea la fila y no el nombre del producto: la misma instancia de Windows puede estar en dos filas distintas según el software que se ejecute en ella.
Cliente dentro de la máquina virtual: la máquina se une a una red
Un cliente de salida necesita que se revisen la compilación de Windows, la arquitectura y los requisitos de controladores antes de instalar nada. El cliente cambiará rutas y DNS en la instancia, lo que puede afectar a servicios que ya se ejecutan allí, incluida la ruta que usa para la administración remota. Anote el nombre del adaptador y la métrica de interfaz que establece el cliente, porque la nueva interfaz puede tener prioridad sobre la existente. Si la instancia se gestiona mediante un gestor de sesiones en lugar de SSH o RDP, confirme que esa ruta sigue funcionando después de que el cliente se conecte.
Decida qué tráfico debe transportar el cliente antes de activarlo. Un túnel completo puede capturar la sesión de administración y dejarlo fuera, y un túnel dividido puede dejar que la instancia llegue a la red privada mientras su otro tráfico sale por otra vía. Pruebe con una segunda ruta de administración disponible y anote las rutas que instala el cliente para que un cambio posterior sea explicable.
Servidor dentro de la máquina virtual: otros clientes se le unen
En un servidor autogestionado usted es dueño del receptor, del certificado o del material de clave, de la base de datos de usuarios y de las reglas de reenvío. Si el servidor reenvía tráfico para otros clientes, la instancia se convierte en un enrutador, y eso exige reenvío a nivel de invitado además de cambios de rutas y de grupos de seguridad a nivel de AWS.
Pruebe el receptor desde el invitado y de nuevo desde otra subred, luego pruebe un host al que la instancia reenvíe. Un servicio local sano no demuestra nada sobre la ruta reenviada, así que anote ambos resultados en la nota de cambio.
Las puertas de enlace gestionadas conservan el servicio, no su diseño de acceso
AWS Site-to-Site VPN documenta los roles de túnel de la puerta de enlace de cliente y de la puerta de enlace AWS, y comprar esa conexión no sustituye todos los diseños de acceso remoto. Client VPN documenta un punto de conexión gestionado con personas de cliente, mientras que las reglas de autorización y las rutas de destino siguen siendo suyas. AWS mantiene el punto de conexión y sus certificados en funcionamiento; quién puede llegar a qué aplicación sigue siendo una regla de autorización que usted escribe y mantiene.
Elija entre los productos en cinco ejes: qué rol desempeña cada uno, qué protocolos acepta, qué origen de identidad espera, cómo se reenvía el tráfico y cómo se entrega la disponibilidad. Ignore cualquier cifra única de rendimiento citada en un hilo de foro, porque la capacidad publicada cambia con el servicio. Y no asuma que un par de túneles gestionados cambia el comportamiento de un cliente invitado arbitrario.
Elija el rol antes del producto
Escriba una frase que nombre la dirección: esta máquina se une a una red, esta máquina acepta clientes o una puerta de enlace AWS conecta redes definidas.
Esa frase decide la lista corta de productos, el propietario del software y los modos de fallo que depurará. Si el requisito es que usuarios remotos lleguen a una aplicación, un cliente instalado en la máquina virtual de la aplicación es la forma equivocada. Si el requisito es que una máquina llegue a una red de socio, una puerta de enlace gestionada de sitio a sitio es más maquinaria de la que la tarea necesita. Ambas respuestas son legítimas; solo una coincide con la frase que escribió.