VPN site a site entre AWS e Azure: escreva primeiro a rota de retorno
Um túnel conectado entre nuvens não prova nada até que cada sub-rede de carga encaminhe para o prefixo remoto. Execute o plano em ordem e depois teste o serviço.
O túnel vai subir. Costuma subir, porque o IKE só precisa de propostas correspondentes e de um endereço de par alcançável. O que falha depois é o caminho de volta: a carga na AWS envia pacotes para um túnel, mas nada do lado do Azure sabe como responder a 10.10.0.0/16, ou a rota do Azure existe numa tabela que a sub-rede de carga não usa. Escreva o plano de rotas antes de tocar em qualquer consola e o túnel passa a ser a parte menos interessante do trabalho.
Passo 1: congele o plano de endereços
Trabalhe com valores concretos. Uma carga na AWS está em 10.10.1.20 dentro de 10.10.0.0/16 e precisa de TCP 443 para um serviço Azure em 10.20.1.30 dentro de 10.20.0.0/16. Os dois intervalos não podem sobrepor-se, e o teste de aceitação é o par de serviços, não o túnel.
Anote esses quatro factos antes de tudo o resto, porque cada passo seguinte é verificado contra eles.
Passo 2: nomeie o gateway que possui cada extremidade
O AWS Site-to-Site VPN pode terminar num virtual private gateway ou num transit gateway, e são proprietários de encaminhamento diferentes. O Azure oferece o seu VPN Gateway gerido e, em separado, aparelhos baseados em VM que os clientes gerem eles próprios. Registe qual é o par que tem, porque o salto seguinte difere em cada combinação.
Para um gateway gerido, não copie uma rota que aponte para um endereço suposto de aparelho privado. Para um aparelho, não assuma que a propagação de rotas na nuvem configura o sistema operativo convidado, porque não configura.
Errar aqui produz um plano que parece completo e envia pacotes para um endereço que nunca responde.
Passo 3: escreva a rota que cada carga realmente usa
Cada fronteira abaixo é uma consulta separada, e uma rota numa delas não é uma rota para o pacote. Preencha a tabela com os seus próprios valores antes de o túnel entrar em serviço.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
Na AWS, a tabela de rotas da sub-rede de carga é sua para atualizar mesmo depois de o BGP ou o túnel estarem saudáveis; a visão geral do encaminhamento considera isso parte da ligação. No Azure, uma tabela de rotas definidas pelo utilizador é associada a uma sub-rede e não à rede virtual, por isso verifique a rota efetiva na NIC da carga e não na lâmina do VNet.
Um gateway Azure gerido pode aprender o prefixo remoto através da propagação do gateway, e uma UDR pode anular essa decisão. Adicione a UDR quando tiver uma razão, não por reflexo. Se adicionar, aponte-a para o salto seguinte que o gateway publica para o caminho VPN em vez de inventar um endereço de aparelho. Depois volte a ler as rotas efetivas na NIC, porque é aí que a decisão é realmente tomada.
Passo 4: reconcilie o âmbito
Para BGP, compare o que cada lado anuncia com o que o outro lado aprendeu realmente, prefixo a prefixo. Para o encaminhamento estático, compare os intervalos remotos configurados com as rotas de carga que escreveu no passo 3.
Uma relação IKE de acordo quanto à criptografia não é prova de que algum lado tenha aprendido 10.10.0.0/16 ou 10.20.0.0/16. Dois túneis podem estar ativos enquanto um lado anuncia um único /24 em vez do /16 que planeou. Verifique o prefixo na tabela de encaminhamento, não no estado do túnel. A discrepância aparece mais tarde como uma sub-rede que funciona e outra que nunca responde.
Passo 5: teste o serviço, a partir da fonte real
Permita o fluxo pretendido nos grupos de segurança e nas ACL de rede da AWS, nos NSG do Azure e em qualquer filtro de aparelho no caminho. Depois abra uma ligação de 10.10.1.20 para o endereço e a porta aprovados do serviço e confirme que a resposta regressa à mesma fonte.
Tanto os grupos de segurança da nuvem como os NSG são stateful, por isso um pacote de retorno negado é um sintoma de encaminhamento, não uma regra que se esqueceu de escrever ao contrário.
Um ping a partir de qualquer gateway não decide nada. O ICMP para o endereço de um gateway exercita o caminho do plano de controlo, não o serviço TCP encaminhado de que a carga precisa.
Reversão e registos
Registe os proprietários das rotas ao lado dos identificadores do túnel e guarde as tabelas de rotas anteriores à alteração. Se a alteração tiver de sair, remova as rotas de carga antes de desmontar o túnel, para que nenhuma sub-rede fique a apontar para um salto seguinte que já não existe.
Assim, uma mudança posterior de sub-rede ou uma ligação spoke tem um local definido onde atualizar, em vez de um túnel a funcionar que carrega a culpa de uma rota que nunca possuiu.