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

  • Artykuł

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

Ten artykuł został zaprojektowany, aby ułatwić rozwiązywanie problemów z komunikacją TCP/IP.

Narzędzia do rozwiązywania problemów

Polecenie ping jest przydatne do testowania podstawowej łączności. Nie należy jednak polegać na niej, aby udowodnić ogólną łączność. Telnet i PsPing są bardziej przydatne z następujących powodów:

  • Te narzędzia mogą testować łączność 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. W związku z tym możesz nawigować po otwartych portach zapory.
  • 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

Przechwyć diagram sieciowy, który zawiera szczegółowe informacje o urządzeniach znajdujących się w ścieżce do obszaru, którego dotyczy problem. Zwróć uwagę na następujące urządzenia:

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

Diagram może pomóc w wizualizacji i określeniu, gdzie szukać przyczyny problemu.

Krok 2. Ślady sieci

Ślady sieci są przydatne, aby zobaczyć, co się dzieje na poziomie sieci, gdy wystąpi problem.

Krok 3. Wysyłanie polecenia 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 wystąpi błąd Ogólny błąd, ten błąd oznacza, że nie ma prawidłowych interfejsów do przetwarzania żądania. Ten problem może być spowodowany problemem ze sprzętem lub problemem ze stosem.

Sprawdź, czy na ikonie Połączenia sieciowe w zasobniku systemowym jest wyświetlany czerwony znak "X", czy żółty wykrzyknik. Czerwony znak X wskazuje, że system Windows nie wykrywa połączenia sieciowego. Żółty wykrzyknik wskazuje, że wskaźnik stanu połączenia sieciowego (NSCI) nie sprawdził sondy.

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, na którym jest połączony węzeł, nie jest w stanie błędu. Kable, porty przełącznika i karty sieciowe można zmienić, aby zawęzić miejsce występowania tego problemu. Jednak ostatecznie problem znajduje się poza systemem operacyjnym. Aby dokładniej zbadać ten problem, skontaktuj się z dostawcami sprzętu.

Może również wystąpić problem między sterownikiem sieciowym a systemem Windows. Ten problem jest zazwyczaj spowodowany uszkodzeniem stosu. Wykonaj następujące kroki rozwiązywania problemów:

  1. Upewnij się, że najnowsze bity w węźle (TCP/IP, NDIS, AFD, Winsock itd.).

  2. Zresetuj adres IP i usługę Winsock, uruchamiając następujące polecenia. Utwórz kopię zapasową całej konfiguracji sieci.

    netsh -c interface dump > C:\netConfig.txt
netsh int ip reset
netsh winsock reset

  3. Uruchom ponownie węzeł.

  4. Przywróć ustawienia sieci po ponownym uruchomieniu. Ta operacja działa tylko wtedy, gdy nazwy interfejsów nie uległy zmianie lub skrypt jest aktualizowany w celu używania nowych nazw.

    netsh -f C:\netConfig.txt

  5. Odinstaluj lub zainstaluj ponownie sterownik karty sieciowej, odpowiednio do potrzeb.

  6. Sprawdź i usuń sterowniki filtrów innych firm (na przykład oprogramowanie antywirusowe).

  7. Spróbuj uruchomić komputer w trybie awaryjnym za pomocą 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 do momentu zwrócenia problemu. Następnie możesz skontaktować się z dostawcą w celu uzyskania pomocy technicznej.

    1. Jeśli żaden z tych elementów nie powiedzie się, problem prawdopodobnie zostanie uszkodzenie rejestru.
    2. Jeśli masz kopię zapasową rejestru (na przykład fizyczną kopię zapasową lub punkt przywracania systemu), możesz spróbować przywrócić węzeł do wcześniej działającej konfiguracji. Złapanie głównej przyczyny uszkodzenia może być trudne i niezwykle czasochłonne. Nawet jeśli zostanie znaleziona korupcja, wiedza o tym, co spowodowało, jest jeszcze trudniejsza. Ręczne zmodyfikowanie uszkodzonego klucza rejestru powoduje przełączenie węzła w stan nieobsługiwany. W związku z tym zalecamy, aby klient przywrócił lub ponownie załadował węzeł w celu skorygowania uszkodzenia.

