Посещая наш сайт, вы соглашаетесь с нашей политикой конфиденциальности в отношении файлов cookie, статистики отслеживания и т. д.

Главная » Вопросы и ответы » Убунту

Почему хост и мост получают IP, а виртуальная машина нет?

На чтение 9 мин Опубликовано
Содержание
  1. Вопрос или проблема
  2. Ответ или решение
  3. Почему хост и мост получают IP-адрес, а виртуальная машина — нет?
  4. 1. Понимание мостовых интерфейсов
  5. 2. Конфигурация виртуальной машины
  6. 3. Мониторинг и диагностика
  7. 4. Проблемы с ARP
  8. Заключение

Вопрос или проблема

Мне трудно подключить мою KVM виртуальную машину к локальной сети.

$ brctl show br0
имя моста    id моста            STP включен    интерфейсы
br0            8000.4c5262097e59    да            enp0s31f6
                                                   vnet0

enp0s31f6 – это Ethernet карта хоста, а vnet0 – это карта KVM гостя.

На хосте у меня полная сетевое подключение. Никаких проблем.

На виртуальной машине у меня нет подключения к сети вообще:

$ ping 8.8.8.8
connect: Сеть недоступна

Так что я пытаюсь выяснить, что не так. Уже здесь я озадачен, потому что думал, что мост – это эквивалент аппаратного свича, и если это так, как одно устройство, подключенное к свичу, может достичь сети, а другое – нет?

Давайте посмотрим на их IP-адреса:

$ ip a show enp0s31f6
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether 4c:52:62:09:7e:59 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.4/24 brd 192.168.1.255 scope global enp0s31f6
       valid_lft forever preferred_lft forever
$ ip a show vnet0
26: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:f0:0e:f8 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fef0:ef8/64 scope link 
       valid_lft forever preferred_lft forever

Итак, у хоста есть IP 192.168.1.4, но у виртуальной машины его нет (кроме IPv6, не знаю почему).

Хост получил свой IP от DHCP сервера в локальной сети:

sudo dhclient -v enp0s31f6
Клиент DHCP Internet Systems Consortium 4.3.5
Авторское право 2004-2016 Internet Systems Consortium.
Все права защищены.
Для получения информации, пожалуйста, посетите https://www.isc.org/software/dhcp/

Прослушивание на LPF/enp0s31f6/4c:52:62:09:7e:59
Отправка на   LPF/enp0s31f6/4c:52:62:09:7e:59
Отправка на   Socket/fallback
DHCPREQUEST адреса 192.168.1.4 на enp0s31f6 на 255.255.255.255 порт 67 (xid=0x64e68ab1)
DHCPACK адреса 192.168.1.4 от 192.168.1.1
RTNETLINK отвечает: Файл существует
привязан к 192.168.1.4 -- обновление через 40526 секунд.

Теперь давайте попробуем получить один для виртуальной машины тоже:

$ sudo dhclient -v vnet0
Клиент DHCP Internet Systems Consortium 4.3.5
Авторское право 2004-2016 Internet Systems Consortium.
Все права защищены.
Для получения информации, пожалуйста, посетите https://www.isc.org/software/dhcp/

Прослушивание на LPF/vnet0/fe:54:00:f0:0e:f8
Отправка на   LPF/vnet0/fe:54:00:f0:0e:f8
Отправка на   Socket/fallback
DHCPDISCOVER на vnet0 на 255.255.255.255 порт 67 интервал 3 (xid=0xf64429)
DHCPDISCOVER на vnet0 на 255.255.255.255 порт 67 интервал 3 (xid=0xf64429)
DHCPDISCOVER на vnet0 на 255.255.255.255 порт 67 интервал 7 (xid=0xf64429)
DHCPDISCOVER на vnet0 на 255.255.255.255 порт 67 интервал 13 (xid=0xf64429)
DHCPDISCOVER на vnet0 на 255.255.255.255 порт 67 интервал 14 (xid=0xf64429)
DHCPDISCOVER на vnet0 на 255.255.255.255 порт 67 интервал 18 (xid=0xf64429)
DHCPDISCOVER на vnet0 на 255.255.255.255 порт 67 интервал 10 (xid=0xf64429)
DHCPDISCOVER на vnet0 на 255.255.255.255 порт 67 интервал 15 (xid=0xf64429)
DHCPDISCOVER на vnet0 на 255.255.255.255 порт 67 интервал 18 (xid=0xf64429)
^C

