Azure peering vai VNet–VNet VPN? Izlemiet pirms maršrutēšanas

Azure piedāvā vismaz divus veidus, kā savienot divus virtuālos tīklus, un tie nav viena un tā paša objekta aizvietojami iestatījumi. Peering savieno VNet tīklus Microsoft mugurkaulā bez vārtejas; VNet–VNet VPN ievieto IPsec attiecības starp divām vārtejām, kuras jūs izvietojat, izmērāt un uzraugāt. Lēmums reducējas uz trim nosacījumiem, un, ja pirms maršruta pievienošanas nevarat atbildēt uz visiem trim, jūs grasāties būvēt apkārtceļu modelim, kuru nekad neizvēlējāties.

Trīs nosacījumi, kas nosaka modeli

Pirmais ir, vai kaut kam prasībā vajadzīga IPsec robeža, kas pieder jums un uz kuru varat norādīt. Otrais ir, vai adrešu telpas ir tīras un vai diviem VNet tīkliem jāsarunājas tikai savā starpā. Trešais ir, kam pieder jebkurš tranzīta ceļš un vārtejas rēķins. Atbildiet šajā secībā, jo pirmais var izslēgt peering, lai cik pievilcīgs izskatītos otrais.

Abiem modeļiem kopīgs ir stingrs adresācijas noteikums: VNet adrešu telpas nedrīkst pārklāties. Ne peering, ne VNet–VNet VPN nav atbalstīts veids, kā padarīt divus identiskus diapazonus viennozīmīgus, un pārklāšanās prasa kartēšanas dizainu vai pārprojektēšanu, nevis citu savienojuma veidu.

1. nosacījums: vai jums vajadzīga IPsec robeža, kas pieder jums?

Peering pārvada satiksmi pa Azure privāto mugurkaulu un neprasa VPN vārteju pašam peered savienojumam. Tas ir apgalvojums par transportu, nevis apgalvojums par šifrēšanu, ko varat nodot auditoram kā «mēs lietojam IPsec». Ja prasība nosauc klienta konfigurētu tuneli, konkrētu IKE politiku vai robežu, kas beidzas jūsu kontrolētā aparatūrā, peering to neizpilda, lai cik privāts būtu mugurkauls.

VNet–VNet VPN nodrošina šo robežu: divas vārtejas, IPsec/IKE attiecības, koplietotas atslēgas un visa ar to saistītā operatīvā virsma. Jūs mantoja tuneļa stāvokli, vārtejas jaudu, SKU ierobežojumus un uzraudzību, kas pierāda, ka tunelis darbojas. Tas ir pareizā atbilde, kad prasība attiecas tieši uz šo robežu, kas peering pārskatā aprakstīta kā atšķirīgs savienojuma veids.

Esiet tikpat uzmanīgs pretējā virzienā. «Mums vajag šifrēšanu starp VNet tīkliem» bieži apmierina pašas darba slodzes TLS, un tad vārteja ir izmaksas bez prasības aiz tās. Uzrakstiet teikumu, ko auditors lasīs, pirms izvēlaties mehānismu.

2. nosacījums: vai topoloģija ir tieša, vai kaut kam jātranzītē?

Peering nav tranzitīvs. Divi VNet tīkli, kas peered uz koncentratoru, ar to nav savienoti savā starpā, un maršruts, kas šķietami darbojas vienā virzienā, parasti ir peering, kas sasniedzis Connected tikai vienā pusē. Abām pusēm jāpastāv un abām jārāda Connected, un tas ir pirmais, ko pārbaudāt, kad satiksme klusi pazūd.

Ja prasība ir sasniegt vietējo tīklu caur koncentratoru, vārtejas tranzīts ir atsevišķs dizains ar konkrētām lomām: koncentrators pārvalda vārteju, spoke peering atļauj vārtejas tranzītu, un spoke ir jāatļauj pārsūtītā satiksme. Tie ir peering rekvizīti, nevis automātiskas VNet tīklu savienošanas sekas:

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

Efektīvā maršrutu tabula ir godīga atbilde uz «vai ceļš pastāv?». Tā parāda nākamā lēciena tipu, ko platforma faktiski izmantos, tāpēc peering, kas izskatās konfigurēts, bet nav savienots, parādās kā trūkstošs vai nepareizs maršruts, nevis kā noslēpums.

3. nosacījums: kam pieder tranzīta ceļš un rēķins?

Katram papildu lēcienam ir īpašnieks. Ar peering jauns VNet nozīmē jaunu peering pāri abās pusēs, bet tranzītam – koncentratoru, kas turpina pārsūtīt satiksmi, un maršrutu tabulu, kas turpina uz to norādīt. Ar VPN jauns VNet nozīmē vēl vienu vārteju vai vēl vienu savienojumu uz esošas, ar savu jaudas griestu, kas jāuzrauga.

Izmaksas seko tai pašai formai, bet ne tām pašām pozīcijām: peering maksas ir savienojums un datu pārsūtīšana, savukārt VPN pievieno vārtejas stundas un savas pārsūtīšanas maksas. Salīdziniet kopumu topoloģijai, kuru jūs reāli ekspluatēsiet gadu, ieskaitot otro tuneli un uzraudzību, nevis viena savienojuma cenu šodien. Iekļaujiet darbu, ko neviens neizraksta rēķinā: kādam jāmaina atslēgas, jāuzrauga tuneļa stāvoklis un jāatbild uz trauksmi trijos naktī, kad vārteja pārstartējas. Parasti tieši šī pozīcija izšķir strīdu, jo tā ir vienīgā, kas nekad neparādās piedāvājumā.

Lai ko jūs izvēlētos, pārbaudiet trīs plūsmas: paredzēto, noraidīto, kam jāpaliek noraidītam, un atjaunošanas gadījumu, kad koncentratora vārteja vai peering ir izslēgts. Modelis, kas izskaidro tikai laimīgo ceļu, nav pārbaudīts, tas ir demonstrēts.

Pārbaudiet izvēli pret tās pašas apgalvojumu

Uzrakstiet vienu teikumu, kas nosauc modeli, robežu un īpašnieku, pēc tam pārbaudiet, vai izvietotais stāvoklis tam atbilst. Peering gadījumā tas nozīmē abus peering stāvokļus Connected, efektīvais maršruts rāda peering nākamo lēcienu galamērķa prefiksam, un ceļā nav vārtejas. VNet–VNet VPN gadījumā tas nozīmē abus savienojumus Connected, atbilstošas atslēgas un politikas abās vārtejās un maršrutu, kura nākamais lēciens ir virtuālā tīkla vārteja.

Ja pārbaudes ir pretrunā ar teikumu, vispirms izlabojiet teikumu. Lielākā daļa apjukuma šajos dizainos nāk no hibrīda, ko neviens nav aprakstījis: peering darba slodzes apakštīklam, VPN vienam vecam servisam un maršrutu tabula, kas klusi dod priekšroku vienam no tiem.