EC2 entre zonas de disponibilidade: verifique o roteamento antes de uma VPN

Antes de instalar software VPN entre duas instâncias EC2, responda a uma pergunta: elas estão na mesma VPC? Se estiverem, o caminho privado já existe e uma colocação entre zonas não muda isso. A maior parte do trabalho nessa situação é confirmar qual tabela de rotas cada sub-rede realmente usa e, em seguida, descobrir se a falha era sequer um problema de roteamento. Um túnel costuma ser a resposta errada para essa pergunta específica.

Verificação 1: mesma VPC ou VPCs diferentes

Uma VPC é regional e abrange zonas de disponibilidade, enquanto cada sub-rede pertence exatamente a uma zona. Duas instâncias em zonas diferentes de uma mesma VPC continuam dentro do mesmo domínio de roteamento privado.

VPCs diferentes nunca ganham uma rota privada só porque compartilham uma região ou um rótulo de zona. Esse caso exige uma conexão suportada e trabalho próprio de rotas e permissões, que é uma decisão separada.

Verificação 2: o que dizem as tabelas de rotas das sub-redes

Escreva o desenho com valores reais. Uma VPC em 10.60.0.0/16 com sub-redes 10.60.1.0/24 e 10.60.2.0/24 dá às instâncias 10.60.1.10 e 10.60.2.20 um caminho pela rota local da VPC.

Depois examine as tabelas associadas às duas sub-redes, não apenas a que você encontrou primeiro. Uma rota de inspeção ou de appliance mais específica pode substituir a rota base, e o destino da rota local pode ele mesmo ser trocado em configurações mais novas. Uma rota local visível em algum lugar do console não prova que as duas cargas de trabalho a usam.

Use os endereços e nomes privados que a VPC realmente atribui. Um endereço privado não precisa começar com 10, e inventar um de memória é como um ambiente que funciona é diagnosticado errado.

Verificação 3: roteamento ou autorização

O roteamento apenas leva o pacote até a interface de rede do destino. O grupo de segurança do destino ainda precisa admitir a origem e o serviço, as regras de saída da origem precisam permitir a requisição, e qualquer ACL de rede precisa permitir os dois sentidos porque as ACLs não guardam estado.

Por trás disso estão o firewall do hóspede, a vinculação do listener e a identidade da própria aplicação. Qualquer um deles pode recusar uma requisição que o roteamento entregou perfeitamente.

A aceitação precisa ser a operação real da aplicação. Um ping bem-sucedido não concede acesso à aplicação nem prova que o nome TLS e as credenciais estão corretos, e um ping bloqueado não estabelece que todo serviço privado está fora do ar.

Verificação 4: uma conexão separada é realmente necessária

Uma VPN ainda pode fazer parte do desenho, mas por um motivo declarado: conectar esta VPC a um escritório, admitir notebooks ou atender a um requisito de sobreposição. Esse motivo é diferente da comunicação comum dentro da mesma VPC.

Lembre-se também do que a VPC não é. Ela não é uma extensão de um segmento Ethernet doméstico. Uma aplicação que depende de descoberta por broadcast tem um requisito separado a avaliar. Isso é uma lacuna de projeto, não um bug de roteamento.

Verificação 5: a questão da criptografia

Um endereço privado e uma regra de permissão não dizem nada sobre proteção criptográfica na camada de aplicação. Se os dados precisam de proteção ponta a ponta, ela vem do protocolo e do modelo de identidade que o serviço realmente suporta.

Mantenha separadas as afirmações sobre a camada de rede e a camada de aplicação na nota de projeto, porque fundi-las é como uma revisão acaba afirmando uma proteção que ninguém implementou.

O que registrar

Registre os dois identificadores de sub-rede, a tabela de rotas associada a cada uma, as referências dos grupos de segurança e a operação de aplicação que você testou. São quatro fatos, e eles resolvem a maioria das discussões futuras sobre esse caminho.

A colocação em uma zona por si só nunca diz para adicionar uma VPN, e nunca explica por que uma requisição privada falhou.