Azure VPN NAT lost oerlappende VNet-adressen net op
Twa VNet mei deselde privee-rige ferbine net omdat NAT bestiet. Kontrolearje earst it ferbiningstype en dan opnij nûmerje of besit in oersettingsalias.
Beide VNet brûke 10.40.1.0/24, de tunnels komme omheech, en neat wurket. In twadde VPN-gateway tafoegje feroaret dat net, en in legere rûtemetrik ek net, want it probleem is net paadseleksje. Twa workloads dy't itselde privee-adres beantwurdzje litte elk pakket mei in dûbelsinnige bestimming en in net-ferifiearbere weromwei. Foardat jo hokker oersetting dan ek plenje, sykje út hokker ferbiningstype jo echt makke hawwe, want dy iene kar beslúttet oft de NAT-funksje fan Azure hielendal beskikber is.
Wat it symptoom jo echt fertelt
As in host yn VNet A nei 10.40.1.10 stjoert, kin de rûtetabel it allinne earne hinne wize. As VNet B ek 10.40.1.10 befettet, is dat adres net in bestimming dy't it paad ûnderskiede kin; it is ien adres mei twa eigners.
De twadde gateway dy't minsken gewoanwei útrolle helpt net. It jout jo in oare tunnel, net in oar adres, en de dûbele rige reizget ûnferoare yn 'e tunnel. It ferdûbelet ek de konfiguraasje dy't jo konsekwint hâlde moatte. Wat it net kin, is ien adres twa hosts betsjutte litte.
It feroarjen fan 'e iepenbiere adressen fan 'e VPN-peers docht ek neat. Dy adressen identifisearje de tunnel-einpunten, wylst de botsing yn 'e privee-rige sit dy't der binnenyn ferfierd wurdt.
It ferbiningstype beslúttet oft NAT beskikber is
Azure VPN Gateway hat wol in NAT-mooglikheid, en dy is dokumintearre foar rûte-basearre IPsec-ferbiningen tusken lokaasjes op spesifike gateway-SKU's. Deselde dokumintaasje slút VNet-to-VNet- en point-to-site-ferbiningen út, dus de funksje is gjin kontrôlefakje dat by elke gateway-relaasje ferskynt.
| 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 |
Nativer VNet-to-VNet freget ek dat de VNet- en lokale-netwurkriges fan it begjin ôf net oerlappe, wat oerienkomt mei de útsluting. VNet-peering is om deselde reden gjin oplossing foar oerlaap.
Der is in stipe alternatyf dat minsken mei it native type betize: modellearje it oare VNet as in lokaal netwurk en ferbyn it as in site-to-site-ferbining. Dat is in oare boarne en in oar ûntwerp, behannelje in omneamde ferbining dus as in feroaring dy't falidearre wurde moat, net as in gewoane omneaming.
Nûmerje opnij, of oersette mei eat dat it alias besit
As beide VNet fan jo binne, fergelykje in plande opnij-nûmering mei de oanhâldende kosten fan oersetting. Opnij-nûmering rekket applikaasjekonfiguraasje, DNS-records, feiligensregels en elke besteande ferbining, mar lit in netwurk efter dat dêrnei normaal lêst. Doch it ien subnet tagelyk, mei de DNS-feroaring lêst. In heal opnij nûmere rige is slimmer as beide opsjes, want dan lykje beide prefiksen gesachhawwend foar wa't de tabel folgjende lêst.
Wêr't opnij-nûmering net praktysk is, brûk in oersette ûntwerp mei in echte eigner foar it alias. Skellers yn VNet A berikke miskien 10.40.1.10 fan VNet B as 10.140.1.10, mar dat alias hat in apparaat nedich dat oerset, in rûte dêrhinne en oerienkommend gedrach foar it antwurd. In adres dat allinne oan DNS taheakke is, is gjin oersetting.
Registrearje beide riges yn beide rjochtingen: wat de skeller kiist, wat de bestimming as boarne sjocht, en hokker kant inisjearje mei. De eigen NAT-regels fan Azure befetsje de omkearde oersetting foar har SNAT-mappings, dus jo skriuwe net mei de hân in oerienkommende DNAT-regel, mar dat gemak hâldt op by de ferbiningstypes dy't de funksje stipet.
Wat net wurkje sil
In troch de brûker definiearre rûte of in rûtemetrik kin gjin ûntbrekkend adresûnderskied meitsje. Beide wurkje op in bestimming dy't noch dûbelsinnich is, en it pakket komt by hokker folgjende hop dan ek dy't de tabel foarkar jout.
It tafoegjen fan de dûbele rige oan in rûtetabel as in mear spesifyk prefiks ferpleatst de dûbelsinnigens mar ien stap. It hat ek de oanstriid om de oare rjochting te brekken, wêr't it antwurd no twa leauweardige boarnen hat.
Akseptearje it ûntwerp mei ferkear yn beide rjochtingen
Bewiis it ûntwerp mei in farske tastiene operaasje fan elke kant, net mei tunnelstatus. In ferbûne IPsec-tunnel seit dat de peers it iens binne oer krypto; it seit neat oer oft de bestimmingen ûnderskiedber wurden binne.
Rin dan de wegere paden: in adres dat ûnberikber bliuwe moat, en in tsjinst dy't it belied blokkearje moat. As beide noch slagje, is de oersetting breder as it ûntwerp bedoelde.
Slút ôf mei de feiten dy't de opset letter ferklearje: de oarspronklike rige, de presintearre rige, it apparaat dat oerset, en de rjochting dêr't elke kant yn inisjearje mei. As ien fan dy ûntbrekt, erft de folgjende yngenieur in netwurk dêr't twa hosts in namme diele en gjinien him betinkt wêrom't ien fan harren antwurdet.