Um laptop conectado pelo AWS Client VPN alcança uma aplicação no EC2 sem problemas. Depois você tenta o contrário, do EC2 para o endereço atribuído ao cliente, e a conexão trava ou é recusada. Essa assimetria raramente é uma regra de grupo de segurança ausente. Em um endpoint do Client VPN associado a sub-redes da VPC, a AWS traduz as origens IPv4 do cliente para a interface de rede do endpoint, portanto não existe um endereço de VPC de entrada que represente o seu laptop.

Comece pelo que a captura mostra

Faça uma captura no host do EC2 enquanto o cliente se conecta e leia o endereço de origem que a aplicação realmente vê. Se for a interface do endpoint do lado da VPC e não um endereço do pool de clientes, a tradução está confirmada antes de mudar uma única regra.

O pool de clientes é uma faixa de alocação, não uma sub-rede com rota de retorno. É nessa distinção que a maioria dessas investigações erra.

A tradução que explica a assimetria

Três fluxos são confundidos entre si, e apenas um deles é o que as pessoas testam.

FlowStarted byWhat the VPC seesOutcome
Client to EC2 serviceThe clientA translated source at the endpoint interfaceWorks, with a stateful reply
EC2 host to client pool addressThe EC2 hostA destination with no route and no translation stateNo usable path
Client to clientA client, when the feature is configuredTraffic mediated by the endpointWorks only with that feature and its authorisation

A descrição dos componentes do Client VPN declara que as origens IPv4 do cliente são traduzidas para a interface do endpoint, o que basta para ver por que a linha do meio não tem com o que coincidir.

Uma conexão nova precisa de uma rota, de uma etapa de resolução de endereço e de uma decisão de autorização. O estado de tradução da sessão de outra pessoa não fornece nenhum dos três.

Por que uma resposta não é uma conexão nova

Uma resposta TCP é comparada a uma entrada existente, e é por isso que o caminho de volta funciona sem nenhuma regra de entrada. Um SYN novo do host do EC2 não tem entrada com que coincidir, então se torna uma tentativa de saída comum para um destino que a VPC não sabe como alcançar.

Também por isso é enganoso descrever isso como tráfego que vai apenas em um sentido. O tráfego de volta flui continuamente nessas sessões. A parte sem caminho é o início.

O que ainda quebra uma sessão que deveria funcionar

Grupos de segurança, ACLs de rede e o firewall do próprio laptop importam todos para as conexões que deveriam funcionar. Um ping que falha diz menos de tudo, porque a política de ICMP costuma ser separada da política de TCP que lhe interessa.

Escreva essas regras em relação à origem traduzida, não ao endereço do cliente. Regras ligadas ao endereço que nunca aparece na rede são a falha autoinfligida mais comum neste desenho.

Quando a VPC realmente precisa iniciar a conversa

Se um serviço precisa notificar uma estação de trabalho, inverta a direção e deixe o cliente manter um canal de saída persistente ao qual o serviço responde. Se toda uma rede remota precisa ser alcançável a partir da VPC, escolha uma arquitetura que publique os seus prefixos e a sua política de acesso em vez de supor que o Client VPN já faz isso. O acesso cliente a cliente é um terceiro caso, mais estreito, com os seus próprios objetos de rota e autorização. Nada disso é uma caixa de seleção no endpoint existente.

Mantenha honesto também o alcance da explicação de IPv4. A documentação atual da AWS separa o IPv6, onde essa tradução não se aplica, e outros modelos de conexão que encaminham de forma diferente.

Teste em três passos etiquetados: o cliente abre uma sessão permitida, o serviço da VPC responde a essa sessão e um host da VPC abre uma nova sessão em direção ao cliente. Que os dois primeiros funcionem e o terceiro falhe é a forma esperada deste desenho, não um defeito que se deva perseguir com regras de firewall.

Artigos relacionados