NAT në Azure VPN nuk i zgjidh adresat VNet që mbivendosen
Dy VNet me të njëjtin interval privat nuk lidhen vetëm sepse ekziston NAT. Kontrolloni fillimisht llojin e lidhjes, pastaj rinumëroni ose zotëroni një alias përkthimi.
Të dyja VNet përdorin 10.40.1.0/24, tunelet ngrihen dhe asgjë nuk funksionon. Shtimi i një gateway VPN të dytë nuk e ndryshon këtë, as një metrikë route më e ulët, sepse problemi nuk është zgjedhja e rrugës. Dy ngarkesa pune që përgjigjen në të njëjtën adresë private lënë çdo paketë me një destinacion të paqartë dhe një rrugë kthimi të paverifikueshme. Përpara se të planifikoni çdo përkthim, zbuloni çfarë lloj lidhjeje keni krijuar në të vërtetë, sepse ajo zgjedhje e vetme vendos nëse funksioni NAT i Azure është fare i disponueshëm.
Çfarë po ju thotë në të vërtetë simptoma
Kur një host në VNet A dërgon te 10.40.1.10, tabela e rrugëtimit mund vetëm ta drejtojë diku. Nëse edhe VNet B përmban 10.40.1.10, ajo adresë nuk është një destinacion që rruga mund ta dallojë; është një adresë me dy pronarë.
Gateway-i i dytë që njerëzit zakonisht vendosin nuk ndihmon. Ju jep një tunel tjetër, jo një adresë tjetër, dhe intervali i dubluar udhëton brenda tunelit pa ndryshim. Ai gjithashtu dyfishon konfigurimin që duhet ta mbani konsistent. Ajo që nuk mund të bëjë është të bëjë një adresë të nënkuptojë dy hoste.
Ndryshimi i adresave publike të partnerëve VPN gjithashtu nuk bën asgjë. Ato adresa identifikojnë pikat fundore të tunelit, ndërsa përplasja është në intervalin privat që transportohet brenda.
Lloji i lidhjes vendos nëse NAT është i disponueshëm
Azure VPN Gateway ka vërtet një aftësi NAT, dhe ajo është dokumentuar për lidhjet IPsec ndërmjet site-ve të bazuara në rrugë në SKU specifike gateway. I njëjti dokumentacion përjashton lidhjet VNet-to-VNet dhe point-to-site, prandaj funksioni nuk është një kuti kontrolli që shfaqet në çdo lidhje gateway.
| 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 |
VNet-to-VNet origjinale kërkon gjithashtu që intervalet VNet dhe të rrjetit lokal të mos mbivendosen që në fillim, gjë që përputhet me përjashtimin. Edhe bashkimi VNet nuk është zgjidhje për mbivendosjen për të njëjtën arsye.
Ekziston një alternativë e mbështetur që njerëzit e ngatërrojnë me llojin origjinal: modeloni VNet-in tjetër si rrjet lokal dhe lidheni si lidhje site-to-site. Ky është një burim tjetër dhe një dizajn tjetër, prandaj trajtojeni një lidhje të riemërtuar si një ndryshim që duhet validuar, jo si një riemërtim të thjeshtë.
Rinumëroni, ose përktheni me diçka që zotëron aliasin
Nëse të dyja VNet janë tuajat, krahasoni një rinumërim të planifikuar me koston e vazhdueshme të përkthimit. Rinumërimi prek konfigurimin e aplikacioneve, regjistrimet DNS, rregullat e sigurisë dhe çdo lidhje ekzistuese, por lë një rrjet që lexohet normalisht më pas. Bëjeni një nënrrjet në një herë, me ndryshimin e DNS të fundit. Një interval gjysmë i rinumëruar është më keq se të dyja opsionet, sepse atëherë të dy prefikset duken autoritativë për këdo që lexon tabelën më pas.
Aty ku rinumërimi nuk është praktik, përdorni një dizajn të përkthyer me një pronar real për aliasin. Thirrësit në VNet A mund të arrijnë 10.40.1.10 të VNet B si 10.140.1.10, por ai alias kërkon një pajisje që përkthen, një rrugë drejt saj dhe një sjellje përputhëse për përgjigjen. Një adresë e shtuar vetëm në DNS nuk është përkthim.
Regjistroni të dy intervalet në të dy drejtimet: çfarë formon thirrësi, çfarë sheh destinacioni si burim dhe cila anë mund të iniciojë. Rregullat NAT të vetë Azure përfshijnë përkthimin e kundërt për hartëzimet e tyre SNAT, prandaj nuk shkruani me dorë një rregull DNAT përputhës, por ajo lehtësi ndalon tek llojet e lidhjeve që funksioni mbështet.
Çfarë nuk do të funksionojë
Një rrugë e përcaktuar nga përdoruesi ose një metrikë route nuk mund të krijojnë një dallim adresash që mungon. Të dyja veprojnë mbi një destinacion ende të paqartë, dhe paketa arrin në hopin e radhës që tabela preferon.
Shtimi i intervalit të dubluar në një tabelë rrugëtimi si prefiks më specifik lëviz paqartësinë vetëm një hap. Gjithashtu priret të prishë drejtimin e kundërt, ku përgjigja tani ka dy burime të besueshme.
Pranoni dizajnin me trafik në të dy drejtimet
Provoni dizajnin me një operacion të ri të lejuar nga secila anë, jo me statusin e tunelit. Një tunel IPsec i lidhur thotë që partnerët bien dakord për kriptografinë; nuk thotë asgjë nëse destinacionet u bënë të dallueshme.
Më pas ekzekutoni rrugët e refuzuara: një adresë që duhet të mbetet e paarritshme dhe një shërbim që politika duhet të bllokojë. Nëse të dyja ende kanë sukses, përkthimi është më i gjerë sesa synonte dizajni.
Përfundoni me faktet që shpjegojnë konfigurimin më vonë: intervali origjinal, intervali i paraqitur, pajisja që përkthen dhe drejtimi në të cilin secila anë mund të iniciojë. Nëse mungon ndonjëri prej tyre, inxhinieri i radhës trashëgon një rrjet ku dy hoste ndajnë një emër dhe askujt nuk i kujtohet pse njëri prej tyre përgjigjet.