Jeśli funkcja NSCI nie sprawdzi sondy (żółty wykrzyknik), nie musi to oznaczać problemu z łącznością. Upewnij się, że typowa komunikacja odbywa się tak, jak powinna.

  • Jeśli tak, badanie powinno koncentrować się w szczególności na tym, dlaczego ncsi kończy się niepowodzeniem kontroli sondy. Szczegółowe informacje na ten temat zostały omówione w osobnym temacie.
  • Jeśli nie, najpierw zbadaj problemy z łącznością, ponieważ prawdopodobnie zostanie to rozwiązane 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, potwierdzi to, że łączność zewnętrzna działa. Dalsze testy są nadal wymagane, aby zrozumieć, czy istnieje podstawowy problem z łącznością.

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.

  1. Błąd nieosiągalny hosta docelowego oznacza, że żądania ARP wysyłane przez węzeł nie otrzymują odpowiedzi.

  2. Zbierz dwustronny ś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 z powrotem w śledzeniu źródłowym. Jeśli ten proces zakończy się niepowodzeniem, problem prawdopodobnie będzie błędną konfiguracją lub innymi problemami, które wpływają na infrastrukturę.

    Możliwe przyczyny mogą być następujące:

    1. Nieprawidłowe lub niedopasowane sieci VLAN.
    2. Nieprawidłowa konfiguracja portu przełącznika (magistrala a port dostępu).
    3. Inne problemy sprzętowe.

  3. Błąd przekroczenia limitu 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 w sobie nie wskazuje na problem. Ruch ICMP może być blokowany przez oprogramowanie sieciowe lub zapory w węzłach. Korzystne może być wyłączenie profilów zapory (Windows) lub wyłączenie ich za pomocą obsługiwanej przez dostawcę zapory metody testowania protokołu ICMP.

    1. Telnet i PsPing lepiej nadają się do testowania. 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 krok 1 zakończy się pomyślnie, łączność zewnętrzna działa. Kontynuuj testowanie podstawowej łączności.
    3. Jeśli krok 1 nie powiedzie się (i jeśli profile zapory są wyłączone), zbierz dwustronny ślad scenariusza netsh netconnection , aby rozwiązać dalsze problemy.

Krok 5. Ping lub Telnet do bramy domyślnej

Gdy węzeł może wysłać polecenie ping do bramy domyślnej, łączność zewnętrzna (na przykład łączność off-box) jest możliwa z węzła źródłowego. Dalsze testy będą nadal wymagane, aby zrozumieć, czy istnieje podstawowy problem z łącznością. Jeśli węzeł nie może wysłać polecenia ping lub telnet do bramy domyślnej, oznacza to, że odpowiedzi 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ła. Ten wynik wskazuje na problem, który ma wpływ na konkretny węzeł docelowy.

  1. Spróbuj nawiązać połączenia Telnet lub PsPing do określonego portu, na który nasłuchuje aplikacja (na przykład port TCP 445 dla protokołu SMB). Jeśli połączenie zakończy się pomyślnie, można potwierdzić podstawową łączność na poziomie aplikacji. W takiej sytuacji należy skontaktować się z dostawcą aplikacji, aby zbadać, dlaczego aplikacja nie łączy się.

    Uwaga

    Dostawcą aplikacji może być firma Microsoft, jeśli problemem jest na przykład brak połączenia z udziałem. W takich sytuacjach warto skorzystać z dwustronnego śledzenia scenariusza netsh netconnection, aby zebrać dodatkowe informacje i pomóc w sprawdzeniu, czy w stosie sieci nie ma żadnych problemów.

  2. 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 się powiedzie, zapora musi zostać ponownie skonfigurowana, aby zezwolić na ruch aplikacji na określonym porcie.
    3. Usuń dowolne aplikacje innych firm pojedynczo i przetestuj je między każdym usunięciem.
      Jeśli to się powiedzie, skontaktuj się z dostawcą problematycznego oprogramowania.
    4. Wypróbuj tryb awaryjny z siecią.
      Jeśli to się powiedzie, wyizoluj przyczynę, uruchamiając "czysty rozruch" węzła przy użyciu programu MSConfig, a następnie włączając aplikacje i usługi innych firm jeden po drugim do momentu ponownego wystąpienia problemu.
    5. Podczas odtwarzania próby nawiązania połączenia należy uruchomić śledzenie scenariusza netsh netconnection ze źródła do węzła docelowego, którego dotyczy problem. Korzystne byłoby również SDP sieci.

  3. Jeśli węzeł nie może wysłać polecenia ping, Telnet lub PsPing do innych węzłów w podsieci docelowej, problem może być prawdopodobnie związany z infrastrukturą. Ponownie można zablokować protokół ICMP w środowisku. W związku z tym sprawdź łączność za pomocą narzędzia Telnet lub PsPing, aby nawiązać połączenie ze znanymi portami nasłuchiwania. W tym momencie dwuskładniowy ślad sieci jest niezbędny, aby pokazać, gdzie w sieci występuje utrata pakietu. Upewnij się, że oba ślady są uruchomione przed wypróbowaniem testu łączności, aby problem został przechwycony.

