Использование мостовой сети в Sakura Cloud
сервер
Lastmod: 2025-01-21
Published: 2022-07-07

※ Это всего лишь эксперимент, и не является правильным способом использования.
Наслаждайтесь как развлекательным материалом.

В Sakura Cloud нет возможности подключения через мост.

Можно ли назначить фиксированный MAC-адрес для NIC или изменить его на произвольный?

Предположительно, коммутатор Sakura Cloud не позволяет пакетам, не имеющим MAC-адреса созданной виртуальной машины (VM), выходить за пределы VM.

Не удается создать мост внутри VM и напрямую присвоить IP-адреса роутера + коммутатора или локальный IP-адрес коммутатора, чтобы обмениваться данными.

Обычно структура выглядит следующим образом.

Тем не менее, только MAC-адрес устройства eth0 может взаимодействовать с внешней стороной VM, вследствие чего
в таких условиях подключение к интернету невозможно.

Из-за MAC-адреса veth0 контейнера 1 невозможно выйти за пределы VM.

Так что меня заинтересовал вопрос о том, как обрабатываются виртуальные MAC-адреса VRRP.
Существуют ли ограничения на использование виртуального IP-адреса (VIP) при использовании VRRP?

Можно использовать VRID от 1 до 4.

Если вы используете виртуальный MAC-адрес, можно использовать только следующие 4 типа.
00:00:5e:00:01:01
00:00:5e:00:01:02
00:00:5e:00:01:03
00:00:5e:00:01:04

А вдруг, если использовать этот MAC-адрес, станет возможным выйти за пределы VM?
Решил попробовать!

network:
  ethernets:
    eth0:
      dhcp4: 'no'
      dhcp6: 'no'
  bridges:
    br0:
      interfaces: [ eth0 ]
      macaddress: <MAC-адрес eth0>
      addresses:
        - XXX.XXX.XXX.5/29
      dhcp4: 'no'
      dhcp6: 'no'
      gateway4: XXX.XXX.XXX.1

Для начала создадим br0.

Создадим контейнер, подключенный к br0.

Я настроил профиль по умолчанию lxd так, чтобы он подключался к br0.

devices:
  eth0:
    nictype: bridged
    parent: br0
    type: nic

Обычная настройка сети для контейнера.

# lxc launch images:ubuntu/22.04 c1
# lxc exec c1 bash
root@c1:~# cat << _EOF_ > /etc/netplan/10-lxc.yaml
network:
  ethernets:
    eth0:
      dhcp4: 'no'
      dhcp6: 'no'
      addresses:
        - XXX.XXX.XXX.8/29 
      gateway4: XXX.XXX.XXX.1
      nameservers:
        addresses:
          - 133.242.0.3
          - 133.242.0.4
  renderer: networkd
  version: 2
root@c1:~# netplan apply

Но соединение не устанавливается…

root@c1:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 133.242.60.197 icmp_seq=1 Destination Host Unreachable
From 133.242.60.197 icmp_seq=2 Destination Host Unreachable
From 133.242.60.197 icmp_seq=3 Destination Host Unreachable
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4088ms pipe 4

Попробуем назначить виртуальный MAC-адрес VRRP.

network:
  ethernets:
    eth0:
      dhcp4: 'no'
      dhcp6: 'no'
      addresses:
        - XXX.XXX.XXX.8/29 
      macaddress: 
      gateway4: XXX.XXX.XXX.1
      nameservers: 00:00:5e:00:01:01
        addresses:
          - 133.242.0.3
          - 133.242.0.4
  renderer: networkd
  version: 2
root@c1:~# netplan apply

Ура, теперь удалось установить внешнюю связь!

root@c1:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=18.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=18.2 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=18.3 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 18.120/18.195/18.267/0.060 ms

Так как доступно 4 адреса, в одном L2-сетевом сегменте можно создать до 4 контейнеров,
и, возможно, будет возможным присвоить IP-адреса напрямую через мост.

Однако это совсем не его первоначальное назначение, так что лучше оставить это просто как интересный факт.