Always On VPN versus VPN On Demand op iPhone: wat je moet uitrollen

Twee iPhones kunnen allebei VPN zeggen en zich totaal verschillend gedragen. On Demand opent een tunnel zodra een regel klopt, en de gebruiker kan hem nog steeds uitzetten in Instellingen. Beheerde Always On houdt de dekking afgedwongen op een gecontroleerd apparaat, ook op de momenten dat de tunnel niet omhoog komt. Kies door te vragen wat waar moet zijn wanneer de gebruiker niets doet, en test daarna de overgangen in plaats van de stabiele toestand. De stappen hieronder volgen de volgorde waarin een uitrol echt mislukt.

Stap 1: bepaal wat het apparaat kan afdwingen

Always On is een functie voor gecontroleerde apparaten. Is de vloot niet gecontroleerd, dan is de discussie voorbij voordat hij begint, en geen enkele payload-sleutel maakt van een niet-gecontroleerde telefoon een afgedwongen exemplaar. Bevestig de controle aan de beheerkant en vanaf het apparaat, en bevestig dan wie het profiel heeft ondertekend.

Op de telefoon: Instellingen, dan Algemeen, dan VPN en Apparaatbeheer. De profielregel noemt de eigenaar, en een handmatig geïnstalleerd persoonlijk profiel ziet er anders uit dan een dat een beheerdienst levert. Leid de afdwinging niet af uit de naam van het profiel of uit een marketinglabel van een leverancier; het label is niet het beleid van het platform.

Schrijf drie feiten op voordat je de configuratie aanraakt: gecontroleerd of niet, beheerd of persoonlijk profiel, en welke client de tunnel draagt. Elke latere stap hangt van die drie af, en gedrag van een persoonlijke telefoon naar een beheerd profiel overzetten is hoe een uitrol tegen de verkeerde basis wordt goedgekeurd.

Stap 2: lees de on-demand-regels, niet de naam van de functie

On Demand is een lijst regels die op volgorde worden beoordeeld. Elke regel noemt een actie en de voorwaarden die hem selecteren, en de voorwaarden zijn het interessante deel: interfacetype, Wi-Fi-SSID, DNS-domeinsuffix of een probe-URL. Een regelset die nooit klopt is een functie die nooit verbindt.

<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 de hele array en stel per regel twee vragen: kan deze voorwaarde ooit waar zijn op deze vloot, en wat gebeurt er als geen enkele regel klopt? Bedrijfsnetwerken hernoemen toegangspunten, voegen SSID’s samen en wijzigen DNS-suffixen, en elk van die bewerkingen koppelt een regel geruisloos los van de werkelijkheid.

De DNS-suffixvoorwaarde is degene die in het veld het vaakst fout gaat, omdat het suffix dat een telefoon op een gastnetwerk meldt niet het suffix is dat de bedrijfsresolver bedient. Controleer de naam die het apparaat werkelijk resolveert voordat je de regel vertrouwt.

Stap 3: test de overgangen, niet de statische verbinding

Een tunnel die omhoog staat terwijl je ernaar kijkt, bewijst heel weinig. Voer elke overgang bewust uit en noteer wat het apparaat doet, met elke keer dezelfde privébron zodat de resultaten vergelijkbaar zijn:

• Maak verbinding met een netwerk waar een regel zou moeten kloppen, vraag dan de privébron op en bevestig dat die laadt.
• Schakel over naar mobiel met de app op de achtergrond, haal hem dan naar voren en herhaal het verzoek.
• Verbind met een Wi-Fi met captive portal en kijk of de portal bereikbaar is of dat de afdwinging hem blokkeert voordat je kunt inloggen.
• Zet de tunnel handmatig uit op een gecontroleerd apparaat en controleer of hij vanzelf terugkomt, en hoe snel.

Voer dezelfde lijst uit op een niet-gecontroleerd apparaat als je er een hebt. Het verschil tussen beide resultaten is het echte gedrag van de uitrol, en dat is het deel dat een schermafbeelding van een verbonden tunnel nooit laat zien.

Stap 4: ken de twee faalvormen

Afgedwongen dekking faalt door te blokkeren. Als de tunnel niet tot stand komt, verliest het apparaat de gewone internettoegang samen met de privébronnen, en de gebruiker ervaart een telefoon die online is maar niet kan browsen. Opnieuw verbinden en blokkeren zijn aparte waarnemingen, dus log beide in plaats van het ontbreken van internet als één symptoom te behandelen.

On Demand faalt door niet te triggeren. De regel klopt niet, er verschijnt geen tunnel, en de privébron loopt simpelweg af. Dat is makkelijk verkeerd te diagnosticeren als een serverprobleem, omdat de client zich precies gedraagt zoals geconfigureerd.

Een captive portal zit tussen beide in: die heeft connectiviteit nodig voordat de tunnel bestaat, dus een beleid dat alles blokkeert tot de tunnel omhoog is, heeft een gedocumenteerde route door de portal nodig. Beslis dat in het ontwerp, niet bij de helpdesk.

Stap 5: verifieer en oefen daarna de terugdraai

Verificatie hoort op het echte pad met onschadelijk verkeer: vraag een privébron op die niet openbaar mag zijn, bevestig welk adres het apparaat naar buiten presenteert, en herhaal na een herstart zodat je de opstartvolgorde hebt gezien en niet alleen de warme toestand.

Oefen daarna het verwijderen op een testapparaat voordat je het in productie nodig hebt. Het verwijderen van het profiel zet het apparaat terug in de vorige toestand, en weten hoe lang dat duurt en wat de gebruiker ziet is onderdeel van het draaiboek. Apple’s VPN-beveiligingsgids is de referentie voor wat het platform over dit beleid documenteert, en het loont hem te lezen voordat je een configuratie schrijft die meer beweert dan het platform.

Houd de drie feiten uit stap één naast de regelset en de testresultaten. Als de volgende persoon vraagt waarom een telefoon op het ene netwerk wel verbindt en op het andere niet, antwoorden die notities in een minuut in plaats van een herbouw.