Statisch IP in Azure P2S VPN: waarom het clientadres verandert

Elke Azure point-to-site-client krijgt bij authenticatie een adres uit de pool en houdt dat alleen zolang die verbinding duurt. Er is geen reserveringstabel, geen toewijzing per gebruiker en geen gateway-instelling die betekent „geef deze persoon altijd 172.16.0.10“. Juist dat ene mechanisme verklaart beide symptomen die mensen later tegenkomen: een NSG-regel die niet meer past bij een gebruiker bij wie hij eerst paste, en een toegangslijst die stilletjes een machine doorlaat die niemand bewust heeft toegevoegd. De regel vervangen door een slimmere IP-regel lost geen van beide op, omdat wat de regel noemt opnieuw wordt toegewezen volgens een schema dat u niet beheert.

De pool is capaciteit, geen identiteit. Hij bestaat zodat gelijktijdige tunnels unieke adressen krijgen, en hij hergebruikt ze op het moment dat een lease afloopt. Als dat duidelijk is, houdt de nuttige vraag op „hoe speld ik deze client vast“ te zijn en wordt het „waartegen kan ik een regel schrijven die de gateway niet hergebruikt“.

Wat de gateway werkelijk doet wanneer een client verbinding maakt

De gateway houdt de geconfigureerde clientadrespool bij en behandelt die als een leasetabel. Bij verbinding neemt hij het volgende vrije adres, in de praktijk het laagste beschikbare, en wijst dat toe aan de tunneladapter tot de client loskoppelt of de lease verloopt. De volgorde beslist, niet de identiteit: wie na een rustige periode het eerst opnieuw verbinding maakt, krijgt het laagste adres dat op dat moment toevallig vrij is.

De grootte van de pool verbergt het gedrag. Een laboratoriumpool die een of twee adressen groter is dan het aantal testers lijkt deterministisch, omdat dezelfde laptop elke ochtend in dezelfde volgorde opnieuw verbinding maakt. Voeg een derde machine toe, wijzig de grootte van de pool of laat een sessie over de lunch verbonden, en het patroon breekt. Het adres was nooit stabiel; de wachtrij was dat.

Elke wijziging aan de point-to-site-configuratie reset ook de leaseruimte. Een ander authenticatietype, een pool met andere grootte, een nieuw poolbereik of een gateway die wordt afgebroken en opnieuw opgebouwd sturen alle clients terug naar een pool die niet meer bij hun oude adressen past. Niets aan die wijziging raakt uw NSG, daarom lijkt de breuk spontaan.

U kunt het in ongeveer een minuut zien gebeuren. Maak verbinding, noteer het tunneladres in de verbindingsgegevens van de client, verbreek de verbinding, verbind een tweede machine en verbind daarna de eerste weer. Het adres dat u terugkrijgt hangt af van wat de tweede machine vasthoudt, en geen enkele portalinstelling herstelt het vorige op verzoek.

Een NSG op basis van het client-IP is in werkelijkheid een regel over de verbindingsvolgorde

De regel die mensen het eerst schrijven is de voor de hand liggende: een inkomende regel op de NIC van de beheer-VM of op het subnet daarvan, met het interne adres van de VPN-client als bron. Hij is kort, hij slaagt voor de test op de dag dat hij wordt geschreven, en hij faalt zodra de pool meer dan één vrij adres heeft.

Daaruit volgen twee faalwijzen, en slechts één ervan lijkt een bug. Een legitieme gebruiker wordt geweigerd omdat iemand anders op dat moment het adres vasthoudt dat de regel noemt, en dat komt binnen als een vervelend supportticket. Of een onbedoelde gebruiker wordt toegelaten omdat hij een adres heeft geërfd dat de regel nog steeds vertrouwt, en dat komt helemaal niet binnen tot iemand de toegang controleert.

Omdat de regel de lease volgt, luidt het effectieve beleid „de eerste persoon die verbinding maakt krijgt beheerstoegang“. Dat is een beschrijving van de verbindingsvolgorde in de kleren van een bedoeling, en geen enkele regelhygiëne maakt er een uitdrukking van bedoeling van.

De clientlease en het gatewayadres zijn verschillende objecten

Het meeste misverstand komt van één woord. De gateway heeft een openbaar IP dat betrekkelijk stabiel is; clients hebben privéadressen uit de pool die dat niet zijn. Voor een VPN-gateway zonder zoneredundantie wordt het openbare IP dynamisch toegewezen, maar het overleeft een formaatwijziging, een reset en routineonderhoud — het verandert wanneer de gateway zelf wordt verwijderd en opnieuw aangemaakt. Zone-redundante en zonale gateway-SKU's gebruiken een openbaar IP van Standard-SKU, en die toewijzing moet statisch zijn.