Он не получает адрес. 🙁

Так что, может быть, мост сломан, и хост все еще получает IP, потому что он физически подключен к локальной сети? Нет, потому что сам мост, похоже, тоже общается с DHCP сервером:

$ sudo dhclient -v br0
Клиент DHCP Internet Systems Consortium 4.3.5
Авторское право 2004-2016 Internet Systems Consortium.
Все права защищены.
Для получения информации, пожалуйста, посетите https://www.isc.org/software/dhcp/

Прослушивание на LPF/br0/4c:52:62:09:7e:59
Отправка на   LPF/br0/4c:52:62:09:7e:59
Отправка на   Socket/fallback
DHCPREQUEST адреса 192.168.1.4 на br0 на 255.255.255.255 порт 67 (xid=0x58c2333c)
DHCPACK адреса 192.168.1.4 от 192.168.1.1
RTNETLINK отвечает: Файл существует
привязан к 192.168.1.4 -- обновление через 42819 секунд.

Как мне продолжить отсюда?

(Кажется, я попробовал и проверил почти все, но я избавляю вас от информации об этом здесь, так как я сейчас пытаюсь систематически выяснить, где я ошибаюсь в приведенных выше шагах.)

Я не эксперт, но я думаю, что STP должно быть отключено в вашем мосту. У меня оно отключено. У меня нет никаких IP адресов в списке сетевых интерфейсов, IP адрес хоста отображается на интерфейсе br0:

doug@s15:~/idle/k56wtteo/idle$ ip a show enp3s0
3: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether f4:6d:04:65:2d:8e brd ff:ff:ff:ff:ff:ff
doug@s15:~/idle/k56wtteo/idle$ ip a show br0
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether f4:6d:04:65:2d:8e brd ff:ff:ff:ff:ff:ff
    inet 192.168.111.112/24 brd 192.168.111.255 scope global dynamic br0
       valid_lft 84590sec preferred_lft 84590sec

Тем не менее, мостовые данные выглядят как ваши:

doug@s15:~/idle/k56wtteo/idle$ brctl show br0
имя моста     id моста               STP включен     интерфейсы
br0             8000.f46d04652d8e       нет              enp3s0
                                                        vnet0

Уточняет ли ваша конфигурация виртуальной машины использование интерфейса моста? Например (/etc/libvirt/qemu/serv-ff.xml в этом примере (я думаю, я где-то читал, что вы используете kvm)):

<interface type="bridge">
  <mac address="52:54:00:27:1b:4e"/>
  <source bridge="br0"/>
  <model type="virtio"/>
  <address type="pci" domain='0x0000' bus="0x00" slot="0x03" function='0x0'/>
</interface>

Если я посмотрю на таблицу arp в моей локальной сети, я могу увидеть виртуальную машину:

doug@DOUG-64:~$ arp | grep serv-ff
serv-ff.smythies.com     ether   52:54:00:27:1b:4e   C                     enp2s0

И если я установлю tcpdump на хосте для мониторинга интерфейса моста, я могу наблюдать, как гость виртуальной машины запрашивает и получает IP-адрес от моей локальной сети через DHCP при перезагрузке гостя:

doug@s15:~/idle/k56wtteo/idle$ sudo tcpdump -tttt -n -i br0 port 67 and port 68
tcpdump: подробный вывод подавлен, используйте -v или -vv для полного декодирования протокола
прослушивание на br0, тип связи EN10MB (Ethernet), размер захвата 262144 байт
2020-03-05 18:12:35.522302 IP 192.168.111.217.68 > 192.168.111.1.67: BOOTP/DHCP, Запрос от 52:54:00:27:1b:4e, длина 265
2020-03-05 18:12:48.534782 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Запрос от 52:54:00:27:1b:4e, длина 291
2020-03-05 18:12:48.535118 IP 192.168.111.1.67 > 192.168.111.217.68: BOOTP/DHCP, Ответ, длина 300
2020-03-05 18:12:48.535243 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Запрос от 52:54:00:27:1b:4e, длина 303
2020-03-05 18:12:48.535460 IP 192.168.111.1.67 > 192.168.111.217.68: BOOTP/DHCP, Ответ, длина 300

