Always On VPN proti VPN On Demand na iPhonu: kaj uvesti

On Demand odpre tunel, ko se ujemajo njegova pravila; upravljani Always On uveljavlja pokritost na nadzorovanih napravah. Priročnik za izbiro enega in dokazovanje, da deluje.

Dva iPhonea lahko oba trdita VPN in se obnašata povsem različno. On Demand odpre tunel, ko se ujema pravilo, uporabnik pa ga lahko še vedno izklopi v Nastavitvah. Upravljani Always On ohranja pokritost uveljavljeno na nadzorovani napravi, tudi v trenutkih, ko tunela ni mogoče vzpostaviti. Izberite tako, da vprašate, kaj mora veljati, ko uporabnik ne stori ničesar, nato pa preizkusite prehode, ne stabilnega stanja. Spodnji koraki si sledijo v vrstnem redu, v katerem uvajanje dejansko odpove.

Korak 1: ugotovite, kaj lahko naprava uveljavi

Always On je funkcija nadzorovane naprave. Če flota ni nadzorovana, se razprava konča, preden se začne, in noben ključ v payloadu ne naredi iz nenadzorovanega telefona uveljavljene naprave. Nadzor potrdite s strani upravljanja in z naprave, nato potrdite, kdo je podpisal profil.

Na telefonu odprite Nastavitve, nato Splošno, nato VPN in upravljanje naprav. Vnos profila navaja svojega lastnika, ročno nameščen osebni profil pa je videti drugače kot tisti, ki ga dostavi služba za upravljanje. O uveljavljanju ne sklepajte iz imena profila ali iz tržne oznake ponudnika; oznaka ni politika platforme.

Preden se dotaknete konfiguracije, zapišite tri dejstva: nadzorovano ali ne, upravljani profil ali osebni in katera izvedba odjemalca nosi tunel. Vsak poznejši korak je odvisen od teh treh, prenašanje vedenja z osebnega telefona na upravljani profil pa je način, kako se uvajanje potrdi glede na napačno izhodišče.

Korak 2: berite pravila on-demand, ne imena funkcije

On Demand je seznam pravil, ovrednotenih po vrstnem redu. Vsako pravilo navaja dejanje in pogoje, ki ga izberejo, pogoji pa so zanimivi del: vrsta vmesnika, Wi-Fi SSID, pripona domene DNS ali preizkusni URL. Nabor pravil, ki se nikoli ne ujema, je funkcija, ki se nikoli ne poveže.

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

Preberite celotno polje in pri vsakem pravilu vprašajte dve stvari: ali je ta pogoj na tej floti sploh lahko resničen in kaj se zgodi, ko se ne ujema nobeno pravilo? Podjetniška omrežja preimenujejo dostopne točke, združujejo SSID in spreminjajo pripone DNS, vsaka od teh sprememb pa tiho odcepi pravilo od resničnosti.

Pogoj pripone DNS je na terenu najpogosteje napačen, ker pripona, ki jo telefon sporoči v gostujočem omrežju, ni pripona, ki jo streže korporativni resolver. Preden pravilu zaupate, preverite ime, ki ga naprava dejansko razreši.

Korak 3: preizkusite prehode, ne statične povezave

Tunel, ki je vzpostavljen, medtem ko ga gledate, dokaže zelo malo. Vsak prehod izvedite namerno in zapišite, kaj naprava naredi, pri čemer vsakič uporabite isti zasebni vir, da bodo izsledki primerljivi:

  • Povežite se v omrežje, kjer naj bi se pravilo ujemalo, nato zahtevajte zasebni vir in potrdite, da se naloži.
  • Preklopite na mobilno omrežje z aplikacijo v ozadju, nato jo vrnite v ospredje in zahtevo ponovite.
  • Povežite se na Wi-Fi s captive portalom in preverite, ali je portal dosegljiv ali pa uveljavljanje vse blokira, preden se lahko overite.
  • Ročno izklopite tunel na nadzorovani napravi in preverite, ali se sam vrne in kako hitro.

Enak seznam zaženite na nenadzorovani napravi, če jo imate. Razlika med rezultatoma je resnično vedenje uvajanja in prav tega posnetek zaslona povezanega tunela nikoli ne pokaže.

Korak 4: spoznajte dve obliki okvare

Uveljavljena pokritost odpove z blokiranjem. Ko tunela ni mogoče vzpostaviti, naprava izgubi običajen dostop do interneta skupaj z zasebnimi viri, uporabnik pa doživi telefon, ki je povezan, a ne more brskati. Ponovna povezava in blokiranje sta ločena opažanja, zato zabeležite oba, namesto da bi stanje brez interneta obravnavali kot en simptom.

On Demand odpove tako, da se ne sproži. Pravilo se ne ujema, tunel se ne pojavi in zasebni vir preprosto poteče. To je lahko napačno diagnosticirati kot težavo strežnika, ker se odjemalec obnaša točno tako, kot je konfiguriran.

Captive portal stoji med obema: potrebuje povezljivost, preden tunel obstaja, zato politika, ki blokira vse, dokler tunel ni vzpostavljen, potrebuje dokumentirano pot skozi portal. To odločite v zasnovi, ne na help desku.

Korak 5: preverite in nato vadite razveljavitev

Preverjanje sodi na resnično pot z neškodljivim prometom: zahtevajte zasebni vir, ki ne sme biti javen, preverite, kateri naslov naprava predstavlja navzven, in po ponovnem zagonu to ponovite, da vidite zagonsko zaporedje in ne le ogreto stanje.

Nato odstranjevanje vadite na preskusni napravi, preden ga boste v produkciji sploh potrebovali. Odstranitev profila vrne napravo v prejšnje stanje, poznavanje tega, koliko traja in kaj uporabnik vidi, pa je del priročnika. Applov vodič za varnost VPN je referenca za to, kar platforma dokumentira o teh politikah, in vreden je branja, preden napišete konfiguracijo, ki trdi več, kot trdi platforma.

Tri dejstva iz prvega koraka imejte poleg nabora pravil in izsledkov preskusov. Ko se naslednja oseba vpraša, zakaj se telefon poveže v enem omrežju in ne v drugem, bodo te beležke odgovorile v minuti namesto ponovne gradnje.

Sorodni članki