Statisk IP i Azure P2S VPN: hvorfor klientadressen endres

Hver Azure point-to-site-klient får en adresse fra utvalget når den autentiserer seg, og beholder den bare så lenge den tilkoblingen varer. Det finnes ingen reservasjonstabell, ingen tilordning per bruker og ingen gateway-innstilling som betyr «gi alltid denne personen 172.16.0.10». Nettopp denne ene mekanismen forklarer begge symptomene folk støter på senere: en NSG-regel som slutter å passe på en bruker den tidligere passet på, og en tillatelsesliste som stille slipper inn en maskin ingen bevisst har lagt til. Å erstatte regelen med en smartere IP-regel reparerer ingen av dem, fordi det regelen navngir blir tildelt på nytt etter en tidsplan du ikke kontrollerer.

Utvalget er kapasitet, ikke identitet. Det finnes for at samtidige tunneler skal få unike adresser, og det gjenbruker dem i det øyeblikket en leie utløper. Når det er klart, slutter det nyttige spørsmålet å være «hvordan fester jeg denne klienten» og blir «hva kan jeg skrive en regel mot som gatewayen ikke gjenbruker».

Hva gatewayen faktisk gjør når en klient kobler til

Gatewayen holder det konfigurerte klientadresseutvalget og behandler det som en leietabell. Ved tilkobling tar den neste ledige adresse, i praksis den laveste tilgjengelige, og tildeler den til tunneladapteren til klienten kobler fra eller leien utløper. Rekkefølgen avgjør, ikke identiteten: den som kobler til først igjen etter en rolig periode, får den laveste adressen som tilfeldigvis er ledig i det øyeblikket.

Størrelsen på utvalget skjuler atferden. Et laboratorieutvalg som er én eller to adresser større enn antall testere, virker deterministisk, fordi den samme bærbare maskinen har en tendens til å koble til igjen i samme rekkefølge hver morgen. Legg til en tredje maskin, endre størrelsen på utvalget, eller la en økt være tilkoblet over lunsjen, og mønsteret bryter sammen. Adressen var aldri stabil; køen var det.

Enhver endring i point-to-site-konfigurasjonen nullstiller også leieplassen. En annen autentiseringstype, et utvalg med endret størrelse, et nytt utvalgsområde eller en gateway som rives og bygges opp igjen sender alle klienter tilbake i et utvalg som ikke lenger svarer til deres gamle adresser. Ingenting i den endringen berører NSG-en din, og derfor ser bruddet spontant ut.

Du kan se det skje på omtrent et minutt. Koble til, noter tunneladressen i klientens tilkoblingsdetaljer, koble fra, koble til en annen maskin, og koble så den første til igjen. Adressen du får tilbake, avhenger av hva den andre maskinen holder, og ingen portalin innstilling gjenoppretter den forrige på forespørsel.

En NSG som er knyttet til klientens IP, er egentlig en regel om tilkoblingsrekkefølge

Regelen folk skriver først, er den åpenbare: en innkommende regel på NIC-en til administrasjons-VM-en eller på subnettet dens, med VPN-klientens interne adresse som kilde. Den er kort, den består testen den dagen den skrives, og den feiler så snart utvalget har mer enn én ledig adresse.

Det følger to feilmoduser, og bare én av dem ser ut som en feil. En legitim bruker blir avvist fordi noen andre akkurat nå holder adressen regelen navngir, og det kommer inn som en irriterende støttesak. Eller en utilsiktet bruker blir sluppet inn fordi vedkommende arvet en adresse regelen fortsatt stoler på, og det kommer ikke inn som noe som helst før noen reviderer tilgangen.

Fordi regelen følger leien, lyder den effektive policyen «den første som kobler til får administrasjonstilgang». Det er en beskrivelse av tilkoblingsrekkefølge kledd ut som hensikt, og ingen regelhygiene gjør den til en hensiktserklæring.

Klientleien og gatewayadressen er forskjellige objekter

Det meste av forvirringen kommer fra ett ord. Gatewayen har en offentlig IP som er forholdsvis stabil; klientene har private adresser fra utvalget som ikke er det. For en VPN-gateway uten soneredundans tildeles den offentlige IP-en dynamisk, men den overlever en størrelsesendring, en tilbakestilling og rutinemessig vedlikehold — den endres når gatewayen selv slettes og opprettes på nytt. Soneredundante og sonale gateway-SKU-er bruker en offentlig IP av Standard-SKU, og den tildelingen må være statisk.

