Potrebuje Azure VNet, povezan s peeringom, lasten prehod VPN?
VNet, povezan s peeringom, lahko uporablja prehod VPN vozlišča s podprtim SKU in eno nastavitvijo v vsaki smeri peeringa. Preverjajte učinkovite poti, ne stanja peeringa.
Pojavi se nov spoke VNet, hub že ima delujoč prehod site-to-site, in očitno vprašanje je, ali morate plačati za drugi prehod. Običajno ne: tranzit prehoda omogoča spoku, da prek peeringa uporablja prehod huba. O tem, ali bo to delovalo, odločajo trije pogoji in nobenega od njih ni videti na znački stanja peeringa. Povezljivost peeringa in dovoljenje za uporabo tujega prehoda sta ločeni nastavitvi, zato dva VM, ki se že lahko pingata, ne dokazujeta ničesar o poti VPN.
Prvi pogoj: prehod in njegova odsotnost v spoku
Azure podpira tranzit prehoda za SKU VPN Gateway razen Basic, in nosi ga lahko regionalni kot globalni peering. Spok uporablja prehod, ki ni njegov, zato ne more imeti svojega: če v spoku že obstaja prehod ali je že izbrana možnost oddaljenega prehoda, želena nastavitev tranzita ne bo na voljo ali ne bo učinkovita. To preverite, preden kar koli razhroščujete, ker je onemogočeno potrditveno polje simptom, ne napaka. Najprej preberite SKU in obstoječi prehod, nato poglejte nastavitve peeringa.
Ne izbrišite obstoječega prehoda spoka, da bi se možnost prikazala, dokler ne veste, kaj je od njega odvisno. Vrstni red selitve je pomembnejši od potrditvenega polja.
Drugi pogoj: ena nastavitev v vsaki smeri peeringa
Peering sta dva objekta, po eden na vsakem VNetu, in nastavitve tranzita živijo na različnih straneh tega para. Peering huba proti spoku mora prehodu huba dovoliti, da streže spoku; peering spoka proti hubu mora sprejeti prehod huba. Microsoftov vodnik za tranzit prehoda jih poimenuje po smeri, in to je edini način, da jih ohranite pravilne:
| 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 |
Kontrolnik z oznako remote spreminja pomen glede na to, kateri peering VNet urejate, zato berite smer, ne besede. Nastavite obe strani, shranite in potrdite, da peering poroča o povezavi na obeh mestih.
Tretji pogoj: naslovni prostor in meje dovoljenj
Tranzit ne more doseči, da bi ista ciljna predpona pomenila dve omrežji, zato morajo biti obsegi huba, spoka in lokalnega omrežja ločeni, preden kar koli od tega deluje. VNeti so lahko tudi v različnih naročninah ali različnih najemnikih; to ni prepoved, vendar identiteta, ki ustvarja ali posodablja vsak peering, potrebuje zahtevana dovoljenja v tem omrežju. Spremembe med naročninami pogosto ne uspejo zaradi dovoljenj, in napako je lahko napačno brati kot težavo topologije.
Obsege in lastnike zapišite pred spremembo. Ugibanje pri katerem koli od njiju ustvari peering, ki se poveže in ničesar ne usmerja.
Preverjajte z učinkovitimi potmi, ne s stanjem peeringa
Poglejte učinkovite poti na omrežnem vmesniku delovne obremenitve v spoku in poiščite dejansko predpono lokalnega omrežja. Preverite usmerjevalno tabelo podomrežja in ali je širjenje poti prehoda onemogočeno, ker lahko uporabniško določena pot ali naprava za pregledovanje preglasi pot, ki jo nakazujejo zastavice peeringa. Nato potrdite nasprotno smer: lokalno omrežje mora vedeti, kako doseči predpono spoka prek povezave site-to-site, bodisi z naučenimi objavami bodisi z izrecno potjo in ustreznim vnosom za zaščiteno omrežje na odjemalčevi napravi. Če predpona manjka na kateri koli strani, zastavice peeringa niso tisto, kar je treba spremeniti.
Preizkusite eno storitev iz delovne obremenitve v spoku in sledite odgovoru. Preizkus s prehoda VPN ali z VM v hubu izvaja drugo izvorno predpono in drugo pot.
Če topologija streže tudi odjemalcem point-to-site, ločeno preverite njihove nameščene poti. Odjemalski paketi Windows bodo morda potrebovali ponovno ustvarjanje po spremembi topologije, in to je naloga usmerjanja na strani odjemalca, ne dokaz, da je skupna raba prehoda spodletela.
Česa skupna raba prehoda ne daje
Tranzit prehoda je udobje usmerjanja, ne avtorizacija. Skupine za varnost omrežja, lokalni filtri in pravila na ravni storitve še vedno odločajo, do česa lahko doseže delovna obremenitev v spoku, zato omogočite konkretno storitev od vira do cilja, namesto da predpostavljate, da skupni tunel dovoljuje vse za njim.
Peering tudi ni tranzitiven tako, kot ljudje upajo. Dodajanje še enega spoka ali zasebne končne točke prinese lastne zahteve po usmerjanju in dostopu, ki jih obstoječa nastavitev tranzita ne pokriva.