Statisk IP i Azure P2S VPN: varför klientens adress ändras

Varje Azure point-to-site-klient får en adress ur poolen när den autentiserar sig och behåller den bara så länge den anslutningen varar. Det finns ingen reservationstabell, ingen tilldelning per användare och ingen gateway-inställning som betyder ”ge alltid den här personen 172.16.0.10”. Just den här enda mekanismen förklarar båda symptomen som folk stöter på senare: en NSG-regel som slutar matcha en användare den tidigare matchade, och en tillåtelselista som tyst släpper in en maskin som ingen medvetet har lagt till. Att byta ut regeln mot en smartare IP-regel reparerar inget av dem, eftersom det regeln namnger tilldelas om enligt ett schema du inte kontrollerar.

Poolen är kapacitet, inte identitet. Den finns för att samtidiga tunnlar ska få unika adresser, och den återanvänder dem i samma ögonblick som en lease går ut. När det är klart slutar den användbara frågan vara ”hur fäster jag den här klienten” och blir ”vad kan jag skriva en regel mot som gatewayen inte återanvänder”.

Vad gatewayen faktiskt gör när en klient ansluter

Gatewayen håller den konfigurerade klientadresspoolen och behandlar den som en leasetabell. Vid anslutning tar den nästa lediga adress, i praktiken den lägsta tillgängliga, och tilldelar den tunneladaptern tills klienten kopplar från eller leasen löper ut. Ordningen avgör, inte identiteten: den som återansluter först efter en lugn period får den lägsta adressen som råkar vara ledig i det ögonblicket.

Poolens storlek döljer beteendet. En laboratoriepool som är en eller två adresser större än antalet testare verkar deterministisk, eftersom samma laptop tenderar att återansluta i samma ordning varje morgon. Lägg till en tredje maskin, ändra poolens storlek eller låt en session vara ansluten över lunchen, och mönstret bryts. Adressen var aldrig stabil; kön var det.

Varje ändring av point-to-site-konfigurationen nollställer också leaseutrymmet. En annan autentiseringstyp, en pool med ändrad storlek, ett nytt poolintervall eller en gateway som rivs och byggs upp igen skickar alla klienter tillbaka till en pool som inte längre motsvarar deras gamla adresser. Inget i den ändringen rör din NSG, och därför ser felet spontant ut.

Du kan se det hända på ungefär en minut. Anslut, anteckna tunneladressen i klientens anslutningsinformation, koppla från, anslut en andra maskin och återanslut sedan den första. Adressen du får tillbaka beror på vad den andra maskinen håller, och ingen portalinställning återställer den tidigare på begäran.

En NSG som är knuten till klientens IP är egentligen en regel om anslutningsordningen

Regeln folk skriver först är den uppenbara: en inkommande regel på NIC:en för administrations-VM:en eller på dess undernät, med VPN-klientens interna adress som källa. Den är kort, den klarar testet samma dag den skrivs och den fallerar så snart poolen har mer än en ledig adress.

Av det följer två fellägen, och bara ett av dem ser ut som en bugg. En legitim användare nekas eftersom någon annan just nu håller adressen regeln namnger, och det kommer in som ett irriterande supportärende. Eller så släpps en oavsiktlig användare in eftersom hen ärvt en adress som regeln fortfarande litar på, och det kommer inte in som någonting alls förrän någon granskar åtkomsten.

Eftersom regeln följer leasen lyder den effektiva policyn ”den första som ansluter får administrationsåtkomst”. Det är en beskrivning av anslutningsordningen klädd som avsikt, och ingen regelhygien gör den till ett uttryck för avsikt.

Klientens lease och gatewayens adress är olika objekt

Det mesta av förvirringen kommer från ett ord. Gatewayen har en offentlig IP som är förhållandevis stabil; klienterna har privata adresser ur poolen som inte är det. För en VPN-gateway utan zonredundans tilldelas den offentliga IP:n dynamiskt, men den överlever en storleksändring, en återställning och rutinunderhåll — den ändras när själva gatewayen raderas och skapas på nytt. Zonredundanta och zonbaserade gateway-SKU:er använder en offentlig IP av Standard-SKU, och den tilldelningen måste vara statisk.

