iPhone Always On VPN: Zwei Tunnel können sich eine virtuelle IP teilen

Auf einem überwachten iPhone mit verwaltetem Always-On-Profil hält das Telefon für jede aktive IP-Schnittstelle einen Tunnel, sodass Mobilfunk und WLAN jeweils einen eigenen erhalten. Der Server listet dann zwei IKE-Sicherheitsassoziationen für ein Gerät, oft mit einer gemeinsamen virtuellen Adresse, und der erste Impuls ist, das eine Rekey-Schleife zu nennen und Timer zu ändern. Dieser Impuls ist meist falsch. Arbeiten Sie die folgenden Schritte in der Reihenfolge ab, in der die Belege auf dem Server erscheinen, und lassen Sie die Telefoneinstellungen in Ruhe, bis der Server Ihnen sagt, welchen Fall Sie haben.

Beginnen Sie mit den zwei Zeilen, die der Server bereits hat

Listen Sie die Assoziationen mit swanctl --list-sas auf und lesen Sie vier Felder über beide Einträge hinweg: die Gegenstelle, die authentifizierte Identität, die zugewiesene virtuelle IP und die Erstellungszeit. Zwei verschiedene äußere Adressen mit einer Identität und einer virtuellen IP sind die Form, die diese Frage ausgelöst hat, und es lohnt sich, sie vor jeder Änderung festzuhalten. Prüfen Sie dann die untergeordneten Assoziationen an jeder von ihnen, denn die Traffic-Selektoren entscheiden, ob eine Zielsuche die beiden Tunnel jemals unterscheiden könnte. Ein Paar, das in Sekunden erscheint und verschwindet, ist ein anderes Tier als ein Paar, das beide stundenlang lebt.

Sortieren Sie die Liste vor einer Schlussfolgerung nach Erstellungszeit. Nachbarschaft in der Ausgabe bedeutet nichts, und eine tabellarische Auflistung lädt genau zu diesem Fehler ein.

Entscheiden Sie, welches Überlappen Sie sehen

IKEv2-Rekeying und Make-before-break-Reauthentifizierung erzeugen absichtlich eine kurze Überlappung, indem die neue Assoziation aufgebaut wird, bevor die alte gelöscht wird. Zeitstempel klären den Fall, denn eine alte SA, die ein oder zwei Sekunden nach der neuen verschwindet, ist Erneuerung, die ihre Arbeit tut. Unabhängige Schnittstellentunnel sehen nie so aus, da jeder besteht, solange seine Schnittstelle aktiv ist, und das Löschen des einen nicht aus dem Anlegen des anderen folgt.

Apples verwaltetes Always-On-Verhalten gilt pro Schnittstelle, weshalb ein überwachtes Gerät legitim beschäftigter aussehen kann als ein von Hand eingerichtetes Profil. Der Auto-Connect-Schalter einer Anbieter-App bedeutet nicht dasselbe, und eine gewöhnliche On-Demand-Regel auch nicht. Die Apple-Bereitstellungsübersicht beschreibt das Modell pro Schnittstelle; vergleichen Sie Ihre beiden Zeilen damit, bevor Sie eine Schleife annehmen. Beide Formen schöpfen zudem aus demselben Server-Pool, also ist die Überlappung Ihr einziges frühes Signal.

Sehen Sie, warum eine virtuelle Adresse für zwei Tunnel Antworten bricht

Eine Antwort an das Telefon ist an die innere Adresse adressiert, und der Kernel wählt einen ausgehenden Tunnel nach Ziel und Richtlinie, nicht nach der Schnittstelle, die das Telefon benutzt hat. Zwei gleichzeitige Assoziationen mit derselben virtuellen IP und übereinstimmenden Richtlinien lassen die Routing-Entscheidung ohne Möglichkeit, zu sagen, zu welcher Sitzung eine Antwort gehört. Manche Antworten nehmen den falschen Tunnel, und das Telefon zeigt eine Verbindung, die in eine Richtung funktioniert oder stirbt, wenn WLAN hochkommt. Zwei Kommandoausgaben belegen den Zustand: swanctl --list-sas zeigt dieselbe virtuelle IP auf beiden SAs, und ip xfrm policy zeigt zwei identische Selektoren.

Genau dieses Ausgabepaar fügen Sie dem Änderungsnachweis bei. Keine der beiden allein ist überzeugend, weil jede für sich plausibel aussehen kann.

Das ist Adressierung und Richtlinie auf Serverseite, kein Fehlverhalten des Telefons, und keine Clienteinstellung trennt zwei identische innere Adressen. Der Pool hat denselben Wert zweimal ausgegeben, und der Richtlinien-Installer hat ihn akzeptiert. Lesen Sie das Ergebnis von der Serverseite, bevor Sie den Client beschuldigen.

Ändern Sie den Pool oder das Nebenläufigkeitsmodell, nicht den Rekey-Timer

In der swanctl-Konfiguration ist Eindeutigkeit eine ausdrückliche Richtlinie auf der Verbindung: unique = replace entfernt eine ältere Verbindung, wenn eine neue aufgebaut wird, und unique = keep weist den Neuankömmling ab. Beide Werte wirken beim Aufbau einer Verbindung, nicht auf die untergeordneten SAs darin.

connections {
  ios-alwayson {
    unique = replace
  }
}

Keiner der Werte ist für einen Client pro Schnittstelle neutral. keep stellt einen aufgeräumten Statusbildschirm wieder her, indem es den zweiten Tunnel ablehnt, und bricht das verwaltete Design, während replace den älteren Tunnel abreißt und derselbe Kompromiss in die andere Richtung ist. Wenn beide Tunnel wirklich nötig sind, muss das Pool-Backend für eine Identität unterschiedliche Leases ausgeben, und sein Lease-Schlüssel muss die Anfragen unterscheiden. Eine statische Identität-zu-Adresse-Tabelle gibt bereitwillig dieselbe Adresse zweimal zurück und reproduziert das ursprüngliche Problem mit mehr Konfiguration. Prüfen Sie, wie das Backend Lease-Schlüssel bildet, bevor Sie ein zweites statisches Mapping hinzufügen.

Testen Sie die Übergänge, die Sie tatsächlich ausrollen

Gehen Sie mit einer aktiven Sitzung aus der WLAN-Reichweite, gehen Sie dann zurück, und prüfen Sie, dass Antworten in beide Richtungen ankommen. Tun Sie das zweimal, denn beim zweiten Übergang zeigt sich meist eine veraltete Richtlinie. Testen Sie mit einem Dienst, der auf der Verbindung antwortet, die Sie geöffnet haben, und wiederholen Sie den Gang nach draußen, während der Tunnel Verkehr trägt, statt untätig zu stehen. Ein Telefon, das senden, aber nicht empfangen kann, sieht im Handshake-Log gesund und im Browser kaputt aus.

Ein auf eine Zeile reduzierter Statusbildschirm ist kein Beleg für ein funktionierendes Design, nur ein Beleg dafür, dass ein Tunnel weg ist. Beide Richtungen müssen funktionieren, bevor ein Übergang besteht. Notieren Sie, was Sie beobachtet haben, zusammen mit den beiden Ausgaben der Überlappungsprüfung, damit der nächste Ingenieur vergleichen kann, statt den Gang zu wiederholen.