Always On VPN oder VPN On Demand auf dem iPhone: Was man ausrollen sollte

Zwei iPhones können beide VPN sagen und sich völlig unterschiedlich verhalten. On Demand öffnet einen Tunnel, sobald eine Regel greift, und der Nutzer kann ihn in den Einstellungen weiterhin abschalten. Verwaltetes Always On hält die Abdeckung auf einem überwachten Gerät erzwungen, auch in Momenten, in denen der Tunnel nicht hochkommt. Wählen Sie, indem Sie fragen, was gelten muss, wenn der Nutzer nichts tut, und testen Sie dann die Übergänge statt des Dauerzustands. Die folgenden Schritte folgen der Reihenfolge, in der ein Rollout tatsächlich scheitert.

Schritt 1: feststellen, was das Gerät erzwingen kann

Always On ist eine Funktion für überwachte Geräte. Ist der Bestand nicht überwacht, ist das Gespräch vorbei, bevor es beginnt, und kein Payload-Schlüssel macht aus einem nicht überwachten Telefon ein erzwungenes. Bestätigen Sie die Überwachung auf der Verwaltungsseite und am Gerät und bestätigen Sie dann, wer das Profil signiert hat.

Auf dem Telefon: Einstellungen, dann Allgemein, dann VPN und Geräteverwaltung. Der Profileintrag nennt seinen Eigentümer, und ein manuell installiertes persönliches Profil sieht anders aus als eines, das ein Verwaltungsdienst liefert. Leiten Sie die Erzwingung nicht aus dem Profilnamen oder einem Marketingetikett eines Anbieters ab; das Etikett ist nicht die Plattformrichtlinie.

Notieren Sie drei Fakten, bevor Sie die Konfiguration anfassen: überwacht oder nicht, verwaltetes oder persönliches Profil und welcher Client den Tunnel trägt. Jeder spätere Schritt hängt an diesen drei, und Verhalten von einem persönlichen Telefon auf ein verwaltetes Profil zu übertragen ist der Weg, auf dem ein Rollout gegen die falsche Basis abgenommen wird.

Schritt 2: die On-Demand-Regeln lesen, nicht den Funktionsnamen

On Demand ist eine Liste von Regeln, die der Reihe nach ausgewertet werden. Jede Regel nennt eine Aktion und die Bedingungen, die sie auswählen, und die Bedingungen sind der interessante Teil: Schnittstellentyp, Wi-Fi-SSID, DNS-Domänensuffix oder eine Prüf-URL. Ein Regelsatz, der nie greift, ist eine Funktion, die nie verbindet.

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

Lesen Sie das ganze Array und stellen Sie pro Regel zwei Fragen: Kann diese Bedingung in diesem Bestand je wahr sein, und was passiert, wenn keine Regel greift? Unternehmensnetze benennen Zugangspunkte um, führen SSIDs zusammen und ändern DNS-Suffixe, und jede dieser Änderungen löst eine Regel still von der Wirklichkeit.

Die DNS-Suffix-Bedingung ist die im Feld am häufigsten falsche, weil das Suffix, das ein Telefon in einem Gastnetz meldet, nicht das ist, das der Unternehmens-Resolver bedient. Prüfen Sie den Namen, den das Gerät tatsächlich auflöst, bevor Sie der Regel trauen.

Schritt 3: die Übergänge testen, nicht die statische Verbindung

Ein Tunnel, der steht, während Sie hinsehen, beweist wenig. Führen Sie jeden Übergang bewusst aus und protokollieren Sie, was das Gerät tut, mit derselben privaten Ressource jedes Mal, damit die Ergebnisse vergleichbar sind:

• Verbinden Sie sich mit einem Netz, in dem eine Regel greifen sollte, fordern Sie dann die private Ressource an und bestätigen Sie, dass sie lädt.
• Wechseln Sie bei App im Hintergrund auf Mobilfunk, holen Sie sie nach vorn und wiederholen Sie die Anforderung.
• Verbinden Sie sich mit einem Wi-Fi mit Captive Portal und sehen Sie, ob das Portal erreichbar ist oder ob die Erzwingung es blockiert, bevor Sie sich anmelden können.
• Schalten Sie den Tunnel auf einem überwachten Gerät manuell ab und prüfen Sie, ob er von selbst zurückkommt und wie schnell.

Führen Sie dieselbe Liste auf einem nicht überwachten Gerät aus, falls vorhanden. Der Unterschied zwischen beiden Ergebnissen ist das reale Verhalten des Rollouts, und genau das zeigt ein Screenshot eines verbundenen Tunnels nie.

Schritt 4: die zwei Fehlerformen kennen

Erzwungene Abdeckung scheitert durch Blockieren. Kommt der Tunnel nicht zustande, verliert das Gerät den normalen Internetzugang samt privater Ressourcen, und der Nutzer erlebt ein Telefon, das online ist, aber nicht browsen kann. Wiederverbindung und Blockieren sind getrennte Beobachtungen, also protokollieren Sie beides, statt fehlendes Internet als ein Symptom zu behandeln.

On Demand scheitert durch Nichtauslösen. Die Regel greift nicht, kein Tunnel erscheint, und die private Ressource läuft einfach ab. Das lässt sich leicht als Serverproblem fehldiagnostizieren, weil der Client sich genau wie konfiguriert verhält.

Ein Captive Portal liegt dazwischen: Es braucht Konnektivität, bevor der Tunnel existiert, also braucht eine Richtlinie, die alles blockiert, bis der Tunnel steht, einen dokumentierten Weg durch das Portal. Entscheiden Sie das im Design, nicht am Helpdesk.

Schritt 5: verifizieren, dann den Rückbau üben

Verifikation gehört auf den echten Pfad mit harmlosem Verkehr: Fordern Sie eine private Ressource an, die nicht öffentlich sein darf, bestätigen Sie, welche Adresse das Gerät nach außen zeigt, und wiederholen Sie nach einem Neustart, damit Sie die Startsequenz gesehen haben und nicht nur den warmen Zustand.

Üben Sie dann das Entfernen auf einem Testgerät, bevor Sie es in der Produktion brauchen. Das Entfernen des Profils bringt das Gerät in seinen vorherigen Zustand zurück, und zu wissen, wie lange das dauert und was der Nutzer sieht, gehört zum Runbook. Apples VPN-Sicherheitsleitfaden ist die Referenz dafür, was die Plattform zu diesen Richtlinien dokumentiert, und es lohnt sich, ihn zu lesen, bevor Sie eine Konfiguration schreiben, die mehr behauptet als die Plattform.

Halten Sie die drei Fakten aus Schritt eins neben dem Regelsatz und den Testergebnissen. Wenn die nächste Person fragt, warum ein Telefon in einem Netz verbindet und in einem anderen nicht, beantworten diese Notizen das in einer Minute statt in einem Neuaufbau.