Statični IP v Azure P2S VPN: zakaj se naslov odjemalca spreminja

Vsak odjemalec Azure point-to-site ob avtentikaciji dobi naslov iz bazena in ga obdrži le toliko časa, kolikor traja ta povezava. Ni tabele rezervacij, ni preslikave po uporabniku in ni nastavitve prehoda, ki bi pomenila „temu človeku vedno daj 172.16.0.10“. Prav ta edini mehanizem pojasnjuje oba simptoma, na katera ljudje naletijo pozneje: pravilo NSG, ki preneha ustrezati uporabniku, ki mu je prej ustrezalo, in seznam dovoljenih, ki tiho spusti napravo, ki je nihče ni namerno dodal. Zamenjava pravila s pametnejšim pravilom IP ne popravi nobenega od njiju, ker se to, kar pravilo imenuje, prerazporedi po urniku, ki ga ne nadzorujete.

Bazen je zmogljivost, ne identiteta. Obstaja zato, da hkratni tuneli dobijo edinstvene naslove, in jih reciklira v trenutku, ko se najem konča. Ko je to jasno, uporabno vprašanje preneha biti „kako naj tega odjemalca pripnem“ in postane „proti čemu lahko napišem pravilo, ki ga prehod ne bo recikliral“.

Kaj prehod dejansko naredi, ko se odjemalec poveže

Prehod hrani nastavljeni bazen naslovov odjemalcev in ga obravnava kot tabelo najemov. Ob povezavi vzame naslednji prosti naslov, v praksi najnižjega razpoložljivega, in ga dodeli vmesniku tunela, dokler se odjemalec ne odklopi ali dokler najem ne poteče. Odloča vrstni red, ne identiteta: kdor se po mirnem obdobju poveže prvi, dobi najnižji naslov, ki je v tistem trenutku slučajno prost.

Velikost bazena skriva vedenje. Laboratorijski bazen z enim ali dvema naslovoma več od števila preizkuševalcev je videti determinističen, ker se isti prenosnik vsako jutro poveže v istem vrstnem redu. Dodajte tretji stroj, spremenite velikost bazena ali pustite sejo povezano čez kosilo in vzorec se zlomi. Naslov ni bil nikoli stabilen; stabilna je bila vrsta.

Vsaka sprememba konfiguracije point-to-site ponastavi tudi prostor najemov. Druga vrsta avtentikacije, bazen z drugačno velikostjo, nov obseg bazena ali prehod, ki se poruši in znova zgradi, vse pošlje odjemalce nazaj v bazen, ki ne ustreza več njihovim starim naslovom. Nič pri tej spremembi se ne dotakne vašega NSG, zato je okvara videti samodejna.

To lahko vidite v približno eni minuti. Povežite se, zapišite naslov tunela v podrobnostih povezave odjemalca, prekinite povezavo, povežite drugi stroj in nato znova povežite prvega. Naslov, ki ga dobite nazaj, je odvisen od tega, kaj drži drugi stroj, in nobena nastavitev portala ne bo obnovila prejšnjega na zahtevo.

NSG, vezan na IP odjemalca, je v resnici pravilo o vrstnem redu povezovanja

Pravilo, ki ga ljudje napišejo prvo, je očitno: dohodno pravilo na NIC upravljalnega VM ali na njegovem podomrežju, z notranjim naslovom odjemalca VPN kot virom. Je kratko, na dan pisanja prestane preizkus in odpove takoj, ko ima bazen več kot en prost naslov.

Iz tega izhajata dva načina odpovedi in le eden je videti kot hrošč. Zakonit uporabnik je zavrnjen, ker naslov, ki ga pravilo imenuje, v tistem trenutku drži nekdo drug, in to pride kot nadležna zahteva za podporo. Ali pa je nezaželen uporabnik spuščen, ker je podedoval naslov, ki mu pravilo še zaupa, in to ne pride kot nič, dokler nekdo ne pregleda dostopa.

Ker pravilo sledi najemu, se dejanska politika glasi „prvi, ki se poveže, dobi upravljalni dostop“. To je opis vrstnega reda povezovanja, preoblečen v namero, in nobena higiena pravil iz njega ne naredi izraza namere.

Najem odjemalca in naslov prehoda sta različna objekta

Večina zmede izhaja iz ene besede. Prehod ima javni IP, ki je razmeroma stabilen; odjemalci imajo zasebne naslove iz bazena, ki to niso. Pri prehodu VPN brez conske redundance se javni IP dodeljuje dinamično, a preživi spremembo velikosti, ponastavitev in rutinsko vzdrževanje — spremeni se, ko se prehod sam izbriše in znova ustvari. Consko redundantne in conske SKU prehoda uporabljajo javni IP SKU Standard in ta dodelitev mora biti statična.

