EC2 Windows: cliente VPN, servidor VPN ou gateway AWS?
Uma instância EC2 Windows pode executar software VPN, mas um cliente, um servidor autogerenciado e um gateway AWS são papéis diferentes com proprietários diferentes.
Uma equipe precisa de conectividade VPN para um aplicativo que roda em uma instância EC2 Windows, encontra software cliente compatível, instala-o e então pergunta por que o restante da VPC não consegue usá-lo. A instalação funcionou; o papel nunca foi decidido. O software executado dentro de um convidado pode ser um cliente que entra na rede de outra pessoa, um servidor que aceita outros clientes, ou nenhum dos dois produtos VPN gerenciados pela AWS, e cada papel deixa um trabalho diferente para você.
O sintoma costuma ser o papel errado
O sintoma comum é um túnel que funciona e resolve o problema errado. Um cliente na VM dá a essa VM um caminho de saída; não dá ao seu notebook, ao seu escritório ou a outra sub-rede um caminho de entrada. Um servidor na VM dá aos outros um caminho de entrada, mas agora você é dono do ouvinte, da autenticação e do encaminhamento.
Os serviços gerenciados movem a operação do serviço para a AWS e deixam o design com você. O Site-to-Site VPN conecta redes por meio de um gateway de cliente e de um gateway AWS, e o Client VPN dá aos dispositivos remotos um endpoint gerenciado. Nos dois casos, as rotas, as regras de autorização e a origem de identidade são a sua configuração, e nenhum dos produtos instala um cliente de uso geral dentro de um convidado Windows.
Há quatro formas possíveis, e a tabela as separa pelo que se conecta com o quê e por quem carrega o ônus operacional.
| 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 |
Leia a linha, não o nome do produto: a mesma instância Windows pode estar em duas linhas diferentes dependendo do software que roda nela.
Cliente dentro da VM: a VM entra em uma rede
Um cliente de saída precisa ter a compilação do Windows, a arquitetura e os requisitos de driver verificados antes de instalar qualquer coisa. O cliente mudará rotas e DNS na instância, o que pode afetar serviços que já rodam ali, incluindo o caminho que você usa para administração remota. Anote o nome do adaptador e a métrica de interface definida pelo cliente, porque a nova interface pode ter precedência sobre a existente. Se a instância é gerenciada por um gerenciador de sessões em vez de SSH ou RDP, confirme que esse caminho ainda funciona depois que o cliente se conecta.
Decida qual tráfego o cliente deve carregar antes de ativá-lo. Um túnel completo pode capturar a sessão de gerenciamento e prendê-lo do lado de fora, e um túnel dividido pode deixar a instância alcançar a rede privada enquanto o restante do tráfego sai por outro caminho. Teste com um segundo caminho de gerenciamento disponível e anote as rotas que o cliente instala para que uma alteração posterior seja explicável.
Servidor dentro da VM: outros clientes entram nele
Em um servidor autogerenciado, você é dono do ouvinte, do certificado ou do material de chave, do banco de usuários e das regras de encaminhamento. Se o servidor encaminha tráfego para outros clientes, a instância se torna um roteador, e isso exige encaminhamento no nível do convidado mais alterações de rotas e de grupos de segurança no nível da AWS.
Teste o ouvinte a partir do convidado e novamente de outra sub-rede, depois teste um host para o qual a instância encaminha. Um serviço local saudável não prova nada sobre o caminho encaminhado, então anote os dois resultados na nota de alteração.
Gateways gerenciados mantêm o serviço, não o seu design de acesso
AWS Site-to-Site VPN documenta os papéis de túnel do gateway de cliente e do gateway AWS, e comprar essa conexão não substitui todos os designs de acesso remoto. O Client VPN documenta um endpoint gerenciado com personas de cliente, enquanto as regras de autorização e as rotas de destino continuam sendo suas. A AWS mantém o endpoint e seus certificados em funcionamento; quem pode alcançar qual aplicativo continua sendo uma regra de autorização que você escreve e mantém.
Escolha entre os produtos em cinco eixos: qual papel cada um desempenha, quais protocolos aceita, qual origem de identidade espera, como o tráfego é encaminhado e como a disponibilidade é entregue. Ignore qualquer número único de throughput citado em um tópico de fórum, porque a capacidade publicada muda com o serviço. E não presuma que um par de túneis gerenciados mude o comportamento de um cliente convidado arbitrário.
Escolha o papel antes do produto
Escreva uma frase que nomeie a direção: esta VM entra em uma rede, esta VM aceita clientes, ou um gateway AWS conecta redes definidas.
Essa frase decide a lista curta de produtos, o proprietário do software e os modos de falha que você vai depurar. Se o requisito é que usuários remotos alcancem um aplicativo, um cliente instalado na VM do aplicativo é a forma errada. Se o requisito é que uma VM alcance a rede de um parceiro, um gateway site a site gerenciado é mais maquinário do que a tarefa precisa. As duas respostas são legítimas; apenas uma corresponde à frase que você escreveu.