Always On VPN versus VPN On Demand iPhone@APOS@is: mida juurutada

On Demand avab tunnelid, kui reeglid sobivad; hallatav Always On sunnib katvust järelevalvega seadmetes. Juhend valiku tegemiseks ja tõestamiseks, et see töötab.

Kaks iPhone’i võivad mõlemad öelda VPN ja käituda täiesti erinevalt. On Demand avab tunnelid, kui reegel sobib, ja kasutaja saab selle siiski Seadetes välja lülitada. Hallatav Always On hoiab katvust järelevalvega seadmes sunniviisiliselt, ka hetkedel, mil tunnel ei saa püsti tõusta. Valige, küsides, mis peab olema tõsi, kui kasutaja ei tee midagi, ja seejärel testige üleminekuid, mitte püsivat olekut. Allolevad sammud käivad selles järjekorras, milles juurutus tegelikult ebaõnnestub.

Samm 1: tehke kindlaks, mida seade suudab sundida

Always On on järelevalvega seadmete funktsioon. Kui park ei ole järelevalve all, on arutelu enne algust läbi ja ükski payload-võti ei muuda järelevalveta telefoni sunnitud telefoniks. Kinnitage järelevalve halduse poolelt ja seadmest ning seejärel kinnitage, kes profiilile alla kirjutas.

Telefonis: Seaded, seejärel Üldine, seejärel VPN ja seadmehaldus. Profiilikirje nimetab oma omanikku ning käsitsi paigaldatud isiklik profiil näeb teistsugune välja kui haldusteenuse poolt edastatud profiil. Ärge tuletage sundust profiili nimest ega teenusepakkuja turunduslikust sildist; silt ei ole platvormi poliitika.

Kirjutage kolm fakti üles enne konfiguratsiooni puutumist: järelevalve all või mitte, hallatav või isiklik profiil ja milline klient tunnelit kannab. Iga järgnev samm sõltub neist kolmest ning käitumise ülekandmine isiklikust telefonist hallatavasse profiili on viis, kuidas juurutus kinnitatakse vale baasi vastu.

Samm 2: lugege on-demand reegleid, mitte funktsiooni nime

On Demand on järjestikku hinnatavate reeglite loend. Iga reegel nimetab toimingu ja tingimused, mis selle valivad, ning tingimused on huvitav osa: liidese tüüp, Wi-Fi SSID, DNS-domeeni sufiks või sondi URL. Reeglistik, mis kunagi ei sobi, on funktsioon, mis kunagi ei ühendu.

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

Lugege kogu massiiv läbi ja esitage iga reegli kohta kaks küsimust: kas see tingimus saab selles pargis kunagi tõene olla, ja mis juhtub, kui ükski reegel ei sobi? Ettevõtte võrgud nimetavad juurdepääsupunkte ümber, ühendavad SSID-sid ja muudavad DNS-sufikse, ning iga selline muudatus eraldab reegli tegelikkusest vaikselt.

DNS-sufiksi tingimus on see, mis tabamuses kõige sagedamini vale on, sest sufiks, mida telefon külalisvõrgus teatab, ei ole see, mida ettevõtte resolver teenindab. Enne reegli usaldamist kontrollige nime, mille seade tegelikult lahendab.

Samm 3: testige üleminekuid, mitte staatilist ühendust

Tunnel, mis on püsti, kui te seda vaatate, tõestab väga vähe. Viige iga üleminek läbi tahtlikult ja kirjutage üles, mida seade teeb, kasutades iga kord sama privaatset ressurssi, et tulemused oleksid võrreldavad:

  • Ühenduge võrku, kus reegel peaks sobima, seejärel küsige privaatset ressurssi ja kinnitage, et see laaditakse.
  • Lülituge mobiilsidele, kui rakendus on taustal, seejärel tooge see ette ja korrake päringut.
  • Ühenduge captive portal’iga Wi-Fi’ga ja vaadake, kas portaal on kättesaadav või blokeerib sund enne autentimist.
  • Lülitage tunnel järelevalvega seadmes käsitsi välja ja kontrollige, kas see tuleb ise tagasi ja kui kiiresti.

Käivitage sama loend järelevalveta seadmes, kui teil see on. Kahe tulemuse vahe on juurutuse tegelik käitumine ja just seda ei näita kunagi ühendatud tunneli ekraanipilt.

Samm 4: tundke kahte ebaõnnestumise kuju

Sunnitud katvus ebaõnnestub blokeerides. Kui tunnel ei saa püsti, kaotab seade tavalise internetiühenduse koos privaatsete ressurssidega ning kasutaja kogeb telefoni, mis on võrgus, kuid ei saa sirvida. Taasühendumine ja blokeerimine on eraldi vaatlused, seega logige mõlemat, mitte ärge käsitlege interneti puudumist ühe sümptomina.

On Demand ebaõnnestub, jäädes käivitumata. Reegel ei sobi, tunnelit ei ilmu ja privaatne ressurss lihtsalt aegub. Seda on lihtne valesti diagnoosida serveri probleemiks, sest klient käitub täpselt nii, nagu on konfigureeritud.

Captive portal asub kahe vahel: see vajab ühenduvust enne, kui tunnel olemas on, seega poliitika, mis blokeerib kõike kuni tunneli püstitamiseni, vajab dokumenteeritud teed läbi portaali. Otsustage see projekteerimisel, mitte kasutajatoel.

Samm 5: kontrollige ja seejärel harjutage tagasipööramist

Kontrollimine kuulub tegelikule teele ohutu liiklusega: küsige privaatset ressurssi, mis ei tohi olla avalik, kinnitage, millise aadressi seade väljapoole esitab, ja korrake pärast taaskäivitust, et oleksite näinud käivitusjärjestust, mitte ainult sooja olekut.

Seejärel harjutage eemaldamist testseadmes enne, kui seda tootmises vajate. Profiili eemaldamine tagastab seadme eelmisesse olekusse ning teadmine, kui kaua see kestab ja mida kasutaja näeb, on runbooki osa. Apple’i VPN-i turvajuhend on viide sellele, mida platvorm nende poliitikate kohta dokumenteerib, ja seda tasub lugeda enne konfiguratsiooni kirjutamist, mis väidab rohkem kui platvorm.

Hoidke esimese sammu kolm fakti reeglistiku ja testitulemuste kõrval. Kui järgmine inimene küsib, miks telefon ühes võrgus ühendub ja teises mitte, vastavad need märkmed minutiga, selle asemel et kõike uuesti ehitada.

Seotud artiklid