Невозможно проверить связь с хостом с двумя интерфейсами

Я пытаюсь выяснить, почему сетевой интерфейс не доступен для проверки связи и возвращает ответ ICMP типа 3 с кодом 1: Пункт назначения недоступен (хост недоступен).

Я пытаюсь выполнить эхо-запрос с host1 на один из двух интерфейсов на host2. Что странно, так это то, что если я пингуюсь с хоста 2 на хост 1, пинг проходит успешно, а исходный пинг (с хоста 1 на хост 2) внезапно начинает работать. Через некоторое время первоначальная проблема возвращается, и я снова не могу выполнить эхо-запрос с host1 на host2. Я думаю, это связано с маршрутами и тем фактом, что у меня два интерфейса на host2. Вот подробности:

Попробуйте пинговать от host1 (172.16.44.18) к host2 (10.2.80.129). На host1 не возвращается никакой ответ (100% потеря пакетов)

root@host1:~$ ping 10.2.80.129
PING 10.2.80.129 (10.2.80.129) 56(84) bytes of data.
^C
--- 10.2.80.129 ping statistics ---
1201 packets transmitted, 0 received, 100% packet loss, time 1228803ms

Вот интерфейсы и маршруты на host2.

root@host2:~# ip --brief -4 addr
lo               UNKNOWN        127.0.0.1/8
veth-int-core@if183 UP             10.2.80.129/22
veth-mgmt@if185  UP             10.2.28.65/22

root@host2:~# ip route show
default via 10.2.28.1 dev veth-mgmt
10.2.28.0/22 dev veth-mgmt proto kernel scope link src 10.2.28.65
10.2.80.0/22 dev veth-int-core proto kernel scope link src 10.2.80.129

Фильтрация обратного пути установлена ​​на 2:

root@host2:~# cat /proc/sys/net/ipv4/conf/veth-int-core/rp_filter 
2

Я вижу, что эхо-запрос ICMP поступает через интерфейс veth-int-core, но я никогда не вижу эхо-ответа ICMP.

root@host2:~# tcpdump -nei veth-int-core icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on veth-int-core, link-type EN10MB (Ethernet), capture size 262144 bytes
12:42:51.117858 e4:aa:5d:99:88:4a > 00:16:3e:f7:fa:c8, ethertype IPv4 (0x0800), length 98: 172.16.44.18 > 10.2.80.129: ICMP echo request, id 177, seq 3, length 64
12:42:52.141535 e4:aa:5d:99:88:4a > 00:16:3e:f7:fa:c8, ethertype IPv4 (0x0800), length 98: 172.16.44.18 > 10.2.80.129: ICMP echo request, id 177, seq 4, length 64
12:42:53.165507 e4:aa:5d:99:88:4a > 00:16:3e:f7:fa:c8, ethertype IPv4 (0x0800), length 98: 172.16.44.18 > 10.2.80.129: ICMP echo request, id 177, seq 5, length 64
12:42:54.189568 e4:aa:5d:99:88:4a > 00:16:3e:f7:fa:c8, ethertype IPv4 (0x0800), length 98: 172.16.44.18 > 10.2.80.129: ICMP echo request, id 177, seq 6, length 64

Когда я смотрю на интерфейс обратной связи, я вижу ответ о недоступности пункта назначения

root@host2:~# tcpdump -nei lo icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
12:43:52.903768 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 126: 10.2.80.129 > 10.2.80.129: ICMP host 172.16.44.18 unreachable, length 92
12:43:52.903774 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 126: 10.2.80.129 > 10.2.80.129: ICMP host 172.16.44.18 unreachable, length 92
12:43:52.903779 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 126: 10.2.80.129 > 10.2.80.129: ICMP host 172.16.44.18 unreachable, length 92
12:43:55.975774 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 126: 10.2.80.129 > 10.2.80.129: ICMP host 172.16.44.18 unreachable, length 92

Когда я смотрю на пакеты в Wireshark, я вижу ответ типа 3 code 1:

Однако, если я пингую с хоста 1 (172.16.44.18) с хоста 2, начнется работа исходного пинга с хоста 1 (172.16.44.18) на хост 2 (10.2.80.129). Обратите внимание, что этот эхо-запрос выходит из интерфейса veth-mgmt (10.2.28.65), поскольку это маршрут по умолчанию.

root@host2:~# ping 172.16.44.18
PING 172.16.44.18 (172.16.44.18) 56(84) bytes of data.
64 bytes from 172.16.44.18: icmp_seq=1 ttl=63 time=4.06 ms
64 bytes from 172.16.44.18: icmp_seq=2 ttl=63 time=4.05 ms
64 bytes from 172.16.44.18: icmp_seq=3 ttl=63 time=4.12 ms
^C
--- 172.16.44.18 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 4.052/4.079/4.122/0.060 ms

root@host1:~$ ping 10.2.80.129
PING 10.2.80.129 (10.2.80.129) 56(84) bytes of data.
64 bytes from 10.2.80.129: icmp_seq=488 ttl=62 time=1021 ms
64 bytes from 10.2.80.129: icmp_seq=489 ttl=62 time=4.09 ms
64 bytes from 10.2.80.129: icmp_seq=490 ttl=62 time=4.05 ms
64 bytes from 10.2.80.129: icmp_seq=491 ttl=62 time=4.07 ms
64 bytes from 10.2.80.129: icmp_seq=492 ttl=62 time=4.09 ms
64 bytes from 10.2.80.129: icmp_seq=493 ttl=62 time=4.20 ms
^C
--- 10.2.80.129 ping statistics ---
493 packets transmitted, 6 received, 98.783% packet loss, time 503706ms
rtt min/avg/max/mdev = 4.054/173.652/1021.412/379.129 ms

Если я подожду несколько минут, проблема вернется, и я не смогу пропинговать host2 с host1.

Что может вызвать такого рода проблемы? Я чувствую, что это должно быть связано с маршрутизацией. Похоже, что host2 не знает, как вернуться к host1, но затем, когда вы пытаетесь ping host1 от host2, он узнает этот маршрут.

Когда я пингую host1 с host2 и все работает, пакеты ICMP приходят на veth-int-core и отправляются на veth-mgmt, но с использованием адреса источника 10.2.80.129

root@host2:~# tcpdump -nvei any icmp
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
16:35:15.659341  In e4:aa:5d:99:88:4a ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 62, id 59067, offset 0, flags [DF], proto ICMP (1), length 84)
    172.16.44.18 > 10.2.80.129: ICMP echo request, id 202, seq 51, length 64
16:35:15.659361 Out 00:16:3e:e4:13:09 ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 64, id 56778, offset 0, flags [none], proto ICMP (1), length 84)
    10.2.80.129 > 172.16.44.18: ICMP echo reply, id 202, seq 51, length 64
16:35:16.660651  In e4:aa:5d:99:88:4a ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 62, id 59204, offset 0, flags [DF], proto ICMP (1), length 84)
    172.16.44.18 > 10.2.80.129: ICMP echo request, id 202, seq 52, length 64
16:35:16.660670 Out 00:16:3e:e4:13:09 ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 64, id 56854, offset 0, flags [none], proto ICMP (1), length 84)
    10.2.80.129 > 172.16.44.18: ICMP echo reply, id 202, seq 52, length 64