EC2 Windows: cliente VPN, servidor VPN ou pasarela AWS?
Unha instancia EC2 de Windows pode executar software VPN, pero un cliente, un servidor autoxestionado e unha pasarela AWS son roles distintos con propietarios distintos.
Un equipo necesita conectividade VPN para unha aplicación que se executa nunha instancia EC2 de Windows, atopa software cliente compatible, instálao e despois pregunta por que o resto da VPC non pode usalo. A instalación funcionou; o rol nunca se decidiu. O software que se executa dentro dun convidado pode ser un cliente que se une á rede doutra persoa, un servidor que acepta outros clientes, ou ningún dos dous produtos VPN xestionados por AWS, e cada rol deixa un traballo distinto nas túas mans.
O síntoma adoita ser o rol equivocado
O síntoma habitual é un túnel que funciona e resolve o problema equivocado. Un cliente dentro da máquina virtual dá a esa máquina unha ruta de saída; non dá ao teu portátil, á túa oficina nin a outra subrede unha forma de entrar. Un servidor dentro da máquina virtual dá a outros unha forma de entrar, pero agora es dono do receptor, da autenticación e do reenvío.
Os servizos xestionados trasladan a operación do servizo a AWS e déixanche o deseño. Site-to-Site VPN conecta redes mediante unha pasarela de cliente e unha pasarela AWS, e Client VPN dá aos dispositivos remotos un punto de conexión xestionado. En ambos os casos as rutas, as regras de autorización e a orixe de identidade son a túa configuración, e ningún dos produtos instala un cliente de propósito xeral dentro dun convidado Windows.
Hai catro formas posibles, e a táboa sepáraas por que se conecta con que e quen soporta a 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 |
Le a fila e non o nome do produto: a mesma instancia de Windows pode estar en dúas filas distintas segundo o software que se execute nela.
Cliente dentro da máquina virtual: a máquina únese a unha rede
Un cliente de saída necesita que se revisen a compilación de Windows, a arquitectura e os requisitos de controladores antes de instalar nada. O cliente cambiará rutas e DNS na instancia, o que pode afectar servizos que xa se executan alí, incluída a ruta que usas para a administración remota. Anota o nome do adaptador e a métrica de interface que establece o cliente, porque a nova interface pode ter prioridade sobre a existente. Se a instancia se xestiona mediante un xestor de sesións en lugar de SSH ou RDP, confirma que esa ruta segue funcionando despois de que o cliente se conecte.
Decide que tráfico debe transportar o cliente antes de activalo. Un túnel completo pode capturar a sesión de administración e deixarte fóra, e un túnel dividido pode deixar que a instancia chegue á rede privada mentres o seu outro tráfico sae por outra vía. Proba cunha segunda ruta de administración dispoñible e anota as rutas que instala o cliente para que un cambio posterior sexa explicable.
Servidor dentro da máquina virtual: outros clientes se lle unen
Nun servidor autoxestionado es dono do receptor, do certificado ou do material de clave, da base de datos de usuarios e das regras de reenvío. Se o servidor reenvía tráfico para outros clientes, a instancia convértese nun enrutador, e iso esixe reenvío a nivel de convidado ademais de cambios de rutas e de grupos de seguridade a nivel de AWS.
Proba o receptor desde o convidado e de novo desde outra subrede, despois proba un host ao que a instancia reenvíe. Un servizo local san non demostra nada sobre a ruta reenviada, así que anota ambos os resultados na nota de cambio.
As pasarelas xestionadas conservan o servizo, non o teu deseño de acceso
AWS Site-to-Site VPN documenta os roles de túnel da pasarela de cliente e da pasarela AWS, e comprar esa conexión non substitúe todos os deseños de acceso remoto. Client VPN documenta un punto de conexión xestionado con persoas de cliente, mentres que as regras de autorización e as rutas de destino seguen sendo túas. AWS mantén o punto de conexión e os seus certificados en funcionamento; quen pode chegar a que aplicación segue sendo unha regra de autorización que escribes e mantés.
Elixe entre os produtos en cinco eixos: que rol desempeña cada un, que protocolos acepta, que orixe de identidade espera, como se reenvía o tráfico e como se entrega a dispoñibilidade. Ignora calquera cifra única de rendemento citada nun fío de foro, porque a capacidade publicada cambia co servizo. E non asumas que un par de túneles xestionados cambia o comportamento dun cliente convidado arbitrario.
Elixe o rol antes do produto
Escribe unha frase que nomee a dirección: esta máquina únese a unha rede, esta máquina acepta clientes ou unha pasarela AWS conecta redes definidas.
Esa frase decide a lista curta de produtos, o propietario do software e os modos de fallo que depurarás. Se o requisito é que usuarios remotos cheguen a unha aplicación, un cliente instalado na máquina virtual da aplicación é a forma equivocada. Se o requisito é que unha máquina chegue a unha rede de socio, unha pasarela xestionada de sitio a sitio é máis maquinaria da que a tarefa necesita. Ambas as respostas son lexítimas; só unha coincide coa frase que escribiches.