Always On VPN protiv VPN On Demand na iPhoneu: šta uvesti
On Demand otvara tunel kad se pravila poklope; upravljani Always On održava pokrivenost na nadziranim uređajima. Uputa za izbor i dokazivanje da radi.
Dva iPhonea mogu oba tvrditi da imaju VPN i ponašati se potpuno 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 kada se tunel ne može podići. Birajte pitajući šta mora biti tačno kada korisnik ne uradi ništa, pa testirajte prelaze, a ne stabilno stanje. Koraci ispod idu redom kojim uvođenje zaista pada.
Korak 1: utvrdite šta uređaj može nametnuti
Always On je funkcija 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 sa uređaja, pa potvrdite ko je potpisao profil.
Na telefonu: Postavke, pa Općenito, pa VPN i upravljanje uređajem. Zapis profila navodi svog vlasnika, a ručno instaliran lični profil izgleda drugačije od onog koji dostavlja servis za upravljanje. Ne zaključujte o nametanju iz imena profila ili marketinške oznake dobavljača; oznaka nije politika platforme.
Zapišite tri činjenice prije nego dirnete konfiguraciju: nadziran ili ne, upravljani ili lični profil i koji klijent nosi tunel. Svaki kasniji korak zavisi od tih tri, a prenošenje ponašanja sa ličnog telefona na upravljani profil je način da se uvođenje odobri prema pogrešnoj osnovi.
Korak 2: čitajte on-demand pravila, a ne ime funkcije
On Demand je lista pravila koja se ocjenjuju po redu. Svako pravilo imenuje radnju i uslove koji ga biraju, a uslovi su zanimljivi dio: tip interfejsa, Wi-Fi SSID, DNS sufiks domena ili URL za provjeru. Skup pravila koji se nikad ne poklopi je funkcija 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 uslov ikad biti tačan na ovoj floti i šta se dešava kada nijedno pravilo ne odgovara? Poslovne mreže preimenuju pristupne tačke, spajaju SSID-ove i mijenjaju DNS sufikse, a svaka takva izmjena tiho odvaja pravilo od stvarnosti.
DNS sufiks je uslov 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 resolver. Provjerite ime koje uređaj zaista razrješava prije nego povjerujete pravilu.
Korak 3: testirajte prelaze, a ne statičnu vezu
Tunel koji je podignut dok ga gledate dokazuje malo. Izvedite svaki prelaz namjerno i zabilježite šta uređaj radi, koristeći isti privatni resurs svaki put da rezultati budu uporedivi:
- Povežite se na mrežu gdje pravilo treba da se poklopi, zatim zatražite privatni resurs i potvrdite da se učitava.
- Pređite na mobilnu mrežu s aplikacijom u pozadini, pa je vratite u prvi plan i ponovite zahtjev.
- Povežite se na Wi-Fi sa 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 istu listu na nenadziranom uređaju ako ga imate. Razlika između dva rezultata je stvarno 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 dobija telefon koji je online ali ne može pregledati. Ponovno povezivanje i blokiranje su odvojena opažanja, pa bilježite oba umjesto da odsustvo 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 dijagnostikovati kao problem servera, jer se klijent ponaša tačno kako je konfigurisan.
Captive portal stoji između njih: treba mu veza prije nego tunel postoji, pa politika koja blokira sve dok se tunel ne podigne zahtijeva dokumentovan 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 saobraćajem: 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 šta korisnik vidi dio je runbook-a. Appleov vodič za sigurnost VPN-a referenca je za ono što platforma dokumentuje o ovim 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.