Azure VPN NAT løser ikke overlappende VNet-adresser
To VNet med samme private område kobles ikke bare fordi NAT finnes. Sjekk tilkoblingstypen først, og omnummerer deretter eller eier et oversettelsesalias.
Begge VNet bruker 10.40.1.0/24, tunnelene kommer opp, men ingenting fungerer. En ekstra VPN-gateway endrer ikke dette, og heller ikke en lavere rutemetrikk, fordi problemet ikke er veivalg. To arbeidslaster som svarer på samme private adresse, gir hver pakke en tvetydig destinasjon og en returvei som ikke kan verifiseres. Før du planlegger en oversettelse, finn ut hvilken tilkoblingstype du faktisk opprettet, fordi det valget avgjør om NAT-funksjonen i Azure er tilgjengelig i det hele tatt.
Hva symptomet egentlig sier deg
Når en vert i VNet A sender til 10.40.1.10, kan rutetabellen bare peke den mot et sted. Hvis VNet B også har 10.40.1.10, er ikke den adressen en destinasjon veien kan skille; det er én adresse med to eiere.
Den andre gatewayen som vanligvis settes opp, hjelper ikke. Den gir en annen tunnel, ikke en annen adresse, og det dupliserte området går uendret gjennom tunnelen. Den dobler også konfigurasjonen du må holde konsistent. Det den ikke kan, er å gjøre én adresse til to verter.
Å endre de offentlige adressene til VPN-motpartene gjør heller ingen forskjell. Disse adressene identifiserer tunnelens endepunkter, mens kollisjonen ligger i det private området som fraktes inni den.
Tilkoblingstypen avgjør om NAT er tilgjengelig
Azure VPN Gateway har en NAT-funksjon, og den er dokumentert for rutebaserte IPsec-forbindelser mellom lokasjoner på bestemte gateway-SKU-er. Samme dokumentasjon utelukker VNet-til-VNet- og point-to-site-forbindelser, så funksjonen er ikke en avkrysningsboks som vises på alle gateway-relasjoner.
| 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 |
Innebygd VNet-til-VNet krever også at VNet- og lokalnettområdene ikke overlapper fra begynnelsen, noe som passer med utelukkelsen. VNet-peering er ikke en overlappsløsning av samme grunn.
Det finnes et støttet alternativ som ofte forveksles med den innebygde typen: modeller det andre VNet-et som et lokalt nettverk og koble det som en lokasjon-til-lokasjon-forbindelse. Det er en annen ressurs og et annet design, så behandle en omdøpt forbindelse som en endring som må valideres, ikke som en ren 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 alle eksisterende forbindelser, men etterlater et nettverk som leses normalt etterpå. Gjør det ett subnett om gangen, med DNS-endringen til slutt. Et halvt omnummerert område er verre enn begge alternativer, fordi begge prefiksene da virker autoritative for den som leser tabellen neste gang.
Der omnummerering ikke er praktisk, bruk et oversatt design med en reell eier for aliaset. Kallere i VNet A kan nå 10.40.1.10 i VNet B som 10.140.1.10, men dette 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 initiere. Azures egne NAT-regler inkluderer den motsatte oversettelsen for sine SNAT-mappinger, så du skriver ikke en tilsvarende DNAT-regel manuelt, men denne 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 kommer frem til 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 sannsynlige kilder.
Aksepter designet med trafikk i begge retninger
Bevis designet med en ny 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 banene: en adresse som skal forbli uoppnåelig, og en tjeneste som policyen skal blokkere. Hvis begge fortsatt lykkes, er oversettelsen bredere enn designet tilsiktet.
Avslutt med faktaene som forklarer oppsettet senere: det opprinnelige området, det presenterte området, enheten som oversetter, og retningen hver side kan initiere 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.