у меня есть KVM/QEMU настройка с запущенным хостом и гостем (ВМ) Ubuntu 18.04 LTS с участием bridged networking. Виртуальные машины настраиваются со статическим IP-адресом для свободного сетевого подключения случайным образом (нет шаблона). Виртуальные машины, настроенные с помощью DHCP, работают нормально.
Вот конфигурация моей хост-сети,
network:
version: 2
ethernets:
eno1:
dhcp4: no
dhcp6: no
eno4:
dhcp4: true
eno5np0:
dhcp4: true
eno6np1:
dhcp4: true
ens2f0np0:
dhcp4: true
ens2f1np1:
dhcp4: true
bridges:
br0:
interfaces: [eno1]
dhcp4: no
addresses:
- 10.2.0.92/24
gateway4: 10.2.1.252
nameservers:
addresses:
- 8.8.8.8
Вот моя конфигурация сети vm (гостевая) со статическим IP,
network:
version: 2
ethernets:
ens3:
dhcp4: no
addresses:
- 10.2.0.210/23
gateway4: 10.2.1.252
nameservers:
addresses:
- 8.8.8.8
Вот моя конфигурация сети vm (гостевая) с DHCP,
network:
version: 2
ethernets:
ens3:
dhcp4: true
Виртуальные машины со статическим IP-адресом переходят в состояние ожидания. Поэтому, когда вы когда-либо пытаетесь подключиться к SSH или получить доступ к службам в нем, требуется время, затем он подключается,
$ nc -z -v -w5 10.2.0.210 22
nc: connect to 10.2.0.210 port 22 (tcp) timed out: Operation now in progress
Попробуйте еще раз, это сработает, потому что виртуальная машина перешла из состояния ожидания в рабочее состояние с первой попытки,
$nc -z -v -w5 10.2.0.210 22
Connection to 10.2.0.210 22 port [tcp/ssh] succeeded!
Нет проблем с виртуальными машинами с DHCP. Он отлично подключается в любое время,
$ nc -z -v -w5 10.2.0.184 22
Connection to 10.2.0.184 22 port [tcp/ssh] succeeded!
Я проверил следующие ссылки,
но это не помогло.
Есть проблемы с конфигурацией KVM? Не только SSH, но и любые сервисы, представленные на виртуальных машинах, также недоступны. Я подтвердил, что VMs are in running state когда я спрашиваю virsh.
Одна довольно основная проблема, которую я вижу, заключается в том, что ваш шлюз на br0 не входит в область действия адреса. Вы определяете / 24 вместо / 23.
br0:
interfaces: [eno1]
dhcp4: no
addresses:
- 10.2.0.92/**24**
gateway4: 10.2.1.252
nameservers:
addresses:
- 8.8.8.8
Вам просто нужно изменить / 24 в / 23
10.2.0.92/23 будет охватывать 10.2.0.0–10.2.1.255, как и хосты в вашей виртуальной машине. Проблема не в перекрытии пробелов, а в том, что с / 24 шлюз хостов не доступен хосту.
Если бы вы отправили эхо-запрос от гостя -> хост ... Пакет покинул бы гостя и получил широковещательную передачу, потому что хост находится в пределах СЕТЕВАЯ МАСКА для текущей сети гостя. Хост получит пакет. Хост отправит ответ. Поскольку пункт назначения x.x.1.x не находится в текущей сети x.x.0.x, пакет обычно направляется на шлюз. Ой, подождите, шлюза тоже нет на x.x.0.x. Пакет никуда не денется.
Помните, пакеты не умны. Они идут только туда, куда вы им говорите.
Часть этого, о которой я не говорил выше, - это ARP. Приведенный выше комментарий @ Gerrit также касается этого. Когда пакеты отправляются в домене конфликтов, они перемещаются по MAC-адресу, а не по IP. Когда 10.2.0.210/23 отправляет пакет на 10.2.0.92, исходящие пакеты отправляются непосредственно на 10.2.0.92 после того, как 10.2.0.210/23 отправляет широковещательный пакет с вопросом, кто такой 10.2.0.92. Я не уверен, получит ли гость ответ или нет. Это может быть, поскольку ARP отвечает на MAC-адрес запрашивающей стороны. Гость добавит эту информацию в свою собственную таблицу ARP.
Хост, хотя в ответе не будет иметь MAC-адрес гостя, потому что для хоста гость находится за пределами своего домена коллизии / 24. Обычно он направляется к шлюзу для маршрутизации, но не может этого сделать, потому что шлюз HOST также не находится в локальной сети. Шлюзы, которые являются маршрутизаторами, не могут направлять пакеты обратно по проводу, по которому они поступают. Пакет должен пройти через устройство. Его, вероятно, уронили бы, если бы он добрался до ворот.
Что мне более интересно, так это то, что иногда это срабатывает. Сетевая маска, широковещательная рассылка и коллизионные домены влияют только на отправителя пакетов, а не на их получателей. Возможно, потому что Гость - это виртуальная вещь на хосте, некоторые пакеты проходят через виртуальный коммутатор и видны.