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!
Respuestas:
No olvide que, en Windows 2008, el firewall está activado de forma predeterminada. Potencialmente, esto puede bloquear cualquier y todo el tráfico incluso en la interfaz de bucle invertido. Además, si se une a 0.0.0.0, está aceptando conexiones en TODAS las interfaces. El cortafuegos aún bloquearía esto. Podría intentar apagar el firewall mientras realiza la prueba ... y luego volver a encenderlo. No he tenido problemas para conectarme a varios programas que he desarrollado en 127.0.0.1.
fuente
Intente conectarse a 127.0.0.2 en Vista / win2k8 y superior; suena divertido pero funciona. Tuve resultados positivos con esto en el pasado
fuente
Estoy seguro de que está conectado con la función de seguridad de verificación de bucle invertido, aunque no puedo obtener detalles detallados sobre cómo se implementa, solo cómo superarlo:
http://chillicode.wordpress.com/tag/loopback-check/
Y para "APLICA A" Windows 2008 ver http://support.microsoft.com/kb/896861
Bueno, ¿qué hay exactamente en tu archivo HOSTS? No tengo W2008. ¿Quiere decir que no hay "127.0.0.1 localhost" allí?
También leí en alguna parte que la configuración predeterminada de W2008 no permite comunicarse con puertos superiores a 1024.
Puede enviar comentarios sobre MS Windows Server 2008 directamente al equipo de MS a través de
y ellos responderán
Si intentó desactivar la "verificación de bucle invertido" a través del método de edición del registro, entonces debe reiniciar. Otro, no.
NAT dentro de la máquina? 127.0.0.1 no se reenvía o enruta, creo que es interno, puede desconectar la tarjeta de red, su 1.2.3.4 desaparecerá pero 127.0.0.1 continuará allí.
¿Cuál es el resultado de su (Ejecutar -> cmd -> ruta de impresión)?
Hay un momento más, estaba pensando, aunque no sé cómo armarlo.
127.0.0.1 es localhost (interfaz), es un nombre de etiqueta única y se considera local. 1.2.3.4 es un nombre sin etiqueta única.
Posibles problemas con esto es que dicho nombre podría haber sido considerado externo
¿Puedes probar, por separado:
¿Deshabilitar (si está habilitado y habilitar si está deshabilitado) IPv6 en el adaptador de red?
¿Poner algún nombre de etiqueta única para 1.2.3.4 en el archivo HOSTS?
¿Cuál es la descripción del evento correspondiente, EventID, etc. en eventvwr.msc por no comunicarse desde 1.2.3.4 a 127.0.0.1:8334?
¿Es para SMB-direct sobre TCP / IP? para compartir archivos? CIFS?
No es tan confiable ... Constantemente está siendo pirateado por las revisiones de MS. Leer:
("La exploración de NetBIOS en subredes puede fallar después de actualizar a Windows Server 2008") - http://blogs.technet.com/b/networking/archive/2008/07/25/netbios-browsing-across-subnets-may-fail -after-upgrade-to-windows-server-2008.aspx? wa = wsignin1.0
Entonces,
fuente