Почему некоторые tcp-пакеты с флагом RST классифицируются как новое входящее соединение?

Question

Просматривая журнал iptables, я периодически наблюдаю входящие соединения с установленным флагом RESET с нескольких ip-адресов в сети моего провайдера. Это пример tcpdump для одного из этих соединений:

22:18:13.026881 IP 192.168.1.2.43948 > XX.XX.X.103.443: Flags [S]  seq 3805987202     win 29200  options [mss 1460 sackOK TS val 3031189 ecr 0 nop wscale 7]  length 0  
22:18:13.032076 IP XX.XX.X.103.443 > 192.168.1.2.43948: Flags [S.]  seq 738249760  ack 3805987203  win 29200  options [mss 1460 nop nop sackOK nop wscale 6]  length 0     
22:18:13.032151 IP 192.168.1.2.43948 > XX.XX.X.103.443: Flags [.]   738249761  ack 1  win 229  length 0 
22:18:13.032415 IP 192.168.1.2.43948 > XX.XX.X.103.443: Flags [P.]  seq 3805987203:3805987396  ack 1  win 229  length 193 
22:18:13.036553 IP XX.XX.X.103.443 > 192.168.1.2.43948: Flags [.]   3805987396  ack 194  win 473  length 0 
22:18:13.042920 IP XX.XX.X.103.443 > 192.168.1.2.43948: Flags [.]  seq 738249761:738251221  ack 194  win 473  length 1460 
22:18:13.042979 IP 192.168.1.2.43948 > XX.XX.X.103.443: Flags [.]   738251221  ack 1461  win 251  length 0 
22:18:13.043133 IP XX.XX.X.103.443 > 192.168.1.2.43948: Flags [P.]  seq 738251221:738251809  ack 194  win 473  length 588 
....
22:20:10.652745 IP 192.168.1.2.43948 > XX.XX.X.103.443: Flags [.]   738254876  ack 5116  win 365  length 0 
22:21:09.649107 IP 192.168.1.2.43948 > XX.XX.X.103.443: Flags [P.]  seq 3805988348:3805988389  ack 5116  win 365  length 41 
22:21:09.657454 IP XX.XX.X.103.443 > 192.168.1.2.43948: Flags [P.]  seq 738254876:738254921  ack 1187  win 509  length 45 
22:21:09.657498 IP 192.168.1.2.43948 > XX.XX.X.103.443: Flags [.]   738254921  ack 5161  win 365  length 0 
22:21:09.657612 IP 192.168.1.2.43948 > XX.XX.X.103.443: Flags [P.]  seq 3805988389:3805988434  ack 5161  win 365  length 45 
22:21:09.657748 IP 192.168.1.2.43948 > XX.XX.X.103.443: Flags [FP.]  seq 3805988434:3805988465  ack 5161  win 365  length 31 
22:21:09.660431 IP XX.XX.X.103.443 > 192.168.1.2.43948: Flags [F.]  seq 738254921  ack 1187  win 509  length 0 
22:21:09.660467 IP 192.168.1.2.43948 > XX.XX.X.103.443: Flags [.]   738254922  ack 5162  win 365  length 0 
22:21:09.667156 IP XX.XX.X.103.443 > 192.168.1.2.43948: Flags [R]  seq 738254921     win 0  length 0 
22:21:09.667923 IP XX.XX.X.103.443 > 192.168.1.2.43948: Flags [R]  seq 738254921     win 0  length 0 
22:21:09.667971 IP XX.XX.X.103.443 > 192.168.1.2.43948: Flags [R]  seq 738254922     win 0  length 0 

Порядковый номер tcp является непрерывным. Не следует ли это рассматривать как часть установленного соединения, используя правило в iptables ниже:

-A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT

Answer 1

Сброс TCP - это неподтвержденный метод завершения соединения TCP. Обычно резервируется для случая, когда что-то пошло не так, и требуется быстрый способ начать все сначала (после RST).

Если в разгар вашего TCP-соединения вы получаете RST от того же протокола, IP-адреса источника, порта источника, IP-адреса назначения, порта назначения (также известного как Five-Tuple), вы классифицируете этот пакет как принимаемый "в пределах". «установленное соединение.

Однако, если вы являетесь субъектом, отправляющим RST, вы немедленно удалили информацию о своем соединении после отправки RST. Если в этот момент другой конец решит отправить TCP RST, после его получения вы не будете знать об этом конкретном «Five-Tuple» (поскольку вы только что удалили это знание), поэтому вы будете рассматривать только что полученный пакет "Новое" соединение, которое затем будет немедленно удалено из таблицы соединений, поскольку именно это следует сделать в ответ на пакет RST.

Короче говоря, чтобы ответить на ваш вопрос. Ваша машина пометит RST-пакет как новое соединение, если у него не было предварительных сведений о соединении (иначе говоря, пятикорпусном), внутри которого был отправлен RST.

Answer 2

Похоже, сервер жестко закрывает соединение.

Вот некоторая информация о TCP RST: TCP использует бит RST (Сброс) в заголовке TCP для сброса соединения TCP. Сброс надлежащим образом отправляется, например, в ответ на запрос на несуществующее соединение. Получатель TCP сброса сбрасывает соединение TCP и уведомляет приложение [RFC793, RFC1122, Ste94].

Также эта тема кажется связанной и уместной: какова причина и как избежать [FIN, ACK], [RST] и [RST, ACK]

Answer 3

Я наблюдал такое поведение с некоторыми клиентами в моей сети, когда у меня было несоответствие MTU для одного сегмента - нормальный MTU равен 1500, но у маршрутизаторов сегмента было 1300, в конечном итоге время ожидания пакетов клиента и PUSH не доходят до места назначения и другой стороны начал в РСТ. Исправление MTU для сегмента позволило решить проблему.