Unter Windows Server 2008 R2 haben wir eine Anwendung, die eine Verbindung von einer öffentlichen IP-Adresse auf dem Server zu 127.0.0.1:8334 herstellt (eine Verbindung zu einem Dienst herstellt, der 0.0.0.0:8334 überwacht).
In Windows 2003 gab es kein Problem damit. Wir können eine Verbindung mit TCP von 1.2.3.4 [zB] bis 127.0.0.1:8334 herstellen.
In Windows 2008 stellen wir fest, dass TCP-Verbindungen von öffentlichen IP-Adressen, z. B. 1.2.3.4 bis 127.0.0.1:8334, sogar fehlschlagen. Der Dienst akzeptiert jedoch Verbindungen von 127.0.0.1 bis 127.0.0.1:8334 und von 127.0.0.1 bis 1.2.3.4:8334.
Es wurde versucht, die Windows-Firewall auszuschalten, die Protokollierung usw. zu konfigurieren (es wurden keine nützlichen Protokolleinträge angezeigt), ohne Erfolg. Ist dies ein Problem mit dem neuen Netzwerkstapel?
Änderungen
1.2.3.4 versucht, auf demselben Computer eine Verbindung zu localhost [127.0.0.1] herzustellen
Die Hosts-Datei ist die Standard-Windows 2008-Hostdatei.
Loopback Check Info, interessant. Versuchte es ... hat nicht funktioniert. Crosschecked, um zu überprüfen, ob ich alles richtig gemacht habe - das habe ich.
Ich frage mich, ob es eine Lösung gibt, die NAT oder eine andere Möglichkeit zum Weiterleiten von Ports verwendet. Wenn ich 127.0.0.1:port an 1.2.3.4:port weiterleiten würde, würde das funktionieren? Da die App auf 0.0.0.0:port hört, würde sie Verbindungen auf 1.2.3.4:port aufnehmen
Die HOSTS-Datei enthält localhost 127.0.0.1. Die Hosts-Datei wird jedoch nur bei der Suche nach Hostnamen verwendet. In diesem Fall würde unsere Anwendung keinen Hostnamen nachschlagen, da die IP-Adresse 127.0.0.1 fest darin codiert ist (anstelle des Hostnamens localhost). Die HOSTS-Datei würde hier also nicht ins Spiel kommen.
Was Ports über 1024 betrifft [denken Sie, Sie beziehen sich vielleicht auf das MaxUserPort-Problem?], Habe ich dies getestet, indem ich eine einfache Verbindung zu Port 445 versucht habe - funktioniert ab 127.0.0.1, funktioniert nicht, wenn ich eine Verbindung von Quell-IP 1.2.3.4 herstelle. 445 ist ein Standard-Windows-Dienst, sollte also funktionieren!
Derzeit wird NAT oder RRAS nicht auf dem Computer ausgeführt. Ich habe mich gefragt, ob es eine Möglichkeit gibt, die Umleitung durchzuführen. Ich vermute, dass dies nicht funktioniert, da der TCP / IP-Stapel das Paket ablehnt, bevor es die Loopback-Schnittstelle zum Umleiten erreicht.
Routendruck, den ich überprüft hatte - scheint in Ordnung zu sein, die öffentlichen IPs wurden zuerst weitergeleitet, dann schließlich 127.0.0.0 Netzmaske 255.255.255.0 und 127.0.0.1 Netzmaske 255.255.255.255 beide an Loopback.
Bearbeiten Scheint, als hätte ich die Antwort auf den Grund für das Problem gefunden. Ich habe eventvwr.msc verwendet, die Winsock-Protokollierung aktiviert, andere Dienste deaktiviert und gerade diesen Verbindungstest versucht. Ich habe einen Fehler erhalten, der in hexadezimaler Reihenfolge STATUS_INVALID_ADDRESS_COMPONENT zugeordnet wurde, als ich ihn gegoogelt habe.
Das brachte mich zu: http://social.msdn.microsoft.com/Forums/en-US/wfp/thread/d7cb6138-3f67-4467-a068-8325f56739ba
Dies bestätigte, dass dies eine Designänderung in WFP für Vista / 7 / Server 2008 [Windows-Filterplattform] ist.
[Siehe Antwort von Anupama Vasanth]
Sieht so aus, als müsste ich den harten Weg gehen und den Code neu schreiben [schwer, weil es bedeutet, mit Managern umzugehen!]
Vielen Dank, dass Sie mir geholfen haben, das Problem zu finden / zu bestätigen!