Um Elastic IP do EC2 não é o endereço VPN privado da instância

A instância tem um endereço privado, o Elastic IP está associado a ele, e uma rota para esse /32 público é adicionada à VPN na esperança de que os dois se tornem a mesma coisa. Não se tornam. Um Elastic IP é uma tradução realizada fora do convidado, pelo gateway de internet, sobre o tráfego que segue o caminho de internet. O sistema operacional do convidado nunca vê esse endereço configurado numa interface. Adicioná-lo a uma interface de túnel não reproduz a tradução a montante e cria uma segunda identidade, em conflito, para a mesma máquina.

Dois endereços, uma instância

A interface de rede da instância tem um endereço privado dentro da VPC, e esse é o endereço que o convidado conhece. O Elastic IP está associado à mesma interface mas vive no lado público do mapeamento.

Tudo o que chega à instância pela internet chega traduzido para o endereço privado. Tudo o que a instância envia para a internet sai com o Elastic IP como origem, novamente por causa dessa tradução.

Dentro do convidado existe um endereço. Fora existem dois. Essa assimetria explica a maior parte da confusão nesta área. O convidado não pode configurar o que o gateway traduz. Só pode responder no endereço que realmente tem.

O que o gateway de internet realmente faz

A documentação da AWS sobre o gateway de internet descreve o arranjo: a instância conhece o seu endereço IPv4 privado e o gateway fornece a tradução correspondente para IPv4 público ou Elastic IP do tráfego no caminho de internet.

Isso é tradução de endereços de rede, não um alias. O mapeamento é mantido pelo gateway, está ligado à associação e aplica-se apenas aos pacotes que o atravessam. Remova a associação e a identidade pública desaparece sem que o convidado note nada.

Por isso um pacote VPN privado endereçado ao /32 público não é reinterpretado como um pacote privado para o endereço local do convidado. O pacote segue a rota com que corresponde, que o envia para o gateway de internet, e o comportamento do gateway depende de o caminho ser permitido nos dois sentidos.

Porque é que o truque da interface de túnel falha

Atribuir o Elastic IP a uma interface de túnel pede ao convidado que trate um endereço público como local. Agora duas coisas reivindicam o mesmo endereço: a tradução do gateway no caminho de internet e a interface local dentro do túnel. O tráfego de retorno não tem uma resposta consistente sobre qual se aplica.

Mesmo quando parece funcionar, o desenho escondeu a verdadeira questão. Os clientes chegam ao endereço privado pelo túnel ou ao endpoint público pela internet, e os dois caminhos têm grupos de segurança diferentes, registo diferente e modos de falha diferentes.

O endereço nunca foi o problema. A escolha do caminho é que era.

Três objetivos, três desenhos

Se o objetivo é um endpoint VPN público, o Elastic IP é a ferramenta certa: os pares remotos ligam-se a ele pela internet e o transporte cifrado termina na instância. O tráfego interno da aplicação usa depois o endereço privado.

Se o objetivo é o acesso privado à aplicação, o destino é o endereço privado ou um nome DNS privado que resolve para ele, e a rota VPN, o grupo de segurança e o caminho de retorno têm todos de concordar. O Elastic IP não aparece de todo nesse desenho.

Se o objetivo é uma identidade de saída pública estável para os utilizadores de VPN, isso é um desenho NAT do lado da saída, não um endereço no túnel do cliente. Três objetivos que soam iguais produzem três diagramas diferentes, e só um deles envolve colocar um Elastic IP num lugar novo.

Verifique o caminho que escolheu

Para o acesso privado, confirme que a rota VPN cobre o prefixo privado, que a tabela de rotas da VPC devolve o tráfego ao túnel, que o grupo de segurança permite a origem do cliente e que a firewall do próprio cliente permite a resposta. Depois teste um pedido real em vez de um ping.

Para o acesso público, confirme a saída de internet do cliente, o encaminhamento da entrada pública e a sua política de segurança. Se um cliente VPN consegue chegar a um endpoint público pelo túnel depende das regras de saída e da firewall do túnel, não da associação do Elastic IP.

Se um nome de anfitrião público tem de funcionar dos dois lados, use um desenho DNS que responda com o endereço privado para os clientes VPN e com o endereço público para todos os outros, e mantenha o certificado válido para o nome em vez de para o endereço. Ordem do trabalho: nomeie o objetivo, escolha o endereço que lhe pertence e depois verifique rotas, política e um pedido.