Staatiline IP Azure P2S VPN-is: miks kliendi aadress muutub

Iga Azure point-to-site klient saab autentimisel basseinist aadressi ja hoiab seda ainult selle ühenduse eluea jooksul. Reservatsioonitabelit ei ole, kasutajapõhist vastendust ei ole ja lüüsiseadet, mis tähendaks „anna sellele inimesele alati 172.16.0.10“, ei ole. Just see üks mehhanism selgitab mõlemat sümptomit, millega inimesed hiljem kokku puutuvad: NSG reegel, mis lakkab sobimast kasutajaga, kellega see varem sobis, ja lubatud loend, mis laseb vaikselt sisse masina, mida keegi tahtlikult ei lisanud. Reegli asendamine nutikama IP-reegliga ei paranda kumbagi, sest see, mida reegel nimetab, antakse uuesti välja ajakava järgi, mida te ei kontrolli.

Bassein on mahutavus, mitte identiteet. See on olemas selleks, et samaaegsed tunnelid saaksid unikaalsed aadressid, ja see ringleb need uuesti kasutusse hetkel, kui rent lõpeb. Kui see on selge, lakkab kasulik küsimus olemast „kuidas ma selle kliendi kinni naelutan“ ja muutub „mille vastu saan kirjutada reegli, mida lüüs uuesti kasutusse ei ringle“.

Mida lüüs tegelikult teeb, kui klient ühendub

Lüüs hoiab seadistatud kliendi aadressibasseini ja kohtleb seda renditabelina. Ühendumisel võtab see järgmise vaba aadressi, praktikas madalaima saadaoleva, ja määrab selle tunneladapterile, kuni klient katkestab või rent aegub. Otsustab järjekord, mitte identiteet: kes pärast vaikset perioodi esimesena uuesti ühendub, saab madalaima aadressi, mis sel hetkel juhuslikult vaba on.

Basseini suurus peidab käitumise. Labori bassein ühe või kahe aadressi võrra suurem kui testijate arv näib deterministlik, sest sama sülearvuti kipub igal hommikul samas järjekorras uuesti ühenduma. Lisage kolmas masin, muutke basseini suurust või jätke sessioon lõuna ajal ühendatuks ja muster laguneb. Aadress ei olnud kunagi stabiilne; järjekord oli.

Iga point-to-site konfiguratsiooni muudatus lähtestab ka rendiruumi. Teistsugune autentimistüüp, muudetud suurusega bassein, uus basseini vahemik või lüüs, mis lammutatakse ja uuesti üles ehitatakse, saadavad kliendid tagasi basseini, mis ei vasta enam nende vanadele aadressidele. Miski selles muudatuses ei puuduta teie NSG-d, seepärast näib rike spontaanne.

Seda saab jälgida umbes minutiga. Ühenduge, kirjutage kliendi ühenduse üksikasjadest üles tunneli aadress, katkestage, ühendage teine masin ja ühendage siis uuesti esimene. Tagasi saadav aadress sõltub sellest, mida teine masin hoiab, ja ükski portaali seade ei taasta eelmist nõudmise peale.

Kliendi IP-le suunatud NSG on tegelikult reegel ühendumise järjekorra kohta

Reegel, mille inimesed esimesena kirjutavad, on ilmne: sissetulev reegel haldus-VM-i NIC-il või selle alamvõrgus, allikana VPN-kliendi sisemine aadress. See on lühike, läbib testi kirjutamise päeval ja ebaõnnestub niipea, kui basseinis on rohkem kui üks vaba aadress.

Sellest tuleneb kaks rikkerežiimi ja ainult üks neist näeb välja nagu viga. Õiguspärasel kasutajal keeldutakse, sest keegi teine hoiab praegu aadressi, mida reegel nimetab, mis saabub tüütu tugipiletina. Või lubatakse soovimatu kasutaja, sest ta päris aadressi, mida reegel ikka veel usaldab, ja see ei saabu üldse enne, kui keegi juurdepääsu auditeerib.

Kuna reegel järgib renti, kõlab tegelik poliitika „esimene ühenduja saab haldusjuurdepääsu“. See on ühendumise järjekorra kirjeldus kavatsuseks maskeeritult ja ükski reeglihügieen ei tee sellest kavatsuse väljendust.

Kliendi rent ja lüüsi aadress on erinevad objektid

Suurem osa segadusest tuleb ühest sõnast. Lüüsil on avalik IP, mis on suhteliselt stabiilne; klientidel on basseinist privaatsed aadressid, mis ei ole. Tsooniredundantsuseta VPN-lüüsi puhul eraldatakse avalik IP dünaamiliselt, kuid see elab üle suuruse muutmise, lähtestamise ja rutiinse hoolduse — see muutub siis, kui lüüs ise kustutatakse ja uuesti luuakse. Tsooniredundantsed ja tsonaalsed lüüsi SKU-d kasutavad Standard SKU avalikku IP-d ja see eraldamine peab olema staatiline.

