Wskazówki dotyczące rozwiązywania problemów z komunikacją protokołu TCP/IP

Artykuł
01/15/2025

Wypróbuj naszego agenta wirtualnego — może pomóc w szybkim zidentyfikowaniu i rozwiązaniu typowych problemów z replikacją usługi Active Directory.

Ten artykuł jest przeznaczony do rozwiązywania problemów z komunikacją TCP/IP.

Narzędzia do rozwiązywania problemów

Do testowania łączności podstawowej przydaje się polecenie ping. Jednak nie należy na nim polegać przy sprawdzaniu łączności ogólnej. Narzędzia Telnet i PsPing są bardziej przydatne z następujących powodów:

Te narzędzia umożliwiają testowanie łączności z warstwą aplikacji przy użyciu protokołu TCP lub UDP (tylko PsPing) jako protokołu transportowego.
Możesz określić, który port będzie używany. Pozwala to nawigować po otwartych portach w zaporze.
Możesz nawiązać połączenie z dowolnym portem nasłuchiwania w węźle docelowym, aby zweryfikować dostęp do portu określonej aplikacji.

Lista kontrolna rozwiązywania problemów

Krok 1. Przechwytywanie diagramu sieciowego

Uzyskaj diagram sieci zawierający szczegółowe informacje na temat urządzeń, które znajdują się na drodze do obszaru, którego dotyczy problem. Szczególną uwagę zwróć na następujące urządzenia:

Zapory
IPS (systemy ochrony przed włamaniami/zapobiegania włamaniom)
DPI (głęboka inspekcja pakietów)
Akceleratory sieci WAN

Diagram może ułatwić wizualizację i identyfikację miejsc, w których należy szukać przyczyny problemu.

Krok 2. Ślady sieci

Korzystając z danych śledzenia sieci, można sprawdzić, co dzieje się na poziomie sieci po wystąpieniu problemu.

Krok 3. Wyślij polecenie ping do lokalnego adresu IP komputera

Spróbuj wysłać polecenie ping do lokalnego adresu IP komputera.

Jeśli węzeł nie może wysłać polecenia ping do lokalnego adresu IP, stos lokalny nie działa. Zanotuj wszystkie wyświetlane komunikaty o błędach.

Jeśli zostanie wyświetlony błąd Błąd ogólny , ten błąd oznacza, że nie ma prawidłowych interfejsów do przetworzenia żądania. Ten problem może być spowodowany problemem sprzętowym lub problemem ze stosem.

Sprawdź, czy na ikonie Połączenie sieciowe na pasku zadań nie znajduje się czerwony znak „X” lub żółty wykrzyknik. Czerwony znak X wskazuje, że system Windows nie wykrywa połączenia sieciowego. Żółty wykrzyknik wskazuje, że sprawdzenie sondy przez wskaźnik stanu połączenia sieciowego (NSCI) zakończyło się niepowodzeniem.

Aby rozwiązać ten problem, sprawdź, czy karta sieciowa zgłasza łączność. Upewnij się, że karta sieciowa jest podłączona i że port przełącznika, w którym jest połączony węzeł, nie jest w stanie błędu. Możesz zmienić, porty przełącznika i karty sieciowe, aby zawęzić miejsce wystąpienia tego problemu. Jednak ostatecznie problem leży poza systemem operacyjnym. Aby przeprowadzić dalsze badania, skontaktuj się z dostawcami sprzętu.

Problem może również występować między sterownikiem sieci a systemem Windows. Ten problem jest zwykle spowodowany uszkodzeniem stosu. Wykonaj następujące kroki rozwiązywania problemów:

Upewnij się, że w węźle są dostępne najnowsze bity (TCP/IP, NDIS, AFD, Winsock itd.).
Zresetuj adresy IP i Winsock, uruchamiając poniższe polecenia. Utwórz kopię zapasową całej konfiguracji sieci.
```
netsh -c interface dump > C:\netConfig.txt
netsh int ip reset
netsh winsock reset
```
Uruchom ponownie węzeł.
Po ponownym uruchomieniu przywróć ustawienia sieciowe. Ta operacja działa tylko wtedy, gdy nazwy interfejsów nie uległy zmianie lub skrypt zostanie zaktualizowany tak, aby używał nowych nazw.
```
netsh -f C:\netConfig.txt
```
W zależności od potrzeb odinstaluj lub ponownie zainstaluj sterownik karty sieciowej.
Sprawdź i usuń sterowniki filtrów innych firm (na przykład oprogramowanie antywirusowe).
Spróbuj uruchomić komputer w trybie awaryjnym z siecią. Jeśli tryb awaryjny z siecią działa, uruchom proces "czystego rozruchu", wyłączając wszystkie aplikacje i usługi innych firm w programie MSConfig, a następnie ponownie włączając je jeden po drugim, dopóki problem nie zostanie zwrócony. Następnie możesz skontaktować się z dostawcą w celu uzyskania pomocy technicznej.
1. Jeśli żadne z tych rozwiązań nie pomogło, przyczyną problemu jest prawdopodobnie uszkodzenie rejestru.
2. Jeśli masz kopię zapasową rejestru (np. fizyczną kopię zapasową lub punkt przywracania systemu), możesz spróbować przywrócić węzeł do wcześniej działającej konfiguracji. Przechwytywanie głównej przyczyny uszkodzenia może być trudne i bardzo czasochłonne. Nawet jeśli znaleziono uszkodzenie, wiedząc, co spowodowało, że jest jeszcze trudniejsze. Ręczne zmodyfikowanie uszkodzonego klucza rejestru powoduje przejście węzła w stan nieobsługiwany. W związku z tym zalecamy, aby w celu skorygowania uszkodzenia klient przywrócił lub ponownie załadował węzeł.

