VPN di Windows contro Cisco Secure Client: quale vale?
Un marchio non nomina un protocollo: Windows offre diversi tipi nativi e il client Cisco porta profili per più di una modalità. Leggi il profilo.
Per lo stesso gateway arrivano due istruzioni: connettersi con la VPN di Windows o installare il client Cisco. Nessuna delle due nomina lo scambio che il gateway si aspetta, perché Windows espone diversi tipi di connessione nativi e il client del fornitore porta profili per più di una modalità. Entrambe le etichette descrivono software, mentre il gateway negozia protocollo, autenticazione e criteri. La risposta è nel profilo, e si può leggere senza connettersi.
L’etichetta nomina il software, non uno scambio
Un marchio e un sistema operativo sono due fatti diversi, e nessuno dei due sceglie un formato di filo. Windows fornisce un insieme di tipi nativi, e il client Cisco fornisce un motore di profili che può gestire SSL o IPsec/IKEv2. Confondere i due produce tabelle che confrontano aziende invece di confrontare scambi.
La tabella qui sotto sostituisce la domanda sul prodotto con tre luoghi di lettura e il campo che ciascuno contiene. Annota quei campi, e l’ambiguità scompare:
| 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 |
La documentazione Microsoft sui tipi di VPN di Windows elenca IKEv2 e SSTP tra i tipi nativi, il che scarta l’idea che un profilo nativo significhi PPTP. La documentazione sui profili di Cisco descrive sia la modalità SSL sia quella IPsec/IKEv2 con la relativa politica dell’headend. Ogni fornitore offre diverse opzioni, quindi nessun nome identifica un solo protocollo.
Che cosa mettono sul filo i tipi nativi
IKEv2 negozia associazioni di sicurezza su UDP e trasporta il traffico dentro IPsec, il che lo rende un pari di altre implementazioni IKEv2 e non un progetto specifico di Microsoft. SSTP incapsula PPP in una sessione HTTPS, quindi attraversa proxy che IKEv2 non può superare e sul filo sembra TLS senza essere un protocollo VPN TLS. Questi due fatti spiegano gran parte di un ticket che segnala il tunnel funzionante su una rete e non funzionante su un’altra.
L2TP con IPsec e la voce PPTP più vecchia stanno nello stesso menu a discesa, e la loro presenza lì non dice nulla sul supporto del server. Un menu a discesa è un elenco di ciò che il sistema operativo può tentare, non una dichiarazione di capacità del gateway. Leggerlo come un elenco di supporto è come comincia una caccia alle credenziali di due ore.
I campi che contano in un profilo nativo sono il tipo di connessione, il metodo di autenticazione e l’identità del server. Il tipo sbagliato fallisce in una fase diversa da una password sbagliata, e quella differenza è l’indizio che vale la pena seguire.
Che cosa aggiunge un client del fornitore: profili, non un protocollo
Il client Cisco è un contenitore di profili. Una modalità SSL e una modalità IPsec/IKEv2 differiscono per scambio, attese sulle porte e testo dell’errore, e il profilo importato sceglie tra le due. Installare il client, quindi, non dimostra nulla sulla raggiungibilità.
Le versioni sono accoppiate per una ragione. Funzioni, flussi di autenticazione e controlli di postura vengono negoziati tra client e headend, quindi un client vecchio contro un headend nuovo può fallire in un modo che si legge come un guasto di rete. Quell’accoppiamento appartiene alla definizione di connessione, non a una nota di aggiornamento.
Un profilo esportato da un’altra organizzazione raramente corrisponde all’headend locale, e importarlo può lasciare il client a offrire una modalità che il gateway non serve. Leggi prima la modalità dal profilo, poi confrontala con il protocollo e la politica di autenticazione configurati sul gateway. Solo quando coincidono la rete diventa sospetta. Questo ordine risparmia una cattura di pacchetti che avrebbe mostrato una sessione TLS sana puntata al servizio sbagliato.
Leggi il profilo locale prima di cambiare qualcosa
Su Windows la configurazione nativa si legge senza comporre, e l’output nomina direttamente il tipo e il metodo di autenticazione. Confronta quei valori con ciò che il proprietario del gateway dice che l’headend accetta. Se il tipo non concorda con il ticket, correggi prima il ticket, perché è più economico che reinstallare un client che non era mai sbagliato.
Questi quattro comandi coprono il profilo, le sue rotte, il tentativo di connessione e la raggiungibilità della porta. Eseguili in questo ordine su una macchina dove il profilo è già installato:
Get-VpnConnection | Format-List Name,TunnelType,AuthenticationMethod,ServerAddress
Get-VpnConnection -Name 'Corp' | Select-Object -ExpandProperty Routes
rasdial
Test-NetConnection -ComputerName vpn.example.com -Port 443Il test della porta è quello che viene sovrainterpretato. Un listener TCP 443 che serve una pagina di accesso e uno che termina IKEv2 sembrano identici dall’esterno, perché la porta è un luogo e non un protocollo.
Scrivi il risultato come tre campi, client, modalità e gateway, e tienili accanto al ticket. Qualsiasi cosa più breve lascia alla persona successiva riscoprire la stessa ambiguità.