Флаг сброса TCP (RST)

Question

Я пытаюсь транслировать видео между двумя хостами, также пытаюсь смоделировать сценарий смены IP, клиент начал слушать сервер, затем я переместил клиента на новый коммутатор, и он получил 192.168.2.5, я использую Mininet и Ryu контроллер. моя топология выглядит следующим образом:

ha-eth0<->s1-eth1 (OK OK)
hb-eth0<->s2-eth12 (OK OK)
hc-eth0<->s1-eth3 (OK OK)
s2-eth1<->s1-eth4 (OK OK)
s2-eth2<->s3-eth1 (OK OK)

Я использую vlc-wraper и HTTP-протокол для streaminh. также я установил следующие потоки, чтобы изменить IP-адрес клинта на коммутаторах 1 и 2:

 cookie=0x0, duration=1012.669s, table=0, n_packets=2, n_bytes=1894, idle_age=1004, priority=3,ip,nw_src=192.168.2.2,nw_dst=192.168.2.3 actions=output:4

 cookie=0x0, duration=1012.668s, table=0, n_packets=1, n_bytes=54, idle_age=1004, priority=3,ip,nw_src=192.168.2.3,nw_dst=192.168.2.2 actions=output:1

 cookie=0x0, duration=1059.340s, table=0, n_packets=1, n_bytes=947, idle_age=1051, priority=3,ip,nw_src=192.168.2.2,nw_dst=192.168.2.3 actions=mod_nw_dst:192.168.2.5,output:12

 cookie=0x0, duration=1059.340s, table=0, n_packets=1, n_bytes=54, idle_age=1051, priority=3,ip,nw_src=192.168.2.5,nw_dst=192.168.2.2 actions=mod_nw_src:192.168.2.3,output:1

ha(Host A) IP 192.168.2.2 (клиентский хост)
hb (Host B) старый IP-адрес 192.168.2.3 и новый IP-адрес 192.168.2.5 (хост сервера)

когда поток остановился, я проверил Wireshark и заметил, что там был TCP RST, но я не знаю почему? может кто-нибудь посмотреть в файлах Wireshark и сказать мне причины.

Я прикрепил вывод Wireshark для обоих хостов https://drive.google.com/open?id=1rcVlNT2cwnvNL4-4j061xGpKJohSdU9z

Answer 1

В соответствии со спецификациями TCP, идентичность TCP-соединения определяется комбинацией этих четырех вещей:

• IP-адрес конечной точки A
• Номер порта TCP конечной точки A
• IP-адрес конечной точки B
• Номер порта TCP конечной точки B

Если какая-либо из этих четырех вещей изменяется, то по определению базового протокола TCP это больше не то же самое соединение.

Когда ваш Хост B переключился со своего старого IP-адреса на новый, все существующие соединения и связанное с ними состояние были привязаны к старому IP-адресу. Операционная система достаточно умна, чтобы знать, что после изменения IP-адреса интерфейса любые существующие TCP-соединения не могут быть продолжены, так как старый IP-адрес больше не может использоваться.

Очевидно, что изменение IP-адреса было довольно резким в том, что касается хоста B: нет ни DHCPRELEASE, ни каких-либо попыток упорядоченного завершения существующих соединений перед разрушением старого IP-адреса.

В результате на сетевом интерфейсе хоста B, поскольку старый IP-адрес разрушен, также возникают любые TCP-соединения, которые были связаны со старым IP-адресом.

Ваша программно-определяемая сеть, очевидно, заботится о преобразовании адресов назначения пакетов, поступающих с хоста A, на новый IP-адрес - но операционная система хоста B не знает об этом, и поэтому не имеет ни малейшего представления, что в этом конкретном случае было бы возможно сохранить состояние соединения и продолжать использовать его даже с новым IP-адресом.

Таким образом, как только хост B получает один из повторно переданных пакетов от хоста A, он видит, что он адресован с 192.168.2.2, порт 1234 - 192.168.2.5, порт 37186. Не существует записи о существующем TCP-соединении с этими точными параметрами, поэтому операционная система может отправлять только TCP RST в качестве ответа.

(Даже если информация о старом соединении была сохранена, она имела сторону хоста B в IP-адресе как 192.168.2.3, поэтому, насколько известно узлу B, этот новый пакет для 192.168.2.5 не имеет абсолютно никакого отношения к этому старому соединению.)

Когда ответ RST возвращается к хосту A, SDN преобразует свой адрес источника в 192.168.2.3, поэтому хост A распознает его как принадлежащий существующему соединению. И поэтому узел A получит сообщение о том, что поток мертв.