Always On VPN gegn VPN On Demand á iPhone: hvað á að setja upp

On Demand opnar göng þegar reglur þess passa; stýrt Always On þvingar yfirbreiðslu á eftirlitsskjáum. Leiðarvísir til að velja og sanna að það virki.

Tvö iPhone geta bæði sagt VPN og hagað sér algjörlega ólíkt. On Demand opnar göng þegar regla passar, og notandinn getur samt slökkt á því í Stillingum. Stýrt Always On heldur yfirbreiðslunni þvingaðri á eftirlitsskjá, jafnvel á þeim augnablikum þegar göngin komast ekki upp. Veldu með því að spyrja hvað verði að vera satt þegar notandinn gerir ekkert, og prófaðu síðan umskiptin frekar en stöðuga ástandið. Skrefin hér að neðan fara í þeirri röð sem uppsetning mistekst í raun.

Skref 1: ákvarða hvað tækið getur þvingað

Always On er eiginleiki fyrir eftirlitsskjá. Ef flotinn er ekki undir eftirliti er samræðunni lokið áður en hún byrjar, og enginn payload-lykill gerir síma án eftirlits að þvinguðum. Staðfestu eftirlitið frá stjórnunarhlið og frá tækinu, og staðfestu síðan hver skrifaði undir sniðið.

Á símanum: Stillingar, síðan Almennt, síðan VPN og tækjastjórnun. Færsla sniðsins nefnir eiganda þess, og persónulegt snið sem sett er upp handvirkt lítur öðruvísi út en það sem stjórnunarþjónusta afhendir. Ekki draga þvingun af nafni sniðsins eða markaðsmerki þjónustuaðila; merkið er ekki stefna kerfisins.

Skrifaðu þrjár staðreyndir niður áður en þú snertir stillingarnar: undir eftirliti eða ekki, stýrt eða persónulegt snið, og hvaða biðlari ber göngin. Hvert síðara skref veltur á þessum þremur, og að flytja hegðun af persónulegum síma yfir á stýrt snið er leiðin sem uppsetning er samþykkt gegn rangri grunni.

Skref 2: lestu on-demand reglurnar, ekki nafn eiginleikans

On Demand er listi reglna sem metnar eru í röð. Hver regla nefnir aðgerð og skilyrðin sem velja hana, og skilyrðin eru áhugaverði hlutinn: tegund viðmóts, Wi-Fi SSID, DNS-lénviðskeyti eða prófunar-URL. Reglusett sem passar aldrei er eiginleiki sem tengist aldrei.

<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>

Lestu allt fylkið og spurðu tveggja spurninga fyrir hverja reglu: getur þetta skilyrði nokkurn tíma verið satt á þessum flota, og hvað gerist þegar engin regla passar? Fyrirtækjanet endurnefna aðgangspunkta, sameina SSID og breyta DNS-viðskeytum, og hver þessara breytinga losar reglu frá raunveruleikanum í hljóði.

DNS-viðskeytið er skilyrðið sem oftast er rangt á vettvangi, því viðskeytið sem sími tilkynnir á gestaneti er ekki það sem fyrirtækisleysirinn þjónar. Staðfestu nafnið sem tækið leysir í raun áður en þú treystir reglunni.

Skref 3: prófaðu umskiptin, ekki kyrrstæða tengingu

Göng sem eru uppi meðan þú horfir á þau sanna mjög lítið. Framkvæmdu hvert umskipti viljandi og skrifaðu niður hvað tækið gerir, með sama einkaaðilinu í hvert sinn svo niðurstöðurnar séu samanburðarhæfar:

  • Tengstu neti þar sem regla ætti að passa, biddu síðan um einkaaðilinn og staðfestu að hann hleðst.
  • Skiptu yfir á farsímanet með appið í bakgrunni, færðu það síðan fram og endurtaktu beiðnina.
  • Tengstu Wi-Fi með captive portal og sjáðu hvort portalið er aðgengilegt eða hvort þvingunin lokar því áður en þú getur auðkennt þig.
  • Slökktu á göngunum handvirkt á eftirlitsskjá og athugaðu hvort þau koma aftur af sjálfu sér, og hversu fljótt.

Keyrðu sama lista á skjá án eftirlits ef þú átt einn. Munurinn á niðurstöðunum er raunveruleg hegðun uppsetningarinnar, og það er hlutinn sem skjámynd af tengdum göngum sýnir aldrei.

Skref 4: þekktu tvær myndir mistaka

Þvinguð yfirbreiðsla mistekst með því að loka. Þegar göngin nást ekki missir tækið venjulegan internetþræð með einkaaðilunum, og notandinn upplifir síma sem er á netinu en getur ekki vafrað. Endurtenging og lokun eru aðskilin athugun, svo skráðu bæði í stað þess að meðhöndla skort á interneti sem eitt einkenni.

On Demand mistekst með því að kvikna ekki. Reglan passar ekki, engin göng birtast, og einkaaðilinn rennur einfaldlega út. Auðvelt er að greina þetta ranglega sem netþjónsvandamál, því biðlarinn hegðar sér nákvæmlega eins og hann er stilltur.

Captive portal stendur á milli: það þarf tengingu áður en göngin eru til, svo stefna sem lokar öllu þar til göngin eru uppi þarf skjalfesta leið í gegnum portalið. Ákveddu það í hönnuninni, ekki á hjálparborðinu.

Skref 5: staðfestu og æfðu síðan afturköllunina

Staðfesting á heima á raunverulegu leiðinni með meinlausri umferð: biddu um einkaaðila sem má ekki vera opinbert, staðfestu hvaða vistfang tækið sýnir út á við, og endurtaktu eftir endurræsingu svo þú hafir séð ræsingaröðina en ekki bara heita ástandið.

Æfðu síðan fjarlæginguna á prófunartæki áður en þú þarft hana í framleiðslu. Að fjarlægja sniðið setur tækið aftur í fyrra ástand, og að vita hversu lengi það tekur og hvað notandinn sér er hluti af runbook. Öryggisleiðarvísir Apple um VPN er heimildin fyrir því sem kerfið skjalfestir um þessar stefnur, og það er þess virði að lesa hann áður en þú skrifar stillingu sem fullyrðir meira en kerfið.

Haltu þremur staðreyndum fyrsta skrefs við hlið reglusettsins og prófunarniðurstöðunnar. Þegar næsta manneskja spyr hvers vegna sími tengist á einu neti en ekki öðru svara þessar athugasemdir á einni mínútu í stað endurbyggingar.

Tengdir greinar