Windows-VPN teenoor Cisco Secure Client: wat geld?
’n Handelsnaam noem nie ’n protokol nie: Windows lewer verskeie inheemse tipes en die Cisco-kliënt dra profiele vir meer as een modus. Lees die profiel.
Vir dieselfde gateway kom twee instruksies aan: koppel met die Windows-VPN, of installeer die Cisco-kliënt. Nie een van die twee noem die uitruiling wat die gateway verwag nie, want Windows bied verskeie inheemse verbindingstipes en die verskaffer-kliënt dra profiele vir meer as een modus. Albei etikette beskryf sagteware, terwyl die gateway protokol, verifikasie en beleid onderhandel. Die antwoord lê in die profiel, en dit kan gelees word sonder om te koppel.
Die etiket noem sagteware, nie ’n uitruiling nie
’n Handelsnaam en ’n bedryfstelsel is twee verskillende feite, en nie een van die twee kies ’n draadformaat nie. Windows lewer ’n stel inheemse tipes, en die Cisco-kliënt lewer ’n profiel-enjin wat SSL of IPsec/IKEv2 kan dryf. Om die twee te verwar lewer diagramme wat maatskappye vergelyk in plaas van uitruilings.
Die tabel hieronder vervang die produkvraag met drie leesplekke en die veld wat elkeen hou. Teken daardie velde aan, en die dubbelsinnigheid verdwyn:
| 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 Windows-VPN-tipeverwysing wat Microsoft publiseer, lys IKEv2 en SSTP onder die inheemse tipes, wat die idee dat ’n inheemse profiel PPTP beteken, aftakel. Cisco se profieldokumentasie beskryf beide die SSL- en die IPsec/IKEv2-modus met bypassende headend-beleid. Elke verskaffer bied verskeie opsies, so geen van die name dui een protokol aan nie.
Wat die inheemse tipes op die draad sit
IKEv2 onderhandel sekuriteitsassosiasies oor UDP en dra verkeer binne IPsec, wat dit ’n gelyke maak van ander IKEv2-implementerings eerder as ’n Microsoft-spesifieke ontwerp. SSTP verpak PPP binne ’n HTTPS-sessie, so dit steek deur instaanbedieners wat IKEv2 nie kan nie en lyk soos TLS op die draad sonder om ’n TLS-VPN-protokol te wees. Daardie twee feite verduidelik die meeste van ’n tiket wat rapporteer dat die tonnel op een netwerk werk en op ’n ander misluk.
L2TP met IPsec en die ouer PPTP-inskrywing sit in dieselfde aftreklys, en hul teenwoordigheid daar sê niks oor bedienerondersteuning nie. ’n Aftreklys is ’n spyskaart van wat die bedryfstelsel kan probeer, nie ’n vermoëverklaring van die gateway nie. Om dit as ’n ondersteuningslys te lees, is hoe ’n soektog van twee uur na aanmeldgegewens begin.
Die velde wat by ’n inheemse profiel saak maak, is die verbindingstipe, die verifikasiemetode en die bedieneridentiteit. Die verkeerde tipe misluk in ’n ander fase as ’n slegte wagwoord, en daardie verskil is die leidraad wat die moeite werd is om te volg.
Wat ’n verskaffer-kliënt byvoeg: profiele, nie ’n protokol nie
Die Cisco-kliënt is ’n houer vir profiele. ’n SSL-modus en ’n IPsec/IKEv2-modus verskil in uitruiling, poortverwagtinge en foutteks, en die ingevoerde profiel kies tussen hulle. Om die kliënt te installeer bewys dus niks oor bereikbaarheid nie.
Weergawes word om ’n rede gepaar. Funksies, verifikasiestrome en postuurtoetse word tussen kliënt en headend onderhandel, so ’n ou kliënt teen ’n nuwe headend kan misluk op ’n manier wat soos ’n netwerkfout lees. Daardie paring hoort in die verbindingsdefinisie, nie in ’n opgraderingsnota nie.
’n Profiel wat uit ’n ander organisasie uitgevoer is, pas selde by die plaaslike headend, en om dit in te voer kan die kliënt ’n modus laat bied wat die gateway nie bedien nie. Lees eers die modus uit die profiel en vergelyk dit dan met die gateway se gekonfigureerde protokol en verifikasiebeleid. Eers nadat dié ooreenstem, word die netwerk ’n verdagte. Daardie volgorde spaar ’n pakkie-opname wat ’n gesonde TLS-sessie sou wys wat op die verkeerde diens gerig is.
Lees die plaaslike profiel voordat jy iets verander
Op Windows kan die inheemse konfigurasie sonder skakel gelees word, en die uitvoer noem die tipe en die verifikasiemetode direk. Vergelyk dié waardes met wat die gateway-eienaar sê die headend aanvaar. As die tipe met die tiket verskil, korrigeer eers die tiket, want dit is goedkoper as om ’n kliënt te herinstalleer wat nooit verkeerd was nie.
Hierdie vier opdragte dek die profiel, sy roetes, die verbindingspoging en die bereikbaarheid van die poort. Voer hulle in daardie volgorde uit op ’n masjien waarop die profiel reeds geïnstalleer is:
Get-VpnConnection | Format-List Name,TunnelType,AuthenticationMethod,ServerAddress
Get-VpnConnection -Name 'Corp' | Select-Object -ExpandProperty Routes
rasdial
Test-NetConnection -ComputerName vpn.example.com -Port 443Die poorttoets is die een wat oorgelees word. ’n TCP-443-luisteraar wat ’n aanmeldbladsy bedien en een wat IKEv2 termineer, lyk van buite identies, want die poort is ’n plek en nie ’n protokol nie.
Skryf die resultaat as drie velde, kliënt, modus en gateway, en hou hulle langs die tiket. Enigiets korter laat die volgende persoon dieselfde dubbelsinnigheid herontdek.