Azure VPN NAT løser ikke overlappende VNet-adresser

Begge VNet bruker 10.40.1.0/24, tunnelene kommer opp, og ingenting virker. Å legge til en ekstra VPN-gateway endrer ikke det, og en lavere rutemetrikk gjør det heller ikke, fordi problemet ikke er veivalg. To arbeidsbelastninger som svarer på samme private adresse, etterlater hver pakke med en tvetydig destinasjon og en ubekreftbar returvei. Før du planlegger noen oversettelse, må du finne ut hvilken tilkoblingstype du faktisk har opprettet, fordi det ene valget avgjør om NAT-funksjonen i Azure i det hele tatt er tilgjengelig.

Hva symptomet egentlig forteller deg

Når en vert i VNet A sender til 10.40.1.10, kan rutetabellen bare peke den et sted. Hvis VNet B også inneholder 10.40.1.10, er den adressen ikke en destinasjon veien kan skille; det er én adresse med to eiere.

Den andre gatewayen folk vanligvis setter opp, hjelper ikke. Den gir deg en annen tunnel, ikke en annen adresse, og det dupliserte området reiser uendret inne i tunnelen. Den dobbler også konfigurasjonen du må holde konsistent. Det den ikke kan, er å få én adresse til å bety to verter.

Å endre de offentlige adressene til VPN-peerene gjør heller ingenting. De adressene identifiserer tunnelens endepunkter, mens kollisjonen ligger i det private området som bæres inne i den.

Tilkoblingstypen avgjør om NAT er tilgjengelig

Azure VPN Gateway har faktisk en NAT-funksjon, og den er dokumentert for rutebaserte IPsec-forbindelser mellom lokasjoner på bestemte gateway-SKU-er. Den samme dokumentasjonen utelukker VNet-to-VNet- og point-to-site-forbindelser, så funksjonen er ikke en avkrysningsboks som dukker opp på hver gateway-relasjon.

Native VNet-to-VNet krever også at VNet- og lokalnettområdene ikke overlapper fra starten, noe som stemmer med utelukkelsen. VNet-peering er ikke en løsning på overlapp av samme grunn.

Det finnes et støttet alternativ som folk forveksler med den native typen: modeller det andre VNet-et som et lokalt nettverk og koble det til som lokasjon-til-lokasjon. Det er en annen ressurs og et annet design, så behandle en omdøpt forbindelse som en endring som må valideres, ikke som en omdøping.

Omnummerer, eller oversett med noe som eier aliaset

Hvis begge VNet er dine, sammenlign en planlagt omnummerering med den løpende kostnaden ved oversettelse. Omnummerering berører applikasjonskonfigurasjon, DNS-poster, sikkerhetsregler og hver eksisterende forbindelse, men etterlater et nettverk som leses normalt etterpå. Gjør det ett subnett om gangen, med DNS-endringen sist. Et halvt omnummerert område er verre enn begge alternativene, fordi begge prefiksene da ser autoritative ut for den som leser tabellen neste gang.

Der omnummerering ikke er praktisk, bruk et oversatt design med en ekte eier for aliaset. Kallere i VNet A kan nå 10.40.1.10 i VNet B som 10.140.1.10, men det aliaset trenger en enhet som oversetter, en rute mot den og samsvarende oppførsel for svaret. En adresse som bare legges til i DNS, er ikke en oversettelse.

Registrer begge områdene i begge retninger: hva kalleren ringer, hva destinasjonen ser som kilde, og hvilken side som kan ta initiativet. Azures egne NAT-regler inkluderer den omvendte oversettelsen for sine SNAT-mappinger, så du skriver ikke en samsvarende DNAT-regel for hånd, men den bekvemmeligheten stopper ved tilkoblingstypene funksjonen støtter.

Hva som ikke vil fungere

En brukerdefinert rute eller en rutemetrikk kan ikke skape en manglende adresseforskjell. Begge arbeider på en destinasjon som fortsatt er tvetydig, og pakken ankommer den neste hoppen tabellen foretrekker.

Å legge det dupliserte området inn i en rutetabell som et mer spesifikt prefiks flytter bare tvetydigheten ett steg. Det har også en tendens til å ødelegge den andre retningen, der svaret nå har to mulige kilder.

Aksepter designet med trafikk i begge retninger

Bevis designet med en fersk tillatt operasjon fra hver side, ikke med tunnelstatus. En tilkoblet IPsec-tunnel sier at partene er enige om kryptografi; den sier ingenting om hvorvidt destinasjonene ble skillbare.

Kjør deretter de avviste stiene: en adresse som skal forbli uoppnåelig, og en tjeneste som policyen skal blokkere. Hvis begge fortsatt lykkes, er oversettelsen bredere enn designet mente.

Avslutt med faktaene som forklarer oppsettet senere: det opprinnelige området, det presenterte området, enheten som oversetter, og retningen hver side kan ta initiativet i. Hvis noe av dette mangler, arver neste ingeniør et nettverk der to verter deler et navn og ingen husker hvorfor en av dem svarer.