Rozwiązywanie problemów z łącznością TCP/IP

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

Dotyczy: Obsługiwane wersje klienta systemu Windows i systemu Windows Server

Ten artykuł zawiera kompleksowy przewodnik rozwiązywania problemów z błędami łączności TCP/IP.

Objawy i analiza

Mogą wystąpić problemy z łącznością na poziomie aplikacji lub mogą wystąpić błędy przekroczenia limitu czasu. Oto kilka typowych scenariuszy:

• Łączność aplikacji z serwerem bazy danych
• Błędy przekroczenia limitu czasu SQL
• Błędy przekroczenia limitu czasu aplikacji BizTalk
• Błędy protokołu RDP (Remote Desktop Protocol)
• Błędy dostępu do udziału plików
• Łączność ogólna

W przypadku podejrzenia problemu związanego z siecią zalecamy zebranie przechwytywania pakietów sieciowych. To przechwytywanie można filtrować, aby zidentyfikować problematyczne połączenie TCP i określić przyczynę awarii.

Podczas procesu rozwiązywania problemów w przechwytywaniu sieci może wystąpić zresetowanie protokołu TCP, co może wskazywać na problem z siecią.

Wprowadzenie protokołu TCP

Protokół TCP charakteryzuje się protokołem zorientowanym na połączenie i niezawodnym. Zapewnia niezawodność dzięki procesowi uzgadniania. Sesja TCP inicjuje się za pomocą trójkierunkowego uzgadniania, a następnie transferu danych i kończy się czterokierunkowym zamknięciem.

• Czterokierunkowe zamknięcie, w którym zarówno nadawca, jak i odbiorca zgadzają się zamknąć sesję, jest znany jako łagodne zamknięcie. Jest to identyfikowane przez flagę FIN w nagłówku TCP ustawionym na 1.

• Po czterokierunkowym zamknięciu maszyna czeka 4 minuty (domyślnie) przed zwolnieniem portu. Jest to nazywane stanem TIME_WAIT. W tym stanie TIME_WAIT można przetworzyć wszystkie oczekujące pakiety dla połączenia TCP. Po zakończeniu stanu TIME_WAIT zostaną zwolnione wszystkie zasoby przydzielone do połączenia.

• Resetowanie protokołu TCP to nagłe zamknięcie sesji, co powoduje natychmiastowe zwolnienie przydzielonych zasobów i wymazywanie wszystkich informacji o połączeniu. Jest to identyfikowane przez flagę RESET w nagłówku TCP ustawionym na 1. Dane śledzenia sieci zebrane jednocześnie w źródle i miejscu docelowym pomagają określić przepływ ruchu i zidentyfikować punkt awarii.

W poniższych sekcjach opisano scenariusze, w których może wystąpić resetowanie.

Utrata pakietów przez sieć

Gdy element równorzędny TCP wysyła pakiety bez odbierania odpowiedzi, element równorzędny ponownie przesyła dane. Jeśli nadal nie ma odpowiedzi, sesja kończy się resetowaniem ACK, wskazując, że aplikacja potwierdza wymieniane dane, ale zamyka połączenie z powodu utraty pakietów.

Równoczesne ślady sieci w lokalizacji źródłowej i docelowej mogą zweryfikować to zachowanie. Po stronie źródłowej można zobaczyć ponownie przetransmitowane pakiety. Po stronie docelowej te pakiety nie są obecne. Ten scenariusz wskazuje, że urządzenie sieciowe między źródłem a miejscem docelowym porzuca pakiety.

Scenariusz 1. Utrata pakietów podczas początkowego uzgadniania protokołu TCP

Jeśli początkowe uzgadnianie PROTOKOŁU TCP zakończy się niepowodzeniem z powodu porzucenia pakietów, pakiet TCP SYN jest domyślnie ponownie przesyłany trzy razy.

Uwaga 16.

Liczba ponownych przetransmisji pakietu TCP SYN może być różna w zależności od systemu operacyjnego. Jest to określane przez wartość Max SYN Retransmissions w obszarze Parametrów globalnych TCP, które można wyświetlić za pomocą polecenia netsh int tcp show global.

Załóżmy, że maszyna źródłowa z adresem IP 10.10.10.1 łączy się z miejscem docelowym z adresem IP 10.10.10.2 za pośrednictwem portu TCP 445. Poniżej znajduje się zrzut ekranu przedstawiający ślad sieci zebrany na maszynie źródłowej, który pokazuje początkowy uzgadnianie PROTOKOŁU TCP, na którym jest wysyłany pakiet TCP SYN, a następnie ponownie przesłany przez źródło, ponieważ nie odebrano odpowiedzi z miejsca docelowego.

Ta sama konwersacja TCP widoczna w śledzeniu sieci zebranym w miejscu docelowym pokazuje, że żaden z powyższych pakietów nie został odebrany przez miejsce docelowe. Oznacza to, że pakiet TCP SYN został porzucony przez sieć pośrednią.

Jeśli pakiety TCP SYN docierają do miejsca docelowego, ale miejsce docelowe nie odpowiada, sprawdź, czy port TCP połączony z nim znajduje się w stanie NASŁUCHIWANIE na maszynie docelowej. Można to sprawdzić w danych wyjściowych polecenia netstat -anob.

Jeśli port nasłuchuje i nadal nie ma odpowiedzi, może dojść do spadku na platformie filtrowania systemu Windows (WFP).

Scenariusz 2. Utrata pakietów podczas transferu danych po ustanowieniu połączenia TCP

W scenariuszu, w którym pakiet danych wysyłany po nawiązaniu połączenia TCP zostaje porzucony przez sieć, protokół TCP domyślnie przesyła pakiet pięć razy.

