Trenger en Azure VNet med peering sin egen VPN-gateway?
En VNet med peering kan bruke hubens VPN-gateway med en støttet SKU og én innstilling i hver peering-retning. Verifiser de effektive rutene, ikke peering-statusen.
En ny spoke-VNet dukker opp, huben har allerede en fungerende site-til-site-gateway, og det åpenbare spørsmålet er om du må betale for en ekstra gateway. Som regel ikke: gateway-transitt lar spoken bruke hubens gateway via peering. Tre betingelser avgjør om det virker, og ingen av dem er synlige på peering-statusmerket. Peering-tilkobling og tillatelse til å bruke en annens gateway er separate innstillinger, så to VM-er som allerede kan pinge hverandre beviser ingenting om VPN-stien.
Første betingelse: gatewayen, og spokens mangel på en
Azure støtter gateway-transitt for VPN Gateway-SKU-er utover Basic, og både regional og global peering kan bære den. Spoken bruker en gateway den ikke eier, så den kan ikke ha sin egen: hvis det allerede finnes en gateway i spoken, eller et ekstern gateway-alternativ allerede er valgt, vil transittinnstillingen du ønsker være utilgjengelig eller uten effekt. Kontroller det før du feilsøker noe, fordi den deaktiverte avkrysningsboksen er symptomet, ikke feilen. Les SKU-en og den eksisterende gatewayen først, og se deretter på peering-innstillingene.
Ikke slett en eksisterende spoke-gateway for å få alternativet til å vises før du vet hva som avhenger av den. Migreringsrekkefølgen er viktigere enn avkrysningsboksen.
Andre betingelse: én innstilling i hver peering-retning
En peering er to objekter, ett på hver VNet, og transittinnstillingene bor på hver sin side av det paret. Hubens peering mot spoken må tillate at hubens gateway betjener spoken; spokens peering mot huben må godta hubens gateway. Microsofts veiledning for gateway-transitt navngir dem per retning, og det er den eneste måten å holde dem 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 |
En kontroll merket remote endrer betydning avhengig av hvilken VNets peering du redigerer, så les retningen, ikke ordet. Sett begge sider, lagre og bekreft at peeringen rapporterer tilkoblet begge steder.
Tredje betingelse: adresserom og tillatelsesgrenser
Transitt kan ikke få det samme destinasjonsprefikset til å bety to nettverk, så hub-, spoke- og lokale områder må være adskilte før noe av dette virker. VNet-ene kan også ligge i ulike abonnementer eller ulike leietakere; det er ikke et forbud, men identiteten som oppretter eller oppdaterer hver peering trenger de nødvendige tillatelsene på det nettverket. Endringer på tvers av abonnementer feiler ofte på tillatelser, og feilen er lett å feilleses som et topologiproblem.
Skriv ned områdene og eierne før endringen. Å gjette på ett av dem gir en peering som kobler til og ikke ruter noe.
Verifiser med effektive ruter, ikke med peering-status
Se på de effektive rutene på nettverksgrensesnittet til en spoke-arbeidsbelastning og finn det faktiske lokale prefikset. Kontroller subnettets rutetabell og om gateway-ruteutbredelse er deaktivert, fordi en brukerdefinert rute eller en inspeksjonsenhet kan overstyre stien peering-flaggene antyder. Bekreft deretter den andre retningen: det lokale nettverket må vite hvordan det når spoke-prefikset via site-til-site-forbindelsen, enten gjennom lærte annonser eller gjennom en eksplisitt rute og en samsvarende beskyttet nettverksoppføring på kundeenheten. Hvis prefikset mangler på en av sidene, er det ikke peering-flaggene som skal endres.
Test én tjeneste fra en spoke-arbeidsbelastning og følg svaret. En test fra VPN-gatewayen eller fra en hub-VM bruker et annet kildeperfiks og en annen sti.
Hvis topologien også betjener point-to-site-klienter, valider de installerte rutene deres separat. Windows-klientpakker kan trenge regenerering etter en topologiendring, og det er en klientruteoppgave snarere enn bevis på at deling av gatewayen mislyktes.
Hva deling av en gateway ikke gir
Gateway-transitt er en rutemessig bekvemmelighet, ikke en autorisasjon. Nettverkssikkerhetsgrupper, lokale filtre og regler på tjenestenivå avgjør fortsatt hva en spoke-arbeidsbelastning kan nå, så aktiver den konkrete kilde-til-destinasjon-tjenesten i stedet for å anta at den delte tunnelen tillater alt bak den.
Peering er heller ikke transitiv slik folk håper. Å legge til en ny spoke, eller et privat endepunkt, innfører sine egne rute- og tilgangskrav som den eksisterende transittinnstillingen ikke dekker.