Fast IP í Azure P2S VPN: hvers vegna netfang biðlarans breytist

Sérhver Azure point-to-site biðlari fær netfang úr lauginni þegar hann auðkennir sig og heldur því aðeins á meðan sú tenging varir. Ekkert frátektartöflu er til, engin vörpun á hvern notanda og engin gáttarstilling sem þýðir „gefðu þessari manneskju alltaf 172.16.0.10“. Einmitt þessi eina aðferð skýrir bæði einkennin sem fólk rekst á síðar: NSG-reglu sem hættir að passa við notanda sem hún passaði áður við, og heimildalista sem hleypir hljóðlaust inn vél sem enginn bætti við viljandi. Að skipta reglunni út fyrir sniðugri IP-reglu lagar hvorki annað né hitt, því það sem reglan nefnir er úthlutað aftur samkvæmt áætlun sem þú stjórnar ekki.

Laugin er afkastageta, ekki auðkenni. Hún er til svo að samtímis göng fái einstök netföng, og hún endurnýtir þau um leið og leiga rennur út. Þegar það er skýrt hættir gagnlega spurningin að vera „hvernig festi ég þennan biðlara“ og verður „við hvað get ég skrifað reglu sem gáttin endurnýtir ekki“.

Hvað gáttin gerir í raun þegar biðlari tengist

Gáttin heldur stilltu biðlarasviðinu og meðhöndlar það sem leigutöflu. Við tengingu tekur hún næsta lausa netfang, í reynd það lægsta sem er tiltækt, og úthlutar því til gönguaðlagningarþáttarins þar til biðlarinn aftengist eða leigan rennur út. Röðin ræður, ekki auðkennið: sá sem tengist fyrstur aftur eftir hljóðlát tímabil fær lægsta netfangið sem skyldi vera laust á þeirri stundu.

Stærð laugarinnar felur hegðunina. Rannsóknarstofulaug sem er einu eða tveimur netföngum stærri en fjöldi prófenda virðist ákveðin, því sami fartölvan hefur tilhneigingu til að tengjast aftur í sömu röð á hverjum morgni. Bættu við þriðju vél, breyttu stærð laugarinnar eða láttu setu vera tengda yfir hádegismat, og mynstrið brestur. Netfangið var aldrei stöðugt; röðin var það.

Öll breyting á point-to-site stillingunni endurstillir líka leigurýmið. Önnur tegund auðkenningar, laug með breyttri stærð, nýtt laugarasvið eða gátt sem er rifin og byggð upp aftur senda biðlara alla aftur í laug sem passar ekki lengur við gömul netföng þeirra. Ekkert í þeirri breytingu snertir NSG þinn, þess vegna virðist bilunin spönn.

Þú getur séð þetta gerast á um einni mínútu. Tengstu, skráðu göngunetfangið í tengingarupplýsingum biðlarans, aftengstu, tengdu aðra vél og tengdu svo fyrstu aftur. Netfangið sem þú færð til baka fer eftir því sem önnur vélin heldur, og engin gáttarstilling endurheimtir hina fyrri að beiðni.

NSG sem er byggt á IP biðlarans er í raun regla um röð tenginga

Reglan sem fólk skrifar fyrst er augljósa: inngangsregla á NIC stjórnstöðvarinnar eða á undirnetið hennar, með innra netfangi VPN-biðlarans sem uppruna. Hún er stutt, stenst prófið á þeim degi sem hún er skrifuð og bregst um leið og laugin hefur fleiri en eitt laust netfang.

Af þessu leiða tvenns konar bilanir, og aðeins önnur lítur út eins og villa. Lögmætur notandi er neitaður vegna þess að einhver annar heldur netfanginu sem reglan nefnir á þeirri stundu, og það kemur sem pirrandi stuðningsmiði. Eða óætluðum notanda er hleypt inn vegna þess að hann erfði netfang sem reglan treystir enn, og það kemur sem ekkert fyrr en einhver tekur aðganginn til skoðunar.

Þar sem reglan fylgir leigunni segir virka stefnan „fyrsta manneskjan sem tengist fær stjórnandaðgang“. Þetta er lýsing á röð tenginga í búningi ásetnings, og engin regluhreinleiki gerir hana að tjáningu ásetnings.

Leiga biðlarans og netfang gáttarinnar eru ólíkir hlutir

Mestur hluti ruglingsins kemur frá einu orði. Gáttin hefur opinbert IP sem er tiltölulega stöðugt; biðlarar hafa einkaaðgerðir netföng úr lauginni sem eru það ekki. Fyrir VPN-gátt sem er ekki svæðisvarin er opinbera IP-inu úthlutað kvikt, en hún lifir af stærðarbreytingu, endurstillingu og venjubundið viðhald — hún breytist þegar gáttin sjálf er eytt og endursköpuð. Svæðisvarin og svæðisbundin gáttar-SKU nota opinbert IP af Standard SKU, og þeirri úthlutun verður að vera fast.

