Un porto no campo de enderezo da VPN de Windows só funciona con SSTP

Un servidor VPN responde en TCP 10443, o cliente integrado de Windows ten as credenciais correctas e a conexión segue a caer tras unha pausa que parece un tempo de espera de DNS. A causa adoita ser o campo de enderezo: escribir vpn.example.com:10443 en Nome do servidor ou enderezo fai que Windows lea toda a cadea como un nome de host, porque esa caixa non é unha entrada xeral host:port. Que se poida expresar alí un porto depende do tipo de túnel que use o perfil, e só un dos catro tipos trata o valor como algo que pode analizar.

Por que o campo de enderezo non é unha caixa host:port

A propiedade do perfil detrás dese campo é ServerAddress, e cada tipo de túnel decide que fai coa cadea. Tres deles non teñen ningún parámetro de porto que encher, así que dous puntos e un número son simplemente caracteres dun nome que nunca se resolverá. O cuarto funciona sobre HTTPS, onde un porto forma parte da URL, así que o valor debe escribirse nunha forma que se analice como tal.

Por iso o fallo parece unha resolución de nomes e non unha conexión rexeitada. Non hai ningún porto malo que informar, só un nome de host que non existe, e o erro chega despois de que o resolutor se renda. Antes de tocar o servidor, comprobe que tipo de túnel di usar o perfil.

Os tres tipos con porto fixo

PPTP conéctase a TCP 1723 e despois transporta o túnel en GRE, protocolo IP 47. L2TP/IPsec usa UDP 1701 para o túnel e UDP 500 máis 4500 para IPsec, con 4500 como porto de travesía NAT. IKEv2 tamén usa UDP 500 e 4500. Ningún deses perfís expón un campo de porto en ningún lugar da interface, e ningún negociará un porto non estándar.

Un servidor que escoita nun porto personalizado é, por tanto, inalcanzable para eses perfís, non importa como se escriba o enderezo. As respostas prácticas son estreitas: publique o porto estándar no servidor ou traduza o porto estándar ao personalizado no router que ten diante. Ambas manteñen intacto o perfil do cliente, algo que vale moito cando o perfil se despregue por directiva e non se escribe a man.

SSTP necesita unha URL, non un nome

SSTP é a excepción porque funciona dentro dunha sesión TLS. O campo debe analizarse como unha URL: primeiro o esquema https://, logo o host, logo dous puntos e o porto. Sen o esquema, Windows segue tratando o valor como un nome simple e a conexión falla antes de que se produza calquera intercambio TLS.

A razón pola que isto sorprende é que o porto predeterminado acepta o nome de host espido. Un perfil que nunca necesitou un porto personalizado nunca ensina a regra, e a primeira persoa que engade un descóbreo fallando. Despois de gardar, volva ler o valor almacenado en lugar de confiar no diálogo:

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

ServerAddress mostra exactamente o que se gardou. Se se le como un nome de host espido con dous puntos, o perfil nunca recibiu unha URL e ningunha cantidade de reintentos o arranxará.

Sintaxe de provedor que se pega na mesma caixa

Algunhas pasarelas documentan convencións adicionais para ese campo, como un reino engadido despois do porto ou parámetros de consulta que cambian o tratamento dos certificados. Enténdeos o servidor dese provedor e, nalgunhas compilacións, o seu propio cliente. Non forman parte do formato de perfil de Windows, e pegarlas nun perfil integrado adoita producir o mesmo fallo silencioso de nome.

Trate un parámetro que desactiva a validación de certificados como un aviso e non como unha solución. Se un perfil só se conecta con ese parámetro, o certificado non coincide co nome que se usa, e a reparación correcta está na pasarela, non no cliente. Un reino despois do porto ten a mesma propiedade: fai algo só se o servidor do outro lado o espera.

Demostre o porto e logo lea a etapa que falla

Confirme que algo acepta TCP nese porto desde a rede do cliente antes de culpar o perfil:

Test-NetConnection vpn.example.com -Port 10443

O éxito demostra un oínte, non SSTP. Un servidor web, un proxy inverso ou un balanceador de carga poden completar o aperto de mans TCP e aínda así non falar SSTP, así que unha proba verde cunha VPN vermella é unha combinación real. Compare o suxeito do certificado co nome do perfil e revise o rexistro RasClient nas compilacións que o inclúen, porque rexistra a etapa que fallou en lugar dun tempo de espera xenérico.

Despois considere a opción que elimina o problema en lugar de documentalo: reenviar o TCP 443 do exterior ao 10443 do servidor VPN. O cliente usa entón o perfil predeterminado sen ningún porto, que adoita ser a disposición máis limpa para unha frota xestionada e deixa o porto personalizado como detalle interno.