Always On VPN protiv VPN On Demand na iPhoneu: šta rasporediti

Dva iPhonea mogu oba pisati VPN i ponašati se potpuno različito. On Demand otvara tunel kada se poklopi pravilo, a korisnik ga i dalje može isključiti u Postavkama. Upravljani Always On održava pokrivenost na nadziranom uređaju, uključujući trenutke kada se tunel ne može uspostaviti. Odaberite tako što ćete pitati šta mora biti istina kada korisnik ne uradi ništa, a zatim testirajte prelaze, a ne stabilno stanje. Koraci ispod idu redom kojim se raspoređivanje zaista kvari.

Korak 1: utvrdite šta uređaj može da sprovede

Always On je funkcija nadziranog uređaja. Ako flota nije nadzirana, rasprava je završena prije nego što počne i nijedan ključ u payloadu ne pretvara nenadzirani telefon u prinudni. Potvrdite nadzor sa strane upravljanja i sa samog uređaja, a zatim potvrdite ko je potpisao profil.

Na telefonu otvorite Postavke, zatim Opšte, pa VPN i upravljanje uređajem. Stavka profila navodi svog vlasnika, a ručno instaliran lični profil izgleda drugačije od onog koji isporučuje servis za upravljanje. Ne zaključujte o prinudi iz naziva profila ili iz marketinške oznake provajdera; oznaka nije politika platforme.

Zapišite tri činjenice prije nego što dodirnete konfiguraciju: nadziran ili ne, upravljani profil ili lični, i koja implementacija klijenta nosi tunel. Svaki kasniji korak zavisi od te tri, a prenošenje ponašanja sa ličnog telefona na upravljani profil je način na koji se raspoređivanje potpisuje prema pogrešnoj osnovi.

Korak 2: čitajte pravila on-demand, a ne naziv funkcije

On Demand je lista pravila koja se ocjenjuju po redu. Svako pravilo navodi akciju i uslove koji ga biraju, a uslovi su zanimljiv dio: tip interfejsa, Wi-Fi SSID, DNS sufiks domena ili probni URL. Skup pravila koji se nikada ne poklopi je funkcija koja se nikada 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 pitajte dva pitanja po pravilu: može li ovaj uslov ikada biti istinit na ovoj floti i šta se dešava kada se nijedno pravilo ne poklopi? Korporativne mreže preimenuju pristupne tačke, spajaju SSID-ove i mijenjaju DNS sufikse, a svaka od tih izmjena tiho odvaja pravilo od stvarnosti.

Uslov DNS sufiksa je onaj koji je najčešće pogrešan na terenu, jer sufiks koji telefon prijavi na gostujućoj mreži nije sufiks koji servira korporativni resolver. Provjerite ime koje uređaj zaista razrješava prije nego što se pouzdate u pravilo.

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

Tunel koji je aktivan dok ga gledate dokazuje vrlo malo. Izvedite svaki prelaz namjerno i zabilježite šta uređaj radi, koristeći isti privatni resurs svaki put da bi rezultati bili uporedivi:

• Povežite se na mrežu gdje bi pravilo trebalo da se poklopi, zatim zatražite privatni resurs i potvrdite da se učitava.
• Pređite na mobilnu mrežu sa aplikacijom u pozadini, zatim je vratite u prvi plan i ponovite zahtjev.
• Povežite se na Wi-Fi sa captive portalom i vidite da li je portal dostupan ili prinuda blokira sve prije nego što se možete autentifikovati.
• Ručno isključite tunel na nadziranom uređaju i provjerite da li se sam vraća i koliko brzo.

Pokrenite istu listu na nenadziranom uređaju ako ga imate. Razlika između dva rezultata je stvarno ponašanje raspoređivanja i to je dio koji snimak ekrana povezanog tunela nikada ne pokaže.

Korak 4: poznajte dva oblika kvara

Prinudna pokrivenost pada tako što blokira. Kada tunel ne može da se uspostavi, uređaj gubi običan internet pristup zajedno sa privatnim resursima, a korisnik doživljava telefon koji je online ali ne može da pretražuje. Ponovno povezivanje i blokiranje su odvojena zapažanja, pa zabilježite oba umjesto da tretirate nema interneta kao jedan simptom.

On Demand pada tako što se ne aktivira. Pravilo se ne poklopi, tunel se ne pojavi, a privatni resurs jednostavno istekne. Ovo je lako pogrešno dijagnostikovati kao problem servera, jer se klijent ponaša tačno onako kako je konfigurisan.

Captive portal stoji između dva slučaja: potrebna mu je povezanost prije nego što tunel postoji, pa politika koja blokira sve dok tunel ne bude aktivan treba dokumentovan put kroz portal. To odlučite u dizajnu, a ne na help desku.

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

Provjera pripada stvarnoj putanji sa bezopasnim saobraćajem: zatražite privatni resurs koji ne smije biti javan, potvrdite koju adresu uređaj predstavlja spolja i ponovite nakon restarta da biste vidjeli sekvencu pokretanja, a ne samo toplo stanje.

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

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 ne na drugoj, te bilješke odgovore za minut umjesto ponovne izgradnje.