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

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.

Dotyczy: system Windows 10

Błędy łączności mogą wystąpić na błędach zakończenia aplikacji lub przekroczenia limitu czasu. Poniżej przedstawiono najbardziej typowe scenariusze:

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

Jeśli podejrzewasz, że problem występuje w sieci, zbierasz ślad sieci. Ślad sieci będzie następnie filtrowany. Podczas rozwiązywania problemów z błędami łączności można natknąć się na resetowanie TCP w przechwytywaniu sieci, które może wskazywać na problem z siecią.

• Protokół TCP jest definiowany jako protokół zorientowany na połączenie i niezawodny. Jednym ze sposobów zapewnienia niezawodności protokołu TCP jest proces uzgadniania. Ustanowienie sesji TCP rozpoczynałoby się od uzgadniania trójstopnienego, a następnie transferu danych, a następnie czterokierunkowego zamknięcia. Czterostopniowe zamknięcie, w którym zarówno nadawca, jak i odbiorca zgadzają się na zamknięcie sesji, jest określane jako łagodne zamknięcie. Po czterokierunkowym zamknięciu serwer będzie zezwalał na 4 minuty czasu (domyślnie), podczas którego mają być przetwarzane wszystkie oczekujące pakiety w sieci, ten okres jest stanem TIME_WAIT. Po zakończeniu stanu TIME_WAIT zwalniane są wszystkie zasoby przydzielone dla tego połączenia.
• Resetowanie TCP jest nagłym zamknięciem sesji; Powoduje to natychmiastowe zwolnienie zasobów przydzielonych do połączenia i usunięcie wszystkich innych informacji o połączeniu.
• Resetowanie TCP jest identyfikowane przez flagę RESET w nagłówku TCP ustawioną na 1.

Ślad sieciowy w źródle i miejscu docelowym pomaga określić przepływ ruchu i zobaczyć, w jakim momencie zaobserwowano awarię.

W poniższych sekcjach opisano niektóre scenariusze, w których zobaczysz resetowanie.

Porzucanie pakietów

Gdy jeden element równorzędny TCP wysyła pakiety TCP, dla których nie otrzymano odpowiedzi z drugiego końca, element równorzędny TCP będzie w końcu ponownie przesyłał dane, a jeśli nie otrzymano odpowiedzi, zakończy sesję przez wysłanie resetowania ACK (to resetowanie ACK oznacza, że aplikacja potwierdza, jakiekolwiek dane są wymieniane do tej pory, ale z powodu upuszczania pakietu połączenie jest zamknięte).

Jednoczesne ślady sieci w źródle i miejscu docelowym ułatwią sprawdzenie tego zachowania, gdy po stronie źródła zobaczysz, że pakiety są ponownie przesyłane, a w miejscu docelowym żaden z tych pakietów nie jest widoczny. Ten scenariusz oznacza, że urządzenie sieciowe między źródłem a miejscem docelowym porzuca pakiety.

Jeśli początkowe uzgadnianie protokołu TCP kończy się niepowodzeniem z powodu porzucania pakietów, zobaczysz, że pakiet TCP SYN jest ponownie przesyłany tylko trzy razy.

Połączenie po stronie źródła na porcie 445:

Po stronie docelowej: zastosowanie tego samego filtru nie powoduje wyświetleń żadnych pakietów.

W przypadku pozostałych danych protokół TCP przetransmituje pakiety pięć razy.

Ślad po stronie źródła 192.168.1.62:

Ślad po stronie docelowej 192.168.1.2:

Nie zobaczysz żadnego z powyższych pakietów. Engage zespołu sieciowego w celu zbadania różnych przeskoków i sprawdzenia, czy którykolwiek z nich może powodować spadki w sieci.

Jeśli widzisz, że pakiety SYN docierają do miejsca docelowego, ale miejsce docelowe nadal nie odpowiada, sprawdź, czy port, z którym próbujesz nawiązać połączenie, jest w stanie nasłuchiwania. (Dane wyjściowe netstatu pomogą). Jeśli port nasłuchuje i nadal nie ma odpowiedzi, może wystąpić spadek WFP.

Nieprawidłowy parametr w nagłówku TCP

