Azure VPN NAT löser inte överlappande VNet-adresser

Båda VNet använder 10.40.1.0/24, tunnlarna kommer upp och ingenting fungerar. Att lägga till en extra VPN-gateway ändrar inte det, och inte heller en lägre rutmetrik, eftersom problemet inte är vägval. Två arbetslaster som svarar på samma privata adress lämnar varje paket med ett tvetydigt mål och en overifierbar returväg. Innan du planerar någon översättning bör du ta reda på vilken anslutningstyp du faktiskt skapade, eftersom det enda valet avgör om NAT-funktionen i Azure ens är tillgänglig.

Vad symtomet egentligen säger dig

När en värd i VNet A skickar till 10.40.1.10 kan rutttabellen bara peka den någonstans. Om VNet B också innehåller 10.40.1.10 är den adressen inte ett mål som vägen kan skilja; det är en adress med två ägare.

Den andra gatewayen som folk vanligtvis driftsätter hjälper inte. Den ger en annan tunnel, inte en annan adress, och det duplicerade intervallet färdas oförändrat inuti tunneln. Den fördubblar också konfigurationen du måste hålla konsekvent. Det den inte kan är att få en adress att betyda två värdar.

Att ändra VPN-peers offentliga adresser gör inte heller något. De adresserna identifierar tunnelns ändpunkter, medan kollisionen ligger i det privata intervallet som bärs inuti den.

Anslutningstypen avgör om NAT är tillgängligt

Azure VPN Gateway har faktiskt en NAT-förmåga, och den är dokumenterad för ruttbaserade IPsec-förbindelser mellan platser på specifika gateway-SKU:er. Samma dokumentation utesluter VNet-till-VNet- och point-to-site-förbindelser, så funktionen är inte en kryssruta som dyker upp på varje gateway-relation.

Inbyggd VNet-till-VNet kräver också att VNet- och lokalnätsintervallen inte överlappar från början, vilket stämmer med uteslutningen. VNet-peering är inte en lösning på överlapp av samma skäl.

Det finns ett stött alternativ som folk förväxlar med den inbyggda typen: modellera det andra VNet:et som ett lokalt nätverk och anslut det som en plats-till-plats-förbindelse. Det är en annan resurs och en annan design, så behandla en omdöpt anslutning som en ändring som måste valideras, inte som en enkel namnändring.

Numrera om, eller översätt med något som äger aliaset

Om båda VNet är dina, jämför en planerad omnumrering med den löpande kostnaden för översättning. Omnumrering berör applikationskonfiguration, DNS-poster, säkerhetsregler och varje befintlig anslutning, men lämnar ett nätverk som läses normalt efteråt. Gör det ett subnät i taget, med DNS-ändringen sist. Ett halvt omnumrerat intervall är sämre än båda alternativen, eftersom båda prefixen då ser auktoritativa ut för den som läser tabellen nästa gång.

Där omnumrering inte är praktiskt, använd en översatt design med en riktig ägare för aliaset. Anropare i VNet A kan nå 10.40.1.10 i VNet B som 10.140.1.10, men det aliaset kräver en enhet som översätter, en rutt mot den och motsvarande beteende för svaret. En adress som bara läggs till i DNS är ingen översättning.

Registrera båda intervallen i båda riktningarna: vad anroparen slår, vad målet ser som källa och vilken sida som får initiera. Azures egna NAT-regler innehåller den omvända översättningen för sina SNAT-mappningar, så du skriver inte en matchande DNAT-regel för hand, men den bekvämligheten tar slut vid de anslutningstyper som funktionen stöder.

Vad som inte kommer att fungera

En användardefinierad rutt eller en rutmetrik kan inte skapa en saknad adressskillnad. Båda arbetar på ett mål som fortfarande är tvetydigt, och paketet når den nästa hopp som tabellen föredrar.

Att lägga det duplicerade intervallet i en rutttabell som ett mer specifikt prefix flyttar bara tvetydigheten ett steg. Det tenderar också att bryta den andra riktningen, där svaret nu har två troliga källor.

Acceptera designen med trafik i båda riktningarna

Bevisa designen med en färsk tillåten åtgärd från varje sida, inte med tunnelstatus. En ansluten IPsec-tunnel säger att parterna är överens om kryptografi; den säger ingenting om huruvida målen blev urskiljbara.

Kör sedan de nekade vägarna: en adress som ska förbli onåbar och en tjänst som policyn ska blockera. Om båda fortfarande lyckas är översättningen bredare än designen avsåg.

Avsluta med fakta som förklarar uppsättningen senare: det ursprungliga intervallet, det presenterade intervallet, enheten som översätter och riktningen varje sida får initiera i. Om något av detta saknas ärver nästa ingenjör ett nätverk där två värdar delar ett namn och ingen minns varför en av dem svarar.