Android-VPN zu Cisco IOS: der Vertrag, der zuerst her muss

Das Telefon muss ein Cisco-Gateway erreichen. Jemand hat bereits den zu installierenden Client benannt. Das ist das falsche Ende des Verfahrens, und deshalb scheitert der Tunnel nach einer Stunde des erneuten Eintippens von Anmeldedaten.

Was Sie zuerst brauchen, ist ein Verbindungsvertrag: Protokoll, Authentifizierung, Identität, Vertrauensmaterial, Adressvergabe und Routing, aufgeschrieben von der Stelle, die das Gateway betreibt.

Holen Sie sich das schriftlich, und die Client-Wahl wird zu einem Nachschlagen. Lassen Sie es weg, und jeder Fehler sieht wie ein falsches Passwort aus.

Führen Sie die Erhebung durch, bevor Sie irgendetwas installieren

Schicken Sie dem Gateway-Betreiber eine Liste und verlangen Sie Antworten, keinen Produktnamen. Neun Punkte decken ein Fernzugriffsprofil vollständig ab:

1. Hostname oder Adresse des Gateways, das der Client anwählen soll, und ob es von außen erreichbar ist.
2. Das Protokoll und die Version: IKEv2, eine andere IPsec-Generation oder ein TLS-basierter Dienst.
3. Die Peer-Identität, die das Gateway erwartet, und was es seinerseits vorzeigt.
4. Vertrauensmaterial: welche CA das Gateway-Zertifikat signiert oder ob ein vorab geteilter Schlüssel verwendet wird.
5. Benutzerauthentifizierung: Zertifikat, EAP-Benutzername und Passwort oder ein vorab geteilter Schlüssel.
6. Der Adresspool, in dem der Client landet, mit Maske und Gateway.
7. DNS-Server, die im Tunnel zu verwenden sind, und ob der Client sie annehmen muss.
8. Erlaubte Zielpräfixe und ob Verkehr außerhalb davon blockiert werden muss.
9. Die unterstützten Client-Versionen und Telefon-Betriebssystemversionen sowie jede Registrierungsanforderung.

Zwei dieser Punkte verursachen die meisten vermeidbaren Fehler. Ohne das Vertrauensmaterial können Sie das Gateway nicht validieren, sodass ein korrekter Client defekt wirkt. Ohne die erlaubten Präfixe können Sie eine Routing-Einschränkung nicht von einem Dienstproblem unterscheiden.

Der Herstellername ist kein Protokoll

Cisco IOS und IOS XE bieten mehrere Fernzugriffsarrangements, und sie teilen kein gemeinsames Übertragungsformat. IKEv2 mit einem FlexVPN-artigen Profil ist nicht derselbe Dienst wie eine ältere IKEv1-Konfiguration, und ein TLS-basierter Client-Dienst ist wieder ein anderes Produkt, oft auf einer anderen Plattform in derselben Umgebung.

Ein Client, dessen Name den Router-Hersteller nennt, beweist also nichts. Er kann einen dieser Dienste gut umsetzen und keinen der anderen. Fragen Sie, welcher Dienst konfiguriert ist, und prüfen Sie dann, ob die Dokumentation des Clients diesen Dienst als unterstützt nennt.

Ciscos eigene IKEv2-Dokumentation trennt Proposal, Policy, Profil und Keyring als eigene Objekte. Diese Struktur ist nützlich, wenn Sie eine Konfiguration lesen, die Ihnen jemand hineinkopiert: Sie sagt Ihnen, welches Objekt die Einstellungen enthält, die für ein entferntes Telefon wichtig sind, statt die ganze Datei als einen Block zu behandeln.

Was Androids eingebauter Stack abdeckt

Android stellt über Ikev2VpnProfile ein Plattformprofil für IKEv2/IPsec bereit, mit getrennten Authentifizierungstypen für einen vorab geteilten Schlüssel, ein RSA-Zertifikat sowie EAP-Benutzername und Passwort. Die Ikev2VpnProfile-Referenz ist die maßgebliche Quelle dafür, was der Builder akzeptiert, einschließlich des Gateway-Hostnamens und der Server-Root-CA, mit der er validiert wird.

Diese API ist eine Fähigkeitsaussage, kein Kompatibilitätsversprechen. Sie sagt, dass die Plattform IKEv2 mit diesen Authentifizierungstypen kann. Sie sagt nicht, dass ein bestimmter OEM-Einstellungsbildschirm jedes Feld zeigt, noch dass eine aus einem anderen Produkt exportierte Profildatei importiert wird.

Das heißt auch: Der eingebaute Stack rettet Sie nicht, wenn das Gateway einen Dienst betreibt, den die Plattform nicht implementiert. Dann brauchen Sie den Herstellerclient, den der Betreiber unterstützt, installiert und konfiguriert wie vom Betreiber dokumentiert, statt eines Workarounds auf einem Protokoll, das das Telefon nicht spricht.

Testen Sie in der Reihenfolge, in der der Vertrag geschrieben ist

Validieren Sie eine Schicht nach der anderen und stoppen Sie beim ersten Fehler, denn spätere Tests sind sinnlos, bis die früheren bestehen.

Vertrauen. Wenn der Client das Gateway-Zertifikat ablehnt, spielt nichts anderes eine Rolle. Bestätigen Sie, dass die CA, die Sie erhalten haben, das Zertifikat signiert, das das Gateway vorzeigt, und dass der angewählte Hostname darin vorkommt. Lassen Sie die Validierung an; ihr Abschalten verwandelt ein Identitätsproblem in ein Abhörrisiko.

Authentifizierung. Abgelehnte Anmeldedaten und ein nicht passendes Proposal erzeugen unterschiedliche Fehler, aber ähnlich aussehende Ausfälle. Das Gateway-Log entscheidet: Es sagt, ob das Proposal akzeptabel war, bevor es etwas über den Benutzer sagt.

Adresse und DNS. Bestätigen Sie, dass das Telefon eine Adresse aus dem dokumentierten Pool erhalten hat, und lösen Sie dann einen internen Namen auf. Ein Tunnel, der mit einer Adresse und ohne Resolver hochkommt, sieht verbunden aus und verhält sich, als würde nichts funktionieren.

Erreichbarkeit. Testen Sie ein erlaubtes Ziel nach Adresse, dann nach Name. Funktioniert die Adresse und der Name nicht, sind Sie wieder bei DNS. Funktioniert keines, vergleichen Sie das getestete Präfix mit der erlaubten Liste, bevor Sie den Client anfassen.

Fehlerbilder und der Rollback

Halten Sie das zuletzt funktionierende Profil exportiert und dokumentiert, bevor Sie etwas ändern, einschließlich des CA-Alias und des Adresspools. Rollback heißt dann, ein bekanntes Profil wiederherzustellen, nicht eines während einer Störung aus dem Gedächtnis zu rekonstruieren.

Wenn es läuft, notieren Sie die neun Erhebungsantworten neben dem Profil. Das nächste Telefon, das nächste Betriebssystem-Update und die nächste Gateway-Änderung werden alle zu einem Vergleich mit einem Dokument statt zu einem weiteren Nachmittag des Ratens.