Waarom point-to-site een routegebaseerde Azure VPN-gateway nodig heeft

Een beleidsgebaseerde gateway bouwt een IPsec-tunnel die door verkeersselectoren wordt gekozen, en heeft geen interface om clientroutes aan af te geven. Point-to-site is een routingfunctie: de gateway bezit een pool met clientadressen en installeert routes naar die clients in het virtuele netwerk. Die mismatch is de reden dat de portal geen optie toont om het toe te voegen. Niets op de bestaande gateway kan worden omgeschakeld om de interface te maken, dus de wijziging is een vervanging en geen configuratiebewerking.

De volgorde is belangrijker dan de afzonderlijke stappen. Gaat de volgorde mis, dan loopt de storing tussen sites voorbij het onderhoudsvenster.

Wat een beleidsgebaseerde gateway werkelijk doet

Een beleidsgebaseerde gateway vergelijkt pakketten met de verkeersselectoren die op de verbinding zijn geconfigureerd en stuurt de overeenkomsten naar één tunnel. Er is geen tunnelinterface met een adres, en nergens in het virtuele netwerk verschijnt een route per client. De routetabel krijgt alleen de lokale prefixen die naar de gateway wijzen. Dat model volstaat voor een verbinding tussen sites tussen twee vaste adresruimten.

Een routegebaseerde gateway werkt omgekeerd: hij biedt een tunnelinterface, en routes bepalen wat erin komt. Point-to-site, en elk ontwerp waarvan de set peers verandert, hangt af van het bestaan van die interface.

Waarom de clientpool die interface nodig heeft

Wanneer een laptop verbinding maakt, wijst de gateway er een adres uit de point-to-site-pool aan toe. Het virtuele netwerk heeft dan een route nodig die zegt dat dit adres via de gateway bereikbaar is. Zonder tunnelinterface is er niets om die route aan te koppelen.

De pool komt uit een bereik dat u opgeeft, en de gateway deelt daaruit uit. Als dat bereik overlapt met het lokale netwerk of met een gepeerd virtueel netwerk, komt het conflict pas aan het licht nadat een client verbinding heeft gemaakt, wat een slecht moment is om het te ontdekken. Reserveer de pool voordat de migratie begint.

Het type is ook geen instelling per verbinding. Eén gateway heeft één type, en elke verbinding die hij houdt gedraagt zich daarnaar, dus een gemengd ontwerp heeft een tweede gateway nodig en niet een tweede verbinding.

Het type staat vast bij het aanmaken

Microsoft stelt dat een gateway voor virtuele netwerken na implementatie niet kan worden gewijzigd tussen beleidsgebaseerd en routegebaseerd. Er is geen conversieopdracht en geen schakelaar in de portal. Een tweede gateway in hetzelfde subnet maken is ook geen omweg, omdat Azure één gateway per virtueel netwerk toestaat. De migratie is daarom verwijderen, opnieuw opbouwen en opnieuw verbinden.

Dat brengt ook de SKU-keuze in dezelfde opbouw. Later naar een grotere SKU gaan is nog een gatewayvervanging met nog een storing.

Eén gateway, één GatewaySubnet

De gateway woont in een subnet met de naam GatewaySubnet, en slechts één gateway neemt het in beslag. Het dimensioneren van dat subnet hoort bij de voorbereiding, omdat een grotere SKU meer adressen nodig heeft en een subnet achteraf niet kan worden verkleind. Noteer de huidige instellingen tussen sites, de gedeelde sleutel, de lokale netwerkgateway en de effectieve routes voordat u iets aanraakt. Behandel het venster daarna als een storing, omdat de tunnel tussen sites omlaag blijft tot de nieuwe verbinding is geconfigureerd.

Een herbouwvolgorde die de storing begrensd houdt: maak de routegebaseerde gateway aan, maak de verbinding tussen sites opnieuw naar dezelfde lokale netwerkgateway, bevestig de tunnel en één verzoek van host naar host, en voeg pas daarna point-to-site toe en genereer een nieuw clientpakket.

Wat de vervanging niet oplost

Een tweede beperking hoort bij de peer en niet bij Azure. Een beleidsgebaseerd lokaal apparaat kan alleen het virtuele netwerk bereiken waarmee het is verbonden, en kan niet via dezelfde gateway naar andere lokale netwerken of andere virtuele netwerken doorvoeren. Het vervangen van de Azure-kant verandert niet wat de peer kan selecteren.

Als de eis werkelijk doorvoer tussen sites is, is het antwoord een routegebaseerd peerapparaat of een topologie waarin elke bestemming afzonderlijk eindigt. Beslis dat voordat u een datum belooft, want de gatewayvervanging alleen levert het niet.

Volgorde van handelingen en controles

Controleer elke mogelijkheid afzonderlijk. Eerst de tunnelstatus tussen sites en één verzoek van host naar host, dan een point-to-site-verbinding en één privéresource, dan elk doorvoerpad dat het ontwerp claimt. Een groene gatewaystatus bewijst alleen dat de beveiligingskoppeling tot stand kwam, en niets meer. Houd de controles in die volgorde zodat een fout wijst naar de fase die hem heeft ingevoerd.

Genereer clientpakketten opnieuw na elke topologiewijziging en houd de pool vrij van elk lokaal en gepeerd bereik. De beperkingen en SKU-verschillen zijn verzameld in de referentie voor Azure VPN Gateway-instellingen.