NAT i Azure VPN løyser ikkje overlappande VNet-adresser
To VNet med same private område vert ikkje kopla berre fordi NAT finst. Sjekk fyrst kva slags tilkopling du har laga, og nummerer deretter om eller eig eit omsetjingsalias.
Båe VNet brukar 10.40.1.0/24, tunellane kjem opp, og ingenting verkar. Å leggje til ein ekstra VPN-gateway endrar ikkje det, og ein lågare rutemetrikk gjer det heller ikkje, fordi problemet ikkje er vegval. To arbeidslaster som svarar på same private adresse, lèt kvar pakke liggje att med eit tvitydig mål og ein returveg som ikkje kan stadfestast. Før du planlegg noka omsetjing, må du finne ut kva slags tilkopling du faktisk har laga, fordi det eine valet avgjer om NAT-funksjonen i Azure i det heile er tilgjengeleg.
Kva symptomet eigentleg fortel deg
Når ein vert i VNet A sender til 10.40.1.10, kan rutetabellen berre peike han ein stad. Viss VNet B òg inneheld 10.40.1.10, er den adressa ikkje eit mål vegen kan skilje; det er éi adresse med to eigarar.
Den andre gatewayen folk vanlegvis set opp, hjelper ikkje. Han gjev deg ein annan tunell, ikkje ei anna adresse, og det dobla området fer uendra inne i tunellen. Han doblar òg konfigurasjonen du må halde konsistent. Det han ikkje kan, er å få éi adresse til å tyde to vertar.
Å endre dei offentlege adressene til VPN-peerane gjer heller ingenting. Dei adressene identifiserer endepunkta til tunellen, medan kollisjonen ligg i det private området som vert bore inne i han.
Tilkoplingstypen avgjer om NAT er tilgjengeleg
Azure VPN Gateway har faktisk ein NAT-funksjon, og han er dokumentert for rutebaserte IPsec-samband mellom lokasjonar på bestemte gateway-SKU-ar. Den same dokumentasjonen utelukkar VNet-til-VNet- og point-to-site-samband, så funksjonen er ikkje ei avkryssingsboks som dukkar opp på kvar gateway-relasjon.
| 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 |
Innfødd VNet-til-VNet krev òg at VNet- og lokalnettområda ikkje overlappar frå starten, noko som stemmer med utelukkinga. VNet-peering er ikkje ei løysing på overlapp av same grunn.
Det finst eit støtta alternativ som folk forvekslar med den innfødde typen: modeller det andre VNet-et som eit lokalt nettverk og kople det til som lokasjon-til-lokasjon. Det er ein annan ressurs og eit anna design, så handsam ein omdøypt tilkopling som ei endring som må validerast, ikkje som ei omdøyving.
Nummerer om, eller set om med noko som eig aliaset
Viss båe VNet er dine, samanlikn ei planlagd omnummerering med den løpande kostnaden ved omsetjing. Omnummerering rører applikasjonskonfigurasjon, DNS-oppføringar, tryggingsreglar og kvart eksisterande samband, men lèt att eit nettverk som vert lese normalt etterpå. Gjer det eitt subnett om gongen, med DNS-endringa sist. Eit halvt omnummerert område er verre enn båe alternativa, fordi båe prefiksa då ser autoritative ut for den som les tabellen neste gong.
Der omnummerering ikkje er praktisk, bruk eit omsett design med ein ekte eigar for aliaset. Kallarar i VNet A kan nå 10.40.1.10 i VNet B som 10.140.1.10, men det aliaset treng ein eining som set om, ein rute mot han og samsvarande åtferd for svaret. Ei adresse som berre vert lagd til i DNS, er ikkje ei omsetjing.
Registrer båe områda i båe retningar: kva kallaren slår, kva målet ser som kjelde, og kva side som kan ta initiativet. Dei eigne NAT-reglane til Azure tek med den omvende omsetjinga for SNAT-mappingane sine, så du skriv ikkje ei samsvarande DNAT-regel for hand, men den enkelheita stoppar ved tilkoplingstypane funksjonen støttar.
Kva som ikkje vil verke
Ein brukardefinert rute eller ein rutemetrikk kan ikkje skape ein manglande adresseskilnad. Båe arbeider på eit mål som framleis er tvitydig, og pakken kjem fram til den neste hoppen tabellen føretrekkjer.
Å leggje det dobla området inn i ein rutetabell som eit meir spesifikt prefiks flyttar berre tvitydigheita eitt steg. Det har òg ei tilbøying til å øydeleggje den andre retninga, der svaret no har to moglege kjelder.
Godta designet med trafikk i båe retningar
Prov designet med ein fersk tillaten operasjon frå kvar side, ikkje med tunellstatus. Ein tilkopla IPsec-tunell seier at partane er samde om kryptografi; han seier ingenting om måla vart skilbare.
Køyr deretter dei avviste stigane: ei adresse som skal halde fram med å vere utilgjengeleg, og ei teneste som policyen skal blokkere. Viss båe framleis lukkast, er omsetjinga breiare enn designet meinte.
Avslutt med fakta som forklarar oppsettet seinare: det opphavlege området, det presenterte området, eininga som set om, og retninga kvar side kan ta initiativet i. Viss noko av dette manglar, arvar neste ingeniør eit nettverk der to vertar deler eit namn og ingen hugsar kvifor ein av dei svarar.