Þessi stöðugleiki er það sem staðbundinn jafningi þarf í stillingum sínum, og hann segir ekkert um að bera kennsl á einstakan biðlara. Þegar félagi spyr hvaða netfang hann muni sjá er svarið opinbert IP gáttarinnar undir site-to-site, eða sameiginlegt NAT-svið — aldrei gönguleiga fartölvu.

Hópalaugar gefa þér svið sem er þess virði að skrifa reglur við

Virtual WAN point-to-site styður notendahópa, og hverjum hópi má úthluta eigin biðlarasviði. Aðild ræðst af auðkenni, svo sviðið sem biðlari lendir á verður fyrirsjáanlegt: rekstur á einu sviði, verktakar á öðru, og sviðið er eitthvað sem eldveggjar- eða NSG-regla getur nefnt án þess að giska.

Reglusettið sem verður til hefur lögun sem þú getur farið yfir:

• ein laug fyrir hvern hóp, mæld fyrir hámarks samtímis setur frekar en höfðatölu;
• hópmeðlimur er meðhöndlaður með auðkenni, ekki með því að breyta reglum í hvert sinn sem einhver gengur inn;
• NSG- eða Azure Firewall-reglur skrifaðar við laugarasvið, aldrei við einstakar leigur;
• aðskilin stöð eða gátt fyrir hópa sem mega aldrei deila sviði.

Að setja alla laug á heimildalistann er heiðarlegt en gróft: sérhver tengdur biðlari á því sviði fær sama aðgang. Það er stefnumótandi ákvörðun sem er þess virði að segja upphátt í staðinn fyrir að uppgötva hana í yfirferð. Allt sem enn þarf svar á hvern einstakling á heima hjá auðlindinni, í gegnum hlutverkauðkenni, ekki hjá pakkasíunni.

Þegar uppsetningin getur ekki færst yfir í Virtual WAN

Margar gáttir halda sér sem venjulegar VPN-gáttir, og að færa sig yfir í Virtual WAN er ekki afsprengisbreyting. Hagnýta svarið er að færa ákvörðunina fyrir hvern notanda frá pakkasíunni yfir á eitthvað sem veit þegar hver notandinn er.

Auðkenni á auðlindastigi er ódýrasta útgáfan. Storage, SQL og Key Vault styðja öll Entra ID-auðkenningu með hlutverkauðkenningum fyrir hvern notanda eða hóp, svo VPN-ið þarf aðeins að sanna nettengingu. Stökkvaþjónn með nefndum reikningum gerir sama starf fyrir stjórnunarstörf, því þjónninn skráir manneskjuna og göngin bera aðeins pakka. Að skrá biðlara í DNS og heimila nafnið í stað númerisins færir regluna eitt lag upp. Auðkenni á forritslaginu — vottorðsefni, tákniður kröfu, hópmeðlimur — virkar þegar forritið, ekki netið, er beðið um að ákveða.

Fyrir félaga sem krefjast föstu upprunanetfangs er svarið site-to-site eða ExpressRoute með skilgreindu jafningjaforskeyti. Þeir heimila jafningjaforskeytið, netfangið sem birtist á þeirra hlið tilheyrir gáttinni, og það breytist ekki þegar einhver endurræsir fartölvu.

Athugaðu laugina áður en þú breytir öðrum heimildalista

Tveir eiginleikar laugarinnar valda mestri hegðuninni sem fólk kennir biðlaranum um. Of lítil laug endurnýtir leigur hratt, svo netföng virðast stöðugt á hreyfingu og hver netfangstengd regla virðist óstöðug frá hönnun. Laug sem skarast við staðbundin svið eða netfangarými sýndarnetsins skapar óskýrleika í leiðsögn sem engin eldveggjarregla lagar.

Setja þrjá hluti á eina síðu áður en þú snertir reglu: point-to-site laugina, netfangarými sýndarnetsins og staðbundin sviðin. Þau mega ekki skarast, og laugin þarf rúm fyrir hvern samtímis biðlara auk skekkjumarks fyrir endurtengingar.

Lokaðu svo hringnum í þessari röð:

• Tengstu frá tveimur vélum í báðum röðum og berðu saman netföngin; ef þau geta skiptst er engin netfangstengd regla örugg.
• Athugaðu hvort gáttin er Virtual WAN; ef svo er, notaðu hópalaugar í stað reglna fyrir hvert netfang.
• Spurðu hvað gerist þegar regla hittir rangt fólk; ef svarið er atvik í aðgangi skaltu færa stjórnina yfir á auðkenni.
• Skráðu hvaða svið tilheyrir hvaða hóp í sama geymslu og NSG-skýringarnar.
• Prófaðu aftur eftir hverja breytingu á laug, auðkenningu eða gátt, því þær breytingar endurskrifa vörpunina án þess að tilkynna það.