Azure VPN-i NAT ei kõrvalda kattuvaid VNet-aadresse
Kaks VNeti sama privaatvahemikuga ei ühendu lihtsalt seetõttu, et NAT olemas on. Kontrollige esmalt ühenduse tüüpi, seejärel nummerdage ümber või omage tõlkealiast.
Mõlemad VNetid kasutavad vahemikku 10.40.1.0/24, tunnelid tõusevad püsti ja miski ei tööta. Teise VPN-lüüsi lisamine ei muuda seda, ega ka madalam marsruudimeetrika, sest probleem ei ole tee valikus. Kaks töökoormust, mis vastavad samale privaataadressile, jätavad iga paketi ebamäärase sihtkoha ja kontrollimatu tagasiteega. Enne mis tahes tõlke planeerimist tehke kindlaks, millise ühenduse tüübi te tegelikult lõite, sest see üks valik otsustab, kas Azure'i NAT-funktsioon üldse saadaval on.
Mida see sümptom teile tegelikult ütleb
Kui VNet A host saadab aadressile 10.40.1.10, saab marsruutimistabel selle ainult kuhugi suunata. Kui ka VNet B sisaldab aadressi 10.40.1.10, ei ole see aadress sihtkoht, mida tee suudab eristada; see on üks aadress kahe omanikuga.
Teine lüüs, mida tavaliselt juurutatakse, ei aita. See annab teise tunneli, mitte teise aadressi, ja dubleeritud vahemik liigub tunnelis muutumatult. See ka kahekordistab konfiguratsiooni, mida peate järjekindlana hoidma. Mida see teha ei suuda, on muuta üks aadress kaheks hostiks.
Ka VPN-partnerite avalike aadresside muutmine ei tee midagi. Need aadressid määravad tunneli otspunktid, samas kui kokkupõrge on privaatvahemikus, mida selle sees kantakse.
Ühenduse tüüp otsustab, kas NAT on saadaval
Azure VPN Gatewayl on tõepoolest NAT-võimekus ja see on dokumenteeritud marsruudipõhistele IPsec-i site-vahelistele ühendustele kindlatel lüüsi SKU-del. Sama dokumentatsioon välistab VNet-to-VNet ja point-to-site ühendused, seega ei ole see funktsioon märkeruut, mis ilmub igas lüüsi suhtes.
| 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 |
Natiivne VNet-to-VNet nõuab ka seda, et VNeti ja kohaliku võrgu vahemikud ei kattuks algusest peale, mis on kooskõlas välistamisega. VNeti vastastikune ühendamine ei ole kattumise lahendus samal põhjusel.
On olemas toetatud alternatiiv, mida inimesed natiivse tüübiga segi ajavad: modelleerige teine VNet kohaliku võrguna ja ühendage see saidi-saidi ühendusena. See on teine ressurss ja teine disain, seega käsitlege ümber nimetatud ühendust valideerimist vajava muudatusena, mitte lihtsa ümbernimetamisena.
Nummerdage ümber või tõlkige millegagi, mis aliast omab
Kui mõlemad VNetid on teie omad, võrrelge kavandatud ümbernummerdamist tõlkimise jooksva kuluga. Ümbernummerdamine puudutab rakenduse konfiguratsiooni, DNS-kirjeid, turbekirjeid ja iga olemasolevat ühendust, kuid jätab võrgu, mida hiljem loetakse tavaliselt. Tehke seda üks alamvõrk korraga, DNS-i muudatus viimasena. Poolenisti ümber nummerdatud vahemik on halvem kui kumbki valik, sest siis näivad mõlemad prefiksid järgmisele tabeli lugejale autoriteetsed.
Kus ümbernummerdamine ei ole otstarbekas, kasutage tõlgitud disaini, millel on aliasel tegelik omanik. VNet A kutsujad võivad jõuda VNet B aadressile 10.40.1.10 aadressina 10.140.1.10, kuid see alias vajab seadet, mis tõlgib, marsruuti selle juurde ja vastusele vastavat käitumist. Ainult DNS-i lisatud aadress ei ole tõlge.
Kirjutage mõlemad vahemikud mõlemas suunas üles: mida kutsuja valib, mida sihtkoht näeb allikana ja milline pool võib algatada. Azure'i enda NAT-reeglid sisaldavad pöördtõlget oma SNAT-vastenduste jaoks, seega te ei kirjuta sobivat DNAT-reeglit käsitsi, kuid see mugavus lõpeb nende ühenduse tüüpide juures, mida funktsioon toetab.
Mis ei tööta
Kasutaja määratud marsruut ega marsruudimeetrika ei saa luua puuduvat aadressierinevust. Mõlemad toimivad sihtkohal, mis on endiselt ebamäärane, ja pakett jõuab järgmise hüppeni, mida tabel eelistab.
Dubleeritud vahemiku lisamine marsruutimistabelisse täpsema prefiksina liigutab ebamäärasust vaid ühe sammu. See kipub ka teist suunda rikkuma, kus vastusel on nüüd kaks usutavat allikat.
Nõustuge disainiga liiklusega mõlemas suunas
Tõestage disaini värske lubatud toiminguga mõlemalt poolelt, mitte tunneli staatusega. Ühendatud IPsec-tunnel ütleb, et partnerid on krüptograafias ühel meelel; see ei ütle midagi selle kohta, kas sihtkohad muutusid eristatavaks.
Seejärel käivitage keelatud teed: aadress, mis peaks jääma kättesaamatuks, ja teenus, mille poliitika peaks blokeerima. Kui mõlemad veel õnnestuvad, on tõlge laiem, kui disain kavatses.
Lõpetage faktidega, mis selgitavad seadistust hiljem: algne vahemik, esitatud vahemik, seade, mis tõlgib, ja suund, milles kumbki pool võib algatada. Kui midagi sellest puudub, pärib järgmine insener võrgu, kus kaks hosti jagavad nime ja keegi ei mäleta, miks üks neist vastab.