Azure VPN NAT løser ikke overlappende VNet-adresser

Begge VNet bruger 10.40.1.0/24, tunnelerne kommer op, og intet virker. At tilføje en ekstra VPN-gateway ændrer ikke det, og en lavere rutemetrik gør heller ikke, fordi problemet ikke er valg af sti. To arbejdsbelastninger, der svarer på samme private adresse, efterlader hver pakke med en tvetydig destination og en uverificerbar returvej. Før du planlægger nogen oversættelse, skal du finde ud af, hvilken forbindelsestype du faktisk har oprettet, for det ene valg afgør, om Azures NAT-funktion overhovedet er tilgængelig.

Hvad symptomet egentlig fortæller dig

Når en vært i VNet A sender til 10.40.1.10, kan rutetabellen kun pege den et sted hen. Hvis VNet B også indeholder 10.40.1.10, er den adresse ikke en destination, som stien kan skelne; det er én adresse med to ejere.

Den anden gateway, som folk normalt udruller, hjælper ikke. Den giver dig en anden tunnel, ikke en anden adresse, og det duplikerede interval rejser uændret inde i tunnelen. Den fordobler også den konfiguration, du skal holde konsistent. Det, den ikke kan, er at få én adresse til at betyde to værter.

At ændre VPN-peerenes offentlige adresser gør heller ingenting. De adresser identificerer tunnelens endepunkter, mens kollisionen ligger i det private interval, der bæres inde i den.

Forbindelsestypen afgør, om NAT er tilgængelig

Azure VPN Gateway har faktisk en NAT-funktion, og den er dokumenteret til rutebaserede IPsec-forbindelser mellem lokationer på bestemte gateway-SKU'er. Den samme dokumentation udelukker VNet-to-VNet- og point-to-site-forbindelser, så funktionen er ikke et afkrydsningsfelt, der vises på hver gateway-relation.

Native VNet-to-VNet kræver også, at VNet- og lokalnetværksintervallerne ikke overlapper fra starten, hvilket er i overensstemmelse med udelukkelsen. VNet-peering er ikke en løsning på overlap af samme grund.

Der findes et understøttet alternativ, som folk forveksler med den native type: modellér det andet VNet som et lokalt netværk, og forbind det som lokation-til-lokation. Det er en anden ressource og et andet design, så behandl en omdøbt forbindelse som en ændring, der skal valideres, ikke som en omdøbning.

Omnummerér, eller oversæt med noget, der ejer aliaset

Hvis begge VNet er dine, skal du sammenligne en planlagt omnummerering med den løbende omkostning ved oversættelse. Omnummerering berører applikationskonfiguration, DNS-poster, sikkerhedsregler og hver eksisterende forbindelse, men efterlader et netværk, der læses normalt bagefter. Gør det ét undernet ad gangen, med DNS-ændringen sidst. Et halvt omnummereret interval er værre end nogen af de to muligheder, fordi begge præfikser derefter ser autoritative ud for den, der læser tabellen næste gang.

Hvor omnummerering ikke er praktisk, skal du bruge et oversat design med en rigtig ejer af aliaset. Kaldere i VNet A kan nå VNet B's 10.40.1.10 som 10.140.1.10, men det alias kræver en enhed, der oversætter, en rute mod den og tilsvarende adfærd for svaret. En adresse, der kun tilføjes i DNS, er ikke en oversættelse.

Registrér begge intervaller i begge retninger: hvad kalderen ringer til, hvad destinationen ser som kilde, og hvilken side der må tage initiativet. Azures egne NAT-regler inkluderer den omvendte oversættelse for deres SNAT-mappinger, så du skriver ikke en matchende DNAT-regel i hånden, men den bekvemmelighed stopper ved de forbindelsestyper, som funktionen understøtter.

Hvad ikke vil virke

En brugerdefineret rute eller en rutemetrik kan ikke skabe en manglende adresseforskel. Begge arbejder på en destination, der stadig er tvetydig, og pakken ankommer til det næste hop, som tabellen foretrækker.

At tilføje det duplikerede interval til en rutetabel som et mere specifikt præfiks flytter kun tvetydigheden ét skridt. Det har også tendens til at bryde den anden retning, hvor svaret nu har to plausible kilder.

Accepter designet med trafik i begge retninger

Bevis designet med en frisk tilladte operation fra hver side, ikke med tunnelstatus. En tilsluttet IPsec-tunnel siger, at parterne er enige om krypto; den siger intet om, hvorvidt destinationerne blev skelnelige.

Kør derefter de afviste stier: en adresse, der skal forblive uopnåelig, og en tjeneste, som politikken skal blokere. Hvis begge stadig lykkes, er oversættelsen bredere, end designet tilsigtede.

Afslut med de fakta, der forklarer opsætningen senere: det oprindelige interval, det præsenterede interval, enheden der oversætter, og den retning hver side må tage initiativet i. Hvis noget af det mangler, arver den næste ingeniør et netværk, hvor to værter deler et navn, og ingen husker, hvorfor én af dem svarer.