Ĉu Azure VNet ligita per peering bezonas sian propran VPN-pordegon?
VNet ligita per peering povas uzi la VPN-pordegon de la hubo kun subtenata SKU kaj unu agordo en ĉiu peering-direkto. Kontrolu la efektivajn itinerojn, ne la peering-staton.
Nova spoke-VNet aperas, la hubo jam havas funkciantan site-to-site-pordegon, kaj la evidenta demando estas ĉu vi devas pagi por dua pordego. Kutime ne: pordega transito lasas la spoke uzi la pordegon de la hubo trans peering. Tri kondiĉoj decidas ĉu tio funkcios, kaj neniu el ili videblas en la peering-stata insigno. Peering-konekteco kaj permeso uzi alies pordegon estas apartaj agordoj, do du VM-oj kiuj jam povas pingi unu la alian pruvas nenion pri la VPN-vojo.
Unua kondiĉo: la pordego, kaj la manko de ĝi en la spoke
Azure subtenas pordegan transiton por VPN Gateway-SKU-oj krom Basic, kaj kaj regiona kaj tutmonda peering povas porti ĝin. La spoke konsumas pordegon kiun ĝi ne posedas, do ĝi ne povas havi propran: se pordego jam ekzistas en la spoke, aŭ fora-pordega opcio jam estas elektita, la transita agordo kiun vi volas estos neatingebla aŭ senefika. Kontrolu tion antaŭ ol vi sencimigi ion ajn, ĉar la malŝaltita markobutono estas la simptomo, ne la difekto. Legu unue la SKU-on kaj la ekzistantan pordegon, poste rigardu la peering-agordojn.
Ne forigu ekzistantan spoke-pordegon por igi la opcion aperi ĝis vi scios kio dependas de ĝi. La migrada ordo pli gravas ol la markobutono.
Dua kondiĉo: unu agordo en ĉiu peering-direkto
Peering estas du objektoj, po unu sur ĉiu VNet, kaj la transitaj agordoj loĝas sur malsamaj flankoj de tiu paro. La peering de la hubo al la spoke devas permesi al la huba pordego servi la spoke; la peering de la spoke al la hubo devas akcepti la pordegon de la hubo. La gvidilo de Microsoft pri pordega transito nomas ilin laŭ direkto, kaj tio estas la sola maniero teni ilin ĝustaj:
| 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 |
Regilo etikedita remote ŝanĝas signifon laŭ tio kies VNet-peering vi redaktas, do legu la direkton, ne la vorton. Agordu ambaŭ flankojn, konservu, kaj konfirmu ke la peering raportas konektite en ambaŭ lokoj.
Tria kondiĉo: adresspaco kaj permeslimoj
Transito ne povas igi la saman celprefikson signifi du retojn, do la areoj de hubo, spoke kaj loka reto devas esti disaj antaŭ ol iu ajn el tio funkcios. La VNet-oj ankaŭ povas esti en malsamaj abonoj aŭ malsamaj luantoj; tio ne estas malpermeso, sed la identeco kreanta aŭ ĝisdatiganta ĉiun peering bezonas la postulatajn permesojn sur tiu reto. Ŝanĝoj trans abonoj ofte malsukcesas pro permesoj, kaj la eraron facile mislegi kiel topologian problemon.
Skribu la areojn kaj la posedantojn antaŭ la ŝanĝo. Diveni pri iu ajn el ili produktas peering kiu konektiĝas kaj enkursigas nenion.
Kontrolu per efektivaj itineroj, ne per peering-stato
Rigardu la efektivajn itinerojn sur la reta interfaco de spoke-laborŝarĝo kaj trovu la faktan lokan prefikson. Kontrolu la itinertabelon de la subreto kaj ĉu pordega itinera disvastigo estas malŝaltita, ĉar uzant-difinita itinero aŭ inspekta aparato povas superregi la vojon kiun la peering-flagoj sugestas. Poste konfirmu la alian direkton: la loka reto devas scii kiel atingi la spoke-prefikson tra la site-to-site-konekto, ĉu per lernitaj anoncoj ĉu per eksplicita itinero kaj kongrua protektita-reta enskribo sur la klienta aparato. Se la prefikso mankas sur iu ajn flanko, la peering-flagoj ne estas tio kion ŝanĝi.
Testu unu servon el spoke-laborŝarĝo kaj sekvu la respondon. Testo el la VPN-pordego aŭ el huba VM ekzercas malsaman fontprefikson kaj malsaman vojon.
Se la topologio ankaŭ servas point-to-site-klientojn, validigu iliajn instalitajn itinerojn aparte. Windows-klientaj pakaĵoj povas bezoni regeneradon post topologia ŝanĝo, kaj tio estas klienta enkursiga tasko, ne pruvo ke pordega kunhavigo malsukcesis.
Kion kunhavigi pordegon ne donas
Pordega transito estas enkursiga oportuneco, ne rajtigo. Retaj sekurecgrupoj, lokaj filtriloj kaj servonivelaj reguloj ankoraŭ decidas kion spoke-laborŝarĝo povas atingi, do ebligu la specifan servon de fonto al celo anstataŭ supozi ke la kunhavigita tunelo permesas ĉion malantaŭ ĝi.
Peering ankaŭ ne estas transira tiel kiel homoj esperas. Aldoni alian spoke, aŭ privatan finpunkton, enkondukas proprajn enkursigajn kaj alirajn postulojn kiujn la ekzistanta transita agordo ne kovras.