Вопрос или проблема
Установка MicroCloud прошла успешно, и между инстансами возможен пинг, но нет доступа к выходящим и входящим подключениям. Прошу помощи с дальнейшими шагами по диагностике, подтверждению корневой причины, исправлению и т.д… любая помощь будет весьма кстати.
Следовал этому руководству, и все шаги были успешными до 7.4, «Убедитесь, что вы можете пинговать виртуальный маршрутизатор в OVN».
https://canonical-microcloud.readthedocs-hosted.com/en/latest/microcloud/tutorial/get_started/
Вывод различных команд ниже…
microcloud-01:~$ ping -c 5 172.16.2.100
PING 172.16.2.100 (172.16.2.100) 56(84) байт данных.
— 172.16.2.100 статистика пинга —
5 пакетов передано, 0 получено, 100% потеря пакетов, время 4103мс
$ lxc network show default
name: default
description: “”
type: ovn
managed: true
status: Created
config:
bridge.mtu: “1442”
ipv4.address: 10.217.129.1/24
ipv4.nat: “true”
ipv6.address: fd42:26b3:d263:222a::1/64
ipv6.nat: “true”
network: UPLINK
volatile.network.ipv4.address: 172.16.2.100
used_by:
/1.0/instances/u1
/1.0/instances/u2
/1.0/profiles/default
locations:
microcloud-01
microcloud-03
microcloud-02
$ lxc network show UPLINK
name: UPLINK
description: “”
type: physical
managed: true
status: Created
config:
ipv4.gateway: 172.16.2.1/24
ipv4.ovn.ranges: 172.16.2.100-172.16.2.254
volatile.last_state.created: “false”
used_by:
/1.0/networks/default
locations:
microcloud-01
microcloud-03
microcloud-02
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:4d:f5:85 brd ff:ff:ff:ff:ff:ff
inet 172.16.1.11/24 brd 172.16.1.255 scope global enp1s0
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe4d:f585/64 scope link
valid_lft forever preferred_lft forever
3: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master ovs-system state UP group default qlen 1000
link/ether 52:54:00:47:7d:bd brd ff:ff:ff:ff:ff:ff
4: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether a6:90:ec:49:ee:05 brd ff:ff:ff:ff:ff:ff
5: br-int: <BROADCAST,MULTICAST> mtu 1442 qdisc noop state DOWN group default qlen 1000
link/ether 62:75:01:ce:f6:a3 brd ff:ff:ff:ff:ff:ff
6: genev_sys_6081: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65000 qdisc noqueue master ovs-system state UNKNOWN group default qlen 1000
link/ether ea:29:6a:c6:d3:76 brd ff:ff:ff:ff:ff:ff
inet6 fe80::20d0:16ff:fee6:187/64 scope link
valid_lft forever preferred_lft forever
7: lxdovn1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 32:65:88:ec:04:48 brd ff:ff:ff:ff:ff:ff
9: vethf5c8a706@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1442 qdisc noqueue master ovs-system state UP group default qlen 1000
link/ether d2:ad:26:c3:f3:b5 brd ff:ff:ff:ff:ff:ff link-netnsid 0
$ ip r
default via 172.16.1.1 dev enp1s0 proto static
172.16.1.0/24 dev enp1s0 proto kernel scope link src 172.16.1.11
$ cat /etc/netplan/00-installer-config.yaml
Это конфигурация сети, написанная «subiquity»
network:
ethernets:
enp1s0:
addresses:
- 172.16.1.11/24
nameservers:
addresses: - 4.2.2.2
- 8.8.8.8
search:
routes: - to: default
via: 172.16.1.1
enp2s0:
accept-ra: false
dhcp4: false
link-local:
version: 2
Ответ или решение
Ваша проблема с MicroCloud, где виртуальный маршрутизатор OVN не отвечает на ICMP-запросы (ping), может иметь несколько причин. Давайте пройдемся по шагам для устранения неполадок и потенциальным решениям.
1. Проверка конфигурации сетей
Сначала убедитесь, что конфигурации сетей и маршрутизации выполнены правильно. На основе выводов ваших команд можно сделать следующие наблюдения:
- Сеть ‘default’ использует IPv4-адрес 10.217.129.1 с диапазоном NAT, но виртуальный маршрутизатор имеет IP 172.16.2.100. Убедитесь, что экземпляры (u1 и u2) действительно находятся в этой сети и могут обращаться к виртуальному маршрутизатору.
- Проверьте, правильно ли настроен NAT, особенно если вы ожидаете доступ в интернет. Вы можете попробовать выполнить
lxc listдля проверки IP-адресов всех экземпляров и их статуса.
2. Проверка состояния сети
Вывод ip a показывает, что br-int находится в состоянии DOWN. Это может быть критическим моментом. Убедитесь, что Open vSwitch (OVS) правильно настроен и запущен. Выполните следующие команды:
sudo systemctl status openvswitch-switch
sudo systemctl restart openvswitch-switchЭто перезапустит Open vSwitch и может восстановить связь.
3. Виртуальный маршрутизатор OVN
Убедитесь, что виртуальный маршрутизатор настроен правильно. Проверьте его состояние в OVN, выполнив:
ovn-nbctl showЭто должно отобразить информацию о виртуальном маршрутизаторе и связях с экземплярами. Убедитесь, что экземпляры правильно подключены к маршрутизатору.
4. Проверка правил брандмауэра
Проверьте, действуют ли какие-либо правила брандмауэра (например, iptables), которые могут блокировать ICMP-трафик:
sudo iptables -L -v -nЕсли есть правила, блокирующие ICMP, вам нужно будет их изменить. Чтобы разрешить ICMP, выполните:
sudo iptables -A INPUT -p icmp --dport echo-request -j ACCEPT
sudo iptables -A OUTPUT -p icmp --sport echo-reply -j ACCEPT5. Проверка конфигурации сетевого интерфейса
Ваша статическая конфигурация на enp1s0 с адресом 172.16.1.11 может не совпадать с ожидаемыми маршрутами. Проверьте, упоминается ли 172.16.2.0/24 в маршрутах. Возможно, надо будет добавить явный маршрут:
sudo ip route add 172.16.2.0/24 via 172.16.1.16. Тестирование
После того как все вышеперечисленные шаги выполнены, попробуйте снова выполнить ping до виртуального маршрутизатора:
ping -c 5 172.16.2.100Если всё равно не работает, проверьте журналы системных сообщений и ошибок Open vSwitch и OVN для получения дополнительной информации:
journalctl -u openvswitch-switchЗаключение
Следуя этим шагам, вы должны обнаружить и устранить проблему с доступом к вашему виртуальному маршрутизатору. Обратите внимание на консистентность между сетью, маршрутами и конфигурациями NAT. Если проблема все еще не решается, уточните дополнительные детали, чтобы можно было помочь более целенаправленно.