Always On VPN kundër VPN On Demand në iPhone: çfarë të vendosni

Dy iPhone mund të thonë të dy VPN dhe të sillen krejt ndryshe. On Demand hap një tunel kur përputhet një rregull, dhe përdoruesi prapë mund ta fikë atë në Cilësimet. Always On i menaxhuar e mban mbulimin të zbatuar në një pajisje të mbikëqyrur, duke përfshirë momentet kur tuneli nuk mund të ngrihet. Zgjidhni duke pyetur çfarë duhet të jetë e vërtetë kur përdoruesi nuk bën asgjë, pastaj provoni kalimet, jo gjendjen e qëndrueshme. Hapat më poshtë shkojnë sipas rendit në të cilin një vendosje në të vërtetë dështon.

Hapi 1: përcaktoni çfarë mund të zbatojë pajisja

Always On është funksion i pajisjeve të mbikëqyrur. Nëse flota nuk është e mbikëqyrur, diskutimi mbaron përpara se të fillojë, dhe asnjë çelës payload nuk e kthen një telefon të pambikëqyrur në një të detyruar. Konfirmoni mbikëqyrjen nga ana e menaxhimit dhe nga pajisja, pastaj konfirmoni kush e nënshkroi profilin.

Në telefon, hapni Cilësimet, pastaj Të përgjithshme, pastaj VPN dhe menaxhimi i pajisjes. Zëri i profilit tregon pronarin e tij, dhe një profil personal i instaluar me dorë duket ndryshe nga ai i dorëzuar nga një shërbim menaxhimi. Mos e nxirrni detyrimin nga emri i profilit ose nga etiketa e marketingut e ofruesit; etiketa nuk është politika e platformës.

Shkruani tri fakte përpara se të prekni konfigurimin: i mbikëqyrur ose jo, profil i menaxhuar ose personal, dhe cili implementim i klientit e mban tunelin. Çdo hap i mëvonshëm varet nga ato të tre, dhe transferimi i sjelljes nga një telefon personal në një profil të menaxhuar është mënyra se si një vendosje miratohet kundrejt një baze të gabuar.

Hapi 2: lexoni rregullat on-demand, jo emrin e funksionit

On Demand është një listë rregullash, të vlerësuara me radhë. Çdo rregull emërton një veprim dhe kushtet që e zgjedhin, dhe kushtet janë pjesa interesante: lloji i ndërfaqes, Wi-Fi SSID, prapashtesa e domenit DNS, ose një URL provë. Një grup rregullash që nuk përputhet kurrë është një funksion që nuk lidhet kurrë.

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

Lexoni të gjithë grupin dhe bëni dy pyetje për çdo rregull: a mund të jetë ndonjëherë i vërtetë ky kusht në këtë flotë, dhe çfarë ndodh kur nuk përputhet asnjë rregull? Rrjetet e ndërmarrjeve i riemërtojnë pikat e aksesit, bashkojnë SSID-të dhe ndryshojnë prapashtesat DNS, dhe secila prej atyre ndryshimeve e shkëput në heshtje një rregull nga realiteti.

Kushti i prapashtesës DNS është ai që gabon më shpesh në terren, sepse prapashtesa që një telefon raporton në një rrjet mysafirësh nuk është prapashtesa që shërben zgjidhësi i korporatës. Verifikoni emrin që pajisja zgjidh vërtet përpara se t'i besoni rregullit.

Hapi 3: provoni kalimet, jo lidhjen statike

Një tunel që është lart ndërsa e shikoni provon shumë pak. Kryeni çdo kalim me qëllim dhe regjistroni çfarë bën pajisja, duke përdorur të njëjtin burim privat çdo herë që rezultatet të jenë të krahasueshme:

• Lidhu me një rrjet ku rregulli duhet të përputhet, pastaj kërko burimin privat dhe konfirmo që ngarkohet.
• Kalo në rrjet celular me aplikacionin në sfond, pastaj ktheje në plan të parë dhe përsërit kërkesën.
• Lidhu me një Wi-Fi me captive portal dhe shiko nëse portali është i arritshëm ose nëse zbatimi bllokon gjithçka përpara se të mund të autentifikohesh.
• Fike tunelin me dorë në një pajisje të mbikëqyrur dhe kontrollo nëse kthehet vetë dhe sa shpejt.

Ekzekuto të njëjtën listë në një pajisje të pambikëqyrur nëse ke një të tillë. Diferenca midis dy rezultateve është sjellja e vërtetë e vendosjes, dhe është pjesa që një pamje ekrani e një tuneli të lidhur nuk e tregon kurrë.

Hapi 4: njihni dy format e dështimit

Mbulimi i detyruar dështon duke bllokuar. Kur tuneli nuk mund të vendoset, pajisja humbet aksesin e zakonshëm në internet bashkë me burimet private, dhe përdoruesi përjeton një telefon që është online por nuk shfleton dot. Rilidhja dhe bllokimi janë vëzhgime të ndara, prandaj regjistroni të dyja në vend që ta trajtoni mungesën e internetit si një simptomë të vetme.

On Demand dështon duke mos u aktivizuar. Rregulli nuk përputhet, nuk shfaqet asnjë tunel, dhe burimi privat thjesht skadon. Kjo diagnostikohet lehtë gabimisht si problem serveri, sepse klienti sillet pikërisht siç është konfiguruar.

Një captive portal qëndron midis të dyjave: ka nevojë për lidhshmëri përpara se tuneli të ekzistojë, prandaj një politikë që bllokon gjithçka derisa tuneli të ngrihet ka nevojë për një rrugë të dokumentuar përmes portalit. Vendoseni atë në dizajn, jo në help desk.

Hapi 5: verifikoni, pastaj provoni kthimin pas

Verifikimi i takon rrugës reale me trafik të padëmshëm: kërkoni një burim privat që nuk duhet të jetë publik, konfirmoni cilën adresë pajisja paraqet nga jashtë, dhe përsëriteni pas një rindezjeje që të keni parë sekuencën e nisjes, jo vetëm gjendjen e ngrohtë.

Pastaj provoni heqjen në një pajisje testuese përpara se t'ju duhet ndonjëherë në prodhim. Heqja e profilit e kthen pajisjen në gjendjen e mëparshme, dhe të dish sa zgjat dhe çfarë sheh përdoruesi është pjesë e udhëzuesit. Udhëzuesi i sigurisë së VPN të Apple është referenca për atë që platforma dokumenton për këto politika, dhe ia vlen të lexohet përpara se të shkruani një konfigurim që pohon më shumë sesa pohon platforma.

Mbani tri faktet nga hapi i parë pranë grupit të rregullave dhe rezultateve të testeve. Kur personi tjetër pyet pse një telefon lidhet në një rrjet dhe jo në një tjetër, ato shënime përgjigjen për një minutë në vend të një rindërtimi.