Treng ein Azure VNet med peering sin eigen VPN-gateway?
Eit VNet med peering kan bruke VPN-gatewayen til huben med ein støtta SKU og éi innstilling i kvar peering-retning. Verifiser dei effektive rutene, ikkje peering-statusen.
Ein ny spoke-VNet dukkar opp, huben har allereie ein fungerande site-til-site-gateway, og det openberre spørsmålet er om du må betale for ein ekstra gateway. Som regel ikkje: gateway-transitt lèt spoken bruke gatewayen til huben via peering. Tre vilkår avgjer om det verkar, og ingen av dei er synlege på peering-statusmerket. Peering-tilkopling og løyve til å bruke gatewayen til ein annan er separate innstillingar, så to VM-ar som allereie kan pinge kvarandre beviser ingenting om VPN-stien.
Fyrste vilkår: gatewayen, og mangelen på ein i spoken
Azure støttar gateway-transitt for VPN Gateway-SKU-ar utover Basic, og både regional og global peering kan bera han. Spoken brukar ein gateway han ikkje eig, så han kan ikkje ha sin eigen: viss det allereie finst ein gateway i spoken, eller eit eksternt gateway-alternativ allereie er valt, vil transittinnstillinga du ønskjer vere utilgjengeleg eller utan effekt. Kontroller det før du feilsøkjer noko, fordi den deaktiverte avkryssingsboksen er symptomet, ikkje feilen. Les SKU-en og den eksisterande gatewayen fyrst, og sjå deretter på peering-innstillingane.
Ikkje slett ein eksisterande spoke-gateway for å få alternativet til å visast før du veit kva som avheng av han. Migreringsrekkjefølgja er viktigare enn avkryssingsboksen.
Andre vilkår: éi innstilling i kvar peering-retning
Ein peering er to objekt, eitt på kvar VNet, og transittinnstillingane bur på kvar si side av det paret. Peeringa til huben mot spoken må tillate at gatewayen til huben tener spoken; peeringa til spoken mot huben må godta gatewayen til huben. rettleiinga til Microsoft for gateway-transitt namngjev dei per retning, og det er den einaste måten å halde dei riktige på:
| 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 |
Eit kontrollmerkt remote endrar tyding avhengig av kva VNet si peering du redigerer, så les retninga, ikkje ordet. Set begge sider, lagre og stadfest at peeringa rapporterer tilkopla begge stader.
Tredje vilkår: adresserom og løyvegrensar
Transitt kan ikkje få det same målprefikset til å bety to nettverk, så områda til hub, spoke og det lokale nettet må vere åtskilde før noko av dette verkar. VNet-ane kan også liggje i ulike abonnement eller ulike leigetakarar; det er ikkje eit forbod, men identiteten som opprettar eller oppdaterer kvar peering treng dei nødvendige løyva på det nettverket. Endringar på tvers av abonnement feilar ofte på løyve, og feilen er lett å feilleses som eit topologiproblem.
Skriv ned områda og eigarane før endringa. Å gjette på eitt av dei gir ei peering som koplar til og ikkje rutar noko.
Verifiser med effektive ruter, ikkje med peering-status
Sjå på dei effektive rutene på nettverksgrensesnittet til ein spoke-arbeidslast og finn det faktiske lokale prefikset. Kontroller rutetabellen til subnettet og om gateway-ruteutbreiing er deaktivert, fordi ei brukardefinert rute eller ein inspeksjonseining kan overstyre stien peering-flaggene antydar. Stadfest deretter den andre retninga: det lokale nettet må vite korleis det når spoke-prefikset via site-til-site-sambandet, anten gjennom lærde annonsar eller gjennom ei eksplisitt rute og ei samsvarande oppføring for eit verna nettverk på kundeeininga. Viss prefikset manglar på ein av sidene, er det ikkje peering-flaggene som skal endrast.
Test éin teneste frå ein spoke-arbeidslast og følg svaret. Ein test frå VPN-gatewayen eller frå ein hub-VM brukar eit anna kjeldedprefiks og ein annan sti.
Viss topologien også tener point-to-site-klientar, valider dei installerte rutene deira separat. Windows-klientpakkar kan trengje regenerering etter ei topologiendring, og det er ein klientruteoppgåve snarare enn prov på at deling av gatewayen mislukkast.
Kva deling av ein gateway ikkje gir
Gateway-transitt er ei rutemessig lettvintheit, ikkje ein autorisasjon. Nettverkssikkerheitsgrupper, lokale filter og reglar på tenestenivå avgjer framleis kva ein spoke-arbeidslast kan nå, så aktiver den konkrete kjelde-til-mål-tenesta i staden for å anta at den delte tunnelen tillèt alt bak han.
Peering er heller ikkje transitiv slik folk håpar. Å leggje til ein ny spoke, eller eit privat endepunkt, innfører eigne rute- og tilgangskrav som den eksisterande transittinnstillinga ikkje dekkjer.