Estoy ejecutando Windows Server 2008 R2, tenemos una aplicación que se conecta desde (se une a) una IP pública en el servidor a 127.0.0.1:8334 [se conecta a un servicio que escucha en 0.0.0.0:8334]
En Windows 2003, no hubo problema con esto. Podemos conectarnos usando TCP desde 1.2.3.4 [por ejemplo] a 127.0.0.1:8334 muy bien.
En Windows 2008, encontramos que las conexiones TCP desde la IP pública, por ejemplo, 1.2.3.4 a 127.0.0.1:8334 fallan, incluso. pero el servicio acepta conexiones desde 127.0.0.1 a 127.0.0.1:8334 y 127.0.0.1 a 1.2.3.4:8334.
Intenté desactivar el firewall de Windows, configurar su registro, etc. (no aparecieron entradas de registro útiles), pero fue en vano. ¿Es este un problema con la nueva pila de red?
ediciones
1.2.3.4 está intentando conectarse a localhost [127.0.0.1] en la misma máquina
El archivo de hosts es el archivo de host predeterminado de Windows 2008.
Información de verificación de bucle invertido, interesante. Lo probé ... no funcionó. Realicé una verificación cruzada para verificar que Id hubiera hecho todo correctamente, lo he hecho.
Me pregunto si hay una solución usando NAT o alguna otra forma de reenviar puertos: si reenvío 127.0.0.1:port a 1.2.3.4:port, ¿funcionaría? Dado que la aplicación escucha en 0.0.0.0:port, tomaría conexiones en 1.2.3.4:port
El archivo HOSTS contiene localhost 127.0.0.1; sin embargo, el archivo hosts solo se usa en las búsquedas de nombres de host. En este caso, nuestra aplicación no buscaría ningún nombre de host, ya que la dirección IP 127.0.0.1 está codificada (en lugar del nombre de host localhost). Entonces el archivo HOSTS no entraría en juego aquí.
En cuanto a los puertos superiores a 1024 [¿crees que te refieres al problema de MaxUserPort quizás?] Lo probé al intentar una simple conexión al puerto 445: funciona desde 127.0.0.1, no funciona cuando me conecto desde la fuente IP 1.2.3.4. 445 es un servicio estándar de Windows, ¡así que debería funcionar!
Actualmente no ejecuta NAT o RRAS en la máquina ... me preguntaba si había una manera de cambiar el ruteo. Supongo que no funcionará ya que la pila TCP / IP rechazará el paquete antes de que llegue a la interfaz de bucle invertido para redirigirlo.
La impresión de ruta que había verificado - parece estar bien, las IP públicas enrutadas primero, luego finalmente 127.0.0.0 netmask 255.255.255.0 y 127.0.0.1 netmask 255.255.255.255 ambas al loopback.
Editar Parece que he encontrado la respuesta en cuanto a la razón del problema. Utilicé eventvwr.msc, habilité el registro de Winsock, apagué otros servicios, solo probé esta prueba de conexión. Obtuve un error que en hexadecimal se asignó a STATUS_INVALID_ADDRESS_COMPONENT cuando lo busqué en Google.
Eso me llevó a: http://social.msdn.microsoft.com/Forums/en-US/wfp/thread/d7cb6138-3f67-4467-a068-8325f56739ba
Lo que confirmó que este es un cambio de diseño en WFP para Vista / 7 / Server 2008 [plataforma de filtrado de Windows].
[Ver respuesta de Anupama Vasanth]
Parece que tendré que ir por el camino difícil y reescribir el código [¡difícil porque significa tratar con los gerentes!]
¡Gracias por ayudarme a localizar / confirmar el problema!