Always On VPN nasuprot VPN On Demand na iPhoneu: što uvesti

Dva iPhonea mogu oba tvrditi da imaju VPN i ponašati se posve različito. On Demand otvara tunel kad se pravilo poklopi, a korisnik ga ipak može isključiti u Postavkama. Upravljani Always On drži pokrivenost nametnutom na nadziranom uređaju, čak i u trenucima kada se tunel ne može podići. Birajte pitajući što mora biti točno kada korisnik ne učini ništa, pa testirajte prijelaze, a ne stabilno stanje. Koraci ispod idu redom kojim uvođenje doista pada.

Korak 1: utvrdite što uređaj može nametnuti

Always On je značajka za nadzirane uređaje. Ako flota nije nadzirana, rasprava je gotova prije početka i nijedan payload ključ ne pretvara nenadzirani telefon u nametnuti. Potvrdite nadzor sa strane upravljanja i s uređaja, pa potvrdite tko je potpisao profil.

Na telefonu: Postavke, pa Općenito, pa VPN i upravljanje uređajem. Zapis profila navodi svog vlasnika, a ručno instaliran osobni profil izgleda drukčije od onoga koji dostavlja servis za upravljanje. Ne zaključujte o nametanju iz imena profila ni iz marketinške oznake dobavljača; oznaka nije politika platforme.

Zapišite tri činjenice prije nego dirnete konfiguraciju: nadziran ili ne, upravljani ili osobni profil i koji klijent nosi tunel. Svaki kasniji korak zavisi od tih triju, a prenošenje ponašanja s osobnog telefona na upravljani profil je način na koji se uvođenje odobrava prema pogrešnoj osnovi.

Korak 2: čitajte on-demand pravila, a ne ime značajke

On Demand je popis pravila koja se ocjenjuju po redu. Svako pravilo imenuje radnju i uvjete koji ga biraju, a uvjeti su zanimljiv dio: tip sučelja, Wi-Fi SSID, DNS sufiks domene ili URL za provjeru. Skup pravila koji se nikad ne poklopi jest značajka koja se nikad ne povezuje.

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

Pročitajte cijeli niz i postavite dva pitanja po pravilu: može li ovaj uvjet ikad biti točan na ovoj floti i što se događa kada nijedno pravilo ne odgovara? Poslovne mreže preimenuju pristupne točke, spajaju SSID-ove i mijenjaju DNS sufikse, a svaka takva izmjena tiho odvaja pravilo od stvarnosti.

DNS sufiks je uvjet koji se na terenu najčešće pogrešno postavi, jer sufiks koji telefon prijavi na gostujućoj mreži nije onaj koji opslužuje korporativni razrješivač. Provjerite ime koje uređaj doista razrješava prije nego povjerujete pravilu.

Korak 3: testirajte prijelaze, a ne statičnu vezu

Tunel koji je podignut dok ga gledate dokazuje malo. Izvedite svaki prijelaz namjerno i zabilježite što uređaj radi, koristeći isti privatni resurs svaki put da rezultati budu usporedivi:

• Povežite se na mrežu gdje bi se pravilo trebalo poklopiti, zatim zatražite privatni resurs i potvrdite da se učitava.
• Prijeđite na mobilnu mrežu s aplikacijom u pozadini, pa je vratite u prvi plan i ponovite zahtjev.
• Povežite se na Wi-Fi s captive portalom i vidite je li portal dostupan ili ga nametanje blokira prije autentifikacije.
• Isključite tunel ručno na nadziranom uređaju i provjerite vraća li se sam i koliko brzo.

Izvedite isti popis na nenadziranom uređaju ako ga imate. Razlika između dvaju rezultata stvarno je ponašanje uvođenja i to je dio koji snimka povezanog tunela nikad ne pokaže.

Korak 4: upoznajte dva oblika kvara

Nametnuta pokrivenost pada blokiranjem. Kada se tunel ne uspostavi, uređaj gubi uobičajen pristup internetu zajedno s privatnim resursima, a korisnik dobije telefon koji je online ali ne može pregledavati. Ponovno povezivanje i blokiranje odvojena su opažanja, pa bilježite oboje umjesto da odsutnost interneta tretirate kao jedan simptom.

On Demand pada tako što se ne aktivira. Pravilo se ne poklopi, tunel se ne pojavi, a privatni resurs jednostavno istekne. Lako je to pogrešno dijagnosticirati kao problem poslužitelja, jer se klijent ponaša točno kako je konfiguriran.

Captive portal stoji između njih: treba mu veza prije nego tunel postoji, pa politika koja blokira sve dok se tunel ne podigne zahtijeva dokumentiran put kroz portal. Odlučite to u dizajnu, ne na servisnom stolu.

Korak 5: provjerite, pa uvježbajte vraćanje

Provjera pripada stvarnom putu s bezopasnim prometom: zatražite privatni resurs koji ne smije biti javan, potvrdite koju adresu uređaj predstavlja prema van i ponovite nakon restarta da vidite redoslijed pokretanja, a ne samo toplo stanje.

Zatim uvježbajte uklanjanje na testnom uređaju prije nego vam zatreba u produkciji. Uklanjanje profila vraća uređaj u prethodno stanje, a znati koliko traje i što korisnik vidi dio je runbooka. Appleov vodič za sigurnost VPN-a referenca je za ono što platforma dokumentira o tim politikama i vrijedi ga pročitati prije pisanja konfiguracije koja tvrdi više od platforme.

Držite tri činjenice iz prvog koraka uz skup pravila i rezultate testova. Kada sljedeća osoba pita zašto se telefon povezuje na jednoj mreži a na drugoj ne, te bilješke odgovaraju za minutu umjesto ponovne izgradnje.