Kill switch për çdo aplikacion kundrejt bllokimit të të gjithë pajisjes: çfarë ndryshon
Vendosni sipas grupit të mbrojtur, jo sipas etiketës: çfarë ndalon për aplikacionet e përjashtuara, ndihmësit në sfond dhe lidhjet e reja, dhe si të provoni secilin rast.
Një kill switch për çdo aplikacion tingëllon si zgjedhja e kujdesshme: vetëm klienti i punës humbet rrjetin kur tuneli bie, dhe çdo gjë tjetër vazhdon të punojë. Pastaj dikush vëren se shfletuesi personal prapëseprapë ngarkoi një faqe, se ndihmësi i sinkronizimit i ardhur me të njëjtin paketë vazhdoi të provonte, dhe se një emër i ruajtur në cache ende zgjidhej në një adresë që nuk preku kurrë tunelin. Etiketa mbi funksionin dhe grupi i lidhjeve që ai me të vërtetë mbron janë dy gjëra të ndryshme. Përcaktoni fillimisht grupin e mbrojtur, sepse ai grup vendos nëse zbatimi për çdo aplikacion apo bllokimi i të gjithë pajisjes është përshkrimi i sinqertë.
Filloni me grupin, jo me etiketën
Një politikë për çdo aplikacion mbron aplikacionet e zgjedhura. Një bllokim pajisjeje synon një kufi rrjeti më të gjerë, zakonisht me përjashtime të dokumentuara për shtypjen lokale, trafikun e menaxhimit ose portat captive. Asnjëra etiketë nuk është e plotë derisa të mund të përgjigjeni tre pyetjeve: çfarë ndodh me aplikacionet e përjashtuara, çfarë ndodh me ndihmësit që ato aplikacione nisin, dhe çfarë ndodh me lidhjet e hapura ndërsa mbrojtja nuk është e disponueshme.
Shkruani ato përgjigje përpara se të prekni ndonjë cilësim të klientit. Nëse kërkesa është "ky klient pagash nuk duhet të flasë kurrë me internetin jashtë tunelit, dhe shfletuesi im mundet", grupi është i vogël dhe zbatimi për çdo aplikacion përshtatet. Nëse kërkesa është "asgjë në këtë pajisje nuk arrin internetin pa mbrojtje, përveç shërbimit të përditësimit", asnjë politikë për çdo aplikacion nuk do ta prodhojë, sepse problemet janë aplikacionet që nuk i emërtuat.
Zbatimi për çdo aplikacion përputh identifikuesit, jo emrat e programeve
Android ekspozon VPN për çdo aplikacion përmes paketave, dhe dokumentacioni i VpnService përshkruan si ndërvepron ajo me funksionimin gjithmonë aktiv dhe bllokimin. iOS konfiguron VPN për çdo aplikacion përmes një profili menaxhimi dhe përputh sipas aplikacionit ose sipas domenit. Windows dhe Linux nuk kanë fare rrugë sipas procesit, prandaj e njëjta ide përafrohet me një rregull muri zjarri të kufizuar në një program ose me një rregull që përputh me përdoruesin pronar.
Kufiri është identifikuesi, dhe identifikuesit anashkalohen lehtë. Një aplikacion që i dorëzon një URL shfletuesit të sistemit, ose hap një dokument në një shikues, kalon në një proces që politika juaj nuk e emërtoi kurrë. Edhe opsioni për të përfunduar në rënie nuk është filtër paketash: ai vret aplikacionin që konfiguruat, ndërsa një proces fëmijë, një punëtor radhe ose një skedë shfletuesi mund të mbajë gjallë një socket ekzistues.
Bllokimi mbulon atë që një politikë për çdo aplikacion nuk mund të shohë
Bllokimi i të gjithë pajisjes heq zgjedhjen. Çdo paketë dalëse që nuk i përket tunelit hidhet, duke përfshirë trafikun nga proceset që politika juaj e aplikacioneve nuk i njihte kurrë. Në Android kjo është VPN gjithmonë aktiv i kombinuar me cilësimin që bllokon lidhjet, dhe zbatimi ndodh në sistem, jo në dritaren e klientit. Në desktop është një rregull i përhershëm muri zjarri ose një rrugë e paracaktuar drejt një porta që nuk arrihet.
Çmimi është që gjithçka tjetër ndalon, kështu që përjashtimet bëhen pjesë e projektimit dhe jo një mendim i mëvonshëm. Printerat lokalë, zbulimi i shërbimeve, hyrja në portat captive, agjentët e menaxhimit dhe përditësimet e OS secili kërkon një vrimë të dokumentuar, sepse secili është një rrugë që mbetet e hapur kur tuneli është jashtë funksionit. Bllokimi është vetëm aq i fortë sa hyrja më e shkurtër në atë listë.
DNS, IPv6 dhe ndihmësit në sfond fshehin rrjedhjet
Fakti që një aplikacion i mbrojtur nuk arrin të zgjidhë një emër nuk provon se përgjigjet në cache ose trafiku i drejtpërdrejtë IP janë bllokuar. Nëse zgjidhësi është ende i arritshëm jashtë tunelit, emri zgjidhet dhe lidhja dështon, gjë që duket si kill switch që punon dhe nuk është. Më keq, një regjistrim në cache mund të tregojë një adresë që tuneli nuk e mban, kështu që lidhja del direkt ndërsa aplikacioni raporton një gabim VPN.
IPv6 kërkon rregullin e vet në çdo platformë që e ekzekuton, sepse një rregull hedhjeje për v4 nuk mbulon një rrugë v6. Në celular, një cilësim DNS privat mund ta zhvendosë zgjidhjen në një kanal të kriptuar që politika e pajisjes nuk e inspekton. Dhe ndihmësit në sfond janë fajtori i zakonshëm në desktop: një proces përditësimi ose sinkronizimi në tray nis përpara klientit VPN dhe mban lidhjen e vet, kështu që nuk e sheh kurrë rrugën e ndryshuar.
Provoni tre aplikacione dhe dy kalime
| Test | What it proves |
|---|---|
| Included app, by name and by direct IP | the policy is applied, not just the resolver |
| Excluded app, same checks | the exclusion is intentional and documented |
| Helper or updater process | nothing inherited an older route |
| Tunnel drop, then Wi-Fi to cellular | the block survives the transition |
Ekzekutoni çdo rresht dy herë, një herë me një emër hosti dhe një herë me një adresë fjalë për fjalë, dhe një herë më shumë përmes IPv6 nëse rrjeti e ofron. Kalimi do të thotë që aplikacioni i përfshirë u ndal, ai i përjashtuar u soll siç keni shkruar, dhe ndihmësi nuk rrëshqiti jashtë. Regjistroni sjelljen e drejtpërdrejtë që vendosët se ishte e pranueshme, që administratori i ardhshëm të mund të dallojë një përjashtim të qëllimshëm nga një defekt.
Më pas përshkruani rezultatin me një fjali që emërton aplikacionet dhe kushtet, për shembull: klienti i pagave nuk ka rrugë jashtë tunelit, shfletuesi është i drejtpërdrejtë sipas projektimit, dhe gjithçka tjetër ndalon kur tuneli është jashtë funksionit. Nëse ajo fjali është e vështirë për t'u shkruar, politika është ende dy politika që luftojnë me njëra-tjetrën.