Co powoduje wysłanie flagi resetowania TCP / IP (RST)?

Próbuję dowiedzieć się, dlaczego połączenie TCP / IP mojej aplikacji przerywa czkawkę co 10 minut (dokładnie w ciągu 1-2 sekund). Uruchomiłem Wiresharka i odkryłem, że po 10 minutach bezczynności drugi koniec wysyła pakiet z ustawioną flagą resetowania (RST). Wyszukiwarka Google mówi mi, że „flaga RESET oznacza, że ​​odbiorca jest zdezorientowany i chce przerwać połączenie”, ale brakuje mi szczegółów, których potrzebuję. Co może być tego przyczyną? I czy to możliwe, że jakiś router po drodze jest za to odpowiedzialny, czy też zawsze będzie to pochodzić z innego punktu końcowego?

Edycja: Między moim komputerem a drugim punktem końcowym znajduje się router (w szczególności Linksys WRT-54G) - czy jest coś, czego powinienem szukać w ustawieniach routera?

`` Router '' może robić wszystko - szczególnie NAT, co może wiązać się z dowolną ilością błędów w ruchu ...

Jednym z powodów, dla których urządzenie wyśle ​​RST, jest odpowiedź na odebranie pakietu dla zamkniętego gniazda.

Trudno jest udzielić jednoznacznej, ale ogólnej odpowiedzi, ponieważ każda możliwa perwersja była odwiedzana na TCP od samego początku, a wszyscy ludzie mogą wstawiać RST, próbując zablokować ruch. (Na przykład niektóre „krajowe zapory ogniowe” działają w ten sposób).

Uruchom sniffer pakietów (np. Wireshark) również na peerze, aby sprawdzić, czy to peer wysyła RST, czy ktoś w środku.

Właśnie spędziłem trochę czasu na rozwiązywaniu tego właśnie problemu. Żadne z proponowanych rozwiązań nie zadziałało. Okazało się, że nasz sysadmin przez pomyłkę przypisał ten sam statyczny adres IP do dwóch niepowiązanych ze sobą serwerów należących do różnych grup, ale znajdujących się w tej samej sieci. Efektem końcowym były sporadyczne zerwane połączenia vnc, przeglądarka, która musiała być kilkakrotnie odświeżana, aby pobrać stronę internetową i inne dziwne rzeczy.

Niektóre firewalle robią to, jeśli połączenie jest bezczynne przez x liczbę minut. Niektórzy usługodawcy internetowi ustawiają swoje routery w taki sposób również z różnych powodów.

W dzisiejszych czasach będziesz musiał z wdziękiem poradzić sobie z tym stanem (w razie potrzeby przywrócić go).

RST jest wysyłany przez stronę wykonującą aktywne zamknięcie, ponieważ jest to strona, która wysyła ostatnie ACK. Więc jeśli otrzyma FIN od strony wykonującej pasywne zamknięcie w złym stanie, wysyła pakiet RST, który wskazuje drugiej stronie, że wystąpił błąd.

Jeśli istnieje router wykonujący NAT, zwłaszcza router niskiej jakości z niewielką liczbą zasobów, najpierw starzeje najstarsze sesje TCP. Aby to zrobić, ustawia RSTw pakiecie flagę, która skutecznie nakazuje stacji odbierającej (bardzo niezręcznie) zamknięcie połączenia. ma to na celu oszczędzanie zasobów.

Należy pamiętać, że wiele firewalli netfilter w Linuksie jest źle skonfigurowanych.

Jeśli masz coś takiego:

-A FORWARD -m stan - stan ZWIĄZANY, USTANOWIONY -j AKCEPTUJ

-A FORWARD -p tcp -j REJECT --reject-with tcp-reset

wtedy zmiana kolejności pakietów może skutkować uznaniem przez zaporę sieciową pakietów za nieważne, a tym samym generowaniem resetów, które następnie przerywają zdrowe połączenia.

Zmiana kolejności jest szczególnie prawdopodobna w przypadku sieci bezprzewodowej.

Zamiast tego powinno to być:

-A FORWARD -m stan - stan ZWIĄZANY, USTANOWIONY -j AKCEPTUJ

-A FORWARD -m stan --state INVALID -j DROP

-A FORWARD -p tcp -j REJECT --reject-with tcp-reset

Zasadniczo zawsze, gdy masz:

... -m stan - stan ZWIĄZANY, USTANOWIONY -j AKCEPTUJ

zaraz po nim powinno następować:

... -m stan --state NIEPRAWIDŁOWY -j DROP

Lepiej jest porzucić pakiet, a następnie wygenerować potencjalnie zakłócający protokół reset tcp. Resetowanie jest lepsze, gdy można udowodnić, że jest właściwą rzeczą do wysłania ... ponieważ eliminuje to limity czasu. Ale jeśli jest jakakolwiek szansa, że ​​są niepełnosprawni, mogą powodować tego rodzaju ból.

Dzieje się tak, ponieważ w sieci istnieje inny proces wysyłający RST do połączenia TCP.

Zwykle RST zostanie wysłany w następującym przypadku

• Proces zamyka gniazdo, gdy gniazdo używające opcji SO_LINGER jest włączone
• System operacyjny czyści zasoby, gdy proces kończy pracę bez zamykania gniazda.

W twoim przypadku brzmi to tak, jakby proces łączył twoje połączenie (port IP +) i nadal wysyła RST po ustanowieniu połączenia.