Kailangan ba ng Azure VNet na naka-peer ng sariling gateway ng VPN?

May bagong spoke VNet, may gumaganang site-to-site na gateway na ang hub, at ang halatang tanong ay kung kailangan mong magbayad para sa pangalawang gateway. Karaniwang hindi: pinapayagan ng gateway transit ang spoke na gamitin ang gateway ng hub sa pamamagitan ng peering. Tatlong kundisyon ang nagtatakda kung gagana iyon, at wala sa mga ito ang nakikita sa badge ng status ng peering. Ang koneksyon ng peering at ang pahintulot na gumamit ng gateway ng iba ay magkahiwalay na setting, kaya ang dalawang VM na nakakapag-ping na sa isa't isa ay walang pinapatunayan tungkol sa landas ng VPN.

Unang kundisyon: ang gateway, at ang kawalan nito sa spoke

Sinusuportahan ng Azure ang gateway transit para sa mga SKU ng VPN Gateway maliban sa Basic, at maaaring dalhin ito ng regional at global na peering. Gumagamit ang spoke ng gateway na hindi pag-aari nito, kaya hindi ito maaaring magkaroon ng sarili: kung may gateway na sa spoke, o may napiling opsyon ng remote gateway na, ang transit na setting na gusto mo ay hindi magiging available o hindi magiging epektibo. Suriin iyon bago mag-debug ng kahit ano, dahil ang naka-disabled na checkbox ang sintomas, hindi ang depekto. Basahin muna ang SKU at ang umiiral na gateway, pagkatapos ay tingnan ang mga setting ng peering.

Huwag burahin ang umiiral na gateway ng spoke para lumitaw ang opsyon hanggang alam mo kung ano ang umaasa rito. Mas mahalaga ang pagkakasunod-sunod ng paglipat kaysa sa checkbox.

Ikalawang kundisyon: isang setting sa bawat direksyon ng peering

Ang peering ay dalawang object, isa sa bawat VNet, at ang mga transit setting ay nasa magkaibang panig ng pares na iyon. Ang peering ng hub patungo sa spoke ay dapat payagan ang gateway ng hub na maglingkod sa spoke; ang peering ng spoke patungo sa hub ay dapat tumanggap ng gateway ng hub. ang gabay sa gateway transit ng Microsoft ay pinapangalanan sila ayon sa direksyon, at iyon ang tanging paraan para mapanatili silang tama:

Ang kontrol na may label na remote ay nagbabago ng kahulugan depende sa kung aling peering ng VNet ang ine-edit mo, kaya basahin ang direksyon, hindi ang salita. Itakda ang dalawang panig, i-save at kumpirmahin na iniuulat ng peering ang koneksyon sa dalawang lugar.

Ikatlong kundisyon: espasyo ng address at mga hangganan ng pahintulot

Hindi maaaring gawin ng transit na ang parehong prefix ng destinasyon ay mangahulugan ng dalawang network, kaya ang mga saklaw ng hub, spoke at lokal na network ay dapat na hiwalay bago gumana ang alinman sa mga ito. Ang mga VNet ay maaari ring nasa magkaibang subscription o magkaibang tenant; hindi iyon pagbabawal, ngunit ang identidad na gumagawa o nagbabago ng bawat peering ay nangangailangan ng mga kinakailangang pahintulot sa network na iyon. Madalas nabigo ang mga pagbabago sa pagitan ng subscription dahil sa pahintulot, at madaling mabasa nang mali ang error bilang problema sa topolohiya.

Isulat ang mga saklaw at may-ari bago ang pagbabago. Ang paghula sa alinman sa mga ito ay gumagawa ng peering na kumokonekta at walang ruta.

I-verify sa pamamagitan ng epektibong ruta, hindi ng status ng peering

Tingnan ang mga epektibong ruta sa network interface ng isang workload ng spoke at hanapin ang tunay na lokal na prefix. Suriin ang route table ng subnet at kung naka-disable ang pagpapalaganap ng ruta ng gateway, dahil ang ruta na tinukoy ng user o isang inspection appliance ay maaaring mangibabaw sa landas na iminumungkahi ng mga flag ng peering. Pagkatapos ay kumpirmahin ang kabilang direksyon: dapat alam ng lokal na network kung paano maabot ang prefix ng spoke sa pamamagitan ng koneksyon ng site-to-site, maging sa mga natutunang anunsyo o sa isang tahasang ruta at katugmang entry ng protektadong network sa device ng customer. Kung kulang ang prefix sa alinmang panig, ang mga flag ng peering ay hindi ang dapat baguhin.

Subukan ang isang serbisyo mula sa isang workload ng spoke at sundan ang sagot. Ang pagsubok mula sa gateway ng VPN o mula sa VM ng hub ay gumagamit ng ibang source prefix at ibang landas.

Kung naglilingkod din ang topolohiya sa mga kliyente ng point-to-site, i-validate nang hiwalay ang kanilang mga naka-install na ruta. Maaaring kailanganin ng mga client package ng Windows na muling buuin pagkatapos ng pagbabago ng topolohiya, at iyon ay gawain sa routing ng kliyente, hindi patunay na bigo ang pagbabahagi ng gateway.

Ano ang hindi ibinibigay ng pagbabahagi ng gateway

Ang gateway transit ay kaginhawahan sa routing, hindi awtorisasyon. Ang mga network security group, lokal na filter at panuntunan sa antas ng serbisyo ay nagtatakda pa rin kung ano ang maaabot ng isang workload ng spoke, kaya paganahin ang partikular na serbisyo mula sa pinagmulan patungo sa destinasyon sa halip na ipalagay na pinapayagan ng ibinahaging tunnel ang lahat sa likod nito.

Ang peering ay hindi rin transitive ayon sa inaasahan ng mga tao. Ang pagdaragdag ng isa pang spoke, o isang pribadong endpoint, ay nagdadala ng sarili nitong mga pangangailangan sa routing at access na hindi sakop ng umiiral na transit setting.