Një VPN dytësore i përket një profili Wi-Fi, jo të gjithëve

Konfiguroni një VPN si dytësore të lidhjes Wi-Fi të shtëpisë dhe gjithçka funksionon, derisa laptopi t'i bashkohet një pike tjetër aksesi dhe tuneli mbetet poshtë. Lidhja e re është një objekt konfigurimi i veçantë me UUID-n e vet, dhe nuk ka asnjë arsye të dijë për lidhjen që krijuat për paraardhësin e saj. Asgjë nuk u prish; lidhja thjesht nuk ekzistonte kurrë.

Referenca e lidhjeve të NetworkManager përcakton dytësoret si UUID që aktivizohen së bashku me një lidhje bazë të caktuar. Ajo vëren gjithashtu se profilet e zakonshme VPN nuk zbatojnë aktivizim automatik ashtu si lidhjet bazë. Të dy pohimet çojnë në të njëjtin përfundim: lidhja është për çdo profil, dhe dikush duhet ta krijojë atë për çdo profil të ri.

Çfarë është në të vërtetë një dytësore

Një lidhje bazë ka një identitet, një UUID dhe një listë dytësoresh. Kur aktivizohet, menaxheri aktivizon gjithashtu ato dytësore sipas radhës, dhe kështu një VPN ndjek një rrjet Wi-Fi pa një klikim manual. Marrëdhënia jeton në lidhjen bazë, e shkruar si vargje UUID dhe jo si emra. Ky zgjedhje e paraqitjes nuk është e rastësishme; është ajo që e bën lidhjen të mbijetojë një riemërtim.

Ai detaj për emrat ka më shumë rëndësi sesa duket. Riemërtimi i një profili VPN e lë UUID-n e tij të paprekur, kështu që lidhjet ekzistuese vazhdojnë të funksionojnë. Fshirja e profilit të vjetër dhe importimi i një të reu prodhon një UUID të re, dhe çdo lidhje që drejtohej nga i vjetri tani nuk drejtohet nga asgjë.

Shqyrtoni listën ekzistuese përpara se të shtoni. Një profil shtëpiak me një dytësore nuk është një rregull që përshtatet me çdo SSID; është një rresht në një objekt, dhe nuk do të konsultohet kur aktivizohet një bazë tjetër.

Vendosni lidhjen aty ku krijohen profilet

Në një makinë personale, bëjeni bashkangjitjen e dytësores së synuar pjesë të shtimit të çdo profili Wi-Fi të lejuar. Është zakon dhe jo funksion, por një zakon që prodhon një gjendje konsistente, dhe kërkon një komandë ose dy vizita dialogu për rrjet. Mbani një shënim të shkurtër se cilat rrjete duhet të mbajnë tunelin, sepse lista është politika.

Në pajisjet e menaxhuara, lëreni rrjedhën e punës së furnizimit të krijojë hyrjen Wi-Fi dhe lidhjen e saj VPN në të njëjtin hap, dhe zbatoni të njëjtin trajtim për profilet e lejuara që ekzistojnë tashmë. Shpërndarja e një profili VPN vetëm lë marrëdhëniet bazë të pacaktuara, dhe kështu një flotë përfundon me një tunel që përdoret vetëm nga gjysma e laptopëve.

Atje ku përdoruesit ende mund të krijojnë profile jashtë rrugës së menaxhuar, vendosni në mënyrë eksplicite çfarë ndodh me ato hyrje. Supozimi se trashëgojnë një lidhje nuk është politikë; është një shpresë me kosto mbështetjeje.

Planifikoni ndryshimin e identitetit të VPN-së

Burimi i furnizimit ka nevojë për UUID-n e VPN-së së synuar, jo për një emër shfaqjeje që dikush e mori me mend. Kur mirëmbajtja e zëvendëson atë VPN me një objekt të sapoimportuar, përditësoni shabllonin e furnizimit dhe lidhjet ekzistuese të prekura në të njëjtin ndryshim. Riemërtimi nuk është zëvendësim, dhe trajtimi i të dyjave si ekuivalente është mënyra se si një vendosje funksionale prishet një javë më vonë.

Ruani UUID-n pranë arsyes pse ekziston. Një inxhinier i ardhshëm që gjen një UUID të zhveshur në një listë dytësoresh nuk ka si të thotë nëse është aktual, dhe me gjasë do ta fshijë ndërsa rregullon.

Aktivizimi nuk është zbatim

Një kërkesë për dytësore ndodh në kohën e aktivizimit. Ajo nuk i bllokon aplikacionet në intervalin përpara përfundimit të vërtetimit, dhe nuk e ndalon trafikun pasi tuneli dështon. Këto janë veti të ndryshme të ofruara nga mekanizma të ndryshëm, dhe ngatërrimi i tyre prodhon një dizajn që duket i rreptë në profil dhe është i lejueshëm në praktikë.

Bllokimi i trafikut të drejtpërdrejtë është një funksion i veçantë me konfigurimin e vet dhe mënyrat e veta të dështimit, dhe duhet të marrë parasysh trafikun që duhet të arrijë rrjetin përpara se të mund të ekzistojë çdo tunel: portale captivë, faqe hyrjeje, vetë pika fundore. Një politikë bllokimi që nuk mund të plotësohet përpara vërtetimit e mbyll makinën jashtë pikërisht atij rrjeta që i nevojitet.

Vendoseni atë dallim në udhëzimet që përdoruesit lexojnë vërtet. Një rrjet i re Wi-Fi mund të kërkojë tunelin; zbatimi vendos nëse diçka mund të dalë kur nuk mund të lidhet. Përdoruesit të cilëve u thuhet vetëm gjysma e parë do të raportojnë dizajnin si të prishur.

Testoni me një profil vërtet të re

Përdorni një rrjet testimi të miratuar dhe një profil bazë të sapokrijuar, jo hyrjen e shtëpisë që funksionon tashmë. Vëzhgoni aktivizimin e bazës, UUID-n dytësore të kërkuar dhe çdo kërkesë vërtetimi me radhë, dhe shënoni në cilën fazë ngec kur ngec. Një agjent sekret që bëhet i disponueshëm pas hyrjes në desktop nuk është automatikisht i pranishëm në çdo kontekst nisjeje, prandaj një rinisje i përket planit të testimit. Më pas kontrolloni burimin e synuar dhe rrugën e dështimit: a ngrihet tuneli përpara se aplikacioni ta ketë nevojë, dhe çfarë ndodh me atë aplikacion kur vërtetimi dështon?

Më pas kontrolloni burimin e synuar dhe rrugën e dështimit: a ngrihet tuneli përpara se aplikacioni ta ketë nevojë, dhe çfarë ndodh me atë aplikacion kur tuneli nuk mund të vërtetohet? Këto dy vëzhgime janë kriteret e pranimit, dhe asnjëra prej tyre nuk është e dukshme në vetë profilin.