Hvorfor point-to-site trenger en rutebasert Azure VPN-gateway

En policybasert gateway bygger en IPsec-tunnel som velges av trafikkvelgere, og den har ingen grensesnitt å levere klientruter til. Point-to-site er en rutingfunksjon: gatewayen eier en klientadressepool og installerer ruter til disse klientene i det virtuelle nettverket. Denne uoverensstemmelsen er grunnen til at portalen ikke viser noen mulighet for å legge den til. Ingenting på den eksisterende gatewayen kan slås om for å lage grensesnittet, så endringen er en utskifting og ikke en konfigurasjonsendring.

Rekkefølgen betyr mer enn de enkelte trinnene. Tar du feil av sekvensen, strekker avbruddet mellom nettstedene seg utover vedlikeholdsvinduet.

Hva en policybasert gateway faktisk gjør

En policybasert gateway matcher pakker mot trafikkvelgerne som er konfigurert på tilkoblingen, og sender treffene inn i én tunnel. Det finnes ikke noe tunnelgrensesnitt med adresse, og ingen rute per klient vises noe sted i det virtuelle nettverket. Rutetabellen får bare de lokale prefiksene som peker på gatewayen. Den modellen er tilstrekkelig for en tilkobling mellom nettsteder mellom to faste adresserom.

En rutebasert gateway fungerer motsatt: den presenterer et tunnelgrensesnitt, og ruter avgjør hva som kommer inn i det. Point-to-site, og ethvert design der settet av parter endres, avhenger av at dette grensesnittet finnes.

Hvorfor klientpoolen trenger dette grensesnittet

Når en bærbar PC kobler til, tildeler gatewayen den en adresse fra point-to-site-poolen. Det virtuelle nettverket trenger da en rute som sier at denne adressen er nåbar gjennom gatewayen. Uten et tunnelgrensesnitt er det ingenting å feste den ruten til.

Poolen kommer fra et område du angir, og gatewayen tildeler fra det. Hvis området overlapper det lokale nettverket eller et peer-tilkoblet virtuelt nettverk, vises konflikten først etter at en klient har koblet til, noe som er et dårlig tidspunkt å oppdage den på. Reserver poolen før migreringen begynner.

Typen er heller ikke en innstilling per tilkobling. En gateway har én type, og hver tilkobling den holder oppfører seg deretter, så et blandet design trenger en annen gateway og ikke en annen tilkobling.

Typen er fastlåst ved opprettelsen

Microsoft oppgir at en gateway for virtuelle nettverk ikke kan endres mellom policybasert og rutebasert etter distribusjon. Det finnes ingen konverteringskommando og ingen bryter i portalen. Å opprette en annen gateway i samme subnett er heller ingen omvei, fordi Azure tillater én gateway per virtuelt nettverk. Migreringen er derfor fjern, bygg på nytt, koble til på nytt.

Det legger også SKU-avgjørelsen inn i samme bygging. Å flytte til en større SKU senere er en ny gateway-utskifting med et nytt avbrudd.

Én gateway, ett GatewaySubnet

Gatewayen bor i et subnett som heter GatewaySubnet, og bare én gateway opptar det. Dimensjoneringen av dette subnettet hører til forberedelsen, fordi en større SKU trenger flere adresser, og et subnett kan ikke krympes etterpå. Noter de nåværende innstillingene mellom nettsteder, den delte nøkkelen, den lokale nettverksgatewayen og de effektive rutene før du rører noe. Behandle deretter vinduet som et avbrudd, fordi tunnelen mellom nettstedene forblir nede til den nye tilkoblingen er konfigurert.

En gjenoppbyggingsrekkefølge som holder avbruddet begrenset: opprett den rutebaserte gatewayen, gjenopprett tilkoblingen mellom nettstedene til den samme lokale nettverksgatewayen, bekreft tunnelen og én forespørsel fra vert til vert, og legg først deretter til point-to-site og generer en ny klientpakke.

Hva utskiftingen ikke fikser

En andre begrensning tilhører parten og ikke Azure. En policybasert lokal enhet kan bare nå det virtuelle nettverket den kobles til, og kan ikke gå via den samme gatewayen til andre lokale nettverk eller andre virtuelle nettverk. Å skifte ut Azure-siden endrer ikke hva parten kan velge.

Hvis kravet virkelig er gjennomgang mellom nettsteder, er svaret en rutebasert partsenhet eller en topologi der hver destinasjon avsluttes separat. Avklar det før du lover en dato, fordi gateway-utskiftingen alene ikke leverer det.

Rekkefølge for operasjoner og kontroller

Bekreft hver egenskap for seg. Først tunnelstatus mellom nettstedene og én forespørsel fra vert til vert, deretter en point-to-site-tilkobling og én privat ressurs, deretter enhver gjennomgangsvei designet hevder. En grønn gateway-status beviser bare at sikkerhetstilknytningen kom opp, og ikke noe mer. Hold kontrollene i den rekkefølgen slik at en feil peker på trinnet som innførte den.

Generer klientpakker på nytt etter enhver topologiendring, og hold poolen unna hvert lokalt og peer-tilkoblet område. Begrensningene og SKU-forskjellene er samlet i referansen for Azure VPN Gateway-innstillinger.