Den stabiliteten er det en lokal peer trenger i konfigurasjonen sin, og den sier ingenting om å identifisere en enkelt klient. Når en partner spør hvilken adresse de vil se, er svaret gatewayens offentlige IP under site-to-site, eller et delt NAT-område — aldri tunnel-leien til en bærbar maskin.

Gruppeutvalg gir deg et område det er verdt å skrive regler mot

Virtual WAN point-to-site støtter brukergrupper, og hver gruppe kan tildeles sitt eget klientadresseutvalg. Medlemskap avgjøres av identitet, så området en klient lander i blir forutsigbart: drift i ett område, leverandører i et annet, og området er noe en brannmur- eller NSG-regel kan navngi uten å gjette.

Regelsettet som blir resultatet har en form du kan gjennomgå:

• ett utvalg per målgruppe, dimensjonert for toppunkt samtidige økter i stedet for antall personer;
• gruppemedlemskap håndteres gjennom identitet, ikke ved å redigere regler hver gang noen blir med;
• NSG- eller Azure Firewall-regler skrevet mot utvalgsområder, aldri mot enkeltleier;
• et eget nav eller en egen gateway for målgrupper som aldri skal dele et område.

Å sette et helt utvalg på tillatelseslisten er ærlig, men grovt: hver tilkoblet klient i det området får samme tilgang. Det er en policybeslutning som det er verdt å si høyt i stedet for å oppdage under en gjennomgang. Alt som fortsatt trenger et svar per person, hører til på ressursen gjennom rolletildelinger, ikke på pakkefilteret.

Når utrullingen ikke kan flytte til Virtual WAN

Mange gatewayer blir værende som vanlige VPN-gatewayer, og å flytte til Virtual WAN er ikke en tilfeldig endring. Det praktiske svaret er å flytte beslutningen per bruker fra pakkefilteret til noe som allerede vet hvem brukeren er.

Identitet på ressursnivå er den billigste versjonen. Storage, SQL og Key Vault støtter alle Entra ID-autentisering med rolletildelinger per bruker eller per gruppe, så VPN-en trenger bare å bevise nettverkstilgang. En hoppemaskin med navngitte kontoer gjør samme nytten for administrativt arbeid, fordi verten registrerer mennesket og tunnelen bare frakter pakker. Å registrere klienter i DNS og tillate navnet i stedet for nummeret flytter regelen ett lag opp. Identitet på applikasjonslaget — et sertifikatsubjekt, et tokenkrav, et gruppemedlemskap — fungerer når det er applikasjonen, ikke nettet, som blir bedt om å avgjøre.

For en partner som insisterer på en fast kildeadresse, er svaret site-to-site eller ExpressRoute med et definert peer-prefiks. De tillater peer-prefikset, adressen som vises på deres side tilhører gatewayen, og den endres ikke når noen starter en bærbar maskin på nytt.

Sjekk utvalget før du redigerer en ny tillatelsesliste

To egenskaper ved utvalget forårsaker det meste av atferden folk gir klienten skylden for. Et for lite utvalg gjenbruker leier raskt, så adresser ser ut til å flytte seg hele tiden, og enhver adressebasert regel virker upålitelig av design. Et utvalg som overlapper de lokale områdene eller adresseområdet til det virtuelle nettet, skaper routinguklarhet som ingen brannmurregel reparerer.

Sett tre ting på én side før du rører en regel: point-to-site-utvalget, adresseområdet til det virtuelle nettet og de lokale områdene. De må ikke overlappe, og utvalget trenger plass til hver samtidige klient pluss en margin for tilkoblinger på nytt.

Lukk så sløyfen i denne rekkefølgen:

• Koble til fra to maskiner i begge rekkefølger og sammenlign adressene; hvis de kan bytte, er ingen adressebasert regel trygg.
• Sjekk om gatewayen er Virtual WAN; hvis den er det, bruk gruppeutvalg i stedet for regler per adresse.
• Spør hva som skjer når en regel treffer feil person; hvis svaret er en tilgangshendelse, flytt kontrollen til identitet.
• Noter hvilket område som tilhører hvilken gruppe, i samme depot som NSG-definisjonene.
• Test på nytt etter enhver endring av utvalg, autentisering eller gateway, fordi disse endringene skriver om tilordningen uten å varsle om det.