Het ’n Azure VNet met peering sy eie VPN-gateway nodig?

’n Nuwe spoke-VNet verskyn, die hub het reeds ’n werkende site-to-site-gateway, en die vanselfsprekende vraag is of jy vir ’n tweede gateway moet betaal. Gewoonlik nie: gateway-transit laat die spoke die hub se gateway oor peering gebruik. Drie voorwaardes bepaal of dit sal werk, en nie een daarvan is in die peering-status-kenteken sigbaar nie. Peering-konnektiwiteit en toestemming om iemand anders se gateway te gebruik is aparte instellings, so twee VM's wat mekaar al kan ping, bewys niks oor die VPN-roete nie.

Eerste voorwaarde: die gateway, en die feit dat die spoke nie een het nie

Azure ondersteun gateway-transit vir VPN Gateway-SKU's anders as Basic, en beide streeks- en globale peering kan dit dra. Die spoke gebruik ’n gateway wat hy nie besit nie, so hy kan nie een van sy eie hê nie: as daar reeds ’n gateway in die spoke bestaan, of ’n opsie vir ’n afgeleë gateway reeds gekies is, sal die transit-instelling wat jy wil hê onbeskikbaar of ondoeltreffend wees. Kontroleer dit voordat jy enigiets ontfout, want die gedeaktiveerde merkblokkie is die simptoom, nie die fout nie. Lees eers die SKU en die bestaande gateway, en kyk dan na die peering-instellings.

Moet nie ’n bestaande spoke-gateway skrap net om die opsie te laat verskyn voordat jy weet wat daarvan afhanklik is nie. Migrasievolgorde maak meer saak as die merkblokkie.

Tweede voorwaarde: een instelling in elke peering-rigting

’n Peering is twee objekte, een op elke VNet, en die transit-instellings woon aan verskillende kante van daardie paar. Die hub se peering na die spoke moet toelaat dat die hub-gateway die spoke bedien; die spoke se peering na die hub moet die hub se gateway aanvaar. Microsoft se gids vir gateway-transit noem hulle per rigting, wat die enigste manier is om hulle reg te hou:

’n Beheer wat as remote gemerk is, verander betekenis na gelang van watter VNet se peering jy wysig, so lees die rigting, nie die woord nie. Stel beide kante, stoor, en bevestig dat die peering op beide plekke as verbind gerapporteer word.

Derde voorwaarde: adresruimte en toestemmingsgrense

Transit kan nie dieselfde bestemmingsvoorvoegsel twee netwerke laat beteken nie, so hub-, spoke- en plaaslike reekse moet los van mekaar wees voordat enigiets hiervan werk. Die VNet's kan ook in verskillende subskripsies of verskillende tenante sit; dit is nie ’n verbod nie, maar die identiteit wat elke peering skep of bywerk, het die nodige toestemmings op daardie netwerk nodig. Veranderinge oor subskripsies heen misluk gewoonlik op toestemming, en die fout is maklik om as ’n topologieprobleem verkeerd te lees.

Skryf die reekse en die eienaars voor die verandering neer. Om aan enigeen te raai, lewer ’n peering wat verbind en niks roeteer nie.

Verifieer met effektiewe roetes, nie met peering-status nie

Kyk na die effektiewe roetes op ’n spoke-werklading se netwerkkoppelvlak en vind die werklike plaaslike voorvoegsel. Kontroleer die subnet se roetetabel en of gateway-roeteverspreiding gedeaktiveer is, want ’n gebruikergedefinieerde roete of ’n inspeksietoestel kan die pad oorheers wat die peering-vlae voorstel. Bevestig dan die ander rigting: die plaaslike netwerk moet weet hoe om die spoke-voorvoegsel deur die site-to-site-verbinding te bereik, hetsy deur aangeleerde aankondigings of deur ’n eksplisiete roete en ’n ooreenstemmende beskermde-netwerk-inskrywing op die kliënttoestel. As die voorvoegsel aan enige kant ontbreek, is die peering-vlae nie die ding wat verander moet word nie.

Toets een diens vanaf ’n spoke-werklading en volg die antwoord. ’n Toets vanaf die VPN-gateway of vanaf ’n hub-VM oefen ’n ander bronvoorvoegsel en ’n ander pad.

As die topologie ook point-to-site-kliënte bedien, valideer hulle geïnstalleerde roetes afsonderlik. Windows-kliëntpakkette kan ná ’n topologieverandering weer gegenereer moet word, en dit is ’n kliëntroetetaak eerder as bewys dat gateway-deling misluk het.

Wat die deel van ’n gateway nie toestaan nie

Gateway-transit is ’n roetegerief, nie ’n magtiging nie. Netwerkbeveiligingsgroepe, plaaslike filters en diensvlakreëls besluit steeds wat ’n spoke-werklading mag bereik, so aktiveer die spesifieke bron-tot-bestemming-diens in plaas daarvan om te aanvaar dat die gedeelde tonnel alles daarachter toelaat.

Peering is ook nie oordraagbaar op die manier wat mense hoop nie. Om nog ’n spoke, of ’n private endpoint, by te voeg, bring sy eie roete- en toegangsvereistes mee wat die bestaande transit-instelling nie dek nie.