Always On VPN vagy VPN On Demand iPhone-on: mit telepítsünk

Két iPhone egyaránt mondhatja, hogy VPN, és mégis teljesen másképp viselkedhet. Az On Demand akkor nyit alagutat, amikor egy szabály illeszkedik, és a felhasználó a Beállításokban továbbra is kikapcsolhatja. A felügyelt Always On a felügyelt eszközön kikényszerítve tartja a lefedettséget, azokban a pillanatokban is, amikor az alagút nem tud feljönni. Válasszon úgy, hogy megkérdezi, mi kell igaz legyen, amikor a felhasználó semmit sem tesz, majd az átmeneteket tesztelje, ne az állandósult állapotot. Az alábbi lépések abban a sorrendben haladnak, ahogy egy bevezetés valóban elakad.

1. lépés: állapítsa meg, mit tud az eszköz kikényszeríteni

Az Always On felügyelt eszközök funkciója. Ha a flotta nincs felügyelet alatt, a vita a kezdete előtt véget ér, és egyetlen payload-kulcs sem tesz egy nem felügyelt telefont kikényszerítetté. Erősítse meg a felügyeletet a menedzsment oldaláról és az eszközről, majd erősítse meg, ki írta alá a profilt.

A telefonon: Beállítások, majd Általános, majd VPN és eszközkezelés. A profilbejegyzés megnevezi a tulajdonosát, és a kézzel telepített személyes profil másképp néz ki, mint a kezelőszolgáltatás által szállított. Ne következtessen a kikényszerítésre a profil nevéből vagy egy szolgáltató marketingcímkéjéből; a címke nem a platform szabályzata.

Jegyezzen fel három tényt, mielőtt hozzányúl a konfigurációhoz: felügyelt-e vagy sem, kezelt vagy személyes profil, és melyik kliens hordozza az alagutat. Minden későbbi lépés e háromtól függ, és a viselkedés személyes telefonról kezelt profilra való átvitele az az út, amelyen egy bevezetést rossz alaphoz igazítva hagynak jóvá.

2. lépés: az on-demand szabályokat olvassa, ne a funkció nevét

Az On Demand sorrendben kiértékelt szabályok listája. Minden szabály megnevez egy műveletet és a kiválasztó feltételeket, és a feltételek az érdekes rész: interfésztípus, Wi-Fi SSID, DNS-tartomány utótag vagy próba-URL. Egy soha nem illeszkedő szabálykészlet olyan funkció, amely soha nem csatlakozik.

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

Olvassa el az egész tömböt, és tegyen fel két kérdést minden szabálynál: lehet-e ez a feltétel valaha igaz ezen a flottán, és mi történik, ha egyetlen szabály sem illeszkedik? A vállalati hálózatok átnevezik a hozzáférési pontokat, összevonják az SSID-ket és módosítják a DNS-utótagokat, és mindegyik szerkesztés csendesen elszakít egy szabályt a valóságtól.

A DNS-utótag feltétele hibás leggyakrabban a terepen, mert a telefon által a vendéghálózaton jelentett utótag nem az, amelyet a vállalati feloldó kiszolgál. Ellenőrizze a nevet, amelyet az eszköz valóban felold, mielőtt megbízik a szabályban.

3. lépés: az átmeneteket tesztelje, ne a statikus kapcsolatot

Egy alagút, amely áll, miközben nézi, nagyon keveset bizonyít. Hajtsa végre minden átmenetet szándékosan, és jegyezze fel, mit tesz az eszköz, minden alkalommal ugyanazt a privát erőforrást használva, hogy az eredmények összehasonlíthatók legyenek:

• Csatlakozzon olyan hálózathoz, ahol egy szabálynak illeszkednie kell, majd kérje a privát erőforrást, és erősítse meg, hogy betöltődik.
• Váltson mobilhálózatra úgy, hogy az alkalmazás a háttérben van, majd hozza előre, és ismételje meg a kérést.
• Csatlakozzon captive portállal rendelkező Wi-Fi-hez, és nézze meg, elérhető-e a portál, vagy a kikényszerítés blokkolja-e még az azonosítás előtt.
• Kapcsolja ki az alagutat kézzel egy felügyelt eszközön, és ellenőrizze, magától visszatér-e, és milyen gyorsan.

Futtassa ugyanezt a listát egy nem felügyelt eszközön, ha van. A két eredmény közötti különbség a bevezetés valódi viselkedése, és ezt soha nem mutatja meg egy csatlakozott alagútról készült képernyőkép.

4. lépés: ismerje a két hibaformát

A kikényszerített lefedettség blokkolással hibázik. Amikor az alagút nem jön létre, az eszköz elveszíti a szokásos internethozzáférést a privát erőforrásokkal együtt, és a felhasználó egy online telefont tapasztal, amellyel nem lehet böngészni. Az újracsatlakozás és a blokkolás külön megfigyelés, ezért naplózza mindkettőt, ne kezelje az internet hiányát egyetlen tünetként.

Az On Demand azzal hibázik, hogy nem indul el. A szabály nem illeszkedik, nem jelenik meg alagút, és a privát erőforrás egyszerűen lejár. Könnyű ezt szerverproblémaként félrediagnosztizálni, mert a kliens pontosan úgy viselkedik, ahogy be van állítva.

A captive portal a kettő között áll: kapcsolatra van szüksége, mielőtt az alagút létezik, ezért egy mindent blokkoló szabályzatnak, amíg az alagút fel nem jön, dokumentált útvonalra van szüksége a portálon át. Ezt a tervezésben döntse el, nem a segélyszolgálatnál.

5. lépés: ellenőrizze, majd gyakorolja a visszaállást

Az ellenőrzés a valódi útvonalon, ártalmatlan forgalommal történik: kérjen olyan privát erőforrást, amely nem lehet nyilvános, erősítse meg, milyen címet mutat az eszköz kifelé, és ismételje meg újraindítás után, hogy lássa az indítási sorrendet, ne csak a meleg állapotot.

Utána gyakorolja az eltávolítást egy teszteszközön, mielőtt élesben szükség lenne rá. A profil eltávolítása visszaállítja az eszközt a korábbi állapotába, és tudni, mennyi ideig tart, és mit lát a felhasználó, a runbook része. Az Apple VPN biztonsági útmutatója a hivatkozás arra, amit a platform ezekről a szabályzatokról dokumentál, és érdemes elolvasni, mielőtt olyan konfigurációt ír, amely többet állít a platformnál.

Tartsa az első lépés három tényét a szabálykészlet és a teszteredmények mellett. Amikor a következő ember azt kérdezi, miért csatlakozik egy telefon az egyik hálózaton és nem a másikon, ezek a jegyzetek egy perc alatt válaszolnak újraépítés helyett.