Hvorfor point-to-site kræver en rutebaseret Azure VPN-gateway

En politikbaseret gateway opbygger en IPsec-tunnel, der vælges af trafikvælgere, og den har ingen grænseflade at overlade klientruter til. Point-to-site er en routingfunktion: gatewayen ejer en pulje af klientadresser og installerer ruter til disse klienter i det virtuelle netværk. Den uoverensstemmelse er grunden til, at portalen ikke viser nogen mulighed for at tilføje den. Intet på den eksisterende gateway kan slås til for at skabe grænsefladen, så ændringen er en udskiftning og ikke en redigering af konfigurationen.

Rækkefølgen betyder mere end de enkelte trin. Tager du fejl af sekvensen, strækker afbrydelsen mellem websteder sig ud over vedligeholdelsesvinduet.

Hvad en politikbaseret gateway egentlig gør

En politikbaseret gateway matcher pakker mod de trafikvælgere, der er konfigureret på forbindelsen, og sender matchningerne ind i én tunnel. Der er ingen tunnelgrænseflade med en adresse, og der vises ingen rute per klient noget sted i det virtuelle netværk. Rutetabellen får blot de lokale præfikser, der peger på gatewayen. Den model er tilstrækkelig til en forbindelse mellem websteder mellem to faste adresserum.

En rutebaseret gateway virker omvendt: den fremviser en tunnelgrænseflade, og ruter afgør, hvad der kommer ind i den. Point-to-site, og ethvert design hvis sæt af parter ændrer sig, afhænger af, at den grænseflade findes.

Hvorfor klientpuljen har brug for den grænseflade

Når en bærbar computer opretter forbindelse, tildeler gatewayen den en adresse fra point-to-site-puljen. Det virtuelle netværk har så brug for en rute, der siger, at denne adresse kan nås gennem gatewayen. Uden en tunnelgrænseflade er der intet at knytte den rute til.

Puljen kommer fra et interval, du udpeger, og gatewayen tildeler fra det. Hvis det interval overlapper det lokale netværk eller et peered virtuelt netværk, viser konflikten sig først, efter at en klient har oprettet forbindelse, hvilket er et dårligt tidspunkt at opdage den på. Reserver puljen, før migreringen begynder.

Typen er heller ikke en indstilling per forbindelse. En gateway har én type, og hver forbindelse, den holder, opfører sig derefter, så et blandet design har brug for en anden gateway i stedet for en anden forbindelse.

Typen er fastlagt ved oprettelsen

Microsoft angiver, at en virtuel netværksgateway ikke kan ændres mellem politikbaseret og rutebaseret efter udrulning. Der er ingen konverteringskommando og ingen kontakt i portalen. At oprette en anden gateway i samme undernet er heller ikke en omvej, fordi Azure tillader én gateway per virtuelt netværk. Migreringen er derfor fjern, genopbyg, genopret forbindelse.

Det indarbejder også SKU-beslutningen i samme opbygning. Skift til en større SKU senere er endnu en gatewayudskiftning med endnu en afbrydelse.

Én gateway, ét GatewaySubnet

Gatewayen bor i et undernet med navnet GatewaySubnet, og kun én gateway optager det. Dimensioneringen af det undernet hører til forberedelsen, fordi en større SKU kræver flere adresser, og et undernet kan ikke formindskes bagefter. Noter de nuværende indstillinger for websted til websted, den delte nøgle, den lokale netværksgateway og de effektive ruter, før du rører noget. Behandl derefter vinduet som en afbrydelse, fordi tunnelen mellem websteder forbliver nede, indtil den nye forbindelse er konfigureret.

En genopbygningsrækkefølge, der holder afbrydelsen afgrænset: opret den rutebaserede gateway, genskab forbindelsen mellem websteder til den samme lokale netværksgateway, bekræft tunnelen og én anmodning fra vært til vært, og tilføj først derefter point-to-site og generer en ny klientpakke.

Hvad udskiftningen ikke løser

En anden begrænsning tilhører modparten og ikke Azure. En politikbaseret lokal enhed kan kun nå det virtuelle netværk, den er forbundet med, og kan ikke transitere til andre lokale netværk eller andre virtuelle netværk gennem den samme gateway. Udskiftning af Azure-siden ændrer ikke, hvad modparten kan vælge.

Hvis kravet virkelig er transit mellem websteder, er svaret en rutebaseret modpartsenhed eller en topologi, hvor hver destination afsluttes separat. Afklar det, før du lover en dato, fordi gatewayudskiftningen alene ikke leverer det.

Rækkefølge for handlinger og kontroller

Bekræft hver funktion for sig. Først tunnelstatus mellem websteder og én anmodning fra vært til vært, derefter en point-to-site-forbindelse og én privat ressource, derefter enhver transitvej, som designet hævder. En grøn gatewaystatus beviser kun, at sikkerhedsassociationen kom op, og intet mere. Hold kontrollerne i den rækkefølge, så en fejl peger på det trin, der indførte den.

Genopret klientpakker efter enhver topologiændring, og hold puljen fri af ethvert lokalt og peered interval. Begrænsningerne og SKU-forskellene er samlet i referenceværket for Azure VPN Gateway-indstillinger.