Always On VPN prieš VPN On Demand iPhone telefone: ką diegti

On Demand atidaro tunelį, kai sutampa jo taisyklės; valdomas Always On primeta padengimą prižiūrimuose įrenginiuose. Vadovas, kaip pasirinkti ir įrodyti, kad tai veikia.

Du iPhone gali abu sakyti VPN ir elgtis visiškai skirtingai. On Demand atidaro tunelį, kai sutampa taisyklė, o naudotojas vis tiek gali jį išjungti Nustatymuose. Valdomas Always On palaiko padengimą priverstinai prižiūrimame įrenginyje, net tais momentais, kai tunelis negali pakilti. Rinkitės klausdami, kas turi būti tiesa, kai naudotojas nieko nedaro, o tada tikrinkite perėjimus, o ne pastovią būseną. Toliau pateikti žingsniai eina ta tvarka, kuria diegimas iš tikrųjų žlunga.

1 žingsnis: nustatykite, ką įrenginys gali primesti

Always On yra prižiūrimų įrenginių funkcija. Jei parkas nėra prižiūrimas, pokalbis baigiasi prieš prasidedant, ir joks payload raktas nepaverčia neprižiūrimo telefono priverstiniu. Patvirtinkite priežiūrą iš valdymo pusės ir iš įrenginio, tada patvirtinkite, kas pasirašė profilį.

Telefone: Nustatymai, tada Bendra, tada VPN ir įrenginio valdymas. Profilio įrašas nurodo savininką, o rankiniu būdu įdiegtas asmeninis profilis atrodo kitaip nei valdymo tarnybos pateiktas. Nedarukite primetimo iš profilio pavadinimo ar tiekėjo rinkodaros etiketės; etiketė nėra platformos politika.

Užrašykite tris faktus prieš liesdami konfigūraciją: prižiūrimas ar ne, valdomas ar asmeninis profilis ir kuris klientas neša tunelį. Kiekvienas vėlesnis žingsnis priklauso nuo šių trijų, o elgsenos perkėlimas iš asmeninio telefono į valdomą profilį yra būdas patvirtinti diegimą pagal neteisingą bazę.

2 žingsnis: skaitykite on-demand taisykles, o ne funkcijos pavadinimą

On Demand yra eilės tvarka vertinamų taisyklių sąrašas. Kiekviena taisyklė nurodo veiksmą ir sąlygas, kurios ją parenka, o sąlygos yra įdomioji dalis: sąsajos tipas, Wi-Fi SSID, DNS domeno priesaga arba patikros URL. Taisyklių rinkinys, kuris niekada nesutampa, yra funkcija, kuri niekada neprisijungia.

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

Perskaitykite visą masyvą ir užduokite du klausimus kiekvienai taisyklei: ar ši sąlyga kada nors gali būti teisinga šiame parke, ir kas atsitinka, kai nesutampa nė viena taisyklė? Įmonių tinklai pervadina prieigos taškus, sujungia SSID ir keičia DNS priesagas, ir kiekvienas toks pakeitimas tyliai atskiria taisyklę nuo tikrovės.

DNS priesagos sąlyga lauke klystama dažniausiai, nes priesaga, kurią telefonas praneša svečio tinkle, nėra ta, kurią aptarnauja įmonės sprendėjas. Patikrinkite vardą, kurį įrenginys iš tikrųjų išsprendžia, prieš pasitikėdami taisykle.

3 žingsnis: tikrinkite perėjimus, o ne statinį ryšį

Tunelis, kuris stovi, kol jį stebite, įrodo labai mažai. Atlikite kiekvieną perėjimą sąmoningai ir užrašykite, ką daro įrenginys, kiekvieną kartą naudodami tą patį privatų išteklių, kad rezultatus būtų galima palyginti:

  • Prisijunkite prie tinklo, kuriame taisyklė turėtų sutapti, tada paprašykite privataus ištekliaus ir patvirtinkite, kad jis įkeliamas.
  • Pereikite prie korinio ryšio, kai programėlė fone, tada iškėlę ją į priekį pakartokite užklausą.
  • Prisijunkite prie Wi-Fi su captive portal ir pažiūrėkite, ar portalas pasiekiamas, ar primetimas jį blokuoja prieš autentifikaciją.
  • Išjunkite tunelį rankiniu būdu prižiūrimame įrenginyje ir patikrinkite, ar jis grįžta pats, ir kaip greitai.

Atlikite tą patį sąrašą neprižiūrimame įrenginyje, jei tokį turite. Skirtumas tarp dviejų rezultatų yra tikroji diegimo elgsena, ir to niekada neparodo prisijungusio tunelio ekrano nuotrauka.

4 žingsnis: pažinkite dvi nesėkmės formas

Priverstinis padengimas žlunga blokuodamas. Kai tunelis neužmezgamas, įrenginys praranda įprastą interneto prieigą kartu su privačiais ištekliais, o naudotojas patiria telefoną, kuris yra internete, bet negali naršyti. Prisijungimas iš naujo ir blokavimas yra atskiri stebėjimai, todėl registruokite abu, o ne traktuokite interneto nebuvimą kaip vieną simptomą.

On Demand žlunga neįsijungdamas. Taisyklė nesutampa, tunelis nepasirodo, o privatus išteklius tiesiog baigiasi. Tai lengva klaidingai diagnozuoti kaip serverio problemą, nes klientas elgiasi tiksliai taip, kaip sukonfigūruotas.

Captive portal yra tarp jų: jam reikia ryšio prieš atsirandant tuneliui, todėl politikai, kuri blokuoja viską, kol tunelis pakils, reikia dokumentuoto kelio per portalą. Nuspręskite tai projektavimo metu, o ne pagalbos skyriuje.

5 žingsnis: patikrinkite, tada išbandykite grąžinimą

Tikrinimas atliekamas tikrame kelyje su nekenksmingu srautu: paprašykite privataus ištekliaus, kuris neturi būti viešas, patvirtinkite, kokį adresą įrenginys pateikia į išorę, ir pakartokite po perkrovimo, kad matytumėte paleidimo seką, o ne tik šiltą būseną.

Tada išbandykite pašalinimą bandomajame įrenginyje, prieš prireikiant produkcijoje. Profilio pašalinimas grąžina įrenginį į ankstesnę būseną, o žinojimas, kiek tai trunka ir ką mato naudotojas, yra runbook dalis. Apple VPN saugumo vadovas yra nuoroda, ką platforma dokumentuoja apie šias politikas, ir verta jį perskaityti prieš rašant konfigūraciją, kuri teigia daugiau nei platforma.

Laikykite tris pirmo žingsnio faktus šalia taisyklių rinkinio ir bandymų rezultatų. Kai kitas žmogus paklaus, kodėl telefonas prisijungia viename tinkle, o kitame ne, šios pastabos atsako per minutę, o ne perstatant.

Susiję straipsniai