Azure VPN NAT neatrisina pārklājošās VNet adreses
Divi VNet ar vienu un to pašu privāto diapazonu nesavienosies tikai tāpēc, ka pastāv NAT. Vispirms pārbaudiet savienojuma veidu, pēc tam pārnumurējiet vai pārvaldiet tulkošanas aizstājvārdu.
Abi VNet izmanto 10.40.1.0/24, tuneļi paceļas, un nekas nedarbojas. Otra VPN vārteja to nemaina, un arī zemāka maršruta metrika to nemaina, jo problēma nav maršruta izvēlē. Divas darba slodzes, kas atbild uz vienu un to pašu privāto adresi, atstāj katru paketi ar neskaidru galamērķi un nepārbaudāmu atgriešanās ceļu. Pirms plānot jebkādu tulkošanu, noskaidrojiet, kāda veida savienojumu jūs faktiski izveidojāt, jo šī vienīgā izvēle nosaka, vai Azure NAT funkcija vispār ir pieejama.
Ko šis simptoms jums patiešām saka
Kad VNet A resursdators sūta uz 10.40.1.10, maršrutēšanas tabula to var tikai kaut kur novirzīt. Ja arī VNet B satur 10.40.1.10, šī adrese nav galamērķis, ko maršruts var atšķirt; tā ir viena adrese ar diviem īpašniekiem.
Otrā vārteja, ko cilvēki parasti ievieš, nepalīdz. Tā dod citu tuneli, nevis citu adresi, un dublētais diapazons ceļo tunelī nemainīts. Tā arī dubulto konfigurāciju, kas jums jāsaglabā konsekventa. Ko tā nevar, ir panākt, ka viena adrese nozīmē divus resursdatorus.
VPN partneru publisko adrešu maiņa arī neko nedod. Tās adreses identificē tuneļa galapunktus, savukārt sadursme ir privātajā diapazonā, kas tiek pārnests iekšpusē.
Savienojuma veids nosaka, vai NAT ir pieejams
Azure VPN Gateway patiešām ir NAT iespēja, un tā ir dokumentēta maršrutā balstītiem IPsec savienojumiem starp vietām noteiktos vārtejas SKU. Tā pati dokumentācija izslēdz VNet-to-VNet un point-to-site savienojumus, tāpēc šī funkcija nav izvēles rūtiņa, kas parādās katrā vārtejas attiecībās.
| 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 |
Vietējais VNet-to-VNet arī prasa, lai VNet un vietējā tīkla diapazoni jau no sākuma nepārklātos, kas saskan ar izslēgšanu. VNet savienošana pāros arī nav pārklāšanās risinājums tā paša iemesla dēļ.
Ir atbalstīta alternatīva, ko cilvēki jauc ar vietējo veidu: modelējiet otru VNet kā vietējo tīklu un pievienojiet to kā savienojumu starp vietām. Tas ir cits resurs un cits dizains, tāpēc pret pārdēvētu savienojumu iztieties kā pret pārbaudāmu izmaiņu, nevis vienkāršu pārdēvēšanu.
Pārnumurējiet vai tulkojiet ar kaut ko, kam pieder aizstājvārds
Ja abi VNet ir jūsu, salīdziniet plānoto pārnumurēšanu ar tulkošanas pastāvīgajām izmaksām. Pārnumurēšana skar programmu konfigurāciju, DNS ierakstus, drošības noteikumus un katru esošo savienojumu, taču atstāj tīklu, kas pēc tam lasās normāli. Dariet to pa vienam apakštīklam, DNS izmaiņas pēdējās. Daļēji pārnumurēts diapazons ir sliktāks par jebkuru variantu, jo tad abi prefiksi izskatās autoritatīvi tam, kurš nākamreiz lasīs tabulu.
Kur pārnumurēšana nav praktiska, izmantojiet tulkotu dizainu ar īstu aizstājvārda īpašnieku. Zvanītāji VNet A var sasniegt VNet B 10.40.1.10 kā 10.140.1.10, taču šim aizstājvārdam vajadzīga ierīce, kas tulko, maršruts uz to un atbildei atbilstoša uzvedība. Adrese, kas pievienota tikai DNS, nav tulkojums.
Reģistrējiet abus diapazonus abos virzienos: ko zvana zvanītājs, ko galamērķis redz kā avotu un kura puse drīkst uzsākt. Azure paša NAT noteikumi ietver apgriezto tulkojumu to SNAT kartējumiem, tāpēc jūs ar roku nerakstāt atbilstošu DNAT noteikumu, taču šī ērtība beidzas pie tiem savienojumu veidiem, kurus funkcija atbalsta.
Kas nedarbosies
Lietotāja definēts maršruts vai maršruta metrika nevar radīt trūkstošu adrešu atšķirību. Abi darbojas uz vēl neskaidru galamērķi, un pakete nonāk pie nākamā lēciena, kuram tabula dod priekšroku.
Dublētā diapazona pievienošana maršrutu tabulai kā konkrētākam prefiksam pārvieto neskaidrību tikai par vienu soli. Tas arī mēdz salauzt pretējo virzienu, kur atbildei tagad ir divi ticami avoti.
Pieņemiet dizainu ar trafiku abos virzienos
Pierādiet dizainu ar svaigu atļautu darbību no katras puses, nevis ar tuneļa statusu. Savienots IPsec tunelis saka, ka partneri vienojas par kriptogrāfiju; tas neko nesaka par to, vai galamērķi kļuva atšķirami.
Pēc tam izpildiet liegtos ceļus: adresi, kurai jāpaliek nesasniedzamai, un pakalpojumu, kuru politikai jābloķē. Ja abi joprojām izdodas, tulkojums ir plašāks, nekā dizains bija iecerējis.
Noslēdziet ar faktiem, kas vēlāk izskaidros iestatījumu: sākotnējais diapazons, uzrādītais diapazons, ierīce, kas tulko, un virziens, kurā katra puse drīkst uzsākt. Ja kaut kas no tā trūkst, nākamais inženieris manto tīklu, kur divi resursdatori dala vienu vārdu un neviens neatceras, kāpēc viens no tiem atbild.