Jeśli sprawdzanie sondy NSCI zakończy się niepowodzeniem (żółty wykrzyknik), niekoniecznie oznacza to problem z łącznością. Upewnij się, że typowa komunikacja odbywa się tak, jak powinna.

Jeśli tak, badanie powinno skupić się konkretnie na tym, dlaczego sprawdzanie sond przez wskaźnik NCSI kończy się niepowodzeniem. Szczegółowe informacje na ten temat znajdują się w oddzielnym temacie.
Jeśli nie, najpierw zbadaj problemy z łącznością, ponieważ błąd prawdopodobnie zostanie usunięty po przywróceniu łączności.

Krok 4. Rozwiązywanie problemów z komunikatami o błędach występującymi podczas testu ping lub telnet

Jeśli węzeł może wysyłać polecenia ping lub telnet do węzłów w tej samej podsieci lub segmencie sieci, może to potwierdzać, że łączność zewnętrzna działa. Konieczne jest przeprowadzenie dalszych testów w celu ustalenia, czy występuje problem z łącznością podstawową.

Jeśli węzeł nie może wysłać polecenia ping/telnet do węzłów w tym samym segmencie podsieci/sieci. Zanotuj wszystkie wyświetlane komunikaty o błędach.

Błąd nieosiągalny hosta docelowego oznacza, że żądania ARP wysyłane przez węzeł nie otrzymują odpowiedzi.
Zbierz dwukierunkowy ślad z węzłów, między którymi testujesz. Upewnij się, że żądanie ARP wysyłane przez węzeł źródłowy dociera do węzła docelowego i że węzeł docelowy odpowiada odpowiednio. Ta odpowiedź powinna być widoczna w danych śledzenia węzła źródłowego. Jeśli ten proces kończy się niepowodzeniem, przyczyną może być błędna konfiguracja lub inne problemy mające wpływ na infrastrukturę.

Możliwe przyczyny to:
1. Nieprawidłowe lub niezgodne sieci VLAN.
2. Nieprawidłowa konfiguracja portu przełącznika (magistrala a port dostępu).
3. Inne problemy sprzętowe.
Błąd upłynął limit czasu żądania oznacza, że żądanie ARP otrzymało odpowiedź, ale żądanie echa ICMP wysyłane przez węzeł nie otrzymuje odpowiedzi echa ICMP. To samo nie wskazuje problemu. Ruch ICMP może być blokowany przez sieć lub oprogramowanie zapory w węzłach. Warto wyłączyć profile zapory w systemie Windows lub za pośrednictwem metody testowania ICMP obsługiwanej przez dostawcę zapory.
1. Do testowania lepiej nadają się narzędzia Telnet i PsPing. Uruchom polecenie Telnet lub PsPing z węzła źródłowego do węzła docelowego na porcie nasłuchiwania (na przykład 445).
2. Jeśli udaje się wykonać krok 1, łączność zewnętrzna działa. Przejdź do testowania łączności podstawowej.
3. Jeśli krok 1 nie powiedzie się (a jeśli profile zapory są wyłączone), zbierz ślad scenariusza dwustronnego netsh netconnection , aby rozwiązać problem.

Krok 5. Polecenie Ping lub Telnet do bramy domyślnej

Gdy węzeł może wysyłać polecenia ping do swojej bramy domyślnej, łączność zewnętrzna (na przykład łączność poza usługą) z węzła źródłowego jest możliwa. Konieczne może być przeprowadzenie dalszych testów w celu ustalenia, czy występuje problem z łącznością podstawową. Jeśli węzeł nie może wysłać polecenia ping lub Telnet do bramy domyślnej, oznacza to, że odpowiedzi protokołu ICMP są wyłączone na routerze.

Krok 6. Sprawdzanie problemów, które mają wpływ na konkretny węzeł docelowy

