VPN în Windows versus Cisco Secure Client: care este corect?
Un brand nu numește un protocol: Windows oferă mai multe tipuri native, iar clientul Cisco poartă profiluri pentru mai mult de un mod. Citiți profilul.
Pentru același gateway sosesc două instrucțiuni: conectați-vă cu VPN-ul din Windows sau instalați clientul Cisco. Niciuna nu numește schimbul pe care îl așteaptă gateway-ul, pentru că Windows expune mai multe tipuri native de conexiune și clientul furnizorului poartă profiluri pentru mai mult de un mod. Ambele etichete descriu software, în timp ce gateway-ul negociază protocol, autentificare și politică. Răspunsul este în profil și poate fi citit fără conectare.
Eticheta numește software, nu un schimb
Un brand și un sistem de operare sunt două fapte diferite, iar niciunul nu alege un format pe fir. Windows livrează un set de tipuri native, iar clientul Cisco livrează un motor de profiluri care poate conduce SSL sau IPsec/IKEv2. Confundarea celor două produce tabele care compară companii în loc de schimburi.
Tabelul de mai jos înlocuiește întrebarea despre produs cu trei locuri de citire și câmpul pe care îl ține fiecare. Notați acele câmpuri, iar ambiguitatea dispare:
| 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 |
Referința Microsoft despre tipurile de VPN din Windows enumeră IKEv2 și SSTP printre tipurile native, ceea ce elimină ideea că un profil nativ înseamnă PPTP. Documentația Cisco despre profiluri descrie atât modul SSL, cât și modul IPsec/IKEv2, cu politica corespunzătoare a nodului central. Fiecare furnizor oferă mai multe opțiuni, așa că niciun nume nu identifică un singur protocol.
Ce pun tipurile native pe fir
IKEv2 negociază asocieri de securitate prin UDP și transportă traficul în interiorul IPsec, ceea ce îl face egal cu alte implementări IKEv2, nu un design specific Microsoft. SSTP înfășoară PPP într-o sesiune HTTPS, așa că trece prin proxy-uri prin care IKEv2 nu poate și pe fir arată ca TLS fără a fi un protocol VPN TLS. Aceste două fapte explică cea mai mare parte a unui tichet care raportează că tunelul funcționează într-o rețea și eșuează în alta.
L2TP cu IPsec și intrarea mai veche PPTP stau în același meniu derulant, iar prezența lor acolo nu spune nimic despre suportul serverului. Un meniu derulant este o listă cu ce poate încerca sistemul de operare, nu o declarație de capabilitate a gateway-ului. A-l citi ca listă de suport este felul în care începe o vânătoare de două ore după acreditări.
Câmpurile care contează într-un profil nativ sunt tipul conexiunii, metoda de autentificare și identitatea serverului. Tipul greșit eșuează într-o etapă diferită față de o parolă rea, iar acea diferență este urma care merită urmată.
Ce adaugă un client al furnizorului: profiluri, nu un protocol
Clientul Cisco este un container pentru profiluri. Un mod SSL și un mod IPsec/IKEv2 diferă prin schimb, așteptări de port și textul erorii, iar profilul importat alege între ele. Instalarea clientului nu dovedește, așadar, nimic despre accesibilitate.
Versiunile sunt împerecheate dintr-un motiv. Funcțiile, fluxurile de autentificare și verificările de postură se negociază între client și nodul central, așa că un client vechi în fața unui nod nou poate eșua într-un mod care se citește ca o defecțiune de rețea. Acea împerechere aparține definiției conexiunii, nu unei note de actualizare.
Un profil exportat din altă organizație se potrivește rar cu nodul central local, iar importul lui poate lăsa clientul să ofere un mod pe care gateway-ul nu îl deservește. Citiți mai întâi modul din profil, apoi comparați-l cu protocolul și politica de autentificare configurate pe gateway. Doar când acestea coincid rețeaua devine suspectă. Această ordine economisește o captură de pachete care ar fi arătat o sesiune TLS sănătoasă îndreptată spre serviciul greșit.
Citiți profilul local înainte de a schimba ceva
În Windows configurația nativă poate fi citită fără apelare, iar rezultatul numește direct tipul și metoda de autentificare. Comparați acele valori cu ce spune proprietarul gateway-ului că acceptă nodul central. Dacă tipul nu se potrivește cu tichetul, corectați mai întâi tichetul, pentru că este mai ieftin decât reinstalarea unui client care nu a fost niciodată greșit.
Aceste patru comenzi acoperă profilul, rutele lui, încercarea de conectare și accesibilitatea portului. Rulați-le în această ordine pe o mașină care are deja profilul instalat:
Get-VpnConnection | Format-List Name,TunnelType,AuthenticationMethod,ServerAddress
Get-VpnConnection -Name 'Corp' | Select-Object -ExpandProperty Routes
rasdial
Test-NetConnection -ComputerName vpn.example.com -Port 443Testul portului este cel care este citit în exces. Un ascultător TCP 443 care servește o pagină de autentificare și unul care termină IKEv2 arată identic din exterior, pentru că portul este un loc, nu un protocol.
Scrieți rezultatul ca trei câmpuri, client, mod și gateway, și țineți-le lângă tichet. Orice mai scurt lasă următoarea persoană să redescopere aceeași ambiguitate.