6 votos

Windows 2k3 y RDP problema a través de Internet edición (RDP funciona localmente)

Me pidió que echar un vistazo a los miembros de la familia' amigos' Win2k3 servidor de Escritorio Remoto ya no estaba trabajando, y estaban tratando de averiguar por qué. Este servidor se está ejecutando Win2k3 SP2.

He determinado que la Licencia de servicios estaban teniendo algunos problemas (de IDENTIFICADOR de Suceso 19, ver http://support.microsoft.com/kb/2021885 para más detalles) - esto fue corregido mediante la instalación de una revisión (http://support.microsoft.com/kb/983385) y la reactivación de licencias, por lo que ya no aparece el error. Sin embargo, las conexiones RDP de Internet todavía no.

El hardware de red que está conectado a un módem DSL a un SonicWALL TZ170 aparato, y que está conectado a un 24 puerto del switch, el cual suministra con cable acceso a una PC y a los 10 o 11 de clientes ligeros (Neoware).

Sólo para ir más allá de lo miró:
1. El puerto 3389 a la escucha en el servidor (netstat -a-o muestra ms-wbt-el servidor está a la escucha en 3389)
2. Portqry (desde un remoto sistema Win7) muestra que 3389 TCP Escucha, pero 3389 UDP está escuchando o filtrada (UDP sólo determina el audio, ¿no?)
3. Soy capaz de telnet al sistema desde un remoto sistema Win7, tanto el nombre de host/IP en el puerto 3389 y conectar bien.
4. RDP funciona localmente (es decir. conectar un ordenador portátil a la red local LAN, mstsc conecta muy bien con el servidor con el ordenador portátil con un interno de la 192.168.0.x dirección)
5. Un portscan el uso de nmap en un sistema remoto muestra que 3389 abierto.
6. No me di cuenta de un antivirus en el Win2k3 sistema (no estoy seguro si es que se ejecuta en los dispositivos SonicWALL, aunque no puedo comprobar que a medida que se olvidó la contraseña de administrador, y realmente me gustaría evitar hacer un restablecimiento de fábrica). El local firewall de Windows en el Win2k3 servidor no está habilitado.

Las conexiones al servidor de forma remota recibe este mensaje:

This computer can't connect to the remote computer.

Try connecting again. If the problem continues, contact the owner of the remote 
computer or your network administrator.

El Win2k3 servidor está bien backlevel sobre las correcciones/parches de Windows Update, aunque - pero, ¿por que iba a causar un problema cuando esto fue antes de la licencia problema está más allá de mí..como el sistema nunca había tenido una copia de seguridad completa (sólo copias de seguridad de los datos de usuario), he hecho una imagen de las unidades antes de ejecutar la revisión (por si acaso).

Alguna sugerencia? He hecho todo lo que puedo pensar de eso es la relativa a la concesión de licencias, puertos, etc. Como funciona a nivel local, pero no a través de Internet, lo único que yo podía pensar era en el Sonicwall estaba haciendo algo (aunque el port forward parece funcionar bien a la dirección IP interna de la win2k3 servidor, ya que se puede ver en el servicio como en su escucha)..

Justo al final de mi cuerda (y la paciencia).

Gracias.

Editar:

No estoy más en el sitio remoto en el momento, así que no puedo comprobar w/Wireshark - sin embargo, la comprobación de w/Wireshark de forma remota muestra que el servidor responde (SYN/ACK), pero la conexión no parece llegar.

Como usted puede decir, yo no soy tan versado en Win2k3; yo soy todo un tipo UNIX. /grin

El puerto 443 está abierto en el dispositivo SonicWALL, así que me pregunto si una Puerta de enlace de TS está siendo utilizado.

La modificación de la RDP de configuración para utilizar una Puerta de enlace de RD (RD/TS, lo que sea!) no me consiga un error de certificado de Sonicwall - exportar el certificado y la importación en la Raíz de Certificados de obras, pero tratando de volver a conectar dice el nombre (es decir. CN) no coincide - lo cual tiene sentido, ya que el FQDN que me estoy conectando a no coincide con el cert nombre (el certificado que he recibido desde el dispositivo Sonicwall muestra la IP interna de la Sonicwall 192.168.0.1, pero no un nombre completo).

A la derecha! Más confuso. /grin

2voto

Karthanon Puntos 31

Descubierto el tema:

Aunque el "netstat-a" no mostrar de servicios de terminal server de escuchar, se muestra por su nombre en lugar de puerto (es decir. muestra de ms-wbt-servidor, y no en el puerto 3389). Volví después de usar Wireshark/etc. para verificar la información que viene a través de que el servidor estaba haciendo a través de la red (la que se fue - yo le doy hasta las dos sugerencias anteriores, pero no tengo el rep para todavía!).

Resulta que alguien había establecido la RDP en el servidor para ejecutar en un puerto no estándar.

La clave del registro que contiene este es:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\Winstation\RDP-Tcp

He cambiado de nuevo 3389 (decimal) y guardado, y reinicia el servidor.

Servicios de Terminal server trabajó después de.

Tenga en cuenta que mi anterior cuenta por el puerto 443/Puerta de enlace de TS no era aplicable, como puertas de enlace de TS/443 se utiliza sólo para Windows Server 2008 (como por MS Technet).

1voto

Greg Askew Puntos 17236

Puede que desee utilizar NetMon o Wireshark en el servidor de Windows 2003 para validar que el sistema remoto de la conexión es en realidad lo que es el servidor en el 3389.

0voto

user48838 Puntos 7140

"Yo soy capaz de telnet al sistema desde un remoto sistema Win7, tanto el nombre de host/IP en el puerto 3389 y conectar bien"

Comparar el telnet pancartas de conexión entre "a través de Internet" y "a nivel local dentro de la red" para ver si coinciden.

  • Si no, a continuación, empezar a trabajar su manera de salir hacia Internet de la red.
  • Si coinciden, entonces puede ser una configuración del sistema/problema de interoperabilidad.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: