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!
Odpowiedzi:
Nie zapominaj, że w systemie Windows 2008 zapora jest domyślnie włączona. Może to potencjalnie zablokować cały ruch, nawet w interfejsie sprzężenia zwrotnego. Dodatkowo, jeśli łączysz się z 0.0.0.0, akceptujesz połączenia na WSZYSTKICH interfejsach. Zapora nadal to blokuje. Możesz spróbować wyłączyć zaporę podczas testowania ... a następnie włączyć ją ponownie. Nie miałem żadnych problemów z łączeniem się z różnymi programami, które opracowałem na 127.0.0.1.
źródło
Spróbuj połączyć się z 127.0.0.2 w Vista / win2k8 i nowszych - brzmi zabawnie, ale działa. Miał pozytywne wyniki w przeszłości
źródło
Jestem pewien, że jest to związane z funkcją bezpieczeństwa sprawdzania pętli zwrotnej, chociaż nie mogę uzyskać szczegółowych informacji na temat jego implementacji, a jedynie sposób jej przezwyciężenia:
http://chillicode.wordpress.com/tag/loopback-check/
A „APLIKACJE DO” systemu Windows 2008 można znaleźć na stronie http://support.microsoft.com/kb/896861
Co dokładnie znajduje się w twoim pliku HOSTS? Nie mam W2008. Czy masz na myśli, że nie ma „lokalnego hosta 127.0.0.1”?
Przeczytałem też gdzieś, że domyślna konfiguracja W2008 nie pozwala na komunikację z portami większymi niż 1024.
Możesz przesłać opinię na temat MS Windows Server 2008 bezpośrednio do zespołu MS za pośrednictwem
i odpowiedzą
Jeśli próbowałeś wyłączyć „sprawdzanie pętli zwrotnej” za pomocą metody edycji rejestru, to wymaga ponownego uruchomienia. Kolejny - nie.
NAT wewnątrz maszyny? Wydaje mi się, że 127.0.0.1 nie jest przekierowywany ani trasowany, jest wewnętrzny, możesz odłączyć kartę sieciową, twój 1.2.3.4 zniknie, ale 127.0.0.1 będzie tam nadal.
Jaka jest wydajność twojego (Run -> cmd -> route print)?
Jest jeszcze jedna chwila, pomyślałem, choć nie wiem, jak to złożyć.
127.0.0.1 to localhost (interfejs), jest to nazwa pojedynczej etykiety i uważana za lokalną. 1.2.3.4 to nazwa nie oznaczona pojedynczo.
Możliwe jest to, że taka nazwa mogła zostać uznana za zewnętrzną
Czy możesz spróbować osobno:
Wyłączanie (jeśli jest włączone i włączanie, jeśli jest wyłączone) IPv6 na karcie sieciowej?
Umieścić nazwę pojedynczej etykiety dla 1.2.3.4 w pliku HOSTS?
Co to jest opis zdarzenia, identyfikator zdarzenia itp. W eventvwr.msc w przypadku niepowodzenia komunikacji od 1.2.3.4 do 127.0.0.1:8334?
Czy dotyczy to SMB-direct przez TCP / IP? do udostępniania plików? CIFS?
Nie tak niezawodny ... Ciągle jest hakowany przez poprawki MS. Czytać:
(„Przeglądanie NetBIOS w różnych podsieciach może się nie powieść po aktualizacji do 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
Następnie,
źródło