Statisk IP i Azure P2S VPN: kvifor klientadressa endrar seg

Kvar Azure point-to-site-klient får ei adresse frå utvalet når han autentiserer seg, og held på henne berre så lenge den tilkoplinga varer. Det finst ingen reservasjonstabell, inga tilordning per brukar og ingen gateway-innstilling som tyder «gje alltid denne personen 172.16.0.10». Nettopp denne eine mekanismen forklarer båe symptoma folk støyter på seinare: ein NSG-regel som sluttar å passe på ein brukar han tidlegare passa på, og ei tillatingsliste som stille slepp inn ein maskin ingen medvite har lagt til. Å bytte ut regelen med ein smartare IP-regel reparerer ingen av dei, fordi det regelen namngir blir tildelt på nytt etter ein tidsplan du ikkje kontrollerer.

Utvalet er kapasitet, ikkje identitet. Det finst for at samtidige tunnelar skal få unike adresser, og det brukar dei om att i det augneblinken ein leige går ut. Når det er klart, sluttar det nyttige spørsmålet å vere «korleis festar eg denne klienten» og blir «kva kan eg skrive ein regel mot som gatewayen ikkje brukar om att».

Kva gatewayen faktisk gjer når ein klient koplar til

Gatewayen held på det konfigurerte klientadresseutvalet og behandlar det som ein leigetabell. Ved tilkopling tek han neste ledige adresse, i praksis den lågaste tilgjengelege, og tildeler henne til tunneladapteren til klienten koplar frå eller leiga går ut. Rekkjefølgja avgjer, ikkje identiteten: den som koplar til først igjen etter ein roleg periode, får den lågaste adressa som tilfeldigvis er ledig i det augneblinken.

Storleiken på utvalet skjuler åtferda. Eit laboratorieutval som er éi eller to adresser større enn talet på testarar, verkar deterministisk, fordi den same berbare maskina har ein tendens til å kopla til igjen i same rekkjefølgje kvar morgon. Legg til ein tredje maskin, endre storleiken på utvalet, eller lat ei økt vere tilkopla over lunsjen, og mønsteret bryt saman. Adressa var aldri stabil; køen var det.

Kvar endring i point-to-site-konfigurasjonen nullstiller også leigeplassen. Ein annan autentiseringstype, eit utval med endra storleik, eit nytt utvalsområde eller ein gateway som blir riven og bygd opp att sender alle klientar tilbake i eit utval som ikkje lenger svarar til dei gamle adressene deira. Ingenting i den endringa rører NSG-en din, og difor ser brotet spontant ut.

Du kan sjå det skje på omtrent eitt minutt. Kopla til, noter tunneladressa i tilkoplingsdetaljane til klienten, kopla frå, kopla til ein annan maskin, og kopla så den første til igjen. Adressa du får tilbake, avheng av kva den andre maskina held på, og ingen portalininstilling gjenopprettar den førre på førespurnad.

Ein NSG som er knytt til IP-en til klienten, er eigentleg ein regel om tilkoplingsrekkjefølgja

Regelen folk skriv først, er den openberre: ein innkomande regel på NIC-en til administrasjons-VM-en eller på subnettet hans, med den interne adressa til VPN-klienten som kjelde. Han er kort, han står testen den dagen han blir skriven, og han feilar så snart utvalet har meir enn éi ledig adresse.

Det følgjer to feilmodusar, og berre éin av dei ser ut som ein feil. Ein legitim brukar blir avvist fordi nokon andre akkurat no held adressa regelen namngir, og det kjem inn som ei irriterande støttesak. Eller ein utilsikta brukar blir sleppt inn fordi han arva ei adresse regelen framleis stolar på, og det kjem ikkje inn som noko som helst før nokon reviderer tilgangen.

Fordi regelen følgjer leiga, lyder den effektive policyen «den første som koplar til får administrasjonstilgang». Det er ei skildring av tilkoplingsrekkjefølgja kledd ut som hensikt, og ingen regelhygiene gjer henne til ei hensiktsfråsegn.

Klientleiga og gatewayadressa er ulike objekt

Det meste av forvirringa kjem frå eitt ord. Gatewayen har ein offentleg IP som er nokolunde stabil; klientane har private adresser frå utvalet som ikkje er det. For ein VPN-gateway utan soneredundans blir den offentlege IP-en tildelt dynamisk, men han overlever ei storleiksendring, ein reset og rutinemessig vedlikehald — han endrar seg når gatewayen sjølv blir sletta og oppretta på nytt. Soneredundante og sonale gateway-SKU-ar brukar ein offentleg IP av Standard-SKU, og den tildelinga må vere statisk.

