Uma porta no campo de endereço da VPN do Windows só funciona com SSTP

Um servidor VPN responde no TCP 10443, o cliente integrado do Windows tem as credenciais certas e a ligação morre mesmo assim após uma pausa que parece um tempo limite de DNS. A causa costuma ser o campo de endereço: escrever vpn.example.com:10443 em Nome do servidor ou endereço faz o Windows ler toda a cadeia como um nome de anfitrião, porque essa caixa não é uma entrada host:port genérica. Se uma porta pode sequer ser expressa ali depende do tipo de túnel usado pelo perfil, e só um dos quatro tipos trata o valor como algo que consegue analisar.

Porque é que o campo de endereço não é uma caixa host:port

A propriedade do perfil por trás desse campo é ServerAddress, e cada tipo de túnel decide o que faz com a cadeia. Três deles não têm qualquer parâmetro de porta para preencher, por isso os dois pontos e um número são apenas caracteres num nome que nunca será resolvido. O quarto corre sobre HTTPS, onde uma porta faz parte do URL, por isso o valor tem de ser escrito numa forma que seja analisada como tal.

É por isso que a falha parece uma resolução de nomes e não uma ligação recusada. Não há nenhuma porta má a comunicar, apenas um nome de anfitrião que não existe, e o erro chega depois de o resolvedor desistir. Antes de tocar no servidor, verifique que tipo de túnel o perfil afirma usar.

Os três tipos com porta fixa

O PPTP liga-se ao TCP 1723 e depois transporta o túnel em GRE, protocolo IP 47. O L2TP/IPsec usa UDP 1701 para o túnel e UDP 500 mais 4500 para IPsec, sendo 4500 a porta de travessia NAT. O IKEv2 também usa UDP 500 e 4500. Nenhum desses perfis expõe um campo de porta em qualquer parte da interface, e nenhum negociará uma porta não padrão.

Um servidor à escuta numa porta personalizada é, por isso, inalcançável para esses perfis, independentemente de como o endereço é escrito. As respostas práticas são estreitas: publicar a porta padrão no servidor, ou traduzir a porta padrão para a personalizada no router à sua frente. Ambas deixam o perfil do cliente intacto, o que vale muito quando o perfil é implementado por política e não escrito à mão.

O SSTP precisa de um URL, não de um nome

O SSTP é a exceção porque corre dentro de uma sessão TLS. O campo tem de ser analisado como URL: primeiro o esquema https://, depois o anfitrião, depois dois pontos e a porta. Sem o esquema, o Windows continua a tratar o valor como um nome simples e a ligação falha antes de qualquer troca TLS.

A razão pela qual isto surpreende é que a porta predefinida aceita o nome de anfitrião nu. Um perfil que nunca precisou de uma porta personalizada nunca ensina a regra, e a primeira pessoa que acrescenta uma descobre-a ao falhar. Depois de guardar, leia o valor armazenado em vez de confiar na caixa de diálogo:

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

ServerAddress mostra exatamente o que foi armazenado. Se for lido como um nome de anfitrião nu com dois pontos, o perfil nunca recebeu um URL e nenhuma quantidade de novas tentativas o corrigirá.

Sintaxe de fornecedor que é colada na mesma caixa

Alguns gateways documentam convenções adicionais para esse campo, como um realm acrescentado depois da porta ou parâmetros de consulta que alteram o tratamento dos certificados. São compreendidas pelo servidor desse fornecedor e, em algumas compilações, pelo seu próprio cliente. Não fazem parte do formato de perfil do Windows, e colá-las num perfil integrado produz normalmente a mesma falha silenciosa de nome.

Trate um parâmetro que desativa a validação de certificados como um aviso e não como uma correção. Se um perfil só se liga com esse parâmetro, o certificado não corresponde ao nome em uso, e a reparação correta é no gateway, não no cliente. Um realm depois da porta tem a mesma propriedade: só faz algo se o servidor do outro lado o esperar.

Prove a porta e depois leia a etapa que falha

Confirme que algo aceita TCP nessa porta a partir da rede do cliente antes de culpar o perfil:

Test-NetConnection vpn.example.com -Port 10443

O sucesso prova um ouvinte, não o SSTP. Um servidor web, um proxy inverso ou um balanceador de carga podem concluir o aperto de mão TCP e ainda assim não falar SSTP, por isso um teste verde com uma VPN vermelha é uma combinação real. Compare o sujeito do certificado com o nome no perfil e verifique o registo RasClient nas compilações que o incluem, porque regista a etapa que falhou em vez de um tempo limite genérico.

Considere depois a opção que elimina o problema em vez de o documentar: encaminhe o TCP 443 do exterior para 10443 no servidor VPN. O cliente usa então o perfil predefinido sem qualquer porta, o que costuma ser a disposição mais limpa para uma frota gerida e deixa a porta personalizada como detalhe interno.