Always On VPN edo VPN On Demand iPhonean: zer ezarri

On Demandek tunela irekitzen du bere arauek bat egiten dutenean; kudeatutako Always One estaldura derrigortzen du gainbegiratutako gailuetan. Bat aukeratzeko eta funtzionatzen duela frogatzeko gida.

Bi iPhonek VPN esan dezakete eta erabat desberdin jokatu. On Demandek tunela irekitzen du arau bat betetzean, eta erabiltzaileak oraindik itzal dezake Ezarpenetan. Kudeatutako Always One estaldura derrigortuta mantentzen du gainbegiratutako gailuan, tunela igo ezin den uneetan ere. Aukeratu erabiltzaileak ezer egiten ez duenean zer izan behar duen egiazkoa galdetuz, eta ondoren probatu trantsizioak eta ez egoera egonkorra. Beheko urratsak zabalkunde bat benetan huts egiten duen ordenan doaz.

1. urratsa: zehaztu gailuak zer derrigor dezakeen

Always On gainbegiratutako gailuetarako funtzioa da. Flota gainbegiratuta ez badago, solasaldia hasi aurretik amaitzen da, eta payload gako batek ere ez du gainbegiratu gabeko telefonoa derrigortutako bihurtzen. Berretsi gainbegiratzea kudeaketaren aldetik eta gailutik, eta gero berretsi nork sinatu zuen profila.

Telefonoan: Ezarpenak, gero Orokorra, gero VPN eta Gailuaren kudeaketa. Profilaren sarrerak jabea izendatzen du, eta eskuz instalatutako profil pertsonala kudeaketa zerbitzu batek emandakoaren desberdina da. Ez ondoriozta ezazu derrigortasunik profilaren izenetik edo hornitzaile baten marketin etiketatik; etiketa ez da plataformaren politika.

Idatzi hiru datu konfigurazioa ukitu aurretik: gainbegiratuta edo ez, profil kudeatua edo pertsonala, eta zein bezero daraman tunela. Ondoko urrats bakoitza hiru horien mende dago, eta telefono pertsonal baten jokabidea profil kudeatura eramatea da zabalkundea oinarri oker baten aurka onartzeko bidea.

2. urratsa: irakurri on-demand arauak, ez funtzioaren izena

On Demand ordenan ebaluatutako arauen zerrenda da. Arau bakoitzak ekintza bat eta hura hautatzen duten baldintzak izendatzen ditu, eta baldintzak dira interesgarriena: interfaze mota, Wi-Fi SSIDa, DNS domeinu atzizkia edo proba URL bat. Inoiz bat egiten ez duen arau multzoa inoiz konektatzen ez den funtzioa da.

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

Irakurri matrize osoa eta egin bi galdera arau bakoitzeko: izan al daiteke baldintza hori inoiz egiazkoa flota honetan, eta zer gertatzen da araurik bat egiten ez denean? Enpresen sareek sarbide puntuak berrizendatzen dituzte, SSIDak batzen eta DNS atzizkiak aldatzen, eta aldaketa horietako bakoitzak araua errealitatetik isilka bereizten du.

DNS atzizkiaren baldintza da eremuan gehien huts egiten duena, gonbidatu sarean telefono batek ematen duen atzizkia ez baita enpresaren ebazleak zerbitzatzen duena. Egiaztatu gailuak benetan ebazten duen izena arauan fidatu aurretik.

3. urratsa: probatu trantsizioak, ez konexio estatikoa

Begira zauden bitartean altxatuta dagoen tunel batek gutxi frogatzen du. Exekutatu trantsizio bakoitza nahita eta idatzi gailuak zer egiten duen, beti baliabide pribatu bera erabiliz emaitzak konparagarriak izan daitezen:

  • Sartu arau batek bat egin behar lukeen sarean, gero eskatu baliabide pribatua eta berretsi kargatzen dela.
  • Aldatu sare mugikorrera aplikazioa atzealdean dagoela, gero ekarri aurrera eta errepikatu eskaera.
  • Konektatu captive portal bat duen Wi-Fira eta ikusi portala irisgarria den edo derrigortasunak blokeatzen duen autentifikatu aurretik.
  • Desaktibatu tunela eskuz gainbegiratutako gailuan eta egiaztatu bere kabuz itzultzen den eta zenbat azkar.

Exekutatu zerrenda bera gainbegiratu gabeko gailuan, bat baduzu. Bi emaitzen arteko aldea zabalkundearen benetako jokabidea da, eta hori da konektatutako tunel baten argazkiak inoiz erakusten ez duena.

4. urratsa: ezagutu hutsegite forma biak

Estaldura derrigortuak blokeatuz huts egiten du. Tunela ezartzen ez denean, gailuak ohiko internet sarbidea galtzen du baliabide pribatuekin batera, eta erabiltzaileak linean dagoen baina nabiga ezin duen telefonoa bizi du. Birkonexioa eta blokeoa behaketa bereiziak dira, beraz erregistratu biak, internetik eza sintoma bakartzat hartu beharrean.

On Demandek ez abiaraziz huts egiten du. Arauak ez du bat egiten, tunelik ez da agertzen, eta baliabide pribatuak iraungitzen du. Erraza da zerbitzariaren arazo gisa gaizki diagnostikatzea, bezeroak konfiguratuta dagoen bezala jokatzen baitu.

Captive portal bat bien artean dago: konektibitatea behar du tunela existitu aurretik, beraz tunela igo arte guztia blokeatzen duen politikak bide dokumentatua behar du portaletik. Erabaki hori diseinuan, ez laguntza mahaian.

5. urratsa: egiaztatu eta gero entseatu atzera egitea

Egiaztapena benetako bidean egiten da trafiko eraginik gabearekin: eskatu publikoa izan behar ez duen baliabide pribatu bat, berretsi gailuak kanpora zein helbide aurkezten duen, eta errepikatu berrabiarazten ondoren abiarazte segida ikusi duzula eta ez soilik egoera epela.

Gero entseatu kentzea proba gailuan, produkzioan behar izan aurretik. Profila kentzeak gailua aurreko egoerara itzultzen du, eta zenbat irauten duen eta erabiltzaileak zer ikusten duen jakitea runbookaren parte da. Apple-en VPN segurtasun gidak plataformak politika hauei buruz dokumentatzen duenaren erreferentzia da, eta merezi du irakurtzea plataformak baino gehiago dioen konfigurazio bat idatzi aurretik.

Eduki lehen urratseko hiru datuak arau multzoaren eta proben emaitzen ondoan. Hurrengo pertsonak zergatik konektatzen duen telefono batek sare batean eta ez bestean galdetzen duenean, ohar horiek minutu batean erantzuten dute berreraiki beharrean.

Erlazionatutako artikuluak