Проблема с сетевой доступностью.

Какбы не работал NM, всё одно есть таблица маршрутизации (ip route) и адреса на интрерфейсах (ip addr). Вот их и можно посмотреть. Но, возможно, что дело в конфигурации виртуалок.

При пинге с третьей - на второй tcpdump ловит arp-ы, а вот на первой - нет.

При этом на третьей машине в tcpdump'е видны исходящие arp-запросы?

При этом на третьей машине в tcpdump'е видны исходящие arp-запросы?

Да, исходящие arp-ы есть. Меня смущало то, что в консоли на третьей они выглядят как

ARP, Request who-has gateway, tell localhost.localdomain, length 28

но на второй tcpdump их показывает вот так:

ARP, Request who-has 192.168.0.1, tell 192.168.0.11, length 46

Я так понял, что это просто вывод tcpdump-а на третьей преобразовывает айпишники в имена.

Вот их и можно посмотреть

На первой:

ip addr

1: lo: ...

   inet 127.0.0.1/8

2: eno16777984
   link/ether 00:50:56:93:5d:a0
   inet 192.168.0.1/24 brd 192.168.0.255

3: eno33557248
   link/ether 00:50:56:93:37:59

eno33557248 сейчас ни к чему не подключен. nmcli dev показывает его как disconnected.

ip route

192.168.0.0/24 dev eno16777984 proto kernel scope link src 192.168.0.1 metric 100

На второй:

ip addr

1: lo: ...

   inet 127.0.0.1/8

2: eno16777984
   link/ether 00:50:56:93:4e:65
   inet 192.168.0.2/24 brd 192.168.0.255

ip route

192.168.0.0/24 dev eno16777984 proto kernel scope link src 192.168.0.2 metric 100

На третьей:

ip addr

1: lo: ...

   inet 127.0.0.1/8

2: eno16777984
   link/ether 00:50:56:93:08:16
   inet 192.168.0.11/24 brd 192.168.0.255

ip route

default via 192.168.0.1 dev eno16777984 proto static metric 100

192.168.0.0/24 dev eno16777984 proto kernel scope link src 192.168.0.11 metric 100

Я так понял, что это просто вывод tcpdump-а на третьей преобразовывает айпишники в имена.

Да. Есть опция ″-n″, чтобы не преобразовывал. Хотя, конечно, странно, почему ″192.168.0.11″ стало ″localhost.localdomain″.

Я правильно понял, что при пинге с третьей на первую, tcpdump на третьей и второй показывает arp-запросы, а на первой нет? Если так, что получается, что третья машина arp-отправляет и они от неё уходят, но до первой не доходят. Это больше похоже на проблемы виртуальной сети между ВМ, чем на проблемы настройки ОС внутри ВМ. tcpdump «видит» все пакеты, приходящие на интерфейс, поэтому если он не «видит» arp-запрос, значит он не доходит до интерфейса, а не отбрасывается ядром из-за настроек в /proc и т.д.

Я правильно понял, что при пинге с третьей на первую, tcpdump на третьей и второй показывает arp-запросы, а на первой нет?

Все верно. Я уже думал про то, что могут быть проблемы с вирт. сетью, но тут какой момент - когда я пингую первую машину со второй, то, во-первых, пинг есть, а во-вторых, на третьей я вижу как arp-request, так и arp-reply от первой машины. Я, правда, вообще все вижу, включая icmp echo-request и icmp echo-reply.

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

PS прописал на 192.168.0.11 mac-адрес 192.168.0.1 руками (через arp -s), и ничего не поменялось. Вижу icmp echo-request на 192.168.0.11 (третья машина, с которой пингую), вижу их на 192.168.0.2 (вторая, которая просто в той же сети), но не вижу на 192.168.0.1 (первая, которую пытаюсь пропинговать).

Попробую сперва пересоздать интерфейсы, а потом - вообще португруппу.