Har en Azure VNet med peering brug for sin egen VPN-gateway?
En VNet med peering kan bruge hubbens VPN-gateway med en understøttet SKU og én indstilling i hver peering-retning. Kontrollér de effektive ruter, ikke peering-status.
En ny spoke-VNet dukker op, hubben har allerede en fungerende site-to-site-gateway, og det oplagte spørgsmål er, om du skal betale for en ekstra gateway. Som regel ikke: gateway-transit lader spoken bruge hubbens gateway via peering. Tre betingelser afgør, om det virker, og ingen af dem kan ses på peeringsstatusbadgen. Peering-forbindelse og tilladelse til at bruge en andens gateway er separate indstillinger, så to VM’er, der allerede kan pinge hinanden, beviser intet om VPN-stien.
Første betingelse: gatewayen og spokens mangel på en
Azure understøtter gateway-transit for VPN Gateway-SKU’er ud over Basic, og både regional og global peering kan bære den. Spoken bruger en gateway, den ikke ejer, så den kan ikke have sin egen: hvis der allerede findes en gateway i spoken, eller en ekstern gateway-indstilling allerede er valgt, vil den transitindstilling, du ønsker, være utilgængelig eller uden effekt. Kontroller det, før du fejlfinder noget, for den deaktiverede afkrydsningsboks er symptomet, ikke fejlen. Læs SKU’en og den eksisterende gateway først, og se derefter på peering-indstillingerne.
Slet ikke en eksisterende spoke-gateway for at få indstillingen frem, før du ved, hvad der afhænger af den. Migreringsrækkefølgen er vigtigere end afkrydsningsboksen.
Anden betingelse: én indstilling i hver peering-retning
En peering er to objekter, ét på hver VNet, og transitindstillingerne ligger på hver sin side af det par. Hubbens peering mod spoken skal tillade, at hubbens gateway betjener spoken; spokens peering mod hubben skal acceptere hubbens gateway. Microsofts guide til gateway-transit navngiver dem per retning, hvilket er den eneste måde at holde dem rigtige 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 kontrol med navnet remote skifter betydning, alt efter hvilken VNets peering du redigerer, så læs retningen, ikke ordet. Angiv begge sider, gem, og bekræft, at peeringen rapporterer forbindelse begge steder.
Tredje betingelse: adresserum og tilladelsesgrænser
Transit kan ikke få det samme destinationspræfiks til at betyde to netværk, så hub-, spoke- og lokale områder skal være adskilte, før noget af dette virker. VNet’erne kan også ligge i forskellige abonnementer eller forskellige tenants; det er ikke et forbud, men identiteten, der opretter eller opdaterer hver peering, skal have de nødvendige tilladelser på det netværk. Ændringer på tværs af abonnementer fejler ofte på tilladelser, og fejlen er let at fejllæse som et topologiproblem.
Skriv områderne og ejerne ned før ændringen. At gætte på et af dem giver en peering, der forbinder og ikke ruter noget.
Verificer med effektive ruter, ikke med peering-status
Se på de effektive ruter på en spoke-arbejdsbelastnings netværksgrænseflade, og find det faktiske lokale præfiks. Kontroller undernettets rutetabel, og om gateway-ruteudbredelse er deaktiveret, fordi en brugerdefineret rute eller en inspektionsenhed kan tilsidesætte den sti, peering-flagene antyder. Bekræft derefter den anden retning: det lokale netværk skal vide, hvordan det når spoke-præfikset via site-to-site-forbindelsen, enten gennem indlærte annoncer eller gennem en eksplicit rute og en matchende beskyttet-netværk-post på kundeenheden. Hvis præfikset mangler på en af siderne, er det ikke peering-flagene, der skal ændres.
Test én tjeneste fra en spoke-arbejdsbelastning, og følg svaret. En test fra VPN-gatewayen eller fra en hub-VM øver et andet kilde-præfiks og en anden sti.
Hvis topologien også betjener point-to-site-klienter, skal du validere deres installerede ruter separat. Windows-klientpakker kan kræve regenerering efter en topologiændring, og det er en klient-ruteopgave snarere end bevis på, at deling af gatewayen mislykkedes.
Hvad deling af en gateway ikke giver
Gateway-transit er en rutemæssig bekvemmelighed, ikke en autorisation. Netværkssikkerhedsgrupper, lokale filtre og regler på tjenesteniveau afgør stadig, hvad en spoke-arbejdsbelastning kan nå, så aktivér den specifikke kilde-til-destination-tjeneste i stedet for at antage, at den delte tunnel tillader alt bag den.
Peering er heller ikke transitiv på den måde, folk håber. Tilføjelse af endnu en spoke, eller et privat endepunkt, indfører sine egne rute- og adgangskrav, som den eksisterende transitindstilling ikke dækker.