Varför point-to-site kräver en ruttbaserad Azure VPN-gateway

En principbaserad gateway bygger en IPsec-tunnel som väljs av trafikväljare, och den har inget gränssnitt att lämna över klientrutter till. Point-to-site är en routingfunktion: gatewayen äger en pool med klientadresser och installerar rutter till dessa klienter i det virtuella nätverket. Det är denna diskrepans som gör att portalen inte visar något alternativ att lägga till den. Ingenting på den befintliga gatewayen kan slås om för att skapa gränssnittet, så ändringen är ett utbyte och inte en konfigurationsändring.

Ordningen spelar större roll än de enskilda stegen. Går sekvensen fel sträcker sig avbrottet mellan platserna förbi underhållsfönstret.

Vad en principbaserad gateway faktiskt gör

En principbaserad gateway matchar paket mot de trafikväljare som är konfigurerade på anslutningen och skickar träffarna in i en enda tunnel. Det finns inget tunnelgränssnitt med adress, och ingen rutt per klient visas någonstans i det virtuella nätverket. Ruttabellen får bara de lokala prefix som pekar på gatewayen. Den modellen räcker för en anslutning mellan platser mellan två fasta adressutrymmen.

En ruttbaserad gateway fungerar tvärtom: den presenterar ett tunnelgränssnitt, och rutter avgör vad som kommer in i det. Point-to-site, och varje design vars uppsättning parter ändras, beror på att det gränssnittet finns.

Varför klientpoolen behöver det gränssnittet

När en bärbar dator ansluter tilldelar gatewayen den en adress från point-to-site-poolen. Det virtuella nätverket behöver då en rutt som säger att den adressen nås via gatewayen. Utan ett tunnelgränssnitt finns det inget att fästa den rutten på.

Poolen kommer från ett intervall som du anger, och gatewayen delar ut från det. Om intervallet överlappar det lokala nätverket eller ett peer-anslutet virtuellt nätverk, syns konflikten först efter att en klient har anslutit, vilket är en dålig tidpunkt att upptäcka den. Reservera poolen innan migreringen börjar.

Inte heller typen är en inställning per anslutning. En gateway har en typ, och varje anslutning den håller beter sig därefter, så en blandad design behöver en andra gateway och inte en andra anslutning.

Typen är låst vid skapandet

Microsoft anger att en gateway för virtuella nätverk inte kan ändras mellan principbaserad och ruttbaserad efter distribution. Det finns inget konverteringskommando och ingen brytare i portalen. Att skapa en andra gateway i samma undernät är inte heller någon omväg, eftersom Azure tillåter en gateway per virtuellt nätverk. Migreringen är därför ta bort, bygga om, ansluta igen.

Det lägger också SKU-beslutet i samma bygge. Att flytta till en större SKU senare är ett nytt gatewaybyte med ett nytt avbrott.

En gateway, ett GatewaySubnet

Gatewayen bor i ett undernät som heter GatewaySubnet, och bara en gateway upptar det. Dimensioneringen av undernätet hör till förberedelsen, eftersom en större SKU behöver fler adresser och ett undernät inte kan krympas i efterhand. Notera de nuvarande inställningarna mellan platser, den delade nyckeln, den lokala nätverksgatewayen och de effektiva rutterna innan du rör något. Behandla sedan fönstret som ett avbrott, eftersom tunneln mellan platserna ligger nere tills den nya anslutningen är konfigurerad.

En ombyggnadsordning som håller avbrottet begränsat: skapa den ruttbaserade gatewayen, återskapa anslutningen mellan platser till samma lokala nätverksgateway, bekräfta tunneln och en begäran från värd till värd, och lägg först därefter till point-to-site och generera ett nytt klientpaket.

Vad utbytet inte åtgärdar

En andra begränsning tillhör parten och inte Azure. En principbaserad lokal enhet kan bara nå det virtuella nätverk den ansluter till, och kan inte gå via samma gateway till andra lokala nätverk eller andra virtuella nätverk. Att byta ut Azure-sidan ändrar inte vad parten kan välja.

Om kravet verkligen är genomgång mellan platser, är svaret en ruttbaserad partsenhet eller en topologi där varje destination avslutas separat. Avgör det innan du lovar ett datum, eftersom gatewaybytet ensamt inte levererar det.

Ordning för åtgärder och kontroller

Verifiera varje förmåga för sig. Först tunnelstatus mellan platserna och en begäran från värd till värd, därefter en point-to-site-anslutning och en privat resurs, därefter varje genomgångsväg som designen hävdar. En grön gatewaystatus bevisar bara att säkerhetsassociationen kom upp, och inget mer. Håll kontrollerna i den ordningen så att ett fel pekar på steget som införde det.

Generera om klientpaketen efter varje topologiändring och håll poolen borta från varje lokalt och peer-anslutet intervall. Begränsningarna och SKU-skillnaderna finns samlade i referensen för Azure VPN Gateway-inställningar.