Jeśli węzeł źródłowy może wysyłać polecenia ping, Telnet lub PsPing do innych węzłów w podsieci docelowej, podstawowa łączność i routing w infrastrukturze działają. Taki rezultat wskazuje na problem, który ma wpływ na określony węzeł docelowy.

Wypróbuj narzędzie Telnet lub PsPing na określonym porcie, na którym nasłuchuje aplikacja (na przykład na porcie TCP 445 w przypadku protokołu SMB). Jeśli połączenie zostanie nawiązane pomyślnie, można potwierdzić łączność podstawową na poziomie aplikacji. W takiej sytuacji należy skontaktować się z dostawcą aplikacji, aby uzyskać pomoc w zbadaniu, dlaczego aplikacja nie nawiązuje połączenia.

Uwaga 16.

Dostawca aplikacji może być firmą Microsoft, jeśli na przykład problem nie może nawiązać połączenia z udziałem. W takich sytuacjach warto uzyskać z obu stron dane śledzenia scenariusza netsh netconnection w celu zebrania dodatkowych informacji oraz sprawdzenia, czy w stosie sieci nie występują żadne problemy.
Jeśli połączenie z określonym portem nie powiedzie się:
1. Upewnij się, że port jest w stanie "nasłuchiwania":
  CMD: netstat -nato | findstr :<port>
  PowerShell: Get-NetTcpConnection -LocalPort <port>
2. Tymczasowo wyłącz wszystkie profile zapory. (Uwaga: Wyłącz tylko profile. Nie wyłączaj usługi).
  Jeśli to rozwiązanie przynosi efekt, należy ponownie skonfigurować zaporę, aby zezwolić na ruch aplikacji na jej określonym porcie.
3. Usuwaj pojedynczo aplikacje innych firm, wykonując testy po każdym usunięciu.
  Jeśli to rozwiązanie przynosi efekt, skontaktuj się z dostawcą oprogramowania, które sprawia problem.
4. Wypróbuj tryb awaryjny z siecią.
  Jeśli to się powiedzie, wyizoluj przyczynę przez uruchomienie "czystego rozruchu" węzła przy użyciu narzędzia MSConfig, a następnie włączenie aplikacji i usług innych firm po jednym do momentu ponownego wystąpienia problemu.
5. Podczas odtwarzaniu próby nawiązania połączenia należy uruchomić dane śledzenia scenariusza netsh netconnection ze źródła do węzła docelowego, którego dotyczy problem. Korzystne będzie również sieciowe połączenie SDP.
Jeśli węzeł nie może wysyłać poleceń ping, Telnet lub PsPing do innych węzłów w podsieci docelowej, problem prawdopodobnie może być związany z infrastrukturą. Również w tym przypadku przyczyną może być blokada ICMP w środowisku. Dlatego sprawdź łączność przy użyciu narzędzia Telnet lub PsPing, aby nawiązać połączenie ze znanymi portami nasłuchiwania. W tym momencie niezbędne są dane śledzenia sieci z obu stron, które pokażą, w którym miejscu sieci dochodzi do utraty pakietów. Przed wypróbowaniem testu łączności w celu wychwycenia problemu upewnij się, że zbieranie danych śledzenia jest uruchomione po obu stronach.

Typowe problemy i rozwiązania

Wygląda na to, że połączenie TCP/IP z hostem zostało zatrzymane

Ten problem występuje, ponieważ dane są blokowane w kolejkach TCP i UDP lub występują problemy z opóźnieniem oprogramowania na poziomie sieci lub użytkownika.

Aby rozwiązać ten problem, użyj netstat -a polecenia , aby wyświetlić stan wszystkich działań na portach TCP i UDP na komputerze lokalnym.
Stan dobrego połączenia TCP jest ustanawiany przy użyciu zera (0) bajtów w kolejkach wysyłania i odbierania. Jeśli w którejkolwiek kolejce dane są zablokowane lub stan jest nieregularny, połączenie prawdopodobnie jest wadliwe. Jeśli nie, prawdopodobnie występuje opóźnienie oprogramowania na poziomie sieci lub użytkownika.

Długie czasy nawiązywania połączenia w przypadku używania hostów Lmhost do rozpoznawania nazw

Ten problem występuje, ponieważ plik Lmhosts jest analizowany sekwencyjnie w celu zlokalizowania wpisów bez opcji #PRE.

Aby rozwiązać ten problem, umieść często używane wpisy w górnej części pliku i wpisy #PRE w dolnej części. Jeśli wpis zostanie dodany na końcu dużego pliku Lmhosts, oznacz wpis w lmhosts jako wstępnie załadowany wpis przy użyciu opcji #PRE. Następnie uruchom polecenie nbtstat -R, aby natychmiast zaktualizować pamięć podręczną nazw lokalnych.

Wystąpił błąd systemu 53

