Statisk IP i Azure P2S VPN: hvorfor klientens adresse ændrer sig

Hver Azure point-to-site-klient får en adresse fra puljen, når den godkender sig, og beholder den kun så længe forbindelsen varer. Der er ingen reservationstabel, ingen mapping pr. bruger og ingen gateway-indstilling, der betyder »giv altid denne person 172.16.0.10«. Netop den mekanisme forklarer begge de symptomer, folk senere støder på: en NSG-regel, der holder op med at matche en bruger, den tidligere matchede, og en tilladelsesliste, der stille lukker en maskine ind, som ingen bevidst har tilføjet. At erstatte reglen med en smartere IP-regel løser ingen af delene, fordi det, reglen navngiver, tildeles efter en tidsplan, du ikke styrer.

Puljen er kapacitet, ikke identitet. Den findes, så samtidige tunneller får unikke adresser, og den genbruger dem i det øjeblik, en lease slutter. Når det er klart, holder det nyttige spørgsmål op med at være »hvordan låser jeg denne klient fast« og bliver »hvad kan jeg skrive en regel imod, som gatewayen ikke genbruger«.

Hvad gatewayen faktisk gør, når en klient opretter forbindelse

Gatewayen holder den konfigurerede klientadressepulje og behandler den som en leasetabel. Ved forbindelse tager den den næste ledige adresse, i praksis den laveste tilgængelige, og tildeler den til tunneladapteren, indtil klienten afbryder, eller leasen udløber. Rækkefølgen afgør, ikke identiteten: den, der først genopretter forbindelse efter en rolig periode, får den laveste adresse, der tilfældigvis er ledig i det øjeblik.

Puljens størrelse skjuler adfærden. En laboratoriepulje, der er en eller to adresser større end antallet af testere, virker deterministisk, fordi den samme bærbare typisk genopretter forbindelse i samme rækkefølge hver morgen. Tilføj en tredje maskine, ændr puljens størrelse, eller lad en session være forbundet hen over frokosten, og mønstret bryder sammen. Adressen var aldrig stabil; køen var.

Enhver ændring af point-to-site-konfigurationen nulstiller også lease-pladsen. En anden godkendelsestype, en ændret puljestørrelse, et nyt puljeinterval eller en gateway, der rives ned og genopbygges, sender alle klienter tilbage i en pulje, der ikke længere svarer til deres gamle adresser. Intet ved den ændring rører din NSG, og derfor ser bruddet spontant ud.

Du kan se det ske på cirka et minut. Opret forbindelse, noter tunneladressen i klientens forbindelsesoplysninger, afbryd, forbind en anden maskine, og forbind så den første igen. Den adresse, du får tilbage, afhænger af, hvad den anden maskine holder, og ingen portalindstilling gendanner den tidligere på kommando.

En NSG baseret på klientens IP er i virkeligheden en regel om forbindelsesrækkefølge

Den regel, folk skriver først, er den oplagte: en indgående regel på administrations-VM'ens NIC eller på dens undernet med VPN-klientens interne adresse som kilde. Den er kort, den består testen den dag, den skrives, og den fejler, så snart puljen har mere end én ledig adresse.

Deraf følger to fejltilstande, og kun den ene ligner en fejl. En legitim bruger afvises, fordi en anden lige nu har den adresse, reglen navngiver, hvilket ankommer som en irriterende supporthenvendelse. Eller en utilsigtet bruger lukkes ind, fordi vedkommende har arvet en adresse, som reglen stadig stoler på, hvilket ikke ankommer som noget som helst, før nogen reviderer adgangen.

Fordi reglen følger leasen, lyder den effektive politik »den første, der forbinder, får administrationsadgang«. Det er en beskrivelse af forbindelsesrækkefølge klædt ud som hensigt, og ingen mængde regelhygiejne får den til at udtrykke hensigt.

Klientens lease og gatewayens adresse er forskellige objekter

Det meste af forvirringen kommer fra ét ord. Gatewayen har en offentlig IP, der er forholdsvis stabil; klienter har private adresser fra puljen, som ikke er. For en VPN-gateway uden zone-redundans tildeles den offentlige IP dynamisk, men den overlever en ændret størrelse, en nulstilling og rutinemæssig vedligeholdelse — den ændres, når selve gatewayen slettes og genskabes. Zone-redundante og zonale gateway-SKU'er bruger en offentlig IP af Standard-SKU, og den tildeling skal være statisk.

Den stabilitet er, hvad en lokal peer har brug for i sin konfiguration, og den siger intet om at identificere en enkelt klient. Når en partner spørger, hvilken adresse de vil se, er svaret gatewayens offentlige IP under site-to-site eller et delt NAT-interval — aldrig en bærbars tunnellease.

Gruppepuljer giver dig et interval, der er værd at skrive regler imod

Virtual WAN point-to-site understøtter brugergrupper, og hver gruppe kan tildeles sin egen klientadressepulje. Medlemskab afgøres af identitet, så det interval, en klient lander i, bliver forudsigeligt: drift i ét interval, konsulenter i et andet, og intervallet er noget, en firewall- eller NSG-regel kan navngive uden at gætte.

Det resulterende regelsæt har en form, du kan gennemgå:

• én pulje pr. målgruppe, dimensioneret efter spidssamtidige sessioner frem for antal personer;
• gruppemedlemskab håndteret via identitet, ikke ved at redigere regler, hver gang nogen kommer til;
• NSG- eller Azure Firewall-regler skrevet mod puljeintervaller, aldrig mod enkelte leases;
• en separat hub eller gateway til målgrupper, der aldrig må dele et interval.

At sætte en hel pulje på tilladelseslisten er ærligt, men groft: hver forbundet klient i det interval får samme adgang. Det er en politisk beslutning, der er værd at sige højt i stedet for at opdage under en gennemgang. Alt, der stadig kræver et svar pr. person, hører til på ressourcen via rolletildelinger, ikke på pakkefilteret.

Når udrulningen ikke kan flytte til Virtual WAN

Mange gateways forbliver almindelige VPN-gateways, og et skift til Virtual WAN er ikke en tilfældig ændring. Det praktiske svar er at flytte beslutningen pr. bruger fra pakkefilteret til noget, der allerede ved, hvem brugeren er.

Identitet på ressourceniveau er den billigste version. Storage, SQL og Key Vault understøtter alle Entra ID-godkendelse med rolletildelinger pr. bruger eller pr. gruppe, så VPN'en skal kun bevise netværksrækkevidde. En springserver med navngivne konti gør samme arbejde for administrativt arbejde, fordi værten registrerer mennesket, og tunnellen bare bærer pakker. Registrering af klienter i DNS og tilladelse af navnet i stedet for nummeret flytter reglen et lag op. Identitet på applikationslaget — et certifikatssubjekt, et tokenkrav, et gruppemedlemskab — virker, når det er applikationen, ikke netværket, der bliver bedt om at afgøre det.

For en partner, der insisterer på en fast kildeadresse, er svaret site-to-site eller ExpressRoute med et defineret peer-præfiks. De tillader peer-præfikset, den adresse, der vises på deres side, tilhører gatewayen, og den ændres ikke, når nogen genstarter en bærbar.

Kontroller puljen, før du redigerer endnu en tilladelsesliste

To puljeegenskaber forårsager det meste af den adfærd, folk giver klienten skylden for. En for lille pulje genbruger leases hurtigt, så adresser ser ud til at flytte sig konstant, og enhver adressebaseret regel virker upålidelig af design. En pulje, der overlapper de lokale intervaller eller det virtuelle netværks adresseområde, skaber routingtvivl, som ingen firewall-regel reparerer.

Sæt tre ting på én side, før du rører en regel: point-to-site-puljen, det virtuelle netværks adresseområde og de lokale intervaller. De må ikke overlappe, og puljen skal have plads til hver samtidig klient plus en margen til genforbindelser.

Luk så kredsen i denne rækkefølge:

• Forbind fra to maskiner i begge rækkefølger og sammenlign adresserne; hvis de kan bytte, er ingen adressebaseret regel sikker.
• Kontroller, om gatewayen er Virtual WAN; hvis den er, brug gruppepuljer i stedet for regler pr. adresse.
• Spørg, hvad der sker, når en regel rammer den forkerte person; hvis svaret er en adgangshændelse, flyt kontrollen til identitet.
• Noter, hvilket interval der hører til hvilken gruppe, i samme repository som NSG-definitionerne.
• Test igen efter enhver ændring af pulje, godkendelse eller gateway, fordi de ændringer omskriver mappingen uden at annoncere det.