Korzystając z systemu Windows Server 2008 R2, mamy aplikację, która łączy się z publicznym adresem IP na serwerze z 127.0.0.1:8334 (łączy się z nim) [łączy się z usługą nasłuchującą w dniu 0.0.0.0:8334]
W Windows 2003 nie było z tym problemu. Możemy połączyć się za pomocą TCP od 1.2.3.4 [np.] Do 127.0.0.1:8334 w porządku.
W systemie Windows 2008 okazuje się, że nawet połączenia TCP z publicznego adresu IP, np. 1.2.3.4 do 127.0.0.1:8334, kończą się niepowodzeniem. ale usługa akceptuje połączenia od 127.0.0.1 do 127.0.0.1:8334 i od 127.0.0.1 do 1.2.3.4:8334.
Próbowałem wyłączyć zaporę systemu Windows, skonfigurować rejestrowanie itp. (Nie pojawiły się żadne przydatne wpisy w dzienniku), ale bezskutecznie. Czy to problem z nowym stosem sieci?
edycje
1.2.3.4 próbuje połączyć się z hostem lokalnym [127.0.0.1] na tym samym komputerze
Plik hostów jest domyślnym plikiem hosta systemu Windows 2008.
Ciekawe informacje o sprawdzaniu pętli zwrotnej. Próbowałem ... nie działało. Zaznaczono, aby sprawdzić, czy wszystko zrobiłem poprawnie - mam.
Zastanawiam się, czy istnieje rozwiązanie wykorzystujące NAT lub inny sposób przekierowania portów - jeśli przekażę port 127.0.0.1:port do 1.2.3.4:port, czy to zadziała? Biorąc pod uwagę, że aplikacja nasłuchuje na porcie 0.0.0.0:port, odbierze połączenia z portu 1.2.3.4:port
Plik HOSTS zawiera localhost 127.0.0.1 - jednak plik hosts jest używany tylko do wyszukiwania nazw hostów. W takim przypadku nasza aplikacja nie szukałaby żadnej nazwy hosta, ponieważ adres IP 127.0.0.1 jest w niej zapisany (zamiast nazwy hosta localhost). Dlatego plik HOSTS nie będzie tu odtwarzany.
Jeśli chodzi o porty powyżej 1024 [może masz na myśli MaxUserPort?] Przetestowałem to, próbując prostego połączenia z portem 445 - działa od 127.0.0.1, nie działa, gdy łączę się ze źródłowego adresu IP 1.2.3.4. 445 to standardowa usługa systemu Windows, więc powinna działać!
Obecnie nie działa NAT lub RRAS na komputerze ... zastanawiałem się, czy istnieje sposób na przekierowanie - Zgaduję, że nie zadziała, ponieważ stos TCP / IP odrzuci pakiet, zanim dotrze do interfejsu pętli zwrotnej w celu zmiany trasy.
Wydruk trasy, który sprawdziłem - wydaje się być w porządku, najpierw publiczne adresy IP były kierowane, a następnie maska sieci 127.0.0.0 255.255.255.0 i maska sieci 127.0.0.1 255.255.255.255 oba do sprzężenia zwrotnego.
Edytuj Wydaje się, że znalazłem odpowiedź na temat przyczyny problemu. Użyłem eventvwr.msc, włączyłem rejestrowanie Winsock, wyłączyłem inne usługi, właśnie wypróbowałem ten test połączenia. Wystąpił błąd, który w systemie szesnastkowym został odwzorowany na STATUS_INVALID_ADDRESS_COMPONENT, gdy go przejrzałem.
To doprowadziło mnie do: http://social.msdn.microsoft.com/Forums/en-US/wfp/thread/d7cb6138-3f67-4467-a068-8325f56739ba
Co potwierdziło, że jest to zmiana projektowa w WFP dla Vista / 7 / Server 2008 [platforma filtrowania systemu Windows].
[Zobacz odpowiedź Anupama Vasanth]
Wygląda na to, że będę musiał przejść trudną drogę i przepisać kod [trudny, ponieważ oznacza to kontakt z menedżerami!]
Dziękujemy za pomoc w zlokalizowaniu / potwierdzeniu problemu!