NAT í Azure VPN leysir ekki yfirskaranleg VNet-vistföng
Tvö VNet með sama einkasviði tengjast ekki bara af því að NAT er til. Athugaðu fyrst tegund tengingarinnar og endurnúmeraðu síðan eða eigðu þýðingaralias.
Bæði VNetin nota 10.40.1.0/24, göngin koma upp og ekkert virkar. Að bæta við öðru VPN-gáttinni breytir því ekki, og ekki heldur lægra leiðarmælikvarða, því vandamálið er ekki val á slóð. Tvö vinnuálag sem svara sama einkafanginu skilja hvert pakka eftir með óljósan áfangastað og ósannanlega afturleið. Áður en þú skipuleggur nokkra þýðingu skaltu komast að því hvaða tegund tengingar þú bjóst í raun til, því það eina val ræður því hvort NAT-eiginleiki Azure er yfirhöfuð tiltækur.
Hvað einkennið segir þér í raun
Þegar hýsill í VNet A sendir á 10.40.1.10 getur leiðartöflunni aðeins vísað honum eitthvert. Ef VNet B inniheldur líka 10.40.1.10 er það fang ekki áfangastaður sem slóðin getur greint; það er eitt fang með tvo eigendur.
Önnur gáttin sem fólk setur venjulega upp hjálpar ekki. Hún gefur þér annað göng, ekki annað fang, og tvítekna sviðið fer óbreytt inni í göngunum. Hún tvöfaldar líka stillingarnar sem þú verður að halda samkvæmum. Það sem hún getur ekki gert er að láta eitt fang þýða tvo hýsla.
Að breyta opinberum föngum VPN-jafningjanna gerir heldur ekkert. Þau föng auðkenna endapunkta ganganna, en áreksturinn er í einkasviðinu sem flutt er inni í þeim.
Tegund tengingarinnar ræður því hvort NAT er tiltækt
Azure VPN Gateway hefur vissulega NAT-getu og hún er skjalfest fyrir IPsec-tengingar milli staða sem byggja á leiðum á tilteknum gáttar-SKU-um. Sama skjalið útilokar VNet-to-VNet og point-to-site tengingar, svo eiginleikinn er ekki gátreitur sem birtist á hverri gáttarsambandi.
| 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-to-VNet krefst þess líka að svið VNet og staðarnets skarist ekki frá upphafi, sem er í samræmi við útilokunina. VNet-jöfnun er ekki lausn á skörun af sömu ástæðu.
Það er studdur valkostur sem fólk ruglar saman við innfæddu tegundina: líkanið hitt VNetið sem staðarnet og tengið það sem tengingu milli staða. Það er annar auðlind og önnur hönnun, svo meðhöndlaðu endurnefnda tengingu sem breytingu sem þarf að sannreyna, ekki sem einfalt nafnskipti.
Endurnúmeraðu eða þýddu með einhverju sem á aliasið
Ef bæði VNetin eru þín skaltu bera saman fyrirhugaða endurnúmerun við viðvarandi kostnað þýðingar. Endurnúmerun snertir stillingar forrita, DNS-færslur, öryggisreglur og hverja fyrirliggjandi tengingu, en skilur eftir net sem er lesið eðlilega á eftir. Gerðu það eitt undirnet í einu, með DNS-breytinguna síðasta. Hálfendurnúmerað svið er verra en hvort tveggja valkostanna, því þá virðast bæði forskeytin heimildaríkt fyrir þeim sem les töfluna næst.
Þar sem endurnúmerun er ekki hagkvæm skaltu nota þýdda hönnun með raunverulegan eiganda fyrir aliasið. Hringjendur í VNet A ná kannski 10.40.1.10 í VNet B sem 10.140.1.10, en það alias þarf tæki sem þýðir, leið að því og samsvarandi hegðun fyrir svarið. Fang sem aðeins er bætt við DNS er ekki þýðing.
Skráðu bæði sviðin í báðar áttir: hvað hringjandinn hringir, hvað áfangastaðurinn sér sem uppruna og hvor hliðin má hefja. Eigin NAT-reglur Azure fela í sér öfugu þýðinguna fyrir SNAT-vörpun þeirra, svo þú skrifar ekki samsvarandi DNAT-reglu handvirkt, en þægindin enda við þær tegundir tenginga sem eiginleikinn styður.
Hvað mun ekki virka
Leið sem notandi skilgreinir eða leiðarmælikvarði getur ekki búið til vantaða fanga-aðgreiningu. Bæði vinna á áfangastað sem enn er óljós og pakkinn berst til þess næsta hopps sem taflan kýs.
Að bæta tvítekna sviðinu við leiðartöflu sem nánara forskeyti færir óljósuna aðeins um eitt skref. Það hefur líka tilhneigingu til að brjóta hina áttina, þar sem svarið hefur nú tvo trúverðuga uppruna.
Samþykktu hönnunina með umferð í báðar áttir
Sannaðu hönnunina með nýrri leyfðri aðgerð frá hvorri hlið, ekki með stöðu gangsins. Tengt IPsec-göng segja að jafningjarnir séu sammála um dulritun; það segir ekkert um hvort áfangastaðirnir urðu greinanlegir.
Keyrðu síðan bönnuðu slóðirnar: fang sem á að vera óaðgengilegt og þjónustu sem stefnan á að loka á. Ef báðar ganga enn upp er þýðingin víðtækari en hönnunin ætlaði.
Ljúktu með staðreyndunum sem skýra uppsetninguna síðar: upprunalega sviðið, sviðið sem birtist, tækið sem þýðir og áttina sem hvor hlið má hefja í. Ef eitthvað af þessu vantar erfir næsti verkfræðingur net þar sem tvo hýslar deila nafni og enginn man hvers vegna annar þeirra svarar.