Always On VPN versus VPN On Demand op iPhone: wat om te ontplooi

Twee iPhones kan albei VPN sê en tog heeltemal anders optree. On Demand maak ’n tonnel oop wanneer ’n reël pas, en die gebruiker kan dit steeds in Instellings afskakel. Bestuurde Always On hou dekking afgedwing op ’n toestel onder toesig, ook wanneer die tonnel nie kan opkom nie. Kies deur te vra wat moet geld wanneer die gebruiker niks doen, en toets dan die oorgange eerder as die bestendige toestand. Die stappe hieronder volg die orde waarin ’n ontplooiing werklik misluk.

Stap 1: bepaal wat die toestel kan afdwing

Always On is ’n funksie vir toestelle onder toesig. As die vloot nie onder toesig is nie, is die gesprek verby voordat dit begin, en geen payload-sleutel maak ’n toestel sonder toesig een wat afgedwing word nie. Bevestig toesig by die bestuurkant en by die toestel, en bevestig dan wie die profiel onderteken het.

Op die selfoon: Instellings, dan Algemeen, dan VPN en Toestelbestuur. Die profielinskrywing noem sy eienaar, en ’n persoonlike profiel wat met die hand geïnstalleer is, lyk anders as een wat deur ’n bestuurdienst gelewer is. Moenie afdwinging aflei uit die profiel se naam of uit ’n verskaffer se bemarkingsetiket nie; die etiket is nie die platformbeleid nie.

Skryf drie feite neer voordat jy aan die konfigurasie raak: onder toesig of nie, bestuurde profiel of persoonlike, en watter kliëntimplementering die tonnel dra. Elke latere stap hang van dié drie af, en om gedrag van ’n persoonlike selfoon na ’n bestuurde profiel oor te dra, is hoe ’n ontplooiing teen die verkeerde basislyn goedgekeur word.

Stap 2: lees die on-demand-reëls eerder as die funksienaam

On Demand is ’n lys reëls wat in volgorde geëvalueer word. Elke reël noem ’n aksie en die voorwaardes wat dit kies, en die voorwaardes is die interessante deel: koppelvlaktipe, Wi-Fi-SSID, DNS-domeinagtervoegsel of ’n peil-URL. ’n reëlstel wat nooit pas nie, is ’n funksie wat nooit verbind nie.

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

Lees die hele skikking en vra twee vrae per reël: kan hierdie voorwaarde ooit waar wees op hierdie vloot, en wat gebeur wanneer geen reël pas nie? Ondernemingsnetwerke hernoem toegangspunte, voeg SSID's saam en verander DNS-agtervoegsels, en elkeen van dié wysigings maak ’n reël stilweg los van die werklikheid.

Die DNS-agtervoegsel is die voorwaarde wat die meeste in die veld verkeerd is, want die agtervoegsel wat ’n selfoon op ’n gasnetwerk rapporteer, is nie die agtervoegsel wat die korporatiewe oplosser bedien nie. Verifieer die naam wat die toestel werklik oplos voordat jy die reël vertrou.

Stap 3: toets die oorgange, nie die statiese verbinding nie

’n Tonnel wat op is terwyl jy daarna kyk, bewys baie min. Voer elke oorgang doelbewus uit en teken op wat die toestel doen, met dieselfde private hulpbron elke keer sodat die resultate vergelykbaar is:

• Sluit by ’n netwerk aan waar ’n reël moet pas, vra dan die private hulpbron en bevestig dat dit laai.
• Skakel oor na sellulêr met die app in die agtergrond, bring dit dan na die voorgrond en herhaal die versoek.
• Koppel aan ’n Wi-Fi met ’n vasgevangde portaal en kyk of die portaal bereikbaar is, of of afdwinging dit blokkeer voordat jy kan verifieer.
• Deaktiveer die tonnel met die hand op ’n toestel onder toesig en kyk of dit vanself terugkom, en hoe vinnig.

Voer dieselfde lys op ’n toestel sonder toesig uit as jy een het. Die verskil tussen die twee resultate is die ontplooiing se werklike gedrag, en dit is die deel wat ’n skermkiekie van ’n verbinde tonnel nooit wys nie.

Stap 4: ken die twee mislukkingsvorms

Afgedwonge dekking misluk deur te blokkeer. Wanneer die tonnel nie kan vestig nie, verloor die toestel gewone internettoegang saam met private hulpbronne, en die gebruiker ervaar ’n selfoon wat aanlyn is maar nie kan blaai nie. Herverbinding en blokkering is aparte waarnemings, dus teken albei aan eerder as om geen internet as een simptoom te behandel.

On Demand misluk deur nie te aktiveer nie. Die reël pas nie, geen tonnel verskyn nie, en die private hulpbron wag net tot dit uitty. Dit is maklik om dit verkeerd as ’n bedienerprobleem te diagnoseer, want die kliënt gedra hom presies soos gekonfigureer.

’n Vasgevangde portaal sit tussen die twee: dit het verbinding nodig voordat die tonnel bestaan, so ’n beleid wat alles blokkeer tot die tonnel op is, het ’n gedokumenteerde pad deur die portaal nodig. Besluit dit in die ontwerp, nie by die diensballie nie.

Stap 5: verifieer en oefen dan die terugrol

Verifikasie hoort op die werklike pad met onskadelike verkeer: vra ’n private hulpbron wat nie publiek mag wees nie, bevestig watter adres die toestel na buite aanbied, en herhaal ná ’n herlaai sodat jy die opstartvolgorde gesien het en nie net die warm toestand nie.

Oefen dan die verwydering op ’n toetsapparaat voordat jy dit ooit in produksie nodig het. Om die profiel te verwyder, sit die toestel terug in sy vorige toestand, en om te weet hoe lank dit duur en wat die gebruiker sien, is deel van die runbook. Apple se VPN-veiligheidgids is die verwysing vir wat die platform oor hierdie beleide dokumenteer, en dit is die moeite werd om dit te lees voordat jy ’n konfigurasie skryf wat meer beweer as die platform.

Hou die drie feite van stap een langs die reëlstel en die toetsresultate. Wanneer die volgende persoon vra hoekom ’n selfoon op een netwerk verbind en op ’n ander nie, beantwoord dié notas dit in ’n minuut eerder as ’n herbou.