У меня какая-то странная проблема. После перезагрузки сервера несколько дней назад он неправильно маршрутизирует свои пакеты. Он в основном не отвечает (например, на пинг), если эти пакеты приходят из определенных сетей.
Это виртуальная машина (Qemu, KVM, Debian 10). На том же хосте есть еще одна виртуальная машина, почти идентичная проблемной, которая отлично работает.
Они используют одни и те же мосты для связи, оба используют драйверы virtio для своих сетевых интерфейсов, оба имеют пустые iptables и их таблицы маршрутизации одинаковы.
Затронутый сервер имеет IP 172.16.0.30. Действующий сервер имеет 172.16.0.93.
Destination Gateway Genmask Flags Metric Ref Use Iface
default 172.16.0.1 0.0.0.0 UG 0 0 0 ens10
172.16.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ens10
172.16.2.0 0.0.0.0 255.255.255.0 U 0 0 0 ens3
-------------------------------------------
root@server:~# iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
-------------------------------------------
root@server:~# ip addr show dev ens10
4: ens10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 52:54:00:87:2a:5f brd ff:ff:ff:ff:ff:ff
inet 172.16.0.30/24 brd 172.16.0.255 scope global ens10
valid_lft forever preferred_lft forever
Если я, например, пингую клиент 172.16.34.123, пинг на моем сервере скажет мне, что он не получил никаких пакетов. Но tcpdump на шлюзе и на самом сервере показывает, что сервер получил пакеты, но как-то не реагирует на них.
root@opsi:~# ping 172.16.34.123
PING 172.16.34.123 (172.16.34.123) 56(84) bytes of data.
--- 172.16.34.123 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 70ms
-------------------------------------------
root@server:~# tcpdump -n -i ens10 host 172.16.34.123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens10, link-type EN10MB (Ethernet), capture size 262144 bytes
09:37:56.850996 IP 172.16.0.30 > 172.16.34.123: ICMP echo request, id 1293, seq 1, length 64
09:37:56.852292 IP 172.16.34.123 > 172.16.0.30: ICMP echo reply, id 1293, seq 1, length 64
09:37:57.869612 IP 172.16.0.30 > 172.16.34.123: ICMP echo request, id 1293, seq 2, length 64
09:37:57.870655 IP 172.16.34.123 > 172.16.0.30: ICMP echo reply, id 1293, seq 2, length 64
09:37:58.893600 IP 172.16.0.30 > 172.16.34.123: ICMP echo request, id 1293, seq 3, length 64
09:37:58.894489 IP 172.16.34.123 > 172.16.0.30: ICMP echo reply, id 1293, seq 3, length 64
Как я уже сказал, другая машина, которая подключается к тому же мосту, не имеет этой проблемы. Если я пропингую сервер с другой машины, сервер получит пакет, но не отправит ответ. Еще несколько дней назад этот сервер работал правильно. Я попытался изменить сетевые устройства, сетевые драйверы и изменить конфигурацию между dhcp и статическими настройками.
Пинг другой сети (10.8.0.0) работает нормально.
root@server:~# ping 10.8.0.39
PING 10.8.0.39 (10.8.0.39) 56(84) bytes of data.
64 bytes from 10.8.0.39: icmp_seq=1 ttl=63 time=22.8 ms
64 bytes from 10.8.0.39: icmp_seq=2 ttl=63 time=25.10 ms
64 bytes from 10.8.0.39: icmp_seq=3 ttl=63 time=23.9 ms
^C
--- 10.8.0.39 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 22.794/24.212/25.975/1.321 ms
--------------------------------------------
root@server:~# tcpdump -n -i ens10 -qtln icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens10, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 172.16.0.30 > 10.8.0.39: ICMP echo request, id 3556, seq 1, length 64
IP 10.8.0.39 > 172.16.0.30: ICMP echo reply, id 3556, seq 1, length 64
IP 172.16.0.30 > 10.8.0.39: ICMP echo request, id 3556, seq 2, length 64
IP 10.8.0.39 > 172.16.0.30: ICMP echo reply, id 3556, seq 2, length 64
IP 172.16.0.30 > 10.8.0.39: ICMP echo request, id 3556, seq 3, length 64
IP 10.8.0.39 > 172.16.0.30: ICMP echo reply, id 3556, seq 3, length 64
Есть идеи, в чем может быть причина?
Решил это. На шлюзе удалена запись таблицы arp для этого интерфейса. Он создал новую запись, и теперь она снова работает.