Área de Trabalho Remota por VPN: em qual falha você está?

Seu túnel está ativo, a wiki interna carrega e a Área de Trabalho Remota continua recusando a conexão. Essa combinação é normal, porque a VPN fornece uma rota até o host enquanto o serviço de área de trabalho precisa estar escutando, autorizado pelo próprio firewall e disposto a autenticar a conta. Quatro estágios de falha separam um túnel funcional de uma sessão utilizável, e cada um falha com uma mensagem diferente. Leia a mensagem primeiro, porque ela nomeia o estágio.

Quatro falhas que parecem uma

Os estágios estão ordenados: o nome resolve para o endereço privado que o projeto pretende, a porta responde a um handshake TCP, o host aceita a conexão segundo a própria política e o logon da sessão tem sucesso. Cada estágio torna o seguinte impossível de testar, por isso alterar as configurações de RDP antes de a rede estar resolvida só produz ruído. O sintoma parece idêntico do lado do usuário nos quatro casos. Só a mensagem do cliente os separa.

Um site interno que funciona não prova nenhuma das quatro coisas. Prova que um host na mesma rede respondeu em outra porta com outro serviço. Trate isso como evidência sobre roteamento e nada mais.

Teste em ordem e anote o resultado. Saltar para a tela de logon porque a porta respondeu é a forma de perder uma tarde em um problema de firewall que o primeiro passo já localizou.

Algo está escutando na 3389?

Comece pelo nome, porque um nome que resolve para o endereço errado invalida todos os testes seguintes. Pergunte ao resolvedor do túnel o que o nome significa e depois compare a resposta com o endereço privado que o projeto pretende, não com uma resposta bem-sucedida. Um nome que resolve para um endereço público é todo o problema, e nenhuma mudança de RDP o corrigirá:

nslookup desktop.corp.example
Resolve-DnsName desktop.corp.example

Depois teste a porta, não o host. Um handshake TCP concluído na 3389 separa o alcance de tudo o que está acima:

Test-NetConnection -ComputerName desktop.corp.example -Port 3389

Execute esse teste a partir da LAN e do túnel, porque uma diferença entre os dois resultados localiza a falha no caminho da VPN. Há dois firewalls no caminho e é fácil confundi-los: a rede deve permitir que o endereço do túnel do cliente alcance o host, e o firewall do próprio host deve permitir essa mesma origem na porta que escuta. Uma regra limitada à sub-rede LAN não cobre o pool de clientes VPN, e é a causa mais comum de um tempo limite que só usuários remotos relatam. Verifique o escopo, não a existência da regra.

O caminho de volta merece a mesma verificação. As respostas precisam de uma rota de retorno ao pool de clientes e não à LAN, e uma tradução na frente do host muda a origem que o seu log mostrará. Se a porta responde em uma direção e não na outra, a metade que falta costuma ser o caminho de volta.

Leia a mensagem antes de ler a configuração

O terceiro estágio é o host recusando a conexão segundo a própria política, o que muitas vezes parece uma porta que abre e fecha imediatamente. Algo respondeu, e isso é informação útil em vez de silêncio. Se o handshake foi concluído e a sessão morreu na hora, a rede está bem e o host está decidindo. Verifique as permissões da Área de Trabalho Remota antes de tocar na rede novamente.

O recurso pode estar habilitado para a máquina enquanto o acesso é restrito a grupos específicos, e o ouvinte pode estar vinculado de formas que excluem o endereço de onde você veio. A Autenticação de Nível de Rede acrescenta um portão que falha antes de a área de trabalho carregar, e o texto do erro difere de uma senha incorreta. Compare a mensagem do cliente com o log de eventos do host, porque a mensagem nomeia o portão e o log nomeia a conta.

O logon na sessão é a própria fronteira

A autenticação pertence ao serviço de área de trabalho, não à VPN. A identidade do túnel e a conta da área de trabalho são credenciais separadas com políticas de bloqueio separadas, então um túnel funcional prova apenas que o túnel aceitou você. Bloquear a conta da área de trabalho não perturba o túnel, e o contrário também é verdadeiro.

Mantenha os dois intactos. Quando a rota privada falta, conserte a rota, porque publicar o ouvinte na internet troca um defeito de alcance por uma área de trabalho exposta. Também não enfraqueça as verificações de identidade da sessão para passar por um aviso de certificado que apareceu ao mesmo tempo. Um certificado autoassinado em um ouvinte RDP produz um aviso por design, então aceitá-lo é uma decisão e não um passo.

Conte as tentativas antes de tentar de novo. Os limites de bloqueio da área de trabalho contam logons falhos separadamente das falhas de VPN, e um cliente que tenta de novo por temporizador pode passar do limite enquanto você ainda edita uma regra. É o mesmo mecanismo de tentativas paralelas que bloqueia contas após uma troca de senha.

O que a sessão pode mover, e onde fica

Aprenda o fluxo de logoff aprovado antes de precisar dele. Fechar a janela pode apenas desconectar a visualização enquanto a sessão continua rodando segundo a política configurada, o que importa em um host compartilhado ou auditado. Faça logoff de dentro da sessão quando a política espera isso.

Depois decida o que a sessão pode transportar, porque a área de transferência, as unidades redirecionadas, o redirecionamento de impressora e a transferência de arquivos movem dados entre os sistemas local e remoto onde a política permite. Um aplicativo publicado rodando do outro lado não é automaticamente uma fronteira sem download, e uma sessão que parece somente leitura ainda pode transportar uma área de transferência. Teste a tarefa real e não a conexão: abra o arquivo, use o aplicativo e confirme o redirecionamento de que precisa. As orientações da Microsoft para chegar a uma área de trabalho remota de fora descrevem as opções de exposição suportadas, e são uma referência melhor do que um ouvinte público adicionado sob pressão.