TCP Retransmisja jest kontynuowana nawet po zresetowaniu flagi RST

Question

Z mojego zrozumienia flagi TCP reset (RST) jest ustawiana, gdy odebrany segment nie jest przeznaczony dla bieżącego połączenia, a to powoduje przerwanie bieżącej sesji TCP. Ale schwytanie wiresharka wklejone poniżej nie wydaje się iść za tą teorią. Zasadniczo koniec A, który zainicjował RESET (ramka # 466) sam próbuje ponownie wysłać ramki TCP przez tę samą sesję TCP, a także nadal odpowiadać na każde kolejne żądanie połączenia [SYN] od końca B z [RST, ACK] i tym zachowanie powtarza się 5 razy, a 3-krotny uścisk dłoni powtarza się tylko podczas szóstej próby (ramka # 486).

464 04:35.1 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105    
465 04:35.2 enpc > 50000 [ACK] Seq=7454 Ack=31999 Win=32127 Len=0    
466 04:35.2 50000 > enpc [RST] Seq=31999 Win=0 Len=0     
467 04:35.4 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105     
468 04:36.1 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105     
469 04:37.5 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105     
470 04:40.3 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105     
471 04:45.9 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105     
472 04:57.1 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105     
473 05:17.1 fg-fps > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1     
474 05:17.1 50000 > fg-fps [RST, ACK] Seq=1 Ack=1 Win=0 Len=0    
475 05:17.5 fg-fps > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1     
476 05:17.5 50000 > fg-fps [RST, ACK] Seq=1 Ack=1 Win=0 Len=0    
477 05:18.0 fg-fps > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1     
478 05:18.0 50000 > fg-fps [RST, ACK] Seq=1 Ack=1 Win=0 Len=0    
479 05:19.5 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105     
480 05:23.2 fg-gip > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1     
481 05:23.2 50000 > fg-gip [RST, ACK] Seq=1 Ack=1 Win=0 Len=0    
482 05:23.7 fg-gip > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1     
483 05:23.7 50000 > fg-gip [RST, ACK] Seq=1 Ack=1 Win=0 Len=0    
484 05:24.2 fg-gip > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1     
485 05:24.2 50000 > fg-gip [RST, ACK] Seq=1 Ack=1 Win=0 Len=0    
486 05:29.7 dyniplookup > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1    
487 05:29.7 50000 > dyniplookup [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=2    
488 05:29.7 dyniplookup > 50000 [ACK] Seq=1 Ack=1 Win=65536 Len=0    
489 05:29.7 dyniplookup > 50000 [PSH, ACK] Seq=1 Ack=1 Win=65536 Len=105     
490 05:29.7 50000 > dyniplookup [ACK] Seq=1 Ack=106 Win=5840 Len=0    
491 05:29.7 dyniplookup > 50000 [PSH, ACK] Seq=106 Ack=1 Win=65536 Len=105    

Moje pytanie:

Dlaczego zakończyć przechowywane na re-przekazującej pakiety przez połączenie gdzie RST została wygenerowana z jego własnym końcem?

Answer 1

Istnieje wiele powodów, dla których może zostać wysłany komunikat RST. Flaga resetowania jest używana, gdy nadchodzi segment TCP, który nie jest przeznaczony dla bieżącego otwartego połączenia lub portu nasłuchującego. Na przykład, jeśli port TCP zostanie zamknięty, stos TCP w systemie odpowie RST.

Zazwyczaj, gdy system wysyła reset TCP, będzie miał również ustawioną flagę AC, potwierdzającą próbę połączenia W twoim przypadku nie ma flagi ACK, która (z pamięci) zgodnie z RFC jest wykonywana tylko wtedy, gdy nie ma ustanowionego połączenia, które jest w twoim przypadku, co sugerowałoby mi, że jest to zapora ogniowa lub urządzenie pośredniczące (nie jest częścią połączenia TCP), który wysyła reset. Dlatego serwer A będzie słusznie wtedy nadal uważał, że połączenie jest żywe.

Ramki 467-472 są standardowym zachowaniem retransmisji TCP (z systemu A), a czas między próbami podwojenia połączenia z serwerem w końcu okazuje się zrezygnować po ostatniej próbie w klatce 472. Te ramki są retransmisjami ramki 464, która wydaje się wskazywać, że ramka 465 nie została odebrana przez system B. Zgaduję, że wziąłeś przechwytywanie w systemie B?

wierzę A System przeniesiona tylko zamknięty po rama 473 został wysłany, który wyjaśni dlaczego my wtedy zobaczyć trzy-way handshake zainicjowane z systemu B.

ze swojego śladu, to trudno powiedzieć znacznie więcej bez większa wiedza na temat sieci.

HTH!