Dieselbe IKEv2-Identität auf zwei iPhones? Sie verbinden sich abwechselnd
Ein auf zwei Geräte kopiertes Profil gibt dem Gateway einen Peer statt zwei. Beobachten Sie, wie sich die Peer-Tabelle füllt und leert, und vergeben Sie dann pro Gerät einen Wert.
Zwei Telefone, ein Profil und ein Muster, das übernatürlich wirkt, bis jemand auf das Gateway schaut. Ein Gerät hält den Tunnel, das zweite verbindet sich, und das erste verliert ihn innerhalb von Sekunden. Das erste verbindet sich neu, das zweite fliegt raus. Akkusparen, Wi-Fi-Roaming und das NAT des Mobilfunkanbieters bekommen die Schuld, während die eigentliche Ursache in einem Textfeld steckt, das mit allem anderen kopiert wurde. IKEv2 identifiziert einen Peer anhand eines Namens, und beide Telefone zeigen denselben.
Die Identität ist der Schlüssel, unter dem der Server dich speichert
In einem IKEv2-Austausch gibt jede Seite an, wer sie ist: der Initiator sendet eine lokale Kennung, der Responder antwortet mit seiner eigenen, und der Responder prüft die vom Initiator behauptete Identität außerdem gegen die Richtlinie. Das Gateway führt seinen Zustand pro Identität statt pro Gerät, denn ein Gerät ist nichts, was es sehen kann. Zwei Telefone mit einer Kennung kommen daher als ein Peer an, und der zweite Austausch muss den ersten überschreiben. Das Problem zeigt sich nur, solange beide in Benutzung sind, weshalb ein Test mit einem Telefon es nie reproduziert.
Nichts davon ist ein Fehler im Client. Der Client hat genau das gesendet, was ihm das Profil zu senden befahl.
Wie die Kollision vom Gateway aus aussieht
Beobachten Sie die Peer-Liste, während beide Telefone wach und in Benutzung sind. Eine Kollision zeigt einen einzigen Eintrag, dessen Adresse sich ändert, wenn die Telefone tauschen, während der Zähler aktiver Sitzungen nie zwei erreicht. Das Abbauen auf Abruf sieht anders aus, und sie zu unterscheiden erfordert eine Beobachtung statt einer Theorie.
| Observation | Shared identity | Idle teardown |
|---|---|---|
| Peer entries while both are awake | One, with a changing address | One per phone, or none |
| What triggers the drop | The other device connecting | Time without traffic |
| What restores it | The other device disconnecting | Any app needing the tunnel |
Notieren Sie beide Ereignisse mit Zeitstempeln, während es passiert. Ein Abbruch, der mit dem Verbinden des anderen Geräts zusammenfällt, deutet auf die Kennung hin, und ein Abbruch, der ein Idle-Intervall nach dem letzten Paket kommt, auf einen Timer.
Woher die Duplikate kommen
Eine funktionierende Konfiguration zu exportieren und nur die Serveradresse zu ändern erzeugt eine zweite Datei, in der die Identität der ersten Datei noch steckt. Das ist der übliche Weg zu diesem Fehler, und er passiert meist beim eiligen Onboarding einer kleinen Gruppe.
Die Feldnamen machen es leicht, das zu übersehen. Die Remote-Kennung benennt das Gateway, das das Telefon erwartet, und sie zu kopieren ist richtig. Die lokale Kennung benennt dieses Gerät gegenüber dem Gateway, und genau diesen Wert zu kopieren ist das ganze Problem.
Vergeben Sie einen Wert pro Gerät
Verwenden Sie etwas, das für das Gerät eindeutig und über seine Lebensdauer stabil ist, etwa die Gerätekennung aus dem Inventar oder einen Wert, den Ihr Managementsystem pro Registrierung erzeugt. Ein Abteilungslabel, ein gemeinsam genutzter Dienstkontoname oder die E-Mail-Adresse des Nutzers kollidieren alle, sobald diese Person ein zweites Gerät hat.
Erzeugen Sie die Nutzlast pro Gerät, statt eine Datei zu verteilen. Halten Sie fest, welcher Wert zu welchem Gerät gehört, damit ein Austausch nicht das alte Profil wiederherstellt und das neue Telefon direkt in dieselbe Kollision zurückbringt.
Prüfen Sie auch die Serverseite. Ein Gateway, das die Identität auf eine feste Tunneladresse abbildet, kann immer noch kollidieren, wenn zwei verschiedene Kennungen dieselbe Zuweisung erhalten, bestätigen Sie also, dass der Pool Platz hat und Zuweisungen nicht pro Nutzer festgezurrt sind.
Prüfen Sie mit beiden Telefonen wach
Verbinden Sie das erste, erreichen Sie eine private Ressource, verbinden Sie dann das zweite und lassen Sie beide eine Minute untätig. Beide Sitzungen sollten bestehen bleiben, und die Peer-Liste sollte zwei Identitäten zeigen. Sperren und entsperren Sie dann jedes Telefon, um zu bestätigen, dass der Idle-Fall sich noch richtig verhält.
Wenn eine einzelne Sitzung weiterhin einmal am Tag abbricht, ohne dass sich etwas anderes verbindet, ist die Identität nicht mehr der Verdächtige. Gehen Sie stattdessen zu Idle-Timern und Server-Sitzungslimits über, statt das Profil erneut zu bearbeiten.