Windows Server 2008 - Łączenie z 127.0.0.1

9

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!

Kara Marfia
źródło
Czy w twoim opisie 1.2.3.4 i 127.0.0.1 są na tej samej maszynie? Co masz dla nich w pliku hosts?
Gennady Vanin Геннадий Ванин

Odpowiedzi:

1

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.

TheCompWiz
źródło
0

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
-3

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:

  1. Wyłączanie (jeśli jest włączone i włączanie, jeśli jest wyłączone) IPv6 na karcie sieciowej?

  2. 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?


„445 to standardowa usługa systemu Windows”

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,

„mamy ten sam problem, co opisany wcześniej, gdy maszyny Vista SP2 próbują dotrzeć do udziału plików Windows Server 2008 SP1 lub SP2. Usługa udostępniania plików jest chroniona przez Zaporę systemu Windows z zaawansowanymi zabezpieczeniami przy użyciu wstępnie zdefiniowanej reguły udostępniania plików (SMB) bezpieczne połączenie"

Gennady Vanin Геннадий Ванин
źródło