Statika IP en Azure P2S VPN: kial la klienta adreso ŝanĝiĝas

Ĉiu Azure point-to-site-kliento ricevas adreson el la naĝejo kiam ĝi aŭtentikigas, kaj tenas ĝin nur dum la daŭro de tiu konekto. Ne ekzistas rezerva tabelo, nek mapado laŭ uzanto, nek pordego-agordo kiu signifas “ĉiam donu al ĉi tiu persono 172.16.0.10”. Ĝuste tiu unu mekanismo klarigas ambaŭ simptomojn, kiujn homoj renkontas poste: NSG-regulo kiu ĉesas kongrui kun uzanto kun kiu ĝi antaŭe kongruis, kaj permislisto kiu silente enlasas maŝinon kiun neniu intence aldonis. Anstataŭigi la regulon per pli lerta IP-regulo riparas nek unu nek la alian, ĉar tio, kion la regulo nomas, estas reatribuata laŭ horaro kiun vi ne kontrolas.

La naĝejo estas kapacito, ne identeco. Ĝi ekzistas por ke samtempaj tuneloj ricevu unikajn adresojn, kaj ĝi reciklas ilin en la momento kiam luo finiĝas. Kiam tio estas klara, la utila demando ĉesas esti “kiel mi fiksu ĉi tiun klienton” kaj fariĝas “kontraŭ kio mi povas skribi regulon kiun la pordego ne reciklos”.

Kion la pordego efektive faras kiam kliento konektiĝas

La pordego tenas la agorditan klientan adresaron kaj traktas ĝin kiel luan tabelon. Ĉe konekto ĝi prenas la sekvan liberan adreson, praktike la plej malaltan disponeblan, kaj atribuas ĝin al la tunela adaptilo ĝis la kliento malkonektiĝas aŭ la luo finiĝas. La ordo decidas, ne la identeco: kiu rekonektiĝas unue post kvieta periodo, tiu ricevas la plej malaltan adreson kiu hazarde estas libera en tiu momento.

La grandeco de la naĝejo kaŝas la konduton. Laboratoria naĝejo unu aŭ du adresojn pli granda ol la nombro de testantoj aspektas determinisma, ĉar la sama tekkomputilo emas rekonektiĝi en la sama ordo ĉiun matenon. Aldonu trian maŝinon, ŝanĝu la grandecon de la naĝejo, aŭ lasu sesion konektita dum la tagmanĝo, kaj la ŝablono rompiĝas. La adreso neniam estis stabila; la vico estis.

Ĉiu ŝanĝo en la point-to-site-agordo ankaŭ restarigas la luan spacon. Alia aŭtentikiga tipo, aligrandigita naĝejo, nova naĝeja gamo aŭ pordego kiu estas malkonstruata kaj rekonstruata — ĉio resendas klientojn en naĝejon kiu jam ne mapas al iliaj malnovaj adresoj. Nenio en tiu ŝanĝo tuŝas vian NSG, tial la paneo aspektas spontanea.

Vi povas vidi ĝin okazi en proksimume unu minuto. Konektiĝu, notu la tunelan adreson en la konektaj detaloj de la kliento, malkonektiĝu, konektu duan maŝinon, poste rekonektu la unuan. La adreso kiun vi ricevas reen dependas de tio, kion la dua maŝino tenas, kaj neniu portala agordo restarigos la antaŭan laŭpete.

NSG bazita sur la klienta IP estas efektive regulo pri konekta ordo

La regulo kiun homoj skribas unue estas la evidenta: envena regulo sur la NIC de la administra VM aŭ sur ĝia subreto, kun la interna adreso de la VPN-kliento kiel fonto. Ĝi estas mallonga, ĝi trapasas la teston en la tago kiam ĝi estas skribita, kaj ĝi malsukcesas tuj kiam la naĝejo havas pli ol unu liberan adreson.

El tio sekvas du fiaskaj manieroj, kaj nur unu el ili aspektas kiel cimo. Laŭleĝa uzanto estas rifuzata ĉar iu alia nun tenas la adreson kiun la regulo nomas, kaj tio alvenas kiel ĝena subtena bileto. Aŭ neintencita uzanto estas enlasata ĉar li heredis adreson kiun la regulo ankoraŭ fidas, kaj tio alvenas kiel nenio ĝis iu aŭditas la aliron.

Ĉar la regulo sekvas la luon, la efektiva politiko tekstas “la unua persono kiu konektiĝas ricevas administran aliron”. Tio estas priskribo de konekta ordo vestita kiel intenco, kaj neniu kvanto de regula higieno igas ĝin esprimi intencon.

La klienta luo kaj la pordega adreso estas malsamaj objektoj

Plej multo de la konfuzo venas de unu vorto. La pordego havas publikan IP kiu estas relative stabila; klientoj havas privatajn adresojn el la naĝejo kiuj ne estas. Por VPN-pordego sen zona redundo, la publika IP estas dinamike atribuata, sed ĝi postvivas aligrandigon, restarigon kaj rutinan prizorgon — ĝi ŝanĝiĝas kiam la pordego mem estas forigita kaj rekreiata. Zone redundaj kaj zonaj pordegaj SKU-oj uzas publikan IP de Standard SKU, kaj tiu atribuo devas esti statika.