И на самой виртуальной машине:

doug@serv-ff:~$ ip a show ens3
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:27:1b:4e brd ff:ff:ff:ff:ff:ff
    inet 192.168.111.217/24 brd 192.168.111.255 scope global dynamic ens3
       valid_lft 86044sec preferred_lft 86044sec
    inet6 fe80::5054:ff:fe27:1b4e/64 scope link
       valid_lft forever preferred_lft forever

Ответ или решение

Почему хост и мост получают IP-адрес, а виртуальная машина — нет?

Проблема, с которой вы столкнулись, связана с конфигурацией вашей сетевой среды в контексте виртуализации KVM (Kernel-based Virtual Machine). Давайте разберем все шаги и аспекты, которые могли бы привести к подобной ситуации, где хост и мост успешно получают IP-адреса, но виртуальная машина остается без сетевого подключения.

1. Понимание мостовых интерфейсов

Сетевой мост в Linux, например br0, фактически действует как виртуальный коммутатор, позволяя различным интерфейсам соединяться и обмениваться данными. Ваша реальная сетевая карта enp0s31f6 подключена к br0, и, как показано в выводе команды brctl show br0, оба интерфейса (enp0s31f6 и vnet0) правильно добавлены в мост.

Хост фактически получает IP-адрес через мощный механизм DHCP, запросы которого отправляются через интерфейс моста br0, делая его частью локальной сети. Это объясняет, почему ваш хост получает IP-адрес 192.168.1.4.

2. Конфигурация виртуальной машины

Проблема с отсутствием IP-адреса у виртуальной машины (vnet0) может быть вызвана несколькими причинами:

  • Отсутствие DHCP-клиента в машине: Убедитесь, что внутри вашей виртуальной машины установлен и запущен DHCP-клиент. Попробуйте перезапустить его или проверить его статус.

  • Неправильная конфигурация сети: Важно убедиться в том, что конфигурация вашей виртуальной машины действительно включает подключение к мосту br0. Обычно эта настройка указывается в XML-файле виртуальной машины (например, в /etc/libvirt/qemu/*.xml). Пример правильной конфигурации:

    <interface type="bridge">
<mac address="52:54:00:XX:XX:XX"/>
<source bridge="br0"/>
<model type="virtio"/>
</interface>

    Если source bridge не соответствует br0, виртуальная машина не будет подключена к локальной сети.

  • Состояние сети виртуальной машины: Убедитесь, что сетевой интерфейс внутри виртуальной машины активирован. Для этого выполните команду ip a или ifconfig.

3. Мониторинг и диагностика

Для более глубокой диагностики можно использовать такие инструменты, как tcpdump. С помощью tcpdump, вы сможете просмотреть трафик, который передается через мост. Например:

sudo tcpdump -i br0 -n port 67 or port 68

Это позволит вам увидеть, отправляет ли виртуальная машина запросы DHCP и получает ли она ответы. Если вы видите запросы, но нет ответов, вероятно, есть проблема на уровне сети или конфигурации DHCP-сервера.

4. Проблемы с ARP

Еще одним потенциальным источником проблем может быть кеш ARP на DHCP-сервере. Убедитесь, что MAC-адрес vnet0 (виртуальной машины) не конфликтует с другими активными устройствами в сети.

Заключение

Почему ваш хост и мост получают IP-адреса, а виртуальная машина — нет? Ответ кроется в конфигурации сети и возможной неисправности в настройках виртуальной машины или DHCP-клиента. Следуя приведенным рекомендациям и проводя детальную диагностику, вы сможете выявить и устранить корень проблемы. Если все вышеизложенное не сработает, вы можете рассмотреть возможность временного отключения брандмауэра на хосте или используемом DHCP-сервере для исключения блокировки пакетов.

kvm-virtualization network-bridge networking
Оцените материал
Добавить комментарий

Капча загружается...

© 2024 IZ6.RU
*В материалах сайта упоминаются социальные сети Фейсбук / Инстаграм, принадлежащие Meta Platforms Inc., деятельность которой запрещена на территории РФ в части реализации данных социальных сетей на основании осуществления ею экстремистской деятельности