Załóżmy, że maszyna źródłowa z adresem IP 192.168.1.62 nawiązała połączenie z maszyną docelową o adresie IP 192.168.1.2 za pośrednictwem portu TCP 445. Maszyna źródłowa wysyła dane (pakiet SMB Negotiate), który jest przesyłany ponownie pięć razy, jak pokazano poniżej. Po braku odpowiedzi z miejsca docelowego maszyna źródłowa wysyła ACK-RST, aby zamknąć to połączenie TCP.

Źródło 192.168.1.62 ślad boczny:

Nie widzisz żadnego z powyższych pakietów docierających do miejsca docelowego.

Należy zaangażować zespół ds. sieci wewnętrznej, aby zbadać różne przeskoki między źródłem a miejscem docelowym i sprawdzić, czy którykolwiek z przeskoków potencjalnie powoduje porzucenie pakietów.

Nieprawidłowy parametr w nagłówku TCP

To zachowanie występuje, gdy urządzenia pośrednie w sieci modyfikują pakiety, powodując, że protokół TCP na końcu odbierania zostanie odrzucony. Na przykład numer sekwencji TCP może zostać zmieniony lub pakiety mogą być odtwarzane przez urządzenie pośredniczące z zmodyfikowanym numerem sekwencji TCP.

Jednoczesne śledzenie sieci w źródle i miejscu docelowym może pomóc zidentyfikować wszelkie modyfikacje nagłówków TCP.

Zacznij od porównania śladów źródłowych i docelowych, aby wykryć wszelkie zmiany w pakietach lub obecność nowych pakietów docierających do miejsca docelowego w imieniu źródła.

W takich przypadkach zalecamy znalezienie pomocy od zespołu sieci wewnętrznej w celu zidentyfikowania wszystkich urządzeń, które modyfikują lub ponownie nakładają pakiety na miejsce docelowe. Typowymi sprawcami są urządzenia riverbed lub akceleratory sieci WAN.

Resetowanie na poziomie aplikacji

Po ustaleniu, że resetowanie nie wynika z popuszczania pakietów, nieprawidłowych parametrów lub modyfikacji pakietów (zidentyfikowanych za pośrednictwem śladów sieci), możesz stwierdzić, że problem jest resetowaniem na poziomie aplikacji.

Resetowanie na poziomie aplikacji charakteryzuje się flagą potwierdzenia (ACK) ustawioną na 1 wraz z flagą Reset (R). Oznacza to, że serwer potwierdza otrzymanie pakietu, ale z jakiegoś powodu nie akceptuje połączenia. Ten problem występuje zwykle, gdy aplikacja odbierający pakiet znajdzie coś niedopuszczalnego w danych.

Na poniższych zrzutach ekranu można zaobserwować, że pakiety zarówno w lokalizacji źródłowej, jak i docelowej są identyczne, bez żadnych modyfikacji ani spadków. Jednak jawne resetowanie jest wysyłane przez miejsce docelowe do źródła.

Śledzenie po stronie źródłowej:

Śledzenie po stronie docelowej:

Pakiet TCP oflagowany za pomocą ACK+RST może również wystąpić po wysłaniu pakietu TCP SYN. Pakiet TCP SYN jest inicjowany przez maszynę źródłową w celu nawiązania połączenia na określonym porcie. Jeśli jednak serwer docelowy nie chce zaakceptować pakietu z jakiegokolwiek powodu, serwer odpowiada pakietem ACK+RST.

W takich przypadkach należy zbadać aplikację powodującą zresetowanie (identyfikowane przez numery portów), aby zrozumieć, dlaczego połączenie jest resetowane.

Uwaga 16.

Powyższe informacje dotyczą resetowania z perspektywy protokołu TCP, a nie protokołu UDP. UDP to protokół bez połączenia, a pakiety są wysyłane zawodnie. W związku z tym retransmisje lub resetowanie nie są obserwowane w przypadku korzystania z protokołu UDP jako protokołu transportowego. Jednak protokół UDP używa protokołu ICMP jako protokołu raportowania błędów. Gdy pakiet UDP jest wysyłany do portu, który nie znajduje się na liście w miejscu docelowym, miejsce docelowe natychmiast odpowie komunikatem ICMP "Host docelowy nieosiągalny: port nieosiągalny".

10.10.10.1  10.10.10.2  UDP UDP:SrcPort=49875,DstPort=3343
 
10.10.10.2  10.10.10.1  ICMP    ICMP:Destination Unreachable Message, Port Unreachable,10.10.10.2:3343

Podczas rozwiązywania problemów z łącznością TCP/IP można zaobserwować w śledzeniu sieci, że maszyna odbiera pakiety, ale nie odpowiada na nie. Może to oznaczać spadek w stosie sieciowym serwera docelowego.

Aby określić, czy lokalna Zapora systemu Windows usuwa pakiet, włącz inspekcję dla platformy filtrowania systemu Windows (WFP) na maszynie przy użyciu następującego polecenia.

auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable

Następnie możesz przejrzeć dzienniki zdarzeń zabezpieczeń, aby zidentyfikować upuszczanie pakietu na określonym porcie TCP i adresie IP wraz ze skojarzonym identyfikatorem filtru WFP.

Następnie uruchom polecenie netsh wfp show state , które generuje plik wfpstate.xml .

Ten plik można otworzyć za pomocą Notatnika i filtru identyfikatora znalezionego w dziennikach zdarzeń (na przykład 2944008 w przykładowym zdarzeniu). Wynik ujawnia nazwę reguły zapory skojarzona z identyfikatorem filtru, który blokuje połączenie.