Ar su peering susietai Azure VNet reikia nuosavo VPN šliuzo?
Su peering susieta VNet gali naudoti hub šliuzą su palaikomu SKU ir vienu nustatymu kiekviena peering kryptimi. Tikrinkite efektyvias trasas, o ne peering būseną.
Atsiranda naujas spoke VNet, hub jau turi veikiantį site-to-site šliuzą, ir akivaizdus klausimas – ar reikia mokėti už antrą šliuzą. Paprastai ne: šliuzo tranzitas leidžia spoke naudoti hub šliuzą per peering. Ar tai veiks, sprendžia trys sąlygos, ir nė viena jų nesimato peering būsenos ženklelyje. Peering ryšys ir leidimas naudoti svetimą šliuzą yra atskiri nustatymai, todėl du VM, jau galintys vienas kitą ping, nieko neįrodo apie VPN kelią.
Pirmoji sąlyga: šliuzas ir jo nebuvimas spoke
Azure palaiko šliuzo tranzitą VPN Gateway SKU, išskyrus Basic, ir jį gali perduoti tiek regioninis, tiek globalus peering. Spoke naudoja šliuzą, kurio jam nepriklauso, todėl negali turėti savo: jei spoke jau yra šliuzas arba jau pasirinktas nuotolinio šliuzo variantas, norimas tranzito nustatymas bus nepasiekiamas arba neveiksmingas. Patikrinkite tai prieš ką nors derindami, nes išjungtas žymės langelis yra simptomas, o ne gedimas. Pirmiausia perskaitykite SKU ir esamą šliuzą, tada pažiūrėkite peering nustatymus.
Netrinkite esamo spoke šliuzo, kad atsirastų parinktis, kol nežinote, kas nuo jo priklauso. Migracijos tvarka svarbesnė už žymės langelį.
Antroji sąlyga: vienas nustatymas kiekviena peering kryptimi
Peering yra du objektai, po vieną kiekviename VNet, o tranzito nustatymai gyvena skirtingose tos poros pusėse. Hub peering link spoke turi leisti hub šliuzui aptarnauti spoke; spoke peering link hub turi priimti hub šliuzą. Microsoft šliuzo tranzito vadovas juos įvardija pagal kryptį, ir tai vienintelis būdas išlaikyti juos teisingus:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
Valdiklis su žyme remote keičia reikšmę priklausomai nuo to, kurio VNet peering redaguojate, todėl skaitykite kryptį, o ne žodį. Nustatykite abi puses, išsaugokite ir patvirtinkite, kad peering abiejose vietose praneša apie prisijungimą.
Trečioji sąlyga: adresų erdvė ir leidimų ribos
Tranzitas negali priversti to paties paskirties prefikso reikšti du tinklus, todėl hub, spoke ir vietinio tinklo diapazonai turi nesikirsti prieš pradedant kam nors iš to veikti. VNet taip pat gali būti skirtingose prenumeratose ar skirtinguose nuomininkuose; tai nėra draudimas, bet tapatybė, kuri kuria ar atnaujina kiekvieną peering, turi turėti reikiamus leidimus tame tinkle. Pakeitimai tarp prenumeratų dažnai nepavyksta dėl leidimų, o klaidą lengva neteisingai perskaityti kaip topologijos problemą.
Prieš pakeitimą užsirašykite diapazonus ir savininkus. Spėjimas dėl bet kurio iš jų duoda peering, kuris prisijungia ir nieko nemaršrutizuoja.
Tikrinkite efektyviomis trasomis, ne peering būsena
Pažiūrėkite efektyvias trasas spoke darbinės apkrovos tinklo sąsajoje ir raskite tikrąjį vietinio tinklo prefiksą. Patikrinkite potinklio maršrutų lentelę ir ar šliuzo maršrutų sklaida išjungta, nes vartotojo apibrėžtas maršrutas ar patikros įrenginys gali nustelbti kelią, kurį siūlo peering vėliavėlės. Tada patvirtinkite priešingą kryptį: vietinis tinklas turi žinoti, kaip pasiekti spoke prefiksą per site-to-site ryšį, arba išmoktais skelbimais, arba aiškiu maršrutu ir atitinkamu apsaugoto tinklo įrašu kliento įrenginyje. Jei prefikso trūksta kurioje nors pusėje, keisti reikia ne peering vėliavėles.
Išbandykite vieną paslaugą iš spoke darbinės apkrovos ir sekite atsakymą. Testas iš VPN šliuzo ar hub VM naudoja kitą šaltinio prefiksą ir kitą kelią.
Jei topologija aptarnauja ir point-to-site klientus, atskirai patikrinkite jų įdiegtas trasas. Windows kliento paketams po topologijos pakeitimo gali prireikti iš naujo generuoti, ir tai yra kliento maršrutizavimo užduotis, o ne įrodymas, kad šliuzo bendrinimas nepavyko.
Ko šliuzo bendrinimas nesuteikia
Šliuzo tranzitas yra maršrutizavimo patogumas, o ne autorizacija. Tinklo saugos grupės, vietiniai filtrai ir paslaugos lygio taisyklės vis dar nusprendžia, ką spoke darbinė apkrova gali pasiekti, todėl įjunkite konkretų šaltinio–paskirties servisą, o ne manykite, kad bendras tunelis leidžia viską už jo.
Peering taip pat nėra tranzityvus taip, kaip žmonės tikisi. Pridėjus dar vieną spoke ar privatų galinį tašką, atsiranda jo paties maršrutizavimo ir prieigos reikalavimai, kurių esamas tranzito nustatymas neapima.