Den stabiliteten er det ein lokal peer treng i konfigurasjonen sin, og han seier ingenting om å identifisere ein einskil klient. Når ein partnar spør kva adresse han vil sjå, er svaret den offentlege IP-en til gatewayen under site-to-site, eller eit delt NAT-område — aldri tunnel-leiga til ein berbar maskin.

Gruppeutval gjev deg eit område det er verdt å skrive reglar mot

Virtual WAN point-to-site støttar brukargrupper, og kvar gruppe kan tildelast sitt eige klientadresseutval. Medlemskap blir avgjort av identitet, så området ein klient landar i blir føreseieleg: drift i eitt område, leverandørar i eit anna, og området er noko ein brannmur- eller NSG-regel kan namngi utan å gisse.

Regelsettet som blir resultatet har ein form du kan gå gjennom:

• eitt utval per målgruppe, dimensjonert for toppunkt samtidige økter i staden for talet på personar;
• gruppemedlemskap handtert gjennom identitet, ikkje ved å redigere reglar kvar gong nokon blir med;
• NSG- eller Azure Firewall-reglar skrivne mot utvalsområde, aldri mot enkeltleiger;
• eit eige nav eller ein eigen gateway for målgrupper som aldri skal dele eit område.

Å setje eit heilt utval på tillatingslista er ærleg, men grovt: kvar tilkopla klient i det området får same tilgang. Det er ei policyavgjerd som det er verdt å seie høgt i staden for å oppdage under ein gjennomgang. Alt som framleis treng eit svar per person, høyrer til på ressursen gjennom rolletildelingar, ikkje på pakkefilteret.

Når utrullinga ikkje kan flytte til Virtual WAN

Mange gatewayar blir verande som vanlege VPN-gatewayar, og å flytte til Virtual WAN er ikkje ei tilfeldig endring. Det praktiske svaret er å flytte avgjerda per brukar frå pakkefilteret til noko som allereie veit kven brukaren er.

Identitet på ressursnivå er den billegaste versjonen. Storage, SQL og Key Vault støttar alle Entra ID-autentisering med rolletildelingar per brukar eller per gruppe, så VPN-en treng berre å prove nettverkstilgang. Ein hoppemaskin med namngjevne kontoar gjer same nytten for administrativt arbeid, fordi verten registrerer mennesket og tunnelen berre fraktar pakkar. Å registrere klientar i DNS og tillate namnet i staden for nummeret flyttar regelen eitt lag opp. Identitet på applikasjonslaget — eit sertifikatsubjekt, eit tokenkrav, eit gruppemedlemskap — fungerer når det er applikasjonen, ikkje nettet, som blir beden om å avgjere.

For ein partnar som insisterer på ei fast kjeldeadresse, er svaret site-to-site eller ExpressRoute med eit definert peer-prefiks. Dei tillèt peer-prefikset, adressa som viser seg på deira side høyrer til gatewayen, og ho endrar seg ikkje når nokon startar ein berbar maskin på nytt.

Sjekk utvalet før du redigerer ei ny tillatingsliste

To eigenskapar ved utvalet fører til det meste av åtferda folk gjev klienten skulda for. Eit for lite utval brukar leiger om att raskt, så adresser ser ut til å flytte seg heile tida, og ein kvar adressebasert regel verkar upåliteleg av design. Eit utval som overlappar dei lokale områda eller adresseområdet til det virtuelle nettet, skaper rutingsuklarheit som ingen brannmurregel reparerer.

Set tre ting på éi side før du rører ein regel: point-to-site-utvalet, adresseområdet til det virtuelle nettet og dei lokale områda. Dei må ikkje overlappe, og utvalet treng plass til kvar samtidige klient pluss ein margin for tilkoplingar på nytt.

Lukk så sløyfa i denne rekkjefølgja:

• Kopla til frå to maskiner i båe rekkjefølgjer og samanlikn adressene; om dei kan byte, er ingen adressebasert regel trygg.
• Sjekk om gatewayen er Virtual WAN; om han er det, bruk gruppeutval i staden for reglar per adresse.
• Spør kva som skjer når ein regel treffer feil person; om svaret er ein tilgangshending, flytt kontrollen til identitet.
• Noter kva område som høyrer til kva gruppe, i same depot som NSG-definisjonane.
• Test på nytt etter kvar endring av utval, autentisering eller gateway, fordi desse endringane skriv om tilordninga utan å varsle om det.