Always On VPN a VPN On Demand na iPhone: čo nasadiť

On Demand otvorí tunel, keď sa zhodujú jeho pravidlá; spravovaný Always On vynucuje pokrytie na spravovaných zariadeniach. Runbook na výber jedného a overenie, že funguje.

Dva iPhony môžu oba hovoriť VPN a správať sa úplne odlišne. On Demand otvorí tunel, keď sa zhoduje pravidlo, a používateľ ho stále môže vypnúť v Nastaveniach. Spravovaný Always On udržiava pokrytie vynútené na podozorovanom zariadení vrátane okamihov, keď sa tunel nedá postaviť. Vyberajte tak, že sa spýtate, čo musí platiť, keď používateľ nič nerobí, a potom testujte prechody, nie ustálený stav. Kroky nižšie idú v poradí, v akom nasadenie skutočne zlyháva.

Krok 1: zistite, čo zariadenie dokáže vynútiť

Always On je funkcia podozorovaného zariadenia. Ak flotila nie je podozorovaná, diskusia sa končí skôr, než začne, a žiadny kľúč v payloade neurobí z nepodozorovaného telefónu vynútený. Potvrďte podozorovanie zo strany správy aj zo zariadenia a potom potvrďte, kto podpísal profil.

Na telefóne otvorte Nastavenia, potom Všeobecné, potom VPN a správa zariadení. Záznam profilu uvádza svojho vlastníka a ručne nainštalovaný osobný profil vyzerá inak ako profil doručený službou správy. Nevynucovanie nevyvodzujte z názvu profilu ani z marketingového označenia poskytovateľa; označenie nie je politikou platformy.

Pred dotykom konfigurácie si zapíšte tri fakty: podozorované alebo nie, spravovaný profil alebo osobný a ktorá implementácia klienta nesie tunel. Každý ďalší krok závisí od tých troch a prenášanie správania z osobného telefónu na spravovaný profil je spôsob, akým sa nasadenie odsúhlasí proti nesprávnej základni.

Krok 2: čítajte pravidlá on-demand, nie názov funkcie

On Demand je zoznam pravidiel vyhodnocovaných v poradí. Každé pravidlo pomenúva akciu a podmienky, ktoré ho vyberajú, a podmienky sú tá zaujímavá časť: typ rozhrania, Wi-Fi SSID, prípona domény DNS alebo testovacia URL. Sada pravidiel, ktorá sa nikdy nezhoduje, je funkcia, ktorá sa nikdy nepripojí.

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

Prečítajte celé pole a pri každom pravidle sa spýtajte na dve otázky: môže byť táto podmienka na tejto flotile niekedy pravdivá a čo sa stane, keď sa nezhoduje žiadne pravidlo? Podnikové siete premenúvajú prístupové body, zlučujú SSID a menia prípony DNS a každá z tých úprav ticho odpojí pravidlo od reality.

Podmienka prípony DNS je v teréne najčastejšie nesprávna, pretože prípona, ktorú telefón hlási v hosťovskej sieti, nie je prípona, ktorú obsluhuje firemný resolver. Predtým, než pravidlu uveríte, overte názov, ktorý zariadenie skutočne prekladá.

Krok 3: testujte prechody, nie statické pripojenie

Tunel, ktorý je hore, kým sa naň pozeráte, dokazuje veľmi málo. Každý prechod vykonajte zámerne a zaznamenajte, čo zariadenie robí, pričom vždy použite ten istý súkromný zdroj, aby boli výsledky porovnateľné:

  • Pripojte sa k sieti, kde by sa pravidlo malo zhodovať, potom vyžiadajte súkromný zdroj a potvrďte, že sa načíta.
  • Prepnite na mobilnú sieť s aplikáciou na pozadí, potom ju vráťte do popredia a požiadavku zopakujte.
  • Pripojte sa k Wi-Fi s captive portálom a zistite, či je portál dostupný alebo či vynucovanie zablokuje všetko skôr, než sa stihnete autentifikovať.
  • Ručne vypnite tunel na podozorovanom zariadení a skontrolujte, či sa sám vráti a ako rýchlo.

Ak máte nepodozorované zariadenie, spustite ten istý zoznam aj na ňom. Rozdiel medzi dvoma výsledkami je skutočné správanie nasadenia a práve tú časť snímka obrazovky pripojeného tunela nikdy neukáže.

Krok 4: poznajte dva tvary zlyhania

Vynútené pokrytie zlyháva blokovaním. Keď sa tunel nedá postaviť, zariadenie stratí bežný prístup na internet spolu so súkromnými zdrojmi a používateľ zažíva telefón, ktorý je online, ale nedá sa v ňom prehliadať. Opätovné pripojenie a blokovanie sú oddelené pozorovania, preto zaznamenajte obe namiesto toho, aby ste stav bez internetu považovali za jeden príznak.

On Demand zlyháva tým, že sa nespustí. Pravidlo sa nezhoduje, tunel sa neobjaví a súkromný zdroj jednoducho vyprší. Toto sa ľahko chybne diagnostikuje ako problém servera, pretože klient sa správa presne tak, ako je nakonfigurovaný.

Captive portál stojí medzi oboma: potrebuje konektivitu skôr, než tunel existuje, takže politika, ktorá blokuje všetko, kým tunel nie je hore, potrebuje zdokumentovanú cestu cez portál. To rozhodnite v dizajne, nie na help desku.

Krok 5: overte a potom nacvičte vrátenie

Overenie patrí na skutočnú cestu s neškodnou prevádzkou: vyžiadajte súkromný zdroj, ktorý nesmie byť verejný, overte, ktorú adresu zariadenie prezentuje navonok, a po reštarte to zopakujte, aby ste videli štartovaciu sekvenciu, nielen teplý stav.

Potom si odstraňovanie nacvičte na testovacom zariadení skôr, než ho v produkcii vôbec budete potrebovať. Odstránenie profilu vráti zariadenie do predchádzajúceho stavu a vedieť, ako dlho to trvá a čo používateľ vidí, je súčasťou runbooku. Appleova príručka k zabezpečeniu VPN je referenciou pre to, čo platforma o týchto politikách dokumentuje, a stojí za prečítanie pred písaním konfigurácie, ktorá tvrdí viac, než tvrdí platforma.

Tri fakty z prvého kroku držte pri sade pravidiel a výsledkoch testov. Keď sa ďalší človek spýta, prečo sa telefón pripája v jednej sieti a v inej nie, tie poznámky odpovedia za minútu namiesto prestavby.

Súvisiace články