Always On VPN kontraŭ VPN On Demand en iPhone: kion uzi

On Demand malfermas tunelon kiam ĝiaj reguloj kongruas; administrata Always On devigas kovradon sur prizorgataj aparatoj. Gvidilo por elekti unu kaj pruvi ke ĝi funkcias.

Du iPhone-oj povas ambaŭ diri VPN kaj konduti tute malsame. On Demand malfermas tunelon kiam regulo kongruas, kaj la uzanto ankoraŭ povas malŝalti ĝin en Agordoj. Administrata Always On tenas la kovradon devigita sur prizorgata aparato, eĉ en momentoj kiam la tunelo ne povas leviĝi. Elektu demandante kio devas esti vera kiam la uzanto faras nenion, kaj poste testu la transirojn anstataŭ la stabilan staton. La subaj paŝoj sekvas la ordon en kiu deplojo vere malsukcesas.

Paŝo 1: difinu kion la aparato povas devigi

Always On estas funkcio por prizorgataj aparatoj. Se la araro ne estas prizorgata, la diskuto finiĝas antaŭ ol ĝi komenciĝas, kaj neniu payload-ŝlosilo transformas neprizorgatan telefonon en devigitan. Konfirmu la prizorgadon de la administra flanko kaj de la aparato, poste konfirmu kiu subskribis la profilon.

En la telefono: Agordoj, poste Ĝenerala, poste VPN kaj Aparata administrado. La profila ero nomas sian posedanton, kaj permane instalita persona profilo aspektas malsame ol unu liverita de administra servo. Ne deduku devigon el la nomo de la profilo aŭ el la merkatika etikedo de provizanto; la etikedo ne estas la politiko de la platformo.

Notu tri faktojn antaŭ ol tuŝi la agordon: prizorgata aŭ ne, administrata aŭ persona profilo, kaj kiu kliento portas la tunelon. Ĉiu posta paŝo dependas de tiuj tri, kaj transdoni konduton de persona telefono al administrata profilo estas la maniero aprobi deplojon kontraŭ malĝusta bazo.

Paŝo 2: legu la on-demand regulojn, ne la nomon de la funkcio

On Demand estas listo de reguloj taksataj laŭ ordo. Ĉiu regulo nomas agon kaj la kondiĉojn kiuj elektas ĝin, kaj la kondiĉoj estas la interesa parto: interfaca tipo, Wi-Fi SSID, DNS-domajna sufikso aŭ sondada URL. Regula aro kiu neniam kongruas estas funkcio kiu neniam konektiĝas.

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

Legu la tutan tabelon kaj faru du demandojn por ĉiu regulo: ĉu tiu kondiĉo iam povas esti vera en tiu ĉi araro, kaj kio okazas kiam neniu regulo kongruas? Entreprenaj retoj renomas alirpunktojn, kunfandas SSID-ojn kaj ŝanĝas DNS-sufiksojn, kaj ĉiu el tiuj redaktoj silente apartigas regulon de la realo.

La DNS-sufiksa kondiĉo estas la plej ofte malĝusta sur la kampo, ĉar la sufikso kiun telefono raportas en gastiga reto ne estas tiu kiun servas la entreprena solvilo. Kontrolu la nomon kiun la aparato vere solvas antaŭ ol fidi la regulon.

Paŝo 3: testu la transirojn, ne la statikan konekton

Tunelo kiu staras dum vi rigardas ĝin pruvas tre malmulte. Plenumu ĉiun transiron intence kaj notu kion faras la aparato, uzante la saman privatan rimedon ĉiufoje por ke la rezultoj estu kompareblaj:

  • Aliĝu al reto kie regulo devus kongrui, poste petu la privatan rimedon kaj konfirmu ke ĝi ŝargas.
  • Ŝanĝu al poŝtelefona reto kun la aplikaĵo en fono, poste alportu ĝin antaŭen kaj ripetu la peton.
  • Konektu al Wi-Fi kun captive portal kaj vidu ĉu la portalo atingeblas aŭ ĉu la devigo blokas ĝin antaŭ ol vi aŭtentikiĝu.
  • Malŝaltu la tunelon permane sur prizorgata aparato kaj kontrolu ĉu ĝi revenas memstare kaj kiom rapide.

Plenumu la saman liston sur neprizorgata aparato se vi havas. La diferenco inter la du rezultoj estas la reala konduto de la deplojo, kaj tion ekrankopio de konektita tunelo neniam montras.

Paŝo 4: konu la du fiaskajn formojn

Devigita kovrado fiaskas per blokado. Kiam la tunelo ne establiĝas, la aparato perdas ordinaran interretan aliron kune kun privataj rimedoj, kaj la uzanto spertas telefonon kiu estas enrete sed ne povas retumi. Rekonekto kaj blokado estas apartaj observoj, do registru ambaŭ anstataŭ trakti mankon de interreto kiel unu simptomon.

On Demand fiaskas per neekigo. La regulo ne kongruas, neniun tunelon aperas, kaj la privata rimedo simple finiĝas per tempolimo. Facilas misdiagnozi tion kiel servilan problemon, ĉar la kliento kondutas ĝuste kiel agordite.

Captive portal staras inter la du: ĝi bezonas konektecon antaŭ ol ekzistas la tunelo, do politiko kiu blokas ĉion ĝis la tunelo leviĝas bezonas dokumentitan vojon tra la portalo. Decidu tion en la dezajno, ne ĉe la helpa servo.

Paŝo 5: kontrolu, poste ekzercu la restarigon

Kontrolo apartenas al la reala vojo kun sendanĝera trafiko: petu privatan rimedon kiu ne rajtas esti publika, konfirmu kiun adreson la aparato prezentas eksteren, kaj ripetu post restarto por ke vi vidu la ekĉenan sinsekvon kaj ne nur la varman staton.

Poste ekzercu la forigon sur testa aparato antaŭ ol vi bezonos ĝin en produkto. Forigo de la profilo redonas la aparaton al sia antaŭa stato, kaj scii kiom da tempo tio daŭras kaj kion la uzanto vidas estas parto de la runbook. La VPN-sekureca gvidilo de Apple estas la referenco por tio kion la platformo dokumentas pri tiuj politikoj, kaj indas legi ĝin antaŭ ol verki agordon kiu asertas pli ol la platformo.

Tenu la tri faktojn el la unua paŝo apud la regula aro kaj la testaj rezultoj. Kiam la sekva persono demandos kial telefono konektiĝas en unu reto kaj ne en alia, tiuj notoj respondas en unu minuto anstataŭ rekonstruo.

Rilataj artikoloj