Always On VPN pret VPN On Demand iPhone tālrunī: ko ieviest

Divas iPhone var abas teikt VPN un tomēr uzvesties pilnīgi atšķirīgi. On Demand atver tuneli, kad sakrīt noteikums, un lietotājs joprojām var to izslēgt Iestatījumos. Pārvaldītais Always On uztur pārklājumu piespiedu kārtā uzraudzītā ierīcē, arī brīžos, kad tunelis nevar pacelties. Izvēlieties, jautājot, kam jābūt patiesam, kad lietotājs neko nedara, un pēc tam pārbaudiet pārejas, nevis stabilo stāvokli. Tālāk minētie soļi iet tādā secībā, kādā ieviešana patiešām sabrūk.

1. solis: nosakiet, ko ierīce var uzspiest

Always On ir uzraudzītu ierīču funkcija. Ja parks nav uzraudzīts, saruna beidzas pirms tās sākuma, un neviena payload atslēga nepadara neuzraudzītu tālruni par uzspiestu. Apstipriniet uzraudzību gan pārvaldības pusē, gan ierīcē, un pēc tam apstipriniet, kas parakstīja profilu.

Tālrunī: Iestatījumi, tad Vispārīgi, tad VPN un ierīces pārvaldība. Profila ieraksts nosauc tā īpašnieku, un manuāli instalēts personīgais profils izskatās citādi nekā pārvaldības pakalpojuma piegādātais. Neizseciniet uzspiešanu no profila nosaukuma vai pakalpojumu sniedzēja mārketinga etiķetes; etiķete nav platformas politika.

Pierakstiet trīs faktus pirms konfigurācijas aizskaršanas: uzraudzīts vai nē, pārvaldīts vai personīgais profils, un kurš klients nes tuneli. Katrs nākamais solis ir atkarīgs no šiem trim, un uzvedības pārnese no personīgā tālruņa uz pārvaldītu profilu ir veids, kā ieviešanu apstiprina pret nepareizu bāzi.

2. solis: lasiet on-demand noteikumus, nevis funkcijas nosaukumu

On Demand ir secīgi vērtētu noteikumu saraksts. Katrs noteikums nosauc darbību un nosacījumus, kas to izvēlas, un nosacījumi ir interesantā daļa: saskarnes tips, Wi-Fi SSID, DNS domēna sufikss vai pārbaudes URL. Noteikumu kopa, kas nekad nesakrīt, ir funkcija, kas nekad nepievienojas.

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

Izlasiet visu masīvu un uzdodiet divus jautājumus par katru noteikumu: vai šis nosacījums kādreiz var būt patiess šajā parkā, un kas notiek, kad nesakrīt neviens noteikums? Uzņēmumu tīkli pārdēvē piekļuves punktus, apvieno SSID un maina DNS sufiksus, un katra šāda izmaiņa klusi atdala noteikumu no realitātes.

DNS sufika nosacījums laukā visbiežāk ir nepareizs, jo sufikss, ko tālrunis ziņo viesu tīklā, nav tas, ko apkalpo uzņēmuma risinātājs. Pirms uzticaties noteikumam, pārbaudiet nosaukumu, ko ierīce patiešām atrisina.

3. solis: pārbaudiet pārejas, nevis statisko savienojumu

Tunelis, kas ir pacelts, kamēr jūs uz to skatāties, pierāda ļoti maz. Veiciet katru pāreju apzināti un pierakstiet, ko ierīce dara, katru reizi izmantojot to pašu privāto resursu, lai rezultātus varētu salīdzināt:

• Pievienojieties tīklam, kur noteikumam būtu jāsakrīt, pēc tam pieprasiet privāto resursu un apstipriniet, ka tas ielādējas.
• Pārslēdzieties uz mobilo tīklu, lietotnei atrodoties fonā, pēc tam izceliet to priekšplānā un atkārtojiet pieprasījumu.
• Pievienojieties Wi-Fi ar captive portal un skatiet, vai portāls ir sasniedzams vai uzspiešana to bloķē pirms autentifikācijas.
• Izslēdziet tuneli manuāli uzraudzītā ierīcē un pārbaudiet, vai tas atgriežas pats un cik ātri.

Veiciet to pašu sarakstu neuzraudzītā ierīcē, ja tāda ir. Atšķirība starp abiem rezultātiem ir īstā ieviešanas uzvedība, un to nekad neparāda pievienota tuneļa ekrānuzņēmums.

4. solis: pazīstiet divas kļūmes formas

Uzspiests pārklājums sabrūk bloķējot. Kad tunelis neizveidojas, ierīce zaudē parasto interneta piekļuvi kopā ar privātajiem resursiem, un lietotājs piedzīvo tālruni, kas ir tiešsaistē, bet nevar pārlūkot. Atkārtota pievienošanās un bloķēšana ir atsevišķi novērojumi, tāpēc reģistrējiet abus, nevis uzskatiet interneta trūkumu par vienu simptomu.

On Demand sabrūk neiedarbojoties. Noteikums nesakrīt, tunelis neparādās, un privātais resurs vienkārši beidzas. To ir viegli nepareizi diagnosticēt kā servera problēmu, jo klients uzvedas tieši tā, kā konfigurēts.

Captive portal atrodas starp abiem: tam vajadzīgs savienojums pirms tuneļa pastāvēšanas, tāpēc politikai, kas bloķē visu, līdz tunelis paceļas, vajadzīgs dokumentēts ceļš caur portālu. Izlemiet to projektā, nevis palīdzības dienestā.

5. solis: pārbaudiet un pēc tam trenējiet atritināšanu

Pārbaude notiek uz īstā ceļa ar nekaitīgu satiksmi: pieprasiet privāto resursu, kam nevajadzētu būt publiskam, apstipriniet, kādu adresi ierīce uzrāda uz āru, un atkārtojiet pēc pārstartēšanas, lai būtu redzēta starta secība, ne tikai siltais stāvoklis.

Pēc tam trenējiet noņemšanu testa ierīcē, pirms tā nepieciešama ražošanā. Profila noņemšana atgriež ierīci iepriekšējā stāvoklī, un zināšana, cik ilgi tas prasa un ko lietotājs redz, ir runbook daļa. Apple VPN drošības rokasgrāmata ir atsauce uz to, ko platforma dokumentē par šīm politikām, un to ir vērts izlasīt pirms konfigurācijas rakstīšanas, kas apgalvo vairāk nekā platforma.

Turiet trīs pirmā soļa faktus blakus noteikumu kopai un testu rezultātiem. Kad nākamais cilvēks jautās, kāpēc tālrunis pieslēdzas vienā tīklā un ne otrā, šīs piezīmes atbild minūtes laikā, nevis pārbūvējot.