Как устранить сетевые проблемы для виртуальных машин, подключенных через мост (Ubuntu 18.04)
На моем сервере (Ubuntu 18.04 LTS) Я использую виртуальную машину KVM, которая работает нормально более года или около того, но недавно - вероятно, из-за некоторого обновления - виртуальная машина теряла подключение к сети при каждой перезагрузке хоста. Мне каким-то образом удалось восстановить соединение в последние два раза, но на этот раз я просто не могу заставить его работать.
Я прочитал много руководств и других веб-страниц, и мне кажется, что перепробовал все более одного раза, но - очевидно - мне что-то не хватает. Одновременно задействовано слишком много переменных, и многие из них, вероятно, влияют друг на друга. Итак, с этим вопросом, я хотел бы найти лучшую стратегию устранения неполадок, которая позволит мне (и другим) эффективно сузить источник проблем с подключением, насколько это возможно. Более конкретно, я говорю о проблемах подключения на виртуальных машинах KVM, которые подключены через мост в Ubuntu 18.04.
Я понимаю, что этот вопрос стал очень длинным, поэтому позвольте мне пояснить, что вы можете ответить на вопрос, не читая дальше, чем здесь .
Под заголовками ниже я упоминаю наиболее важные области неопределенности, которые необходимо учитывать при устранении проблем с сетью, но нет необходимости подробно обсуждать их в ответах. Примите их как возможные отправные точки.
Если вы предпочитаете использовать конфигурацию конкретной машины в качестве отправной точки, прокрутите вниз до конца, где я предоставлю такие подробности (под заголовком «Мой пример»).
netplan
Одна проблема с устранением неполадок на 18.04 заключается в том, что в Ubuntu используется netplan , что делает многие доступные в настоящее время советы устаревшими.
Переход на netplan сам по себе также является источником путаницы, потому что, насколько я понимаю , использование netplan влечет за собой то, что вся конфигурация сети выполняется в / etc / netplan / *. Yaml и больше не в / etc / network / interfaces , но когда я комментирую весь контент в / etc / network / interfaces ], кажется, что он каким-то образом записан обратно (возможно, сам через Диспетчер виртуальных машин на рабочем столе Gnome).
Похоже, что я не единственный, кто разочарован netplan и , некоторые рекомендуют вернуться к ifupdown , но чтобы ограничить объем этого вопроса, давайте останемся в рамках netplan и попробуем исправить ситуацию, не возвращаясь назад.
NetworkManager vs systemd-networkd
Другая трудность заключается в том, что существует по крайней мере одно существенное различие между Ubuntu 18.04 Server и Ubuntu 18.04 Desktop: сервер использует systemd-networkd , а рабочий стол использует NetworkManager , что влечет за собой разные способы устранения неполадок. Что еще хуже: что, если вы изначально установили серверную версию, но позже добавили рабочий стол gnome? (Я не помню, что я сделал, но есть вероятность, что я сделал именно это, потому что мой /etc/netplan/01-netcfg.yaml говорит renderer: networkd , а я NetworkManager тоже вроде работает по умолчанию.)
Исправить хост или виртуальную машину?
Моя третья область неуверенности заключается в том, следует ли мне исправлять что-то на хосте или виртуальной машине (или когда изменение на хосте также требует изменения на клиенте). Я до сих пор не обращал особого внимания на виртуальную машину, учитывая, что она работала нормально, и я никогда ее не обновлял (за исключением автоматических обновлений безопасности Ubuntu).Но в последний раз, когда мне удалось решить проблему с подключением, я сделал это, продублировав его жесткий диск и создав с ним новую виртуальную машину (на мой взгляд, идентичную). Я предполагаю, что это подтверждает, что конфигурация на vm была в порядке (поскольку оборудование vms настроено на хосте), но, тем не менее, он сказал мне, что мне, вероятно, нужно уделять больше внимания конфигурации оборудования vm.
Требуется перезагрузка для применения изменений?
Пробуя различные исправления, я также часто не уверен, есть ли
Конфликт пользовательских интерфейсов?
Наконец, я понял, что может иметь значение, через какой пользовательский интерфейс я делаю определенные изменения, потому что они могут писать эти изменения в разных местах. В настоящее время у меня есть следующие интерфейсы для настройки моей виртуальной машины:
- командная строка (в основном используется)
- Диспетчер виртуальных машин (GUI)
- Wok / Kimchi (веб-интерфейс)
- У меня также есть Webmin с запущенным Cloudmin , но мой виртуальный компьютер там не отображается, поэтому в настоящее время я его не использую.
Мой пример
Итак, хотя моя идея здесь состоит в том, чтобы найти несколько общую стратегию устранения неполадок, я полагаю, что всегда полезно начинать с конкретного примера. Итак, вот некоторые подробности о моей текущей настройке (добавлю больше, если запрошено в комментариях):
Это мой текущий /etc/netplan/01-netcfg.yaml (и у меня нет других файлов yaml в этом каталоге):
network:
version: 2
renderer: NetworkManager
ethernets:
enp0s31f6:
dhcp4: no
bridges:
br0:
interfaces: [ enp0s31f6]
dhcp4: yes
dhcp6: yes
Единственная причина, по которой я использую NetworkManager, заключается в том, что я так старался с systemd-networkd безуспешно, что подумал, что дам NetworkManager шанс (но я догадываюсь, что мне следует придерживаться systemd-networkd ).Соответственно, я установил managed = true в моем /etc/NetworkManager/NetworkManager.conf , который теперь выглядит так:
[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=true
[device]
wifi.scan-rand-mac-address=no
virsh net-list --all дает мне следующее:
Name State Autostart Persistent
----------------------------------------------------------
br0 active yes yes
bridged inactive yes yes
default active yes yes
Мост, который я пытаюсь использовать с моей виртуальной машиной, - это br0.
Вот конфигурация br0:
Второй мост был попыткой начать заново и просто создать новый мост и подключить к нему виртуальную машину, но добавление моста не имело никакого эффекта, вероятно, потому что диспетчер виртуальных машин, похоже, напишите это в / etc / network / interfaces , а не в файл yaml в / etc / netplan /
Вот мой / etc / network / interfaces :
##auto lo br0
##iface lo inet loopback
##auto br1
##iface br1 inet dhcp
## bridge_ports enp0s31f6
## bridge_stp on
## bridge_fd 0.0
##iface br0 inet dhcp
## bridge_ports enp0s31f6
auto br0
iface br0 inet dhcp
bridge_ports enp0s31f6
bridge_stp on
bridge_fd 0.0
auto br-kvm
iface br-kvm inet dhcp
bridge_ports enp0s31f6
bridge_stp on
bridge_fd 0.0
Обратите внимание, как я все закомментировал (чтобы убедиться, что этот файл не повлиял на мою конфигурацию) только для того, чтобы добавить его обратно внизу, как упоминалось выше.
ifconfig дает мне длинный список мостов (большинство из них называется как-то вроде br-a5ffb2301edc ), из которых я понятия не имею, откуда они берутся (полагаю, я неосознанно создал их за бесчисленные часы тестирования). Я не буду вставлять их все сюда, только br0 и фактический интерфейс Ethernet:
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.4 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::4e52:62ff:fe09:7e59 prefixlen 64 scopeid 0x20<link>
ether 4c:52:62:09:7e:59 txqueuelen 1000 (Ethernet)
RX packets 806319 bytes 84505505 (84.5 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 307846 bytes 845321927 (845.3 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp0s31f6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether 4c:52:62:09:7e:59 txqueuelen 1000 (Ethernet)
RX packets 817196 bytes 101316866 (101.3 MB)
RX errors 0 dropped 13 overruns 0 frame 0
TX packets 821152 bytes 876709681 (876.7 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xef000000-ef020000
Вот как я тестировал сетевое подключение на своей виртуальной машине:
$ping 8.8.8.8
connect: Network is unreachable
Редактировать: Вот содержимое виртуальной машины /etc/netplan/50-cloud-init.yaml :
network:
version: 2
# renderer: networkd
ethernets:
ens3:
addresses: []
dhcp4: true
dhcp6: false
optional: true
Я не могу вспомнить, почему я - несколько месяцев назад - закомментировал строку редерера (и я не знаю, какой рендерер по умолчанию используется сейчас), но это точный конфиг сработал.
Я также могу упомянуть, что мне пришло в голову, что cloud-init может что-то испортить для меня (на хосте), поэтому я проверил / var / log / cloud-init- output.log , чтобы узнать, делает ли он что-нибудь:
Cloud-init v. 19.4-33-gbb4131a2-0ubuntu1~18.04.1 running 'modules:config' at Fri, 21 Feb 2020 02:24:08 +0000. Up 50.91 seconds.
Cloud-init v. 19.4-33-gbb4131a2-0ubuntu1~18.04.1 running 'modules:final' at Fri, 21 Feb 2020 02:24:15 +0000. Up 56.59 seconds.
Cloud-init v. 19.4-33-gbb4131a2-0ubuntu1~18.04.1 finished at Fri, 21 Feb 2020 02:24:15 +0000. Datasource DataSourceNoCloud [seed=/var/lib/cloud/seed/nocloud-net][dsmode=net]. Up 56.76 seconds
Cloud-init v. 19.4-33-gbb4131a2-0ubuntu1~18.04.1 running 'init-local' at Fri, 21 Feb 2020 02:59:28 +0000. Up 10.48 seconds.
Cloud-init v. 19.4-33-gbb4131a2-0ubuntu1~18.04.1 running 'init' at Fri, 21 Feb 2020 03:04:29 +0000. Up 311.21 seconds.
ci-info: +++++++++++++++++++++++++++++++++++++++++Net device info+++++++++++++++++++++++++++++++++++++++++
ci-info: +-----------+-------+------------------------------+---------------+--------+-------------------+
ci-info: | Device | Up | Address | Mask | Scope | Hw-Address |
ci-info: +-----------+-------+------------------------------+---------------+--------+-------------------+
ci-info: | br-kvm | False | . | . | . | f2:7a:46:82:f9:e0 |
ci-info: | br0 | True | 192.168.1.4 | 255.255.255.0 | global | 4c:52:62:09:7e:59 |
ci-info: | br0 | True | fe80::4e52:62ff:fe09:7e59/64 | . | link | 4c:52:62:09:7e:59 |
ci-info: | enp0s31f6 | True | . | . | . | 4c:52:62:09:7e:59 |
ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | host | . |
ci-info: | lo | True | ::1/128 | . | host | . |
ci-info: +-----------+-------+------------------------------+---------------+--------+-------------------+
ci-info: +++++++++++++++++++++++++++++Route IPv4 info+++++++++++++++++++++++++++++
ci-info: +-------+-------------+-------------+---------------+-----------+-------+
ci-info: | Route | Destination | Gateway | Genmask | Interface | Flags |
ci-info: +-------+-------------+-------------+---------------+-----------+-------+
ci-info: | 0 | 0.0.0.0 | 192.168.1.1 | 0.0.0.0 | br0 | UG |
ci-info: | 1 | 169.254.0.0 | 0.0.0.0 | 255.255.0.0 | br0 | U |
ci-info: | 2 | 192.168.1.0 | 0.0.0.0 | 255.255.255.0 | br0 | U |
ci-info: +-------+-------------+-------------+---------------+-----------+-------+
ci-info: +++++++++++++++++++Route IPv6 info+++++++++++++++++++
ci-info: +-------+-------------+---------+-----------+-------+
ci-info: | Route | Destination | Gateway | Interface | Flags |
ci-info: +-------+-------------+---------+-----------+-------+
ci-info: | 1 | fe80::/64 | :: | br0 | U |
ci-info: | 3 | local | :: | br0 | U |
ci-info: | 4 | ff00::/8 | :: | br0 | U |
ci-info: +-------+-------------+---------+-----------+-------+
Cloud-init v. 19.4-33-gbb4131a2-0ubuntu1~18.04.1 running 'modules:config' at Fri, 21 Feb 2020 03:04:33 +0000. Up 315.26 seconds.
Cloud-init v. 19.4-33-gbb4131a2-0ubuntu1~18.04.1 running 'modules:final' at Fri, 21 Feb 2020 03:04:39 +0000. Up 321.85 seconds.
Cloud-init v. 19.4-33-gbb4131a2-0ubuntu1~18.04.1 finished at Fri, 21 Feb 2020 03:04:40 +0000. Datasource DataSourceNoCloud [seed=/var/lib/cloud/seed/nocloud-net][dsmode=net]. Up 322.15 seconds
Увидев, что он активен, я отключил его с помощью sudo touch /etc/cloud/cloud-init.disabled. Но моя проблема с подключением все еще не решена.
Edit2: Я проверил еще кое-что (на основе этого сообщения ), связан ли сетевой интерфейс моей виртуальной машины с моим мостом. Чтобы получить имя интерфейса, я сделал virsh domiflist LMS (LMS - это имя хоста моей виртуальной машины) и получил следующее:
Interface Type Source Model MAC
-------------------------------------------------------
vnet0 bridge br0 virtio 52:54:00:f0:0e:f8
Там уже написано br0 под исходным кодом , но я не уверен, что именно это означает, поэтому я дважды проверил, используя brctl show br0 , который подтвердил, что vnet0 связан с br0 :
bridge name bridge id STP enabled interfaces
br0 8000.4c5262097e59 yes enp0s31f6
vnet0
Я так надеялся обнаружить отсутствие vnet0, чтобы исправить это, но, к сожалению, это не было проблемой.
1 ответ
Как вы упомянули, это длинный и сложный вопрос, поэтому первое, что я хотел бы сделать, - это попытаться упростить вашу конфигурацию.
В вашем сообщении нет упоминаний об iptables, которые могут быть причиной ваших проблем. Вы можете просмотреть свои текущие правила с помощью iptables -vnL; iptables -t нат -vnL . В качестве альтернативы вы можете настроить ядро на обход iptables для мостов с помощью: sysctl net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge- nf-call-arptables = 0
Лично я ненавижу дополнительный уровень абстракции, которым является netplan, и, поскольку мост можно выполнить напрямую с помощью networkd, я бы избавился от netplan.io и NetworkManager и сделал бы все это с помощью networkd . В вашей сети, очевидно, есть DHCP-сервер, поэтому вам не нужно использовать конфигурацию DNSServer в networkd или dnsmasq. Лучшая вики для networkd - это https://wiki.archlinux.org/index.php/Systemd-networkd - прочтите ее полностью, потому что в ней есть несколько уловок, но как только вы поймете, их, вы можете передать эти знания в любой другой крупный дистрибутив.
Устранение неполадок networkd не так уж и плохо, как только вы его освоите:
journalctl -xe | grep networkd
или для полной отладки:
mkdir /etc/systemd/system/systemd-networkd.service.d
echo -e "[Service]\nEnvironment=SYSTEMD_LOG_LEVEL=debug" >> /etc/systemd/system/systemd-networkd.service.d/override.conf
Оттуда вы можете устранить неполадки с помощью tcpdump -nni br0 , чтобы убедиться, что ваши виртуальные машины фактически отправляют и получают трафик, что может быть неправдой, если у них не работает драйвер virtio. Драйвер e1000 вроде везде хорошо работает.