Błąd systemowy 53 jest zwracany, jeśli rozpoznawanie nazw nie powiedzie się dla określonej nazwy komputera, gdy net use jest używane polecenie.

Jeśli komputer znajduje się w podsieci lokalnej, sprawdź, czy nazwa jest poprawna i czy na komputerze docelowym jest również uruchomiony protokół TCP/IP. Jeśli komputer nie znajduje się w podsieci lokalnej, upewnij się, że jego nazwa i mapowanie adresów IP są dostępne w pliku Lmhosts lub bazie danych WINS. Jeśli wszystkie elementy TCP/IP wydają się być poprawnie zainstalowane, użyj ping polecenia razem z komputerem zdalnym, aby sprawdzić, czy oprogramowanie TCP/IP działa.

Nie można nawiązać połączenia z konkretnym serwerem

Ten problem występuje, ponieważ rozpoznawanie nazw NetBIOS nie rozwiązuje nazwy lub jest rozwiązywany nieprawidłowy adres IP.

Aby rozwiązać ten problem, użyj nbtstat -n polecenia na serwerze, aby określić nazwy serwera zarejestrowanego w sieci. Nazwa komputera, z którym próbujesz nawiązać połączenie, powinna znajdować się na wyświetlonej liście. Jeśli nazwa nie znajduje się na liście, spróbuj użyć jednej z innych unikatowych nazw komputerów wyświetlanych przez nbtstat. Jeśli nazwa używana przez komputer zdalny jest taka sama jak nazwa wyświetlana przez nbtstat -n polecenie, upewnij się, że komputer zdalny ma wpis nazwy serwera, który znajduje się na serwerze WINS lub w jego pliku Lmhosts.

Nie można dodać bramy domyślnej

Ten problem występuje, ponieważ adres IP bramy domyślnej nie znajduje się na tym samym identyfikatorze sieci IP co adres IP.

Aby rozwiązać ten problem, ustal, czy brama domyślna znajduje się w tej samej sieci logicznej co karta sieciowa komputera, porównując adres IP bramy domyślnej z identyfikatorami sieci dowolnej karty sieciowej komputera.

Na przykład komputer ma jedną kartę sieciową, dla której skonfigurowano adres IP 192.168.0.33 i maskę podsieci 255.255.0.0. Wymaga to, aby brama domyślna zawierała postać "192.168".<y>.<z>", ponieważ część identyfikatora sieciowego interfejsu IP to 192.168.0.0.

Zbieranie danych

Przed skontaktowaniem się z pomocą techniczną firmy Microsoft możesz zebrać informacje o problemie.

Wymagania wstępne

Usługa TSS musi być uruchamiana przez konta z uprawnieniami administratora w systemie lokalnym, a umowa EULA musi zostać zaakceptowana (po zaakceptowaniu umowy EULA usługa TSS nie wyświetli monitu ponownie).
Zalecamy zasady wykonywania programu PowerShell komputera RemoteSigned lokalnego.

Uwaga 16.

Jeśli bieżące zasady wykonywania programu PowerShell nie zezwalają na uruchamianie TSS, wykonaj następujące czynności:

RemoteSigned Ustaw zasady wykonywania dla poziomu procesu, uruchamiając polecenie cmdlet PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned.
Aby sprawdzić, czy zmiana zostanie w życie, uruchom polecenie cmdlet PS C:\> Get-ExecutionPolicy -List.
Ponieważ uprawnienia na poziomie procesu mają zastosowanie tylko do bieżącej sesji programu PowerShell, po zamknięciu danego okna programu PowerShell, do przypisanego uprawnienia dla poziomu procesu powróci również do wcześniej skonfigurowanego stanu.

Zbieranie kluczowych informacji przed skontaktowaniem się z pomocą techniczną firmy Microsoft

Pobierz usługę TSS na wszystkich węzłach i rozpakuj ją w folderze C:\tss .
Otwórz folder C:\tss z wiersza polecenia programu PowerShell z podwyższonym poziomem uprawnień.
Uruchom ślady na serwerze źródłowym i docelowym przy użyciu następującego polecenia cmdlet:
```
TSS.ps1 -Scenario NET_General
```
Zaakceptuj umowy EULA, jeśli ślady są uruchamiane po raz pierwszy na serwerze źródłowym lub docelowym.
Zezwalaj na nagrywanie (PSR lub wideo).
Odtwórz problem przed wprowadzeniem Y.

Uwaga 16.

Jeśli zbierasz dzienniki zarówno na kliencie, jak i serwerze, przed odtworzeniem problemu zaczekaj na ten komunikat w obu węzłach.
Wprowadź Y , aby zakończyć zbieranie dzienników po odtworzeniu problemu.

Ślady będą przechowywane w pliku zip w folderze C:\MS_DATA , który można przekazać do obszaru roboczego na potrzeby analizy.

Udostępnij za pośrednictwem