„Azure“ peering ar VNet–VNet VPN? Nuspręskite prieš maršrutizavimą

„Azure“ siūlo bent du būdus sujungti du virtualiuosius tinklus, ir tai nėra keičiamos to paties objekto nuostatos. Peering sujungia VNet tinklus „Microsoft“ magistrale be tinklų sietuvos; VNet–VNet VPN nustato IPsec ryšį tarp dviejų tinklų sietuvų, kurias jūs diegiate, matuojate ir stebite. Sprendimas susiveda į tris sąlygas, ir jei negalite atsakyti į visas tris prieš pridėdami maršrutą, jūs ketinate statyti apvažiavimą modeliui, kurio niekada nepasirinkote.

Trys sąlygos, lemiančios modelį

Pirmoji – ar ko nors reikalavime reikia IPsec ribos, kuri priklauso jums ir į kurią galite parodyti. Antroji – ar adresų erdvės yra švarios ir ar dviem VNet tinklams reikia tik kalbėtis tarpusavyje. Trečioji – kam priklauso bet koks tranzitinis kelias ir tinklų sietuvos sąskaita. Atsakykite šia tvarka, nes pirmoji gali pašalinti peering, kad ir kaip patraukliai atrodytų antroji.

Abiem modeliams bendra griežta adresavimo taisyklė: VNet adresų erdvės negali persidengti. Nei peering, nei VNet–VNet VPN nėra palaikomas būdas padaryti du vienodus diapazonus vienareikšmiškus, o persidengimui reikia atvaizdavimo projekto arba pertvarkymo, o ne kito ryšio tipo.

1 sąlyga: ar jums reikia IPsec ribos, kuri priklauso jums?

Peering perduoda srautą „Azure“ privačia magistrale ir nereikalauja VPN tinklų sietuvos pačiam peered ryšiui. Tai teiginys apie transportą, o ne teiginys apie šifravimą, kurį galite duoti auditoriui kaip „mes naudojame IPsec“. Jei reikalavimas įvardija kliento sukonfigūruotą tunelį, konkrečią IKE politiką arba ribą, kuri baigiasi jūsų kontroliuojamoje įrangoje, peering to nepatenkina, kad ir kokia privati būtų magistralė.

VNet–VNet VPN suteikia tą ribą: dvi tinklų sietuvos, IPsec/IKE ryšį, bendrus raktus ir visą su tuo susijusį operacinį paviršių. Jūs paveldite tunelio būseną, tinklų sietuvos pajėgumą, SKU ribas ir stebėjimą, kuris įrodo, kad tunelis veikia. Tai teisingas atsakymas, kai reikalavimas skirtas būtent tai ribai, aprašytai peering apžvalgoje kaip atskiras ryšio tipas.

Būkite lygiai taip pat atsargūs priešinga kryptimi. „Mums reikia šifravimo tarp VNet tinklų“ dažnai patenkinama pačios darbo apkrovos TLS, ir tada tinklų sietuva yra išlaidos be reikalavimo už jos. Parašykite sakinį, kurį auditorius perskaitys, prieš pasirinkdami mechanizmą.

2 sąlyga: ar topologija tiesioginė, ar kažkas turi tranzituoti?

Peering nėra tranzityvus. Du VNet tinklai, peered į koncentratorių, tuo dar nėra sujungti tarpusavyje, o maršrutas, kuris atrodo veikiantis viena kryptimi, paprastai yra peering, pasiekęs Connected tik vienoje pusėje. Abi pusės turi egzistuoti ir abi turi rodyti Connected, ir tai pirmas dalykas, kurį tikrinate, kai srautas tyliai dingsta.

Jei reikalavimas – pasiekti vietinį tinklą per koncentratorių, tinklų sietuvos tranzitas yra atskiras projektas su konkrečiomis rolėmis: koncentratorius valdo tinklų sietuvą, spoke peering leidžia tinklų sietuvos tranzitą, o spoke turi leisti persiųstą srautą. Tai peering savybės, o ne automatiškos VNet tinklų sujungimo pasekmės:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

Efektyvi maršrutų lentelė yra sąžiningas atsakymas į „ar kelias egzistuoja?“. Ji rodo kito šuolio tipą, kurį platforma iš tikrųjų naudos, todėl peering, kuris atrodo sukonfigūruotas, bet neprijungtas, pasirodo kaip trūkstamas arba neteisingas maršrutas, o ne kaip mįslė.

3 sąlyga: kam priklauso tranzitinis kelias ir sąskaita?

Kiekvienas papildomas šuolis turi savininką. Su peering naujas VNet reiškia naują peering porą abiejose pusėse, o tranzitui – koncentratorių, kuris toliau persiunčia srautą, ir maršrutų lentelę, kuri toliau į jį rodo. Su VPN naujas VNet reiškia dar vieną tinklų sietuvą arba dar vieną ryšį esamoje, su savo pajėgumo lubomis, kurias reikia stebėti.

Išlaidos eina ta pačia forma, bet ne tomis pačiomis eilutėmis: peering mokesčiai yra ryšys ir duomenų perdavimas, o VPN prideda tinklų sietuvos valandas ir savo perdavimo mokesčius. Palyginkite sumą topologijai, kurią iš tikrųjų valdysite metus, įskaitant antrą tunelį ir stebėjimą, o ne vieno ryšio kainą šiandien. Įtraukite darbą, kurio niekas nefaktūruoja: kažkas turi keisti raktus, stebėti tunelio būseną ir atsakyti į aliarmą trečią valandą nakties, kai tinklų sietuva persikrauna. Paprastai būtent ši eilutė nulemia ginčą, nes ji vienintelė niekada neatsiranda pasiūlyme.

Kad ir ką pasirinktumėte, išbandykite tris srautus: numatytą, atmestą, kuris turi likti atmestas, ir atkūrimo atvejį, kai koncentratoriaus tinklų sietuva arba peering neveikia. Modelis, kuris paaiškina tik laimingą kelią, nebuvo patikrintas, jis buvo parodytas.

Patikrinkite pasirinkimą pagal jo paties teiginį

Parašykite vieną sakinį, įvardijantį modelį, ribą ir savininką, tada patikrinkite, ar įdiegta būsena jį atitinka. Peering atveju tai reiškia abi peering būsenas Connected, efektyvus maršrutas rodo peering kitą šuolį paskirties priešdėliui, o kelyje nėra tinklų sietuvos. VNet–VNet VPN atveju tai reiškia abu ryšius Connected, sutampančius raktus ir politikas abiejose tinklų sietuvose bei maršrutą, kurio kitas šuolis yra virtualiojo tinklo tinklų sietuva.

Jei patikros prieštarauja sakiniui, pirmiausia pataisykite sakinį. Didžioji dalis painiavos šiuose projektuose kyla iš hibrido, kurio niekas neaprašė: peering darbo apkrovos potinkliui, VPN vienai senai paslaugai ir maršrutų lentelė, kuri tyliai teikia pirmenybę vienam iš jų.