Always On VPN versus VPN On Demand na iPhonu: co nasadit

On Demand otevře tunel, když se shoduje pravidlo; spravovaný Always On vynucuje pokrytí na sledovaných zařízeních. Postup, jak vybrat a prokázat, že to funguje.

Dva iPhony mohou oba hlásit VPN a přesto se chovat úplně jinak. On Demand otevře tunel, jakmile se shoduje pravidlo, a uživatel ho stále může vypnout v Nastavení. Spravovaný Always On drží pokrytí vynucené na sledovaném zařízení, i ve chvílích, kdy tunel nejde zvednout. Vybírejte tak, že se zeptáte, co musí platit, když uživatel nic nedělá, a pak testujte přechody, ne ustálený stav. Kroky níže jdou v pořadí, v jakém nasazení skutečně selhává.

Krok 1: určete, co zařízení dokáže vynutit

Always On je funkce pro sledovaná zařízení. Pokud flotila není pod dohledem, rozhovor končí dřív, než začne, a žádný klíč payload neudělá z nesledovaného telefonu vynucený. Potvrďte dohled ze strany správy i ze zařízení a poté potvrďte, kdo profil podepsal.

V telefonu: Nastavení, pak Obecné, pak VPN a správa zařízení. Záznam profilu uvádí svého vlastníka a ručně nainstalovaný osobní profil vypadá jinak než profil dodaný službou správy. Nevynucení neodvozujte z názvu profilu ani z marketingového označení poskytovatele; označení není politikou platformy.

Zapište tři fakta, než se dotknete konfigurace: sledované ano či ne, spravovaný nebo osobní profil a který klientský klient nese tunel. Každý další krok závisí na těchto třech a přenos chování z osobního telefonu na spravovaný profil je způsob, jak se nasazení schválí proti špatné základně.

Krok 2: čtěte pravidla on-demand, ne název funkce

On Demand je seznam pravidel vyhodnocovaných v pořadí. Každé pravidlo uvádí akci a podmínky, které ho vybírají, a podmínky jsou to zajímavé: typ rozhraní, SSID Wi-Fi, suffix domény DNS nebo URL pro sondu. Sada pravidel, která nikdy nesedí, je funkce, která se nikdy nepřipojí.

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

Přečtěte celé pole a u každého pravidla položte dvě otázky: může tato podmínka na této flotile někdy platit a co se stane, když nesedí žádné pravidlo? Podnikové sítě přejmenovávají přístupové body, slučují SSID a mění suffixy DNS a každá taková úprava tiše odpojí pravidlo od reality.

Podmínka suffixu DNS je na place nejčastěji špatná, protože suffix, který telefon hlásí v hostitelské síti, není ten, který obsluhuje podnikový resolver. Ověřte jméno, které zařízení skutečně překládá, než pravidlu uvěříte.

Krok 3: testujte přechody, ne statické připojení

Tunel, který je zvednutý, zatímco se na něj díváte, dokazuje málo. Proveďte každý přechod záměrně a zaznamenejte, co zařízení dělá, přičemž pokaždé použijte stejný soukromý zdroj, aby byly výsledky srovnatelné:

  • Připojte se k síti, kde by se pravidlo mělo shodovat, vyžádejte soukromý zdroj a potvrďte, že se načte.
  • Přejděte na mobilní síť s aplikací na pozadí, pak ji vraťte dopředu a žádost zopakujte.
  • Připojte se k Wi-Fi s captive portálem a zjistěte, zda je portál dostupný, nebo zda ho vynucení zablokuje dřív, než se stihnete ověřit.
  • Vypněte tunel ručně na sledovaném zařízení a zkontrolujte, zda se sám vrátí a jak rychle.

Proveďte stejný seznam na nesledovaném zařízení, pokud ho máte. Rozdíl mezi oběma výsledky je skutečné chování nasazení a to je část, kterou snímek připojeného tunelu nikdy neukáže.

Krok 4: poznejte dvě podoby selhání

Vynucené pokrytí selhává blokováním. Když tunel nelze navázat, zařízení ztratí běžný přístup k internetu spolu se soukromými zdroji a uživatel má telefon online, ale nemůže prohlížet. Opětovné připojení a blokování jsou oddělená pozorování, proto zaznamenejte obojí, místo abyste absenci internetu brali jako jeden symptom.

On Demand selhává tím, že se nespustí. Pravidlo nesedí, tunel se neobjeví a soukromý zdroj prostě vyprší. Snadno se to chybně diagnostikuje jako problém serveru, protože klient se chová přesně tak, jak je nakonfigurován.

Captive portál stojí mezi nimi: potřebuje připojení dřív, než tunel existuje, takže politika, která blokuje vše do zvednutí tunelu, potřebuje dokumentovanou cestu portálem. Rozhodněte to v návrhu, ne na help desku.

Krok 5: ověřte a potom nacvičte návrat

Ověření patří na skutečnou cestu s neškodným provozem: vyžádejte soukromý zdroj, který nesmí být veřejný, potvrďte, kterou adresu zařízení ukazuje ven, a zopakujte po restartu, abyste viděli startovní sekvenci, ne jen teplý stav.

Potom nacvičte odstranění na testovacím zařízení, než ho budete potřebovat v produkci. Odebrání profilu vrátí zařízení do předchozího stavu a vědět, jak dlouho to trvá a co uživatel uvidí, je součástí runbooku. Bezpečnostní příručka Apple k VPN je referencí k tomu, co platforma o těchto politikách dokumentuje, a vyplatí se ji přečíst před psaním konfigurace, která tvrdí víc než platforma.

Držte tři fakta z prvního kroku vedle sady pravidel a výsledků testů. Když se příště někdo zeptá, proč se telefon v jedné síti připojí a v jiné ne, tyto poznámky odpoví za minutu místo přestavby.

Související články