O NAT de Azure VPN non resolve as direccións VNet superpostas
Dúas VNet co mesmo rango privado non se conectarán só porque exista NAT. Revise primeiro o tipo de conexión e despois renumere ou sexa dono dun alias de tradución.
Ambas as VNet usan 10.40.1.0/24, os túneles lévantanse e nada funciona. Engadir unha segunda pasarela VPN non o cambia, nin unha métrica de ruta máis baixa, porque o problema non é a selección de ruta. Dúas cargas de traballo que responden á mesma dirección privada deixan cada paquete cun destino ambiguo e unha ruta de retorno non verificable. Antes de planificar calquera tradución, descubra que tipo de conexión creou realmente, porque esa única elección decide se a función NAT de Azure está dispoñible ou non.
Que lle está dicindo realmente o síntoma
Cando un host da VNet A envía a 10.40.1.10, a táboa de enrutamento só pode apuntalo a algún sitio. Se a VNet B tamén contén 10.40.1.10, esa dirección non é un destino que a ruta poida distinguir; é unha dirección con dous propietarios.
A segunda pasarela que a xente adoita despregar non axuda. Dálle outro túnel, non outra dirección, e o rango duplicado viaxa intacto dentro do túnel. Ademais duplica a configuración que debe manter coherente. O que non pode facer é que unha dirección signifique dous hosts.
Cambiar as direccións públicas dos pares VPN tampouco fai nada. Esas direccións identifican os extremos do túnel, mentres que a colisión está no rango privado que se transporta dentro.
O tipo de conexión decide se NAT está dispoñible
Azure VPN Gateway si ten unha capacidade NAT, e está documentada para conexións IPsec entre instalacións baseadas en rutas en SKU de pasarela concretos. Esa mesma documentación exclúe as conexións VNet-to-VNet e de punto a sitio, así que a función non é unha caixa que apareza en todas as relacións de pasarela.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
A VNet-to-VNet nativa tamén require que os rangos de VNet e de rede local non se superpoñan desde o principio, o que concorda coa exclusión. O emparellamento de VNet non é unha solución para a superposición polo mesmo motivo.
Existe unha alternativa admitida que a xente confunde co tipo nativo: modelar a outra VNet como rede local e conectala como conexión de sitio a sitio. É outro recurso e outro deseño, así que trate unha conexión reetiquetada como un cambio que hai que validar, non como un simple cambio de nome.
Renumere, ou traduza con algo que posúa o alias
Se ambas as VNet son súas, compare unha renumeración planificada co custo continuo da tradución. A renumeración toca a configuración de aplicacións, os rexistros DNS, as regras de seguridade e cada conexión existente, pero deixa unha rede que despois se le con normalidade. Fágao unha subrede á vez, co cambio de DNS ao final. Un rango a medio renumerar é peor que calquera das dúas opcións, porque entón ambos os prefixos parecen autoritativos para quen lea a táboa despois.
Onde a renumeración non sexa práctica, use un deseño traducido cun propietario real do alias. Quen chama desde a VNet A pode chegar a 10.40.1.10 da VNet B como 10.140.1.10, pero ese alias necesita un dispositivo que traduza, unha ruta cara a el e un comportamento equivalente para a resposta. Unha dirección engadida só ao DNS non é unha tradución.
Rexiste ambos os rangos nas dúas direccións: que marca quen chama, que ve o destino como orixe e que lado pode iniciar. As propias regras NAT de Azure inclúen a tradución inversa para as súas asignacións SNAT, así que non se escribe á man unha regra DNAT equivalente, pero esa comodidade termina nos tipos de conexión que admite a función.
O que non funcionará
Unha ruta definida polo usuario ou unha métrica de ruta non poden crear unha distinción de direccións que falta. Ambas operan sobre un destino que segue sendo ambiguo, e o paquete chega ao seguinte salto que a táboa prefira.
Engadir o rango duplicado a unha táboa de rutas como prefixo máis específico só move a ambigüidade un paso. Tamén adoita romper a outra dirección, onde a resposta agora ten dúas orixes plausibles.
Acepte o deseño con tráfico nas dúas direccións
Demostre o deseño cunha operación permitida nova desde cada lado, non co estado do túnel. Un túnel IPsec conectado di que os pares coinciden en criptografía; non di nada sobre se os destinos se volveron distinguibles.
Despois execute as rutas denegadas: unha dirección que debe seguir inalcanzable e un servizo que a política debe bloquear. Se ambas seguen tendo éxito, a tradución é máis ampla do que pretendía o deseño.
Pecha cos feitos que explican a configuración máis adiante: o rango orixinal, o rango presentado, o dispositivo que traduce e a dirección na que cada lado pode iniciar. Se falta algún deles, o seguinte enxeñeiro herda unha rede onde dous hosts comparten nome e ninguén recorda por que un deles responde.