Un port al camp d’adreça de la VPN de Windows només funciona amb SSTP

Un servidor VPN respon al TCP 10443, el client integrat de Windows té les credencials correctes i la connexió encara cau després d’una pausa que sembla un temps d’espera de DNS. La causa sol ser el camp d’adreça: escriure vpn.example.com:10443 a Nom del servidor o adreça fa que Windows llegeixi tota la cadena com un nom d’amfitrió, perquè aquesta casella no és una entrada general host:port. Que hi pugui haver un port depèn del tipus de túnel que utilitza el perfil, i només un dels quatre tipus tracta el valor com una cosa que pot analitzar.

Per què el camp d’adreça no és una casella host:port

La propietat del perfil que hi ha darrere d’aquest camp és ServerAddress, i cada tipus de túnel decideix què fa amb la cadena. Tres d’ells no tenen cap paràmetre de port per omplir, així que els dos punts i un número són simplement caràcters d’un nom que no es resoldrà mai. El quart funciona sobre HTTPS, on un port forma part de l’URL, de manera que el valor s’ha d’escriure en una forma que s’analitzi com a URL.

Per això la fallada sembla una resolució de noms i no una connexió rebutjada. No hi ha cap port dolent a reportar, només un nom d’amfitrió que no existeix, i l’error arriba després que el resolutor es rendeixi. Abans de tocar el servidor, comproveu quin tipus de túnel diu el perfil que utilitza.

Els tres tipus amb un port fix

PPTP es connecta al TCP 1723 i després transporta el túnel en GRE, protocol IP 47. L2TP/IPsec utilitza UDP 1701 per al túnel i UDP 500 més 4500 per a IPsec, amb 4500 com a port de travessa NAT. IKEv2 també utilitza UDP 500 i 4500. Cap d’aquests perfils exposa cap camp de port enlloc de la interfície, i cap negociarà un port no estàndard.

Un servidor que escolta en un port personalitzat és, doncs, inabastable per a aquests perfils, tant se val com s’escrigui l’adreça. Les respostes pràctiques són estretes: publiqueu el port estàndard al servidor o traduïu el port estàndard al personalitzat al router que hi ha al davant. Totes dues coses mantenen el perfil del client intacte, cosa que val molt quan el perfil es desplega per política i no s’escriu a mà.

SSTP necessita una URL, no un nom

SSTP és l’excepció perquè funciona dins d’una sessió TLS. El camp s’ha d’analitzar com una URL: primer l’esquema https://, després l’amfitrió, després dos punts i el port. Sense l’esquema, Windows continua tractant el valor com un nom simple i la connexió falla abans que es produeixi cap intercanvi TLS.

La raó per la qual això sorprèn la gent és que el port predeterminat accepta el nom d’amfitrió nu. Un perfil que mai no ha necessitat un port personalitzat no ensenya mai la regla, i la primera persona que n’afegeix un ho descobreix fallant. Després de desar, torneu a llegir el valor emmagatzemat en lloc de confiar en el diàleg:

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

ServerAddress mostra exactament què s’ha desat. Si es llegeix com un nom d’amfitrió nu amb dos punts, el perfil no va rebre mai cap URL i cap quantitat de reintents ho arreglarà.

Sintaxi de proveïdor que s’enganxa a la mateixa casella

Algunes passarel·les documenten convencions addicionals per a aquest camp, com ara un regne afegit després del port o paràmetres de consulta que canvien el tractament dels certificats. Les entén el servidor d’aquell proveïdor i, en algunes compilacions, el seu propi client. No formen part del format de perfil de Windows, i enganxar-les en un perfil integrat sol produir la mateixa fallada silenciosa de nom.

Tracteu un paràmetre que desactiva la validació de certificats com un avís i no com una solució. Si un perfil només es connecta amb aquest paràmetre, el certificat no coincideix amb el nom que s’utilitza, i la reparació correcta és a la passarel·la, no al client. Un regne després del port té la mateixa propietat: fa alguna cosa només si el servidor de l’altre costat l’espera.

Demostreu el port i després llegiu l’etapa que falla

Confirmeu que alguna cosa accepta TCP en aquest port des de la xarxa del client abans de culpar el perfil:

Test-NetConnection vpn.example.com -Port 10443

L’èxit demostra un oient, no SSTP. Un servidor web, un proxy invers o un balancejador de càrrega poden completar l’apretada de mans TCP i encara no parlar SSTP, així que una prova verda amb una VPN vermella és una combinació real. Compareu el subjecte del certificat amb el nom del perfil i reviseu el registre RasClient a les compilacions que el porten, perquè registra l’etapa que va fallar en lloc d’un temps d’espera genèric.

Després considereu l’opció que elimina el problema en lloc de documentar-lo: reenviar el TCP 443 de l’exterior al 10443 del servidor VPN. El client fa servir llavors el perfil predeterminat sense cap port, que sol ser la disposició més neta per a una flota gestionada i deixa el port personalitzat com un detall intern.