La VPN integrata di Windows non raggiunge un gateway SSL del fornitore: perché

Windows include quattro tipi di tunnel, e un gateway SSL del fornitore non è uno di essi. Punta comunque un profilo integrato su uno di questi e la connessione fallisce prima della richiesta delle credenziali, di solito con un messaggio che dice che il sistema locale ha terminato la connessione. Quel testo è un segnale di disallineamento, non una diagnosi. Il tipo di profilo e il client che possiede il protocollo devono coincidere, e uno dei due manca.

Quattro tipi e una finestra di dialogo

Ogni profilo salvato porta un tipo di tunnel. Il client integrato accetta PPTP, L2TP, IKEv2 e SSTP, più una modalità automatica che li prova in ordine. Non esiste una voce SSL VPN generica, e non c’è modo di aggiungerne una dalla finestra di dialogo. Un gateway del fornitore parla il proprio protocollo applicativo su TLS, che solo il client di quel fornitore implementa.

L’elenco è a un comando di distanza, e vale la pena eseguirlo prima di qualsiasi altra diagnosi perché richiede un secondo ed elimina un’intera classe di supposizioni sbagliate:

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, SplitTunneling
Get-VpnConnection -Name "Office" | Format-List

Se il profilo dice SSTP e il gateway non è un server RRAS, il disallineamento è già stabilito. Nessun lavoro su certificati o firewall lo cambia.

SSTP e TLS del fornitore si somigliano sulla porta 443

SSTP incapsula una sessione PPP dentro TLS e viaggia su TCP 443. Nello stack Microsoft la termina RRAS, che presenta un certificato server che il client convalida. Anche un appliance Fortinet, Citrix o Pulse termina TLS sulla 443, e il suo portale si apre in qualsiasi browser senza lamentarsi.

Quel test nel browser dimostra la raggiungibilità, non la compatibilità. Il protocollo di sessione dietro il portale appartiene al fornitore, e il client integrato non ne ha alcuna implementazione. Sapere se il fornitore distribuisce un proprio client ti dice con quale metà del disallineamento hai a che fare.

Anche la confusione inversa si verifica. Un profilo configurato come SSTP contro un vero server RRAS può fallire la convalida del certificato mentre il portale è a posto, e questo è un problema di certificato e non di protocollo.

Errori che compaiono prima che esista un tunnel

I codici della serie 800 vengono segnalati prima che qualsiasi tunnel sia stabilito, per questo le regole del firewall raramente li spostano. L’errore 812 è una politica lato server che rifiuta il metodo di autenticazione offerto dal client. Gli altri dell’intervallo provengono dal gestore connessioni locale e non dalla rete.

Attiva la traccia prima di ricostruire qualsiasi cosa. La traccia nomina la fase che fallisce, e un nome di fase vale più del testo nella finestra di dialogo:

netsh ras set tracing * enable
Get-ChildItem "$env:windir\tracing" | Sort-Object LastWriteTime -Descending | Select-Object -First 5

Le tracce finiscono nella directory di traccia e restano lì finché non le cancelli, quindi disattiva la traccia dopo invece di lasciarla in funzione per settimane.

Un profilo connesso può comunque rompere tutto

Un profilo che si connette e poi rompe la navigazione, una condivisione locale o un motore per container ha un problema di routing, non di tunnel. Il gateway predefinito si è spostato nel tunnel, quindi ogni destinazione passa ora attraverso un peer che forse non la instrada.

Due controlli lo decidono. Uno è la proprietà di split tunneling sul profilo. L’altro è l’opzione per adattatore di usare il gateway predefinito sulla rete remota, che si trova nelle impostazioni avanzate di IPv4.

Set-VpnConnection -Name "Office" -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName "Office" -DestinationPrefix 10.20.0.0/16

Attivare lo split tunneling senza aggiungere route produce un tunnel che si connette e non raggiunge nulla. Disattivarlo senza controllare il DNS produce nomi interni che si risolvono in risposte pubbliche, perché il suffisso e i server propri dell’adattatore non vengono usati.

Verifica l’impianto, poi il tipo

Lavora in questo ordine, e fermati quando un passo fallisce invece di regolare tutto insieme:

Test-NetConnection vpn.example.net -Port 443
Get-VpnConnection -Name "Office" | Format-List TunnelType, ServerAddress, DnsSuffix
netsh interface ipv4 show route
rasdial Office

Il primo comando separa la raggiungibilità dal protocollo. Il secondo conferma ciò che il profilo dichiara di essere. La tabella delle route mostra se il tunnel ha catturato la route predefinita. Il comando di composizione riporta l’errore proprio del gestore connessioni, che spesso è più chiaro della finestra di dialogo.

Annota nel ticket il tipo di tunnel, il prodotto del gateway e l’errore esatto. La persona successiva sa allora in un minuto se si tratta di un disallineamento di protocollo, di un guasto del certificato o di una decisione di routing, invece di partire da “la VPN non funziona”.