Azure VPN NAT neišsprendžia persidengiančių VNet adresų
Du VNet su ta pačia privačia sritimi neprisijungs vien todėl, kad yra NAT. Pirmiausia patikrinkite ryšio tipą, tada pernumeruokite arba turėkite vertimo slapyvardį.
Abu VNet naudoja 10.40.1.0/24, tuneliai pakyla ir niekas neveikia. Antro VPN šliuzo pridėjimas to nepakeis, nei mažesnė maršruto metrika, nes problema ne maršruto pasirinkime. Dvi darbo apkrovos, atsakančios į tą patį privatų adresą, palieka kiekvieną paketą su dviprasmišku tikslu ir nepatikrinamu grįžimo keliu. Prieš planuodami bet kokį vertimą, išsiaiškinkite, kokį ryšio tipą iš tikrųjų sukūrėte, nes šis vienintelis pasirinkimas lemia, ar Azure NAT funkcija apskritai prieinama.
Ką šis simptomas iš tikrųjų jums sako
Kai VNet A mazgas siunčia į 10.40.1.10, maršrutų lentelė gali tik nukreipti jį kažkur. Jei VNet B taip pat turi 10.40.1.10, šis adresas nėra tikslas, kurį maršrutas galėtų atskirti; tai vienas adresas su dviem savininkais.
Antras šliuzas, kurį žmonės paprastai diegia, nepadeda. Jis duoda kitą tunelį, o ne kitą adresą, o pasikartojanti sritis keliauja tunelio viduje nepakitusi. Jis taip pat padvigubina konfigūraciją, kurią turite išlaikyti nuoseklią. Ko jis negali, tai padaryti, kad vienas adresas reikštų du mazgus.
VPN partnerių viešųjų adresų keitimas taip pat nieko neduoda. Tie adresai identifikuoja tunelio galinius taškus, o susidūrimas yra privačioje srityje, pernešamoje viduje.
Ryšio tipas lemia, ar NAT prieinamas
Azure VPN Gateway tikrai turi NAT galimybę, ir ji dokumentuota maršrutais pagrįstiems IPsec ryšiams tarp vietų tam tikruose šliuzo SKU. Ta pati dokumentacija neapima VNet-to-VNet ir point-to-site ryšių, todėl ši funkcija nėra žymės langelis, atsirandantis kiekviename šliuzo santykyje.
| 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 |
Vietinis VNet-to-VNet taip pat reikalauja, kad VNet ir vietinio tinklo sritys nuo pradžių nesidengtų, o tai atitinka išimtį. VNet susiejimas taip pat nėra persidengimo sprendimas dėl tos pačios priežasties.
Yra palaikoma alternatyva, kurią žmonės painioja su vietiniu tipu: modeliuokite kitą VNet kaip vietinį tinklą ir prijunkite jį kaip ryšį tarp vietų. Tai kitas išteklius ir kitas dizainas, todėl pervadintą ryšį traktuokite kaip pokytį, kurį reikia patvirtinti, o ne kaip paprastą pervadinimą.
Pernumeruokite arba verskite tuo, kas valdo slapyvardį
Jei abu VNet yra jūsų, palyginkite planuojamą pernumeravimą su nuolatine vertimo kaina. Pernumeravimas paliečia programų konfigūraciją, DNS įrašus, saugos taisykles ir kiekvieną esamą ryšį, bet palieka tinklą, kuris vėliau skaitomas normaliai. Darykite tai po vieną potinklį, o DNS pakeitimą paskutinį. Pusiau pernumeruota sritis yra blogiau nei bet kuris variantas, nes tada abu priešdėliai atrodo autoritetingi tam, kas kitą kartą skaitys lentelę.
Kai pernumeravimas nepraktiškas, naudokite išverstą dizainą su tikru slapyvardžio savininku. VNet A skambintojai gali pasiekti VNet B 10.40.1.10 kaip 10.140.1.10, bet tam slapyvardžiui reikia įrenginio, kuris verčia, maršruto link jo ir atsakymui atitinkančio elgesio. Adresas, pridėtas tik į DNS, nėra vertimas.
Užrašykite abi sritis abiem kryptimis: ką renka skambintojas, ką tikslas mato kaip šaltinį ir kuri pusė gali inicijuoti. Azure NAT taisyklės apima atvirkštinį vertimą savo SNAT susiejimams, todėl atitinkamos DNAT taisyklės ranka nerašote, tačiau šis patogumas baigiasi ties tais ryšio tipais, kuriuos funkcija palaiko.
Kas neveiks
Vartotojo apibrėžtas maršrutas ar maršruto metrika negali sukurti trūkstamo adresų atskyrimo. Abu veikia dviprasmišką tikslą, o paketas patenka į tą kitą šuolį, kurį lentelė teikia pirmenybę.
Pasikartojančios srities pridėjimas į maršrutų lentelę kaip konkretesnio priešdėlio tik perkelia dviprasmiškumą vienu žingsniu. Jis taip pat linkęs sugadinti priešingą kryptį, kur atsakymas dabar turi du tikėtinus šaltinius.
Priimkite dizainą su srautu abiem kryptimis
Įrodykite dizainą nauja leidžiama operacija iš kiekvienos pusės, o ne tunelio būsena. Prisijungęs IPsec tunelis sako, kad partneriai sutaria dėl kriptografijos; jis nieko nesako apie tai, ar tikslai tapo atskiriami.
Tada paleiskite draudžiamus kelius: adresą, kuris turi likti nepasiekiamas, ir paslaugą, kurią politika turi blokuoti. Jei abu vis dar pavyksta, vertimas platesnis nei dizainas numatė.
Užbaikite faktais, kurie vėliau paaiškins sąranką: pradinė sritis, pateikta sritis, įrenginys, kuris verčia, ir kryptis, kuria kiekviena pusė gali inicijuoti. Jei kurio nors trūksta, kitas inžinierius paveldi tinklą, kuriame du mazgai dalijasi vardu ir niekas neprisimena, kodėl vienas iš jų atsako.