Typowe problemy i rozwiązania

Wydaje się, ż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, mając zero (0) bajtów w kolejkach wysyłania i odbierania. Jeśli dane są blokowane w kolejce lub jeśli stan jest nieregularny, połączenie prawdopodobnie jest uszkodzone. Jeśli tak nie jest, prawdopodobnie występuje opóźnienie oprogramowania na poziomie sieci lub użytkownika.

Długie czasy nawiązywania połączenia podczas 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 #PRE wpisy 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 nbtstat -R polecenie, aby natychmiast zaktualizować lokalną pamięć podręczną nazw.

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 poprawnie wpisana 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 adres IP są dostępne w pliku Lmhosts lub w 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 określonym 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 nazwy nie ma na liście, spróbuj użyć jednej z innych unikatowych nazw komputerów wyświetlanych przez nbtstatprogram . 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 dla nazwy serwera, który znajduje się na serwerze WINS lub w 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 twój 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 sieciowymi dowolnej karty sieciowej komputera.

Na przykład komputer ma jedną kartę sieciową skonfigurowaną z adresem IP 192.168.0.33 i maską podsieci 255.255.0.0. Wymaga to, aby brama domyślna była w postaci "192.168.<y>.<z>", ponieważ część identyfikatora sieci 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

  1. Usługi TSS muszą być uruchamiane przez konta z uprawnieniami administratora w systemie lokalnym, a umowa EULA musi zostać zaakceptowana (po zaakceptowaniu umowy EULA usługa TSS nie będzie monitować ponownie).
  2. Zalecamy stosowanie zasad wykonywania programu PowerShell na maszynie RemoteSigned lokalnej.

Uwaga

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

  • Ustaw zasady wykonywania RemoteSigned dla poziomu procesu, uruchamiając polecenie cmdlet PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned.
  • Aby sprawdzić, czy zmiana zostanie wprowadzona, 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, w którym działa usługa TSS, przypisane uprawnienie do poziomu procesu również wróci do wcześniej skonfigurowanego stanu.

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

  1. Pobierz usługę TSS we wszystkich węzłach i rozpakuj ją w folderze C:\tss .

  2. Otwórz folder C:\tss z wiersza polecenia programu PowerShell z podwyższonym poziomem uprawnień.

  3. Uruchom ślady na serwerze źródłowym i docelowym przy użyciu następującego polecenia cmdlet:

    TSS.ps1 -Scenario NET_General

  4. Zaakceptuj umowę EULA, jeśli ślady są uruchamiane po raz pierwszy na serwerze źródłowym lub docelowym.

  5. Zezwalaj na nagrywanie (PSR lub wideo).

  6. Odtwórz problem przed wprowadzeniem Y.

    Uwaga

    Jeśli zbierasz dzienniki zarówno na kliencie, jak i na serwerze, poczekaj na ten komunikat w obu węzłach przed odtworzeniem problemu.

  7. Wprowadź wartość 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 w celu analizy.

Odwołanie