Escritorio remoto mediante unha VPN: en que fallo estás?

O seu túnel está activo, a wiki interna carga e o escritorio remoto segue negándose a conectar. Esa combinación é normal, porque a VPN fornece unha ruta ata o servidor mentres o servizo de escritorio ten que estar escoitando, permitido pola súa propia devasa e disposto a autenticar a conta. Catro etapas de fallo separan un túnel funcional dunha sesión utilizábel, e cada unha falla cunha mensaxe diferente. Lea primeiro a mensaxe, porque nomea a etapa.

Catro fallos que parecen un

As etapas están ordenadas: o nome resolve á dirección privada que o deseño pretende, o porto responde a un handshake TCP, o servidor acepta a conexión segundo a súa propia política e o inicio de sesión da sesión ten éxito. Cada etapa fai que a seguinte non se poida probar, por iso cambiar os axustes de RDP antes de que a rede estea resolta só produce ruído. O síntoma parece idéntico desde o lado do usuario nos catro casos. Só a mensaxe do cliente os separa.

Un sitio web interno que funciona non demostra ningunha das catro cousas. Demostra que un servidor da mesma rede respondeu nun porto distinto cun servizo distinto. Tome isto como evidencia sobre o encamiñamento e nada máis.

Probe en orde e anote o resultado. Saltar á pantalla de inicio de sesión porque o porto respondeu é a forma de perder unha tarde nun problema de devasa que o primeiro paso xa localizou.

Hai algo escoitando no 3389?

Comece polo nome, porque un nome que resolve á dirección equivocada invalida todas as probas posteriores. Pregunte ao resolutor do túnel que significa o nome e despois compare a resposta coa dirección privada que o deseño pretende, non cunha resposta correcta. Un nome que resolve a unha dirección pública é todo o problema, e ningún cambio de RDP o arranxará:

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

Despois probe o porto en lugar do servidor. Un handshake TCP completado no 3389 separa o alcance de todo o que está por riba:

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

Execute esa proba desde a LAN e desde o túnel, porque unha diferenza entre ambos os resultados localiza o fallo na ruta da VPN. Na ruta hai dúas devasas e é fácil confundilas: a rede debe permitir que a dirección do túnel do cliente chegue ao servidor, e a devasa propia do servidor debe permitir esa mesma orixe no porto que escoita. Unha regra limitada á subrede LAN non cobre o grupo de clientes VPN, e é a causa máis común dun tempo de espera que só reportan os usuarios remotos. Comprobe o alcance, non a existencia da regra.

A rota de volta merece a mesma comprobación. As respostas necesitan unha ruta de regreso ao grupo de clientes e non á LAN, e unha tradución diante do servidor cambia a orixe que mostrará o seu rexistro. Se o porto responde nunha dirección e non na outra, a metade que falta adoita ser a rota de volta.

Lea a mensaxe antes de ler a configuración

A terceira etapa é o servidor rexeitando a conexión segundo a súa propia política, algo que a miúdo parece un porto que se abre e se pecha de inmediato. Algo respondeu, e iso é información útil en lugar de silencio. Se o handshake se completou e a sesión morreu decontado, a rede está ben e decide o servidor. Revise os permisos de escritorio remoto antes de volver tocar a rede.

A función pode estar activada para a máquina mentres o acceso se limita a grupos concretos, e o escoitante pode estar ligado de formas que exclúen a dirección desde a que chegou. A autenticación a nivel de rede engade unha porta que falla antes de que cargue o escritorio, e o seu texto de erro difire do dun contrasinal incorrecto. Compare a mensaxe do cliente co rexistro de eventos do servidor, porque a mensaxe nomea a porta e o rexistro, a conta.

O inicio de sesión é a súa propia fronteira

A autenticación pertence ao servizo de escritorio, non á VPN. A identidade do túnel e a conta do escritorio son credenciais separadas con políticas de bloqueo separadas, así que un túnel funcional só demostra que o túnel o aceptou. Bloquear a conta do escritorio non altera o túnel, e o contrario tamén é certo.

Manteña ambas intactas. Cando falta a ruta privada, arranxe a ruta, porque publicar o escoitante en internet cambia un fallo de alcance por un escritorio exposto. Tampouco debilite as comprobacións de identidade da sesión para pasar un aviso de certificado que apareceu ao mesmo tempo. Un certificado autoasinado nun escoitante RDP produce un aviso por deseño, así que aceptalo é unha decisión e non un paso.

Conte os intentos antes de reintentar. Os limiares de bloqueo do escritorio contan os inicios de sesión fallidos por separado dos fallos da VPN, e un cliente que reintenta cun temporizador pode superar o limiar mentres aínda está a editar unha regra. É o mesmo mecanismo de reintentos en paralelo que bloquea contas tras un cambio de contrasinal.

Que pode mover a sesión e onde queda

Aprenda o fluxo de peche de sesión aprobado antes de necesitalo. Pechar a xanela pode desconectar só a vista mentres a sesión segue executándose segundo a súa política configurada, o que importa nun servidor compartido ou auditado. Peche a sesión desde dentro cando a política o espera.

Despois decida que pode levar a sesión, porque o portapapeis, as unidades redirixidas, a redirección de impresoras e a transferencia de ficheiros moven datos entre os sistemas local e remoto onde a política o permite. Unha aplicación publicada que se executa ao outro lado non é automaticamente unha fronteira sen descargas, e unha sesión que parece de só lectura pode seguir levando un portapapeis. Probe a tarefa real e non a conexión: abra o ficheiro, use a aplicación e confirme a redirección que necesita. As indicacións de Microsoft para chegar a un escritorio remoto desde fóra describen as opcións de exposición admitidas, e son unha referencia mellor que un escoitante público engadido baixo presión.