Den stabiliteten är vad en lokal peer behöver i sin konfiguration, och den säger ingenting om att identifiera en enskild klient. När en partner frågar vilken adress de kommer att se är svaret gatewayens offentliga IP under site-to-site, eller ett delat NAT-intervall — aldrig en laptops tunnellease.

Gruppoolar ger dig ett intervall som det är värt att skriva regler mot

Virtual WAN point-to-site stöder användargrupper, och varje grupp kan tilldelas sin egen klientadresspool. Medlemskap avgörs av identitet, så intervallet en klient hamnar i blir förutsägbart: drift i ett intervall, underleverantörer i ett annat, och intervallet är något som en brandväggs- eller NSG-regel kan namnge utan att gissa.

Den resulterande regeluppsättningen har en form du kan granska:

• en pool per målgrupp, dimensionerad för toppar av samtidiga sessioner i stället för antal personer;
• gruppmedlemskap hanteras via identitet, inte genom att redigera regler varje gång någon ansluter;
• NSG- eller Azure Firewall-regler skrivna mot poolintervall, aldrig mot enskilda leasar;
• ett eget nav eller en egen gateway för målgrupper som aldrig får dela ett intervall.

Att sätta en hel pool i tillåtelselistan är ärligt men grovt: varje ansluten klient i det intervallet får samma åtkomst. Det är ett policybeslut som det är värt att säga högt i stället för att upptäcka vid en genomgång. Allt som fortfarande behöver ett svar per person hör till resursen via rolltilldelningar, inte till paketfiltret.

När utrullningen inte kan flytta till Virtual WAN

Många gatewayer förblir vanliga VPN-gatewayer, och att flytta till Virtual WAN är inte en tillfällig ändring. Det praktiska svaret är att flytta beslutet per användare från paketfiltret till något som redan vet vem användaren är.

Identitet på resursnivå är den billigaste versionen. Storage, SQL och Key Vault stöder alla Entra ID-autentisering med rolltilldelningar per användare eller per grupp, så VPN:en behöver bara bevisa nätverksnåbarhet. En hoppvärd med namngivna konton gör samma arbete för administrativa uppgifter, eftersom värden registrerar människan och tunneln bara fraktar paket. Att registrera klienter i DNS och tillåta namnet i stället för numret flyttar regeln en nivå upp. Identitet på applikationsnivån — ett certifikatsubjekt, ett tokenpåstående, ett gruppmedlemskap — fungerar när det är applikationen, inte nätet, som ombeds avgöra.

För en partner som insisterar på en fast källadress är svaret site-to-site eller ExpressRoute med ett definierat peer-prefix. De tillåter peer-prefixet, adressen som visas på deras sida tillhör gatewayen, och den ändras inte när någon startar om en laptop.

Kontrollera poolen innan du redigerar ännu en tillåtelselista

Två egenskaper hos poolen orsakar det mesta av beteendet folk skyller på klienten. En för liten pool återanvänder leasar snabbt, så adresser ser ut att flytta sig hela tiden och varje adressbaserad regel verkar opålitlig av design. En pool som överlappar de lokala intervallen eller det virtuella nätets adressutrymme skapar routingoklarhet som ingen brandväggsregel reparerar.

Sätt tre saker på en sida innan du rör en regel: point-to-site-poolen, det virtuella nätets adressutrymme och de lokala intervallen. De får inte överlappa, och poolen behöver plats för varje samtidig klient plus marginal för återanslutningar.

Stäng sedan loopen i den här ordningen:

• Anslut från två maskiner i båda ordningarna och jämför adresserna; om de kan byta plats är ingen adressbaserad regel säker.
• Kontrollera om gatewayen är Virtual WAN; om den är det, använd gruppoolar i stället för regler per adress.
• Fråga vad som händer när en regel träffar fel person; om svaret är en åtkomstincident, flytta kontrollen till identitet.
• Anteckna vilket intervall som hör till vilken grupp, i samma repo som NSG-definitionerna.
• Testa om efter varje ändring av pool, autentisering eller gateway, eftersom dessa ändringar skriver om mappningen utan att meddela det.