Prav ta stabilnost je tisto, kar lokalni partner potrebuje v svoji konfiguraciji, in ne pove ničesar o prepoznavanju posameznega odjemalca. Ko partner vpraša, kateri naslov bo videl, je odgovor javni IP prehoda pri site-to-site ali skupni obseg NAT — nikoli najem tunela prenosnika.

Skupinski bazeni vam dajo obseg, proti kateremu se splača pisati pravila

Virtual WAN point-to-site podpira uporabniške skupine in vsaki skupini je mogoče dodeliti svoj bazen naslovov odjemalcev. Članstvo se odloča po identiteti, zato obseg, v katerega pade odjemalec, postane predvidljiv: poslovanje v enem obsegu, pogodbeniki v drugem, obseg pa je nekaj, kar lahko pravilo požarnega zidu ali NSG imenuje brez ugibanja.

Nastali nabor pravil ima obliko, ki jo lahko pregledate:

• en bazen na občinstvo, dimenzioniran na vrh hkratnih sej, ne na število ljudi;
• članstvo v skupini se upravlja z identiteto, ne z urejanjem pravil ob vsaki pridružitvi;
• pravila NSG ali Azure Firewall so napisana proti obsegom bazena, nikoli proti posameznim najemom;
• ločeno zvezdišče ali prehod za občinstva, ki si ne smejo nikoli deliti obsega.

Uvrstiti celoten bazen na seznam dovoljenih je pošteno, a grobo: vsak povezan odjemalec v tem obsegu dobi enak dostop. To je politična odločitev, ki si zasluži, da jo poveste na glas, namesto da bi jo odkrili med pregledom. Vse, kar še vedno potrebuje odgovor na osebo, spada k viru prek dodelitev vlog, ne k filtru paketov.

Ko se uvedba ne more preseliti na Virtual WAN

Veliko prehodov ostane običajnih prehodov VPN, prehod na Virtual WAN pa ni majhna sprememba. Praktični odgovor je, da odločitev na uporabnika premaknete s filtra paketov na nekaj, kar že ve, kdo je uporabnik.

Identiteta na ravni vira je najcenejša različica. Storage, SQL in Key Vault vsi podpirajo avtentikacijo Entra ID z dodelitvami vlog na uporabnika ali skupino, zato mora VPN dokazati le omrežno dosegljivost. Skokovni gostitelj z imenovanimi računi opravi isto delo za upravljalna opravila, ker gostitelj zabeleži človeka, tunel pa le prenaša pakete. Registracija odjemalcev v DNS in dovoljenje imena namesto številke dvigne pravilo za eno plast. Identiteta na aplikacijski ravni — subjekt potrdila, trditev žetona, članstvo v skupini — deluje, ko mora odločiti aplikacija, ne omrežje.

Za partnerja, ki vztraja pri fiksnem izvornem naslovu, je odgovor site-to-site ali ExpressRoute z določeno predpono nasprotne strani. To predpono uvrstijo na seznam dovoljenih, naslov, ki se pojavi na njihovi strani, pripada prehodu in se ne spremeni, ko nekdo znova zažene prenosnik.

Preden uredite še en seznam dovoljenih, preverite bazen

Dve lastnosti bazena povzročita večino vedenja, ki ga ljudje pripišejo odjemalcu. Premajhen bazen hitro reciklira najeme, zato so naslovi videti nenehno premikajoči se in vsako pravilo, ki temelji na naslovu, je videti nezanesljivo že po zasnovi. Bazen, ki se prekriva z lokalnimi obsegi ali z naslovnim prostorom navideznega omrežja, ustvari dvoumnost usmerjanja, ki je nobeno pravilo požarnega zidu ne odpravi.

Preden se dotaknete pravila, položite tri stvari na eno stran: bazen point-to-site, naslovni prostor navideznega omrežja in lokalne obsege. Ne smejo se prekrivati, bazen pa potrebuje prostor za vsakega hkratnega odjemalca in še rezervo za ponovne povezave.

Nato sklenite zanko v tem vrstnem redu:

• Povežite se z dveh strojev v obeh vrstnih redih in primerjajte naslove; če se lahko zamenjata, nobeno pravilo, ki temelji na naslovu, ni varno.
• Preverite, ali je prehod Virtual WAN; če je, uporabite skupinske bazene namesto pravil na posamezni naslov.
• Vprašajte, kaj se zgodi, ko pravilo zadene napačno osebo; če je odgovor varnostni incident, premaknite nadzor na identiteto.
• Zabeležite, kateri obseg pripada kateri skupini, v istem repozitoriju kot definicije NSG.
• Po vsaki spremembi bazena, avtentikacije ali prehoda znova preizkusite, ker te spremembe prepišejo preslikavo, ne da bi to napovedale.