Just seda stabiilsust vajab kohapealne partner oma konfiguratsioonis ja see ei ütle midagi üksiku kliendi tuvastamise kohta. Kui partner küsib, millist aadressi ta näeb, on vastus lüüsi avalik IP site-to-site'i korral või jagatud NAT-vahemik — mitte kunagi sülearvuti tunnelirent.

Gruppibasseinid annavad vahemiku, mille vastu tasub reegleid kirjutada

Virtual WAN point-to-site toetab kasutajagruppe ja igale grupile saab määrata oma kliendi aadressibasseini. Liikmelisuse otsustab identiteet, seega muutub vahemik, kuhu klient satub, prognoositavaks: operatsioonid ühes vahemikus, töövõtjad teises, ja vahemik on midagi, mida tulemüüri- või NSG-reegel saab nimetada ilma oletamata.

Tulemuseks olev reeglistik on kujuga, mida saab üle vaadata:

• üks bassein publikule, mõõdetud tipphetke samaaegsete sessioonide, mitte inimeste arvu järgi;
• grupiliikmelisust hallatakse identiteedi kaudu, mitte reeglite muutmisega iga liitumise järel;
• NSG või Azure Firewall reeglid on kirjutatud basseini vahemike vastu, mitte kunagi üksikute rentide vastu;
• eraldi jaotur või lüüs publikule, mis ei tohi kunagi vahemikku jagada.

Terve basseini lubatud loendisse panemine on aus, aga jäme: iga ühendatud klient selles vahemikus saab sama juurdepääsu. See on poliitikaotsus, mida tasub valjusti öelda, mitte ülevaatuse käigus avastada. Kõik, mis vajab veel vastust inimese kohta, kuulub ressursi juurde rollimäärangute kaudu, mitte paketifiltrisse.

Kui juurutus ei saa Virtual WAN-ile üle minna

Paljud lüüsid jäävad tavalisteks VPN-lüüsideks ja Virtual WAN-ile üleminek ei ole juhuslik muudatus. Praktiline vastus on viia kasutajapõhine otsus paketifiltrilt millelegi, mis juba teab, kes kasutaja on.

Identiteet ressursi tasandil on odavaim versioon. Storage, SQL ja Key Vault toetavad kõik Entra ID autentimist kasutaja- või grupipõhiste rollimäärangutega, seega peab VPN tõestama ainult võrgu kättesaadavust. Nimega kontodega hüppemajut teeb sama tööd haldustöö jaoks, sest majutaja registreerib inimese ja tunnel kannab lihtsalt pakette. Klientide DNS-i registreerimine ja nime, mitte numbri lubamine viib reegli ühe kihi võrra üles. Rakenduskihi identiteet — sertifikaadi subjekt, loa väide, grupiliikmelisus — töötab siis, kui otsustama kutsutakse rakendust, mitte võrku.

Partnerile, kes nõuab kindlat lähteaadressi, on vastus site-to-site või ExpressRoute määratletud partneri eesliidesega. Nad lubavad partneri eesliite, nende poolel ilmuv aadress kuulub lüüsile ja see ei muutu, kui keegi sülearvuti taaskäivitab.

Kontrollige basseini enne, kui muudate järgmist lubatud loendit

Kaks basseini omadust põhjustavad suurema osa käitumisest, mille eest inimesed klienti süüdistavad. Liiga väike bassein ringleb rendid kiiresti uuesti kasutusse, seega tunduvad aadressid pidevalt liikuvat ja iga aadressipõhine reegel näib disaini järgi ebausaldusväärne. Bassein, mis kattub kohapealsete vahemike või virtuaalvõrgu aadressiruumiga, tekitab marsruutimise ebaselgust, mida ükski tulemüürireegel ei paranda.

Pange enne reegli puudutamist kolm asja ühele lehele: point-to-site bassein, virtuaalvõrgu aadressiruum ja kohapealsed vahemikud. Need ei tohi kattuda ja bassein vajab ruumi iga samaaegse kliendi jaoks pluss varu taasühenduste jaoks.

Seejärel sulgege tsükkel selles järjekorras:

• Ühenduge kahest masinast mõlemas järjekorras ja võrrelge aadresse; kui need saavad vahetuda, ei ole ükski aadressipõhine reegel turvaline.
• Kontrollige, kas lüüs on Virtual WAN; kui on, kasutage aadressipõhiste reeglite asemel gruppibasseine.
• Küsige, mis juhtub, kui reegel tabab valet inimest; kui vastus on juurdepääsuintsident, viige kontroll identiteedi juurde.
• Kirjutage üles, milline vahemik kuulub millisesse gruppi, samasse hoidlasse kui NSG definitsioonid.
• Testige uuesti pärast iga basseini, autentimise või lüüsi muudatust, sest need muudatused kirjutavad vastenduse üle seda teavitamata.