To zachowanie jest widoczne, gdy pakiety są modyfikowane w sieci przez urządzenia środkowe, a protokół TCP na końcu odbierającym nie może zaakceptować pakietu, takiego jak modyfikowany numer sekwencji lub pakiety powtarzane przez urządzenie środkowe przez zmianę numeru sekwencji. Ponownie jednoczesny ślad sieci w źródle i miejscu docelowym będzie w stanie sprawdzić, czy którykolwiek z nagłówków TCP zostanie zmodyfikowany. Zacznij od porównania śledzenia źródła i śledzenia miejsca docelowego, możesz zauważyć, czy nastąpiła zmiana w samych pakietach lub jeśli jakiekolwiek nowe pakiety docierają do miejsca docelowego w imieniu źródła.

W takim przypadku ponownie będziesz potrzebować pomocy ze strony zespołu sieciowego w celu zidentyfikowania dowolnego urządzenia, które modyfikuje pakiety lub odtwarza pakiety do miejsca docelowego. Najbardziej typowe są urządzenia RiverBed lub akceleratory sieci WAN.

Resetowanie po stronie aplikacji

Po zidentyfikowaniu, że resetowania nie są spowodowane modyfikacją retransmitów, nieprawidłowego parametru lub pakietów przy użyciu śledzenia sieci, zawęziliśmy je do resetowania na poziomie aplikacji.

Resetowanie aplikacji to te, w których zostanie wyświetlona flaga Potwierdzenie ustawiona na 1 wraz z flagą resetowania. To ustawienie oznaczałoby, że serwer potwierdza otrzymanie pakietu, ale z jakiegoś powodu nie zaakceptuje połączenia. Ten etap polega na tym, że aplikacja, która otrzymała pakiet, nie lubiła otrzymanego elementu.

Na poniższych zrzutach ekranu zobaczysz, że pakiety widoczne w źródle i miejscu docelowym są takie same bez żadnych modyfikacji lub zrzutów, ale zobaczysz jawne zresetowanie wysłane przez miejsce docelowe do źródła.

Strona źródłowa

Na śledzeniu po stronie docelowej

Zobaczysz również pakiet flagi ACK+RST w przypadku wysłania syn pakietu zakładu TCP. Pakiet TCP SYN jest wysyłany, gdy klient chce nawiązać połączenie na określonym porcie, ale jeśli miejsce docelowe/serwer z jakiegoś powodu nie chce akceptować pakietu, wyśle pakiet ACK+RST.

Aplikacja, która powoduje zresetowanie (identyfikowane przez numery portów), powinna zostać zbadana, aby zrozumieć, co powoduje zresetowanie połączenia.

Uwaga

Powyższe informacje dotyczą resetowania z punktu widzenia protokołu TCP, a nie UDP. UDP jest protokołem bez połączenia, a pakiety są wysyłane nieodwracalnie. Podczas używania protokołu UDP jako protokołu transportowego nie będzie widoczna retransmisję ani resetowanie. Jednak protokół UDP używa protokołu ICMP jako protokołu raportowania błędów. Gdy pakiet UDP zostanie wysłany na porcie, a miejsce docelowe nie ma portu na liście, zobaczysz, że miejsce docelowe wysyła hosta docelowego ICMP nieosiągalne: port jest nieosiągalny natychmiast po pakietze UDP.

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 problemu z łącznością w śladzie sieci może być również widoczne, że maszyna odbiera pakiety, ale na nie odpowiada. W takich przypadkach może wystąpić spadek na poziomie serwera. Aby zrozumieć, czy zapora lokalna porzuca pakiet, włącz inspekcję zapory na maszynie.

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

Następnie możesz przejrzeć dzienniki zdarzeń zabezpieczeń, aby zobaczyć, czy pakiet został upuszczony na określonym porcie-adresie IP i skojarzony z nim identyfikator filtru.

Teraz uruchom polecenie netsh wfp show state, to wykonanie wygeneruje plikwfpstate.xml . Po otwarciu tego pliku i odfiltrowaniu identyfikatora, który znajduje się w powyższym zdarzeniu (2944008), będzie można zobaczyć nazwę reguły zapory skojarzoną z tym identyfikatorem, który blokuje połączenie.