Windows-VPN gegen Cisco Secure Client: Was gilt?
Eine Marke benennt kein Protokoll: Windows liefert mehrere native Typen, und der Cisco-Client enthält Profile für mehr als einen Modus. Lies das Profil.
Für dasselbe Gateway treffen zwei Anweisungen ein: Verbinde dich über das Windows-VPN oder installiere den Cisco-Client. Keine der beiden nennt den Austausch, den das Gateway erwartet, denn Windows bietet mehrere native Verbindungstypen und der Hersteller-Client enthält Profile für mehr als einen Modus. Beide Bezeichnungen beschreiben Software, während das Gateway Protokoll, Authentifizierung und Richtlinie aushandelt. Die Antwort steht im Profil, und man kann sie lesen, ohne sich zu verbinden.
Die Bezeichnung nennt Software, nicht einen Austausch
Eine Marke und ein Betriebssystem sind zwei verschiedene Tatsachen, und keine von beiden wählt ein Leitungsformat. Windows liefert eine Reihe nativer Typen, und der Cisco-Client liefert eine Profil-Engine, die SSL oder IPsec/IKEv2 ansteuern kann. Wer beides verwechselt, erzeugt Tabellen, die Unternehmen vergleichen statt Austausche.
Die folgende Tabelle ersetzt die Produktfrage durch drei Lesestellen und das Feld, das jede von ihnen enthält. Notiere diese Felder, und die Mehrdeutigkeit verschwindet:
| Where to read it | Field name to record | What a mismatch looks like |
|---|---|---|
| Native Windows profile | TunnelType and AuthenticationMethod from Get-VpnConnection | The client offers IKEv2 while the gateway answers only on an SSL port |
| Vendor client profile | SSL or IPsec/IKEv2 mode, plus the client and headend version pair | The imported profile negotiates a mode this headend does not serve |
| Gateway configuration | Protocol, authentication policy and the certificate the headend presents | The client authenticates and then drops, because policy expects another method |
Die Referenz zu den Windows-VPN-Typen, die Microsoft veröffentlicht, führt IKEv2 und SSTP unter den nativen Typen auf, was die Vorstellung beendet, dass ein natives Profil PPTP bedeutet. Die Profildokumentation von Cisco beschreibt sowohl den SSL- als auch den IPsec/IKEv2-Modus mit passender Headend-Richtlinie. Jeder Hersteller bietet mehrere Optionen, also benennt kein Name ein einziges Protokoll.
Was die nativen Typen auf die Leitung legen
IKEv2 handelt Sicherheitsassoziationen über UDP aus und trägt den Verkehr in IPsec, was es zu einem Gleichrangigen anderer IKEv2-Implementierungen macht und nicht zu einem Microsoft-spezifischen Entwurf. SSTP verpackt PPP in eine HTTPS-Sitzung, überquert deshalb Proxys, die IKEv2 nicht passieren kann, und sieht auf der Leitung wie TLS aus, ohne ein TLS-VPN-Protokoll zu sein. Diese beiden Tatsachen erklären den größten Teil eines Tickets, das meldet, der Tunnel funktioniere in einem Netz und scheitere in einem anderen.
L2TP mit IPsec und der ältere PPTP-Eintrag stehen im selben Dropdown, und ihre Anwesenheit dort sagt nichts über die Serverunterstützung aus. Ein Dropdown ist ein Menü dessen, was das Betriebssystem versuchen kann, keine Fähigkeitserklärung des Gateways. Wer es als Unterstützungsliste liest, beginnt damit eine zweistündige Suche nach Zugangsdaten.
Die Felder, die bei einem nativen Profil zählen, sind der Verbindungstyp, die Authentifizierungsmethode und die Serveridentität. Der falsche Typ scheitert in einer anderen Phase als ein schlechtes Passwort, und genau dieser Unterschied ist der Hinweis, dem man folgen sollte.
Was ein Hersteller-Client hinzufügt: Profile, kein Protokoll
Der Cisco-Client ist ein Behälter für Profile. Ein SSL-Modus und ein IPsec/IKEv2-Modus unterscheiden sich in Austausch, Port-Erwartungen und Fehlertext, und das importierte Profil wählt zwischen ihnen. Die Installation des Clients beweist daher nichts über die Erreichbarkeit.
Versionen sind aus einem Grund gepaart. Funktionen, Authentifizierungsabläufe und Posture-Prüfungen werden zwischen Client und Headend ausgehandelt, daher kann ein alter Client gegen ein neues Headend auf eine Weise scheitern, die wie ein Netzwerkfehler klingt. Diese Paarung gehört in die Verbindungsdefinition und nicht in eine Upgrade-Notiz.
Ein aus einer anderen Organisation exportiertes Profil passt selten zum lokalen Headend, und nach dem Import bietet der Client womöglich einen Modus an, den das Gateway nicht bedient. Lies zuerst den Modus aus dem Profil und vergleiche ihn dann mit dem konfigurierten Protokoll und der Authentifizierungsrichtlinie des Gateways. Erst wenn diese übereinstimmen, wird das Netzwerk verdächtig. Diese Reihenfolge erspart einen Paketmitschnitt, der eine gesunde TLS-Sitzung gezeigt hätte, die auf den falschen Dienst zeigte.
Lies das lokale Profil, bevor du etwas änderst
Unter Windows lässt sich die native Konfiguration ohne Einwahl lesen, und die Ausgabe nennt Typ und Authentifizierungsmethode direkt. Vergleiche diese Werte mit dem, was der Gateway-Besitzer als akzeptiert nennt. Weicht der Typ vom Ticket ab, korrigiere zuerst das Ticket, denn das ist billiger, als einen Client neu zu installieren, der nie falsch war.
Diese vier Befehle decken das Profil, seine Routen, den Verbindungsversuch und die Erreichbarkeit des Ports ab. Führe sie in dieser Reihenfolge auf einem Rechner aus, auf dem das Profil bereits installiert ist:
Get-VpnConnection | Format-List Name,TunnelType,AuthenticationMethod,ServerAddress
Get-VpnConnection -Name 'Corp' | Select-Object -ExpandProperty Routes
rasdial
Test-NetConnection -ComputerName vpn.example.com -Port 443Der Porttest ist der, der überinterpretiert wird. Ein TCP-Listener auf 443, der eine Anmeldeseite ausliefert, und einer, der IKEv2 terminiert, sehen von außen gleich aus, denn der Port ist ein Ort und kein Protokoll.
Schreibe das Ergebnis als drei Felder, Client, Modus und Gateway, und lege sie neben das Ticket. Alles Kürzere zwingt die nächste Person, dieselbe Mehrdeutigkeit neu zu entdecken.