Behar al du peering bidez lotutako Azure VNet batek bere VPN pasabidea?
Peering bidez lotutako VNet batek hub-aren VPN pasabidea erabil dezake SKU onartu batekin eta peering norabide bakoitzean ezarpen batekin. Egiaztatu ibilbide eraginkorrak, ez peering egoera.
Spoke VNet berri bat agertu da, hub-ak badu jada funtzionatzen duen site-to-site pasabide bat, eta begi bistako galdera da bigarren pasabide bat ordaindu behar duzun. Normalean ez: pasabidearen transit-ak spoke-ari aukera ematen dio hub-aren pasabidea peering bidez erabiltzeko. Hiru baldintzek erabakitzen dute hori funtzionatuko duen, eta bat ere ez da ikusten peering egoeraren txartelean. Peering konektagarritasuna eta beste baten pasabidea erabiltzeko baimena bereiziak dira, beraz, elkarri ping egiteko gai diren bi VM-k ez dute ezer frogatzen VPN bideari buruz.
Lehen baldintza: pasabidea eta spoke-ak bat ez izatea
Azure-k pasabidearen transit-a onartzen du Basic ez diren VPN Gateway SKU-ekin, eta eskualdeko zein globaleko peering-ek ekar dezakete. Spoke-ak ez duen pasabide bat kontsumitzen du, beraz ezin du berea izan: spoke-an pasabide bat badago jada, edo urruneko pasabidearen aukera hautatuta badago, nahi duzun transit ezarpena ez da erabilgarri egongo edo ez du eraginik izango. Egiaztatu hori ezer araztu aurretik, gaitutako kontrol-laukia sintoma baita, ez akatsa. Irakurri lehenengo SKU-a eta lehendik dagoen pasabidea, eta gero begiratu peering ezarpenak.
Ez ezabatu lehendik dagoen spoke pasabide bat aukera ager dadin, ez dakizun arte zer dagoen haren mende. Migrazio ordena kontrol-laukia baino garrantzitsuagoa da.
Bigarren baldintza: ezarpen bat peering norabide bakoitzean
Peering bi objektu dira, bat VNet bakoitzean, eta transit ezarpenak bikote horren alde desberdinetan daude. Hub-aren peering-ak spoke-rantz hub pasabideari spoke-ari zerbitzatzea baimendu behar dio; spoke-aren peering-ak hub-rantz hub-aren pasabidea onartu behar du. Microsoft-en pasabidearen transit gida norabidearen arabera izendatzen ditu, eta hori da zuzen mantentzeko modu bakarra:
| 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 |
remote etiketadun kontrol batek esanahia aldatzen du zein VNet-en peering editatzen ari zaren arabera, beraz irakurri norabidea, ez hitza. Ezarri bi aldeak, gorde eta berretsi peering-ak bi lekuetan konektatuta dagoela dioela.
Hirugarren baldintza: helbide espazioa eta baimen mugak
Transit-ak ezin du helmuga-prefix berak bi sare esan nahi izatea, beraz hub, spoke eta sare lokalaren barrutiek elkar ukitzen ez dutela bermatu behar da, honetatik ezerk funtziona dezan. VNet-ak harpidetza desberdinetan edo maizter desberdinetan egon daitezke; hori ez da debekua, baina peering bakoitza sortzen edo eguneratzen duen identitateak sare horretan behar diren baimenak behar ditu. Harpidetzen arteko aldaketek sarritan huts egiten dute baimenengatik, eta errorea erraza da topologia arazo gisa oker irakurtzea.
Idatzi barrutiak eta jabeak aldaketa aurretik. Bi horietan asmatzeak konektatzen duen baina ezer bideratzen ez duen peering bat sortzen du.
Egiaztatu ibilbide eraginkorrekin, ez peering egoerarekin
Begiratu spoke lan-karga baten sare interfazean dauden ibilbide eraginkorrak eta aurkitu benetako sare lokalaren prefix-a. Egiaztatu azpisarearen ibilbide taula eta pasabidearen ibilbide hedapena desgaituta dagoen, erabiltzaileak definitutako ibilbide batek edo ikuskapen gailu batek peering-en banderek iradokitzen duten bidea gaindi baitezakete. Ondoren berretsi beste norabidea: sare lokalak jakin behar du nola iritsi spoke prefix-era site-to-site konexioaren bidez, ikasitako iragarkien bidez edo ibilbide esplizitu baten eta bezeroaren gailuko sare babestuaren sarrera parekatu baten bidez. Prefix-a bi aldeetakoren batean falta bada, peering-en banderak ez dira aldatu beharrekoa.
Probatu zerbitzu bat spoke lan-karga batetik eta jarraitu erantzuna. VPN pasabidetik edo hub-eko VM batetik egindako probak beste iturburu-prefix bat eta beste bide bat erabiltzen ditu.
Topologiak point-to-site bezeroak ere zerbitzatzen baditu, balidatu haien instalatutako ibilbideak bereizita. Windows bezero-paketeek birsorkuntza behar dezakete topologia aldatu ondoren, eta hori bezeroaren bideratze-zeregin bat da, ez pasabidearen partekatzeak huts egin izanaren froga.
Zer ez du ematen pasabide bat partekatzeak
Pasabidearen transit-a bideratze-erraztasuna da, ez baimena. Sare-segurtasun taldeek, tokiko filtreek eta zerbitzu-mailako arauek oraindik erabakitzen dute spoke lan-karga batek zer har dezakeen, beraz gaitu iturburutik helmugara doan zerbitzu zehatza, partekatutako tunelak haren atzeko guztia onartzen duela pentsatu ordez.
Peering ez da iragankorra ere jendeak espero duen moduan. Beste spoke bat edo amaiera-puntu pribatu bat gehitzeak bere bideratze- eta sarbide-baldintzak dakartza, lehendik dagoen transit ezarpenak estaltzen ez dituenak.