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!
Réponses:
N'oubliez pas que dans Windows 2008, le pare-feu est activé par défaut. Cela peut potentiellement bloquer tout le trafic, même sur l'interface de bouclage. De plus, si vous vous liez à 0.0.0.0, vous acceptez les connexions sur TOUTES les interfaces. Le pare-feu bloquerait toujours cela. Vous pouvez essayer de désactiver le pare-feu pendant le test ... puis de le réactiver. Je n'ai eu aucun problème de connexion aux différents programmes que j'ai développés sur 127.0.0.1.
la source
Essayez de vous connecter à 127.0.0.2 dans Vista / win2k8 et au-dessus - cela semble drôle mais cela fonctionne. A eu des résultats positifs avec cela dans le passé
la source
Je suis le plus certain qu'il est connecté avec la fonction de sécurité de vérification de bouclage, bien que je ne puisse pas obtenir de détails détaillés sur la façon dont il est mis en œuvre, seulement sur la façon de le surmonter:
http://chillicode.wordpress.com/tag/loopback-check/
Et pour "S'APPLIQUE À" Windows 2008, voir http://support.microsoft.com/kb/896861
Eh bien, qu'y a-t-il exactement dans votre fichier HOSTS? Je n'ai pas de W2008. Voulez-vous dire qu'il n'y a pas de "localhost 127.0.0.1" là-bas?
J'ai également lu quelque part que la configuration par défaut de W2008 ne permet pas de communiquer avec des ports supérieurs à 1024.
Vous pouvez envoyer des commentaires sur MS Windows Server 2008 directement à l'équipe MS via
et ils vous répondront
Si vous avez essayé de désactiver la «vérification de bouclage» via la méthode de modification du registre, cela nécessite un redémarrage. Un autre - non.
NAT à l'intérieur de la machine? 127.0.0.1 n'est pas transmis ou routé, je pense que oui, c'est interne, vous pouvez débrancher la carte réseau, votre 1.2.3.4 disparaîtra mais 127.0.0.1 continuera d'être là.
Quelle est la sortie de votre (Run -> cmd -> route print)?
Il y a un moment de plus, pensais-je, bien que je ne sache pas comment l'assembler.
127.0.0.1 est localhost (interface), c'est un nom à étiquette unique et considéré comme local. 1.2.3.4 est un nom non unique.
Les problèmes possibles sont que ce nom aurait pu être considéré comme externe
Pouvez-vous essayer séparément:
Désactivation (si elle est activée et activation si elle est désactivée) IPv6 sur la carte réseau?
Mettre un nom single-label pour 1.2.3.4 dans le fichier HOSTS?
Quelle est la description d'événement correspondante, EventID, etc. dans eventvwr.msc pour l'échec de communication de 1.2.3.4 à 127.0.0.1:8334?
Est-ce pour SMB-direct sur TCP / IP? pour le partage de fichiers? CIFS?
Pas si fiable ... Il est constamment piraté par les correctifs MS. Lis:
("La navigation NetBIOS sur des sous-réseaux peut échouer après la mise à niveau vers 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
Alors,
la source