Tiu stabileco estas kion loka samtavolo bezonas en sia agordo, kaj ĝi diras nenion pri identigado de individua kliento. Kiam partnero demandas kiun adreson ili vidos, la respondo estas la publika IP de la pordego ĉe site-to-site, aŭ komuna NAT-gamo — neniam la tunela luo de tekkomputilo.

Grupaj naĝejoj donas al vi gamon indan je reguloj

Virtual WAN point-to-site subtenas uzantogrupojn, kaj al ĉiu grupo povas esti atribuata propra klienta adresaro. Membreco decidiĝas per identeco, do la gamo en kiun kliento falas fariĝas antaŭvidebla: operacioj en unu gamo, kontraktantoj en alia, kaj la gamo estas io kion fajroŝirma aŭ NSG-regulo povas nomi sen diveni.

La rezulta reguloaro havas formon kiun vi povas revizii:

• unu naĝejo por publiko, dimensiita por pintaj samtempaj sesioj anstataŭ laŭ kapoj;
• grupomembreco traktata per identeco, ne per redaktado de reguloj ĉiufoje kiam iu aliĝas;
• NSG aŭ Azure Firewall-reguloj skribitaj kontraŭ naĝejaj gamoj, neniam kontraŭ individuaj luoj;
• aparta hubo aŭ pordego por publiko kiu neniam rajtas kunhavigi gamon.

Meti tutan naĝejon en la permisliston estas honesta sed kruda: ĉiu konektita kliento en tiu gamo ricevas la saman aliron. Tio estas politika decido inda je laŭta eldiro anstataŭ malkovro dum revizio. Ĉio kio ankoraŭ bezonas respondon por persono apartenas al la rimedo, per rolaj atribuoj, ne al la paketa filtrilo.

Kiam la deplojo ne povas transiri al Virtual WAN

Multaj pordegoj restas ordinaraj VPN-pordegoj, kaj transiri al Virtual WAN ne estas hazarda ŝanĝo. La praktika respondo estas movi la decidon por uzanto de la paketa filtrilo al io kio jam scias kiu estas la uzanto.

Identeco je rimeda nivelo estas la plej malmultekosta versio. Storage, SQL kaj Key Vault ĉiuj subtenas Entra ID-aŭtentikigon kun rolaj atribuoj por uzanto aŭ por grupo, do la VPN nur devas pruvi retan atingeblon. Saltgastiganto kun nomitaj kontoj faras la saman laboron por administra laboro, ĉar la gastiganto registras la homon kaj la tunelo nur portas pakaĵojn. Registri klientojn en DNS kaj permesi la nomon anstataŭ la numeron movas la regulon unu tavolon supren. Identeco je aplikaĵa nivelo — atestila subjekto, ĵetona aserto, grupomembreco — funkcias kiam la aplikaĵo, ne la reto, estas petata decidi.

Por partnero kiu insistas pri fiksa fonta adreso, la respondo estas site-to-site aŭ ExpressRoute kun difinita samtavola prefikso. Ili permesas la samtavolan prefikson, la adreso kiu aperas ĉe ilia flanko apartenas al la pordego, kaj ĝi ne ŝanĝiĝas kiam iu restartigas tekkomputilon.

Kontrolu la naĝejon antaŭ ol redakti alian permisliston

Du ecoj de la naĝejo kaŭzas plej multon de la konduto kiun homoj kulpigas al la kliento. Tro malgranda naĝejo reciklas luojn rapide, do adresoj ŝajnas konstante moviĝi kaj ĉiu adres-bazita regulo aspektas malfidinda laŭ dizajno. Naĝejo kiu interkovras la lokajn gamojn aŭ la adresan spacon de la virtuala reto kreas vojigan malklarecon kiun neniu fajroŝirma regulo riparas.

Metu tri aferojn sur unu paĝon antaŭ ol tuŝi regulon: la point-to-site-naĝejon, la adresan spacon de la virtuala reto kaj la lokajn gamojn. Ili ne rajtas interkovriĝi, kaj la naĝejo bezonas lokon por ĉiu samtempa kliento plus marĝenon por rekonektoj.

Poste fermu la cirklon en ĉi tiu ordo:

• Konektiĝu de du maŝinoj en ambaŭ ordoj kaj komparu la adresojn; se ili povas interŝanĝiĝi, neniu adres-bazita regulo estas sekura.
• Kontrolu ĉu la pordego estas Virtual WAN; se jes, uzu grupajn naĝejojn anstataŭ reguloj por unuopa adreso.
• Demandu kio okazas kiam regulo trafas la malĝustan personon; se la respondo estas alira okazaĵo, movu la kontrolon al identeco.
• Notu kiun gamon apartenas al kiu grupo en la sama deponejo kiel la NSG-difinoj.
• Retestu post ĉiu naĝeja, aŭtentikiga aŭ pordega ŝanĝo, ĉar tiuj ŝanĝoj reskribas la mapadon sen anonci ĝin.