Windows-VPN versus Cisco Secure Client: welke geldt?
Een merk noemt geen protocol: Windows levert meerdere eigen typen en de Cisco-client draagt profielen voor meer dan één modus. Lees het profiel.
Voor dezelfde gateway komen twee instructies binnen: verbind met de Windows-VPN of installeer de Cisco-client. Geen van beide noemt de uitwisseling die de gateway verwacht, omdat Windows meerdere eigen verbindingstypen toont en de client van de leverancier profielen draagt voor meer dan één modus. Beide labels beschrijven software, terwijl de gateway protocol, authenticatie en beleid onderhandelt. Het antwoord staat in het profiel, en dat is te lezen zonder te verbinden.
Het label noemt software, geen uitwisseling
Een merk en een besturingssysteem zijn twee verschillende feiten, en geen van beide kiest een draadformaat. Windows levert een reeks eigen typen, en de Cisco-client levert een profielengine die SSL of IPsec/IKEv2 kan aansturen. De twee verwarren levert diagrammen op die bedrijven vergelijken in plaats van uitwisselingen.
De tabel hieronder vervangt de productvraag door drie leesplekken en het veld dat elk daarvan bevat. Noteer die velden, en de dubbelzinnigheid verdwijnt:
| 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 |
Microsofts referentie voor VPN-typen in Windows noemt IKEv2 en SSTP onder de eigen typen, wat het idee wegneemt dat een eigen profiel PPTP betekent. De profieldocumentatie van Cisco beschrijft zowel de SSL-modus als de IPsec/IKEv2-modus met bijpassend headend-beleid. Elke leverancier biedt meerdere opties, dus geen van de namen wijst één protocol aan.
Wat de eigen typen op de draad zetten
IKEv2 onderhandelt beveiligingsassociaties over UDP en draagt verkeer binnen IPsec, wat het een gelijke maakt van andere IKEv2-implementaties en geen Microsoft-specifiek ontwerp. SSTP verpakt PPP in een HTTPS-sessie, dus het gaat door proxy's waar IKEv2 niet doorheen kan en ziet er op de draad uit als TLS zonder een TLS-VPN-protocol te zijn. Die twee feiten verklaren het grootste deel van een ticket dat meldt dat de tunnel op het ene netwerk werkt en op het andere faalt.
L2TP met IPsec en de oudere PPTP-vermelding staan in dezelfde vervolgkeuzelijst, en hun aanwezigheid daar zegt niets over serverondersteuning. Een vervolgkeuzelijst is een menu van wat het besturingssysteem kan proberen, geen capaciteitsverklaring van de gateway. Hem als ondersteuningslijst lezen is hoe een zoektocht van twee uur naar inloggegevens begint.
De velden die in een eigen profiel tellen, zijn het verbindingstype, de authenticatiemethode en de identiteit van de server. Het verkeerde type faalt in een andere fase dan een slecht wachtwoord, en dat verschil is het spoor dat het volgen waard is.
Wat een client van de leverancier toevoegt: profielen, geen protocol
De Cisco-client is een container voor profielen. Een SSL-modus en een IPsec/IKEv2-modus verschillen in uitwisseling, poortverwachtingen en fouttekst, en het geïmporteerde profiel kiest tussen beide. Het installeren van de client bewijst dus niets over bereikbaarheid.
Versies worden om een reden gepaard. Functies, authenticatiestromen en postuurcontroles worden tussen client en headend onderhandeld, dus een oude client tegen een nieuwe headend kan falen op een manier die als een netwerkstoring leest. Die paring hoort in de verbindingsdefinitie, niet in een upgradenotitie.
Een profiel dat uit een andere organisatie is geëxporteerd, past zelden bij de lokale headend, en het importeren ervan kan de client een modus laten aanbieden die de gateway niet bedient. Lees eerst de modus uit het profiel en vergelijk die daarna met het geconfigureerde protocol en authenticatiebeleid van de gateway. Pas als die overeenkomen, wordt het netwerk verdacht. Die volgorde bespaart een pakketopname die een gezonde TLS-sessie zou hebben getoond die op de verkeerde dienst was gericht.
Lees het lokale profiel voordat je iets verandert
Op Windows is de eigen configuratie te lezen zonder te bellen, en de uitvoer noemt het type en de authenticatiemethode direct. Vergelijk die waarden met wat de eigenaar van de gateway zegt dat de headend accepteert. Als het type niet met het ticket overeenkomt, corrigeer dan eerst het ticket, want dat is goedkoper dan een client opnieuw installeren die nooit fout was.
Deze vier opdrachten dekken het profiel, de routes ervan, de verbindingspoging en de bereikbaarheid van de poort. Voer ze in die volgorde uit op een machine waarop het profiel al is geïnstalleerd:
Get-VpnConnection | Format-List Name,TunnelType,AuthenticationMethod,ServerAddress
Get-VpnConnection -Name 'Corp' | Select-Object -ExpandProperty Routes
rasdial
Test-NetConnection -ComputerName vpn.example.com -Port 443De poorttest is degene die te veel wordt gelezen. Een TCP 443-luisteraar die een inlogpagina serveert en een die IKEv2 beëindigt, zien er van buiten hetzelfde uit, omdat de poort een plek is en geen protocol.
Schrijf het resultaat als drie velden, client, modus en gateway, en houd ze naast het ticket. Alles korter laat de volgende persoon dezelfde dubbelzinnigheid opnieuw ontdekken.