AWS Client VPN ou Site-to-Site: verifique quem abre a ligação

Quatro verificações decidem isto, e nenhuma delas é o nome do protocolo. Quem abre a ligação, o que a AWS autentica, como a ligação se liga à sua rede e que encaminhamento e política a acompanham. Responda por ordem e a escolha do produto costuma fazer-se sozinha; responda depois de já ter comprado um desenho e acabará a defender um túnel que resolve a metade errada do problema. Nenhuma das quatro lhe pede para escolher uma cifra, e é por isso que um desenho que começa pelo protocolo costuma ser sinal de que os requisitos nunca foram escritos.

Execute cada verificação contra o ponto final, o cliente e a família de endereços que realmente pretende usar, não contra a categoria. Os produtos VPN geridos diferem dos blocos OpenVPN e IPsec a que se assemelham.

Primeiro, quem abre a ligação

Se aquilo que precisa de acesso é uma máquina portátil, um telefone ou a estação de trabalho de um único administrador, a ligação começa num dispositivo remoto e o desenho é acesso de cliente remoto. Se aquilo que precisa de acesso é uma filial cheia de máquinas atrás de um único router, a ligação começa nesse router e o desenho é gateway-a-gateway. Esta é a verificação que resolve a maioria dos casos, e é aquela que as pessoas saltam quando uma apresentação de fornecedor já enquadrou a conversa em torno de cifras.

Pare aqui se não conseguir nomear o componente que inicia. Um desenho que tenta servir os dois casos com um único túnel acaba normalmente numa sessão de cliente que se faz passar por um gateway.

Segundo, o que a AWS autentica

Com o Client VPN, a AWS autentica a identidade de cliente ou de utilizador configurada: certificados, um diretório ou uma identidade federada, conforme a configuração. Com o Site-to-Site VPN, a AWS autentica a identidade do par do gateway. Essa diferença não é cosmética. Um modelo escala acrescentando utilizadores e revogando as suas credenciais; o outro escala confiando em tudo o que está atrás de um único gateway.

A autenticação do gateway não autentica cada funcionário nem cada aplicação atrás dele, por isso mantenha as identidades das aplicações e o acesso ao nível do recurso mesmo quando o túnel em si é de confiança. Uma filial cujo router tem uma identidade de par válida não deve ser lida automaticamente como se cada secretária desse edifício estivesse autorizada.

Terceiro, como a ligação se liga

O Client VPN liga-se através de associações de sub-rede VPC ou de uma ligação direta a Transit Gateway suportada. O Site-to-Site VPN liga-se a um destino AWS VPN, habitualmente um gateway privado virtual ou um Transit Gateway. O guia de arquitetura do Client VPN documenta a opção Transit Gateway, e a sua existência não transforma uma sessão de máquina portátil num gateway de filial nem remove a autenticação e a autorização de cliente descritas acima.

Verifique a ligação que a sua conta e a sua região realmente suportam antes de desenhar rotas à volta dela, e depois verifique a quem pertence essa ligação. Uma opção que existe na documentação mas se encontra numa rede que não pode configurar não é uma opção.

Quarto, que encaminhamento e política a acompanham

O Client VPN traz gestão de ligações de cliente e regras de autorização para as redes de destino que permite. Um utilizador ligado continua a precisar da rota prevista até ao ponto final, de uma regra de autorização que a permita e do acesso que o próprio recurso exige. O Site-to-Site VPN encaminha entre redes representadas por um gateway de cliente, usando rotas estáticas suportadas ou BGP conforme o desenho, pelo que as máquinas individuais atrás do router da filial não precisam cada uma de um início de sessão de cliente.

Não inferira comportamento não suportado a partir da categoria em nenhuma direção. As VPN de acesso remoto não são universalmente incapazes de transportar tráfego de retorno ou de suportar disposições de gateway, e o IPsec não é bloqueado automaticamente pelo NAT — a AWS documenta a travessia de NAT e os requisitos do gateway de cliente, e a configuração de gateway suportada é a restrição real. Verifique as restrições do seu ponto final antes de exigir ligações iniciadas para os clientes ou de reencaminhar uma LAN atrás de uma sessão. A mesma cautela aplica-se às famílias de endereços: um ponto final que funciona sobre IPv4 não implica um caminho IPv6, por isso confirme a família que o seu cliente ou gateway vai realmente negociar.

O Site-to-Site VPN dá-lhe dois túneis por ligação, e essa redundância é uma tarefa de desenho e não uma funcionalidade que possa assumir. A operação do gateway de cliente, a comutação de rotas em caso de falha e a cobertura de testes têm todas de ser planeadas; comparar uma sessão de máquina portátil com um servidor VPN abstrato não prova nada sobre nenhum dos dois.

Onde os dois desenhos se encontram

Os serviços não são exclusivos, e a forma de produção comum usa ambos: funcionários no Client VPN, redes de filial no Site-to-Site, com rotas explícitas e política de acesso entre os destinos que têm de comunicar. A tabela é um resumo das quatro verificações, não um substituto para as executar.

Uma coisa que nenhum dos dois produtos substitui: TLS para uma aplicação cujo requisito de cifragem vai além do ponto final da VPN. Se o seu âmbito de conformidade termina na aplicação, o túnel é transporte e o certificado continua a ser o controlo.

Escreva as quatro respostas antes da revisão de desenho, uma linha cada. Quando duas delas não concordam — por exemplo, um desenho de cliente autenticado por utilizador com um requisito de encaminhamento do tamanho de uma filial —, essa discordância é o achado, e é mais barato vê-la agora do que durante a transição.