Una porta nel campo indirizzo della VPN di Windows funziona solo con SSTP

Un server VPN risponde su TCP 10443, il client integrato di Windows ha le credenziali giuste e la connessione muore comunque dopo una pausa che sembra un timeout DNS. La causa di solito è il campo indirizzo: digitare vpn.example.com:10443 in Nome server o indirizzo fa leggere a Windows l’intera stringa come un nome host, perché quella casella non è un input host:port generico. Che una porta possa essere espressa lì dipende dal tipo di tunnel usato dal profilo, e solo uno dei quattro tipi tratta il valore come qualcosa che sa analizzare.

Perché il campo indirizzo non è una casella host:port

La proprietà del profilo dietro quel campo è ServerAddress, e ogni tipo di tunnel decide cosa fa con la stringa. Tre di essi non hanno alcun parametro di porta da riempire, quindi i due punti e un numero sono solo caratteri in un nome che non verrà mai risolto. Il quarto passa su HTTPS, dove una porta fa parte dell’URL, quindi il valore va scritto in una forma che si analizzi come tale.

Per questo l’errore sembra una risoluzione di nomi e non una connessione rifiutata. Non c’è nessuna porta sbagliata da segnalare, solo un nome host che non esiste, e l’errore arriva dopo che il resolver si arrende. Prima di toccare il server, verificate quale tipo di tunnel dichiara di usare il profilo.

I tre tipi con porta fissa

PPTP si connette a TCP 1723 e poi trasporta il tunnel in GRE, protocollo IP 47. L2TP/IPsec usa UDP 1701 per il tunnel e UDP 500 più 4500 per IPsec, con 4500 come porta di traversata NAT. IKEv2 usa anch’esso UDP 500 e 4500. Nessuno di questi profili espone un campo porta da nessuna parte nell’interfaccia, e nessuno negozierà una porta non standard.

Un server in ascolto su una porta personalizzata è quindi irraggiungibile per quei profili, indipendentemente da come è scritto l’indirizzo. Le risposte pratiche sono ristrette: pubblicare la porta standard sul server, o tradurre la porta standard in quella personalizzata sul router che lo precede. Entrambe lasciano intatto il profilo del client, cosa che vale molto quando il profilo viene distribuito tramite criteri invece che digitato a mano.

SSTP ha bisogno di un URL, non di un nome

SSTP è l’eccezione perché gira dentro una sessione TLS. Il campo deve essere analizzato come URL: prima lo schema https://, poi l’host, poi i due punti e la porta. Senza lo schema, Windows continua a trattare il valore come un nome semplice e la connessione fallisce prima che avvenga qualsiasi scambio TLS.

Il motivo per cui questo sorprende è che la porta predefinita accetta il nome host nudo. Un profilo che non ha mai avuto bisogno di una porta personalizzata non insegna mai la regola, e la prima persona che ne aggiunge una lo scopre fallendo. Dopo aver salvato, rileggete il valore memorizzato invece di fidarvi della finestra di dialogo:

Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType

ServerAddress mostra esattamente ciò che è stato salvato. Se si legge come un nome host nudo con i due punti, il profilo non ha mai ricevuto un URL e nessun numero di nuovi tentativi lo sistemerà.

La sintassi dei fornitori che viene incollata nella stessa casella

Alcuni gateway documentano convenzioni aggiuntive per quel campo, come un realm aggiunto dopo la porta o parametri di query che cambiano la gestione dei certificati. Sono comprese dal server di quel fornitore e, in alcune build, dal suo stesso client. Non fanno parte del formato di profilo di Windows, e incollarle in un profilo integrato di solito produce lo stesso errore silenzioso di nome.

Trattate un parametro che disattiva la convalida dei certificati come un avviso e non come una correzione. Se un profilo si connette solo con quel parametro, il certificato non corrisponde al nome in uso, e la riparazione corretta è sul gateway, non nel client. Un realm dopo la porta ha la stessa proprietà: fa qualcosa solo se il server dall’altra parte se lo aspetta.

Dimostrate la porta, poi leggete la fase che fallisce

Confermate che qualcosa accetta TCP su quella porta dalla rete del client prima di dare la colpa al profilo:

Test-NetConnection vpn.example.com -Port 10443

Il successo dimostra un ascoltatore, non SSTP. Un server web, un proxy inverso o un bilanciatore di carico possono completare l’handshake TCP e comunque non parlare SSTP, quindi un test verde con una VPN rossa è una combinazione reale. Confrontate il soggetto del certificato con il nome nel profilo e controllate il registro RasClient nelle build che lo includono, perché registra la fase fallita invece di un timeout generico.

Considerate poi l’opzione che elimina il problema invece di documentarlo: inoltrare TCP 443 dall’esterno alla 10443 sul server VPN. Il client usa allora il profilo predefinito senza alcuna porta, che di solito è la sistemazione più pulita per una flotta gestita e lascia la porta personalizzata come dettaglio interno.