O NAT do Azure VPN não corrige endereços VNet sobrepostos

Ambas as VNet usam 10.40.1.0/24, os túneis sobem e nada funciona. Acrescentar um segundo gateway VPN não muda isso, nem uma métrica de rota mais baixa, porque o problema não está na seleção de caminho. Duas cargas de trabalho que respondem ao mesmo endereço privado deixam cada pacote com um destino ambíguo e um caminho de retorno não verificável. Antes de planear qualquer tradução, descubra que tipo de ligação criou realmente, porque essa única escolha determina se a funcionalidade NAT do Azure está disponível ou não.

O que o sintoma lhe está realmente a dizer

Quando um anfitrião na VNet A envia para 10.40.1.10, a tabela de rotas só o pode apontar para algum lado. Se a VNet B também contiver 10.40.1.10, esse endereço não é um destino que o caminho consiga distinguir; é um endereço com dois proprietários.

O segundo gateway que as pessoas costumam implementar não ajuda. Dá outro túnel, não outro endereço, e o intervalo duplicado viaja inalterado dentro do túnel. Também duplica a configuração que tem de manter coerente. O que não consegue é fazer com que um endereço signifique dois anfitriões.

Alterar os endereços públicos dos pares VPN também não faz nada. Esses endereços identificam as extremidades do túnel, enquanto a colisão está no intervalo privado transportado lá dentro.

O tipo de ligação decide se o NAT está disponível

O Azure VPN Gateway tem, de facto, uma capacidade NAT, e está documentada para ligações IPsec entre instalações baseadas em rotas em SKU de gateway específicos. A mesma documentação exclui as ligações VNet-to-VNet e ponto a site, pelo que a funcionalidade não é uma caixa que apareça em todas as relações de gateway.

A VNet-to-VNet nativa também exige que os intervalos da VNet e da rede local não se sobreponham desde o início, o que é coerente com a exclusão. O emparelhamento de VNet não é uma solução para a sobreposição pelo mesmo motivo.

Existe uma alternativa suportada que as pessoas confundem com o tipo nativo: modelar a outra VNet como rede local e ligá-la como ligação site a site. É outro recurso e outro desenho, por isso trate uma ligação renomeada como uma alteração a validar, não como uma simples mudança de nome.

Renumere, ou traduza com algo que possua o alias

Se ambas as VNet são suas, compare uma renumeração planeada com o custo contínuo da tradução. A renumeração toca na configuração das aplicações, nos registos DNS, nas regras de segurança e em todas as ligações existentes, mas deixa uma rede que depois se lê normalmente. Faça-o uma sub-rede de cada vez, com a alteração de DNS por último. Um intervalo meio renumerado é pior do que qualquer das opções, porque então ambos os prefixos parecem autoritativos para quem ler a tabela a seguir.

Onde a renumeração não é prática, use um desenho traduzido com um proprietário real do alias. Quem chama a partir da VNet A pode chegar a 10.40.1.10 da VNet B como 10.140.1.10, mas esse alias precisa de um dispositivo que traduza, de uma rota até ele e de um comportamento correspondente para a resposta. Um endereço acrescentado apenas ao DNS não é uma tradução.

Registe ambos os intervalos nos dois sentidos: o que marca quem chama, o que o destino vê como origem e que lado pode iniciar. As próprias regras NAT do Azure incluem a tradução inversa para os seus mapeamentos SNAT, por isso não escreve à mão uma regra DNAT correspondente, mas essa conveniência termina nos tipos de ligação que a funcionalidade suporta.

O que não vai funcionar

Uma rota definida pelo utilizador ou uma métrica de rota não podem criar uma distinção de endereços em falta. Ambas atuam sobre um destino ainda ambíguo, e o pacote chega ao próximo salto que a tabela preferir.

Acrescentar o intervalo duplicado a uma tabela de rotas como prefixo mais específico apenas desloca a ambiguidade um passo. Também tende a quebrar o sentido contrário, onde a resposta passa a ter duas origens plausíveis.

Aceite o desenho com tráfego nos dois sentidos

Prove o desenho com uma operação permitida nova de cada lado, não com o estado do túnel. Um túnel IPsec ligado diz que os pares concordam quanto à criptografia; não diz nada sobre se os destinos se tornaram distinguíveis.

Depois execute os caminhos negados: um endereço que deve permanecer inalcançável e um serviço que a política deve bloquear. Se ambos continuarem a ter sucesso, a tradução é mais ampla do que o desenho pretendia.

Termine com os factos que explicam a configuração mais tarde: o intervalo original, o intervalo apresentado, o dispositivo que traduz e o sentido em que cada lado pode iniciar. Se faltar algum deles, o próximo engenheiro herda uma rede onde dois anfitriões partilham um nome e ninguém se lembra por que razão um deles responde.