Im exécutant Windows Server 2008 R2, nous avons une application qui se connecte (se lie à) une adresse IP publique sur le serveur à 127.0.0.1:8334 [se connecte à un service écoutant le 0.0.0.0:8334]
Dans Windows 2003, il n'y avait aucun problème avec cela. Nous pouvons nous connecter en utilisant TCP de 1.2.3.4 [par exemple] à 127.0.0.1:8334 très bien.
Dans Windows 2008, nous constatons que les connexions TCP de l'IP publique, par exemple 1.2.3.4 à 127.0.0.1:8334, échouent même. mais le service accepte les connexions de 127.0.0.1 à 127.0.0.1:8334 et 127.0.0.1 à 1.2.3.4:8334.
J'ai essayé de désactiver le pare-feu Windows, de configurer sa journalisation, etc. (aucune entrée de journal utile n'est apparue), en vain. Est-ce un problème avec la nouvelle pile réseau?
modifications
1.2.3.4 tente de se connecter à localhost [127.0.0.1] sur la même machine
Le fichier hôtes est le fichier hôte Windows 2008 par défaut.
Informations de vérification en boucle, intéressantes. Je l'ai essayé ... n'a pas fonctionné. Croisé pour vérifier que l'ID a tout fait correctement - je l'ai.
Je me demande s'il existe une solution utilisant NAT ou une autre façon de transférer les ports - si je transfère 127.0.0.1:port vers 1.2.3.4:port, cela fonctionnerait-il? Étant donné que l'application écoute sur 0.0.0.0:port, elle reprendra les connexions sur 1.2.3.4:port
Le fichier HOSTS contient localhost 127.0.0.1 - cependant, le fichier hosts n'est utilisé que pour les recherches de nom d'hôte. Dans ce cas, notre application ne rechercherait aucun nom d'hôte, car l'adresse IP 127.0.0.1 y est codée en dur (plutôt que le nom d'hôte localhost). Le fichier HOSTS n'entrerait donc pas en jeu ici.
En ce qui concerne les ports supérieurs à 1024 [pensez-vous que vous faites peut-être référence au problème MaxUserPort?] J'ai testé cela en essayant une connexion simple au port 445 - fonctionne à partir de 127.0.0.1, ne fonctionne pas lorsque je me connecte à partir de l'IP source 1.2.3.4. 445 est un service Windows standard, devrait donc fonctionner!
Actuellement, ne pas exécuter NAT ou RRAS sur la machine ... je me demandais s'il y avait un moyen de faire le reroutage - je suppose que cela ne fonctionnera pas car la pile TCP / IP rejettera le paquet avant qu'il n'atteigne l'interface de bouclage pour le réacheminer.
Impression de l'itinéraire que j'avais vérifiée - semble correct, les adresses IP publiques ont été acheminées en premier, puis enfin le masque de réseau 127.0.0.0 255.255.255.0 et le masque de réseau 127.0.0.1 255.255.255.255 pour le bouclage.
Modifier semble avoir trouvé la réponse à la raison du problème. J'ai utilisé eventvwr.msc, activé la journalisation Winsock, désactivé d'autres services, j'ai juste essayé ce test de connexion. Vous avez une erreur qui, en hexadécimal, mappée à STATUS_INVALID_ADDRESS_COMPONENT lorsque je l'ai recherchée sur Google.
Cela m'a amené à: http://social.msdn.microsoft.com/Forums/en-US/wfp/thread/d7cb6138-3f67-4467-a068-8325f56739ba
Ce qui a confirmé qu'il s'agit d'un changement de conception dans WFP pour Vista / 7 / Server 2008 [plate-forme de filtrage Windows].
[Voir la réponse d'Anupama Vasanth]
On dirait que je vais devoir emprunter la voie difficile et réécrire le code [dur parce que cela signifie avoir affaire à des gestionnaires!]
Merci de m'aider à localiser / confirmer le problème!