Älteres SSL-VPN in IOS: Paket, Profil, Gateway, Sitzung

Sie finden ein Client-Installationsprogramm im Flash des Routers und schließen daraus, dass das SSL VPN konfiguriert ist. Das ist eine von vier Komponenten, und die übrigen drei entscheiden darüber, ob überhaupt jemand eine Verbindung aufbauen kann. Beim alten IOS SSL VPN sind die Teile getrennte Objekte: das Headend-Clientpaket, ein optionales Clientprofil, das WebVPN-Gateway, das TLS terminiert, und der Kontext samt Gruppenrichtlinie, die Authentifizierungs- und Sitzungseinstellungen halten. Fehlt eines, sieht der Fehler von außen gleich aus.

Ciscos IOS-SSL-VPN-Konfigurationsbeispiel, aufgebaut auf IOS 15.3 mit AnyConnect 3.1, ist gerade deshalb nützlich, weil es diese Objekte auseinanderhält. Lesen Sie es als Beschreibung jener älteren Implementierung, nicht als Empfehlung, diese Versionen einzusetzen.

Erstens das Paket: was es ist und was nicht

Das Headend-Paket liefert Clientsoftware für eine Plattform. Es ist weder das Profil noch der Listener, und eine Datei im Flash belegt nur, dass jemand etwas hochgeladen hat. Sie belegt nicht, dass eine Sitzung sie je genutzt hat, dass die Plattform zum Gerät des Benutzers passt oder dass das Gateway überhaupt darauf verweist.

Bestätigen Sie den genauen Dateinamen, die Zielplattform und die Stelle, auf die die Konfiguration zeigt. Ein Windows-Paket sagt nichts über Telefone aus, und eine hochgeladene Datei, die kein Gateway-Objekt erwähnt, ist Speicher und keine Konfiguration. Ein Paket, das zur Plattform passt, aber nie dem Dienst zugeordnet wird, wird keinem Benutzer angeboten. Ebenso wenig eines, dessen Dateiname von dem Wert abweicht, den die Konfiguration erwartet.

Zweitens das Profil: Einstellungen statt Software

Ein optionales Clientprofil trägt Einstellungen, die ein Administrator getrennt vorbereitet, etwa Serverlisten oder Clientvorgaben. Es mit einem Installationsprogramm zu verwechseln ist üblich, weil beide als Dateien mit ähnlichen Namen ankommen. Rechnet der Rollout mit einem Profil, ändert sein Fehlen das Verhalten des Clients nach dem Verbindungsaufbau, nicht ob er überhaupt verbindet.

Erfassen Sie beide Artefakte und notieren Sie, auf welches das Gateway tatsächlich verweist. Diese eine Zeile verhindert eine ganze Klasse von Support-Tickets, in denen zwei Personen über verschiedene Dateien sprechen.

Drittens der Listener und die TLS-Identität

Das Gateway-Objekt definiert die Adresse und den Port, die die Außenwelt erreicht, und das Zertifikat, das beim Handshake vorgelegt wird. Ein Browser, der eine Portalseite erreicht, ein Client, der die Authentifizierung abschließt, und eine Anwendung, die einen privaten Server erreicht, sind drei getrennte Beobachtungen, und nur die erste ist ein Listener-Test. Scheitert der Handshake, zählt noch nichts dahinter, also prüfen Sie Zertifikatskette und Namen, bevor Sie irgendeine Richtlinie bearbeiten.

Schreiben Sie die erwartete Identität irgendwo auf. Ein erneuertes oder ausgetauschtes Zertifikat ist der häufigste Grund, warum ein Rollout, der letzten Monat lief, diesen Monat nicht mehr läuft.

Viertens der Kontext und die Richtlinie mit ihrer virtuellen Vorlage

Kontext und Gruppenrichtlinie binden die Authentifizierung an das Sitzungsverhalten: Adresspool, Split-Routen, DNS und die internen Netze, die ein Benutzer erreichen darf. Das dokumentierte Beispiel hängt seinen Kontext an eine virtuelle Vorlage, die Schnittstellenverhalten pro Sitzung liefert, und diese serverseitigen Objekte bestehen unabhängig von allem, was ein Benutzer herunterlädt.

Wenn ein Benutzer sich authentifiziert, aber nichts erreicht, sitzt der Fehler in der Regel hier und nicht im Client. Vergleichen Sie Pool, die an den Client übergebenen Routen und die ACL, die weiteren Verkehr erlaubt, und prüfen Sie sie gegen das, was der Benutzer meldet, nicht gegen das, was das Design vorgesehen hatte.

Der Reihe nach prüfen und beim ersten Fehler stoppen

Gehen Sie die vier Komponenten in der Reihenfolge durch, in der eine Verbindung sie trifft: Listener, Authentifizierung, Richtlinie und dann das Clientverhalten. Bestätigen Sie TLS mit der erwarteten Identität, authentifizieren Sie ein bekannt funktionierendes Konto, lesen Sie die zugewiesene Adresse und die Routen aus der Sitzung und vergleichen Sie erst danach die Plattform des Clients mit dem Paket. Beim ersten Fehler zu stoppen hält eine einzige Variable im Spiel, und das ist der Unterschied zwischen einer Reparatur und einer Vermutung.

Für ein Telefon oder einen beliebigen Client außerhalb jenes historischen Desktop-Beispiels besorgen Sie sich den tatsächlich unterstützten Vertrag zwischen Client und Gateway, statt anzunehmen, der Windows-Ablauf lasse sich verallgemeinern. Ein anderes angefordertes Protokoll macht aus einem IKEv2-Profil nicht diesen SSL-VPN-Dienst, und die Installation eines Desktop-Pakets belegt nichts über Mobilfunkunterstützung.