Die stabiliteit is wat een on-premises peer in zijn configuratie nodig heeft, en zij zegt niets over het identificeren van een individuele client. Wanneer een partner vraagt welk adres hij zal zien, is het antwoord het openbare IP van de gateway bij site-to-site, of een gedeeld NAT-bereik — nooit de tunnellease van een laptop.

Groepspools geven u een bereik waartegen het de moeite loont regels te schrijven

Virtual WAN point-to-site ondersteunt gebruikersgroepen, en elke groep kan een eigen clientadrespool krijgen. Lidmaatschap wordt door identiteit bepaald, dus het bereik waarin een client terechtkomt wordt voorspelbaar: bedrijfsvoering in het ene bereik, aannemers in het andere, en het bereik is iets dat een firewall- of NSG-regel kan noemen zonder te gissen.

De resulterende regelset heeft een vorm die u kunt beoordelen:

• één pool per doelgroep, gedimensioneerd op pieken in gelijktijdige sessies en niet op het aantal mensen;
• groepslidmaatschap geregeld via identiteit, niet door regels te bewerken telkens wanneer iemand toetreedt;
• NSG- of Azure Firewall-regels geschreven tegen poolbereiken, nooit tegen afzonderlijke leases;
• een aparte hub of gateway voor doelgroepen die nooit een bereik mogen delen.

Een hele pool op de toegangslijst zetten is eerlijk maar grof: elke verbonden client in dat bereik krijgt dezelfde toegang. Dat is een beleidsbeslissing die het verdient hardop te worden gezegd in plaats van tijdens een review te worden ontdekt. Alles wat nog een antwoord per persoon nodig heeft, hoort bij de resource, via roltoewijzingen, niet bij het pakketfilter.

Wanneer de uitrol niet naar Virtual WAN kan

Veel gateways blijven gewone VPN-gateways, en overstappen naar Virtual WAN is geen terloopse wijziging. Het praktische antwoord is de beslissing per gebruiker van het pakketfilter te verplaatsen naar iets dat al weet wie de gebruiker is.

Identiteit op resourceniveau is de goedkoopste versie. Storage, SQL en Key Vault ondersteunen allemaal Entra ID-authenticatie met roltoewijzingen per gebruiker of per groep, dus de VPN hoeft alleen netwerkbereikbaarheid aan te tonen. Een spronghost met benoemde accounts doet hetzelfde werk voor beheertaken, omdat de host de mens vastlegt en de tunnel alleen pakketten draagt. Clients in DNS registreren en de naam in plaats van het nummer toestaan tilt de regel een laag hoger. Identiteit op applicatieniveau — een certificaatonderwerp, een tokenclaim, een groepslidmaatschap — werkt wanneer niet het netwerk, maar de applicatie wordt gevraagd te beslissen.

Voor een partner die op een vast bronadres staat, is het antwoord site-to-site of ExpressRoute met een gedefinieerd peer-prefix. Zij staan het peer-prefix toe, het adres dat aan hun kant verschijnt hoort bij de gateway, en het verandert niet wanneer iemand een laptop herstart.

Controleer de pool voordat u nog een toegangslijst bewerkt

Twee eigenschappen van de pool veroorzaken het grootste deel van het gedrag dat mensen de client verwijten. Een te kleine pool hergebruikt leases snel, waardoor adressen constant lijken te verschuiven en elke op adres gebaseerde regel van nature onbetrouwbaar lijkt. Een pool die de on-premises bereiken of de adresruimte van het virtuele netwerk overlapt, veroorzaakt routeringsdubbelzinnigheid die geen firewallregel repareert.

Zet drie dingen op één pagina voordat u een regel aanraakt: de point-to-site-pool, de adresruimte van het virtuele netwerk en de on-premises bereiken. Ze mogen niet overlappen, en de pool heeft ruimte nodig voor elke gelijktijdige client plus een marge voor herverbindingen.

Sluit daarna de lus in deze volgorde:

• Maak verbinding vanaf twee machines in beide volgordes en vergelijk de adressen; als ze kunnen wisselen, is geen enkele op adres gebaseerde regel veilig.
• Controleer of de gateway Virtual WAN is; zo ja, gebruik groepspools in plaats van regels per adres.
• Vraag wat er gebeurt wanneer een regel de verkeerde persoon raakt; als het antwoord een toegangsincident is, verplaats de controle naar identiteit.
• Leg vast welk bereik bij welke groep hoort, in dezelfde repository als de NSG-definities.
• Test opnieuw na elke wijziging van pool, authenticatie of gateway, omdat die wijzigingen de toewijzing herschrijven zonder dat aan te kondigen.