Zusammenfassung

  • Bleiben VPN-Gateway und VPN-TIA gleich, kann MOBIKE die äußere Zugangsadresse ändern, ohne dass der i-HA eine Bewegung im Mobile-IPv4-Binding sieht.
  • Ein Kontinuitätsbeleg verbindet Zugangswechsel, IKE/MOBIKE, TIA, nötige Mobile-IPv4-Registrierung, Reverse Tunnel, Weiterleitung und Anwendungsempfang.

Zwei Protokolle sahen verschiedene Bewegungen

Der Knoten erhielt in einem anderen externen Netz eine neue Adresse. MOBIKE aktualisierte den Gateway und die IPsec-SA lief über den neuen Weg weiter. Für den äußeren Peer war die Bewegung bestätigt.

Im Tunnel blieb der TIA gleich. Der i-HA kannte weiterhin dieselbe Care-of Address zum Home Address. Sein unverändertes Binding beweist innere Adresskontinuität, nicht einen unbewegten Zugang.

Die Zusammenfassung „Mobilität erfolgreich“ verliert genau diese Zuständigkeit.

Drei Adressen haben drei Bedeutungen

Das Mobile-IPv4-Home-Address bleibt stabil. Der Gateway vergibt den intern routbaren TIA, den der Client als CoA registriert. Das Zugangsnetz vergibt die äußere Adresse, die MOBIKE aktualisiert.

Ein einzelnes Feld „aktuelle IP“ kann weder Ebene noch Autorität oder Lebensdauer ausdrücken. Ein brauchbarer Nachweis benennt, welche Koordinate sich änderte und welche absichtlich gleich blieb.

Der stabile TIA schafft einen blinden Fleck

Ohne TIA-Wechsel braucht der Home Agent nicht jede externe Bewegung zu verarbeiten. Das spart Signalisierung und hält den inneren Tunnel stabil. Sein Log kann deshalb die Reihenfolge der Zugangsnetze nicht rekonstruieren.

Für Forensik müssen MOBIKE-Verlauf, SA, Gateway, TIA-Zuweisung und Binding korreliert werden. Ändert eine neue Gateway-Verbindung den TIA, ist eine neue Registrierung beim i-HA erforderlich. Dann existieren zwei getrennte Commits.

Zwei Tunnel, zwei Quittungen

Im Modus mc liegt Mobile IPv4 innerhalb von IPsec; Reverse Tunneling über den Home Agent ist vorgeschrieben. Die MOBIKE-Antwort bestätigt die äußere Adresse, die Registration Reply das innere Binding.

Keine bestätigt den Durchlauf durch beide Kapseln, korrekte NAT-Zustände, passende Selektoren oder Anwendungsabschluss. Paketbeobachtung an beiden Grenzen und ein Empfängerbeleg bleiben nötig.

Grenzübertritt startet parallele Arbeit

Bei Konnektivitätsänderung kann der Knoten MOBIKE und eine direkte i-HA-Registrierung zugleich senden. Nur Gateway-Antwort stützt „außen“; eine geschützte i-HA-Antwort unter TNC-Bedingungen stützt „innen“. Während der Erkennung soll kein normaler Verkehr laufen.

Beim Wechsel nach außen errichtet VPN zunächst nur den Kanal. Bleibt die direkte i-HA-Antwort aus, folgt die Mobile-IPv4-Registrierung im Tunnel, bevor das Home Address kommunizieren kann.

Direkter Verkehr gehört nicht zur Zusage

Ein Client kann Internetverkehr am VPN vorbeiführen. RFC 5266 verbietet das nicht, gibt ihm aber keine Mobilität oder Sitzungskontinuität. Mobile-IP-Tunnelverkehr geht immer durch den VPN-Gateway.

Bytes auf dem neuen Interface sind daher kein Unternehmensbeleg. Direkter Flow, IPsec und Mobile-IP-in-IPsec müssen getrennt werden. Auch NAT kann auf beiden Ebenen eigene Zustände führen.

Ein geschichteter Mobilitätsbeleg

Bewahren Sie Interface und alte/neue Außenadresse, IKE-SA, Gateway und MOBIKE-Commit, TIA-Zuweisung und Laufzeit, Home Address und CoA, Registrierung und Binding-Version, direkten oder getunnelten i-HA-Pfad, TNC, Authentisierung, Replay, Reverse Tunnel, Selektoren, NAT, Grenzzähler, Transporterholung und Anwendungsbestätigung auf.

Zulässig ist ein geänderter Außenpfad bei gleichem Binding. Kritisch sind neuer TIA ohne i-HA-Update und jede Ausweitung der ersten grünen Antwort auf spätere Ebenen.

Quellen