NAT v Azure VPN ne odpravi prekrivajočih se naslovov VNet
Dve VNet z istim zasebnim obsegom se ne povežeta samo zato, ker NAT obstaja. Najprej preverite vrsto povezave, nato preštevilčite ali imejte alias prevoda.
Obe VNet uporabljata 10.40.1.0/24, tuneli se dvignejo in nič ne deluje. Dodajanje drugega prehoda VPN tega ne spremeni, tudi nižja metrika poti ne, ker težava ni v izbiri poti. Dve delovni obremenitvi, ki odgovarjata na isti zasebni naslov, pustita vsak paket z dvoumnim ciljem in nepreverljivo povratno potjo. Preden načrtujete kakršen koli prevod, ugotovite, katero vrsto povezave ste v resnici ustvarili, ker ta ena izbira odloči, ali je funkcija NAT v Azure sploh na voljo.
Kaj vam simptom v resnici sporoča
Ko gostitelj v VNet A pošlje na 10.40.1.10, ga lahko usmerjevalna tabela samo nekam usmeri. Če tudi VNet B vsebuje 10.40.1.10, ta naslov ni cilj, ki bi ga pot lahko razlikovala; to je en naslov z dvema lastnikoma.
Drugi prehod, ki ga ljudje običajno uvedejo, ne pomaga. Daje drug tunel, ne drug naslov, in podvojeni obseg potuje znotraj tunela nespremenjen. Prav tako podvoji konfiguracijo, ki jo morate ohranjati usklajeno. Česar ne more, je narediti, da en naslov pomeni dva gostitelja.
Spreminjanje javnih naslovov partnerjev VPN prav tako ne naredi ničesar. Ti naslovi označujejo končne točke tunela, medtem ko je trčenje v zasebnem obsegu, ki se prenaša znotraj njega.
Vrsta povezave odloči, ali je NAT na voljo
Azure VPN Gateway ima res možnost NAT in ta je dokumentirana za medspletne povezave IPsec, ki temeljijo na poteh, na določenih SKU-jih prehoda. Ista dokumentacija izključuje povezave VNet-to-VNet in point-to-site, zato funkcija ni potrditveno polje, ki bi se pojavilo pri vsakem odnosu prehoda.
| 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 |
Izvorni VNet-to-VNet tudi zahteva, da se obsegi VNet in lokalnega omrežja že od začetka ne prekrivajo, kar je skladno z izključitvijo. VNet peering ni rešitev za prekrivanje iz istega razloga.
Obstaja podprta alternativa, ki jo ljudje zamenjujejo z izvorno vrsto: modelirajte drugo VNet kot lokalno omrežje in jo povežite kot povezavo med lokacijami. To je drug vir in druga zasnova, zato preimenovano povezavo obravnavajte kot spremembo, ki jo je treba potrditi, ne kot preprosto preimenovanje.
Preštevilčite ali prevajajte z nečim, kar ima alias
Če sta obe VNet vaši, primerjajte načrtovano preštevilčenje s stalnimi stroški prevajanja. Preštevilčenje se dotakne konfiguracije aplikacij, zapisov DNS, varnostnih pravil in vsake obstoječe povezave, a pusti omrežje, ki se nato bere običajno. Naredite to po eno podomrežje naenkrat, s spremembo DNS na koncu. Na pol preštevilčen obseg je slabši od obeh možnosti, ker sta potem oba predpone videti verodostojna za tistega, ki bo naslednji prebral tabelo.
Kjer preštevilčenje ni praktično, uporabite prevedeno zasnovo z resničnim lastnikom aliasa. Klicatelji v VNet A lahko dosežejo 10.40.1.10 v VNet B kot 10.140.1.10, a ta alias potrebuje napravo, ki prevaja, pot do nje in ustrezno vedenje za odgovor. Naslov, dodan samo v DNS, ni prevod.
Zabeležite oba obsega v obeh smereh: kaj klicatelj izbere, kaj cilj vidi kot vir in katera stran lahko začne. Lastna pravila NAT v Azure vključujejo obratni prevod za svoje preslikave SNAT, zato ustreznega pravila DNAT ne pišete ročno, a ta priročnost se ustavi pri vrstah povezav, ki jih funkcija podpira.
Kaj ne bo delovalo
Uporabniško določena pot ali metrika poti ne moreta ustvariti manjkajočega razlikovanja naslovov. Oba delujeta na cilju, ki je še vedno dvoumen, in paket prispe do naslednjega skoka, ki mu tabela daje prednost.
Dodajanje podvojenega obsega v usmerjevalno tabelo kot bolj specifične predpone premakne dvoumnost samo za en korak. Prav tako ponavadi pokvari nasprotno smer, kjer ima odgovor zdaj dva verjetna vira.
Sprejmite zasnovo s prometom v obeh smereh
Dokažite zasnovo s svežo dovoljeno operacijo z vsake strani, ne s stanjem tunela. Povezan tunel IPsec pove, da so partnerji soglasni glede kriptografije; ne pove ničesar o tem, ali so cilji postali razločljivi.
Nato zaženite prepovedane poti: naslov, ki mora ostati nedosegljiv, in storitev, ki jo mora politika blokirati. Če oba še vedno uspeta, je prevod širši, kot je zasnova nameravala.
Zaključite z dejstvi, ki bodo pozneje razložila nastavitev: izvorni obseg, predstavljeni obseg, napravo, ki prevaja, in smer, v kateri lahko vsaka stran začne. Če karkoli od tega manjka, naslednji inženir podeduje omrežje, kjer si dva gostitelja delita ime in se nihče ne spomni, zakaj eden od njiju odgovarja.