※ Esto es solo una posibilidad, pero no es su propósito original.
Disfrútalo como una curiosidad.

En Sakura Cloud no se puede conectar a través de un puente.

¿Se puede asignar una dirección MAC fija al NIC o cambiarla a una arbitraria?

Se supone que los paquetes cuya dirección MAC no corresponde a la de la VM creada no pueden salir de la VM a través del switch de Sakura Cloud.

No es posible crear un puente dentro de la VM e informar la dirección IP del router + switch o la dirección IP local del switch directamente a contenedores LXD para comunicarse.

Normalmente, esta sería la configuración.

Sin embargo, como solo la dirección MAC del dispositivo eth0 puede comunicarse fuera de la VM,
en esta situación no se puede conectar a Internet.

El contenedor 1 no puede comunicarse porque su dirección MAC veth0 no puede salir de la VM.

Entonces, me llamó la atención el manejo de la dirección MAC virtual de VRRP.
¿Existen restricciones sobre el uso de la dirección IP virtual (VIP) cuando se utiliza VRRP?

Se puede utilizar VRID de 1 a 4.

Si se utiliza una dirección MAC virtual, solo se pueden utilizar los siguientes 4 tipos.
00:00:5e:00:01:01
00:00:5e:00:01:02
00:00:5e:00:01:03
00:00:5e:00:01:04

¿Podría ser que con esta dirección MAC se pueda comunicar y salir de la VM?
¡Así que decidí probarlo!

network:
  ethernets:
    eth0:
      dhcp4: 'no'
      dhcp6: 'no'
  bridges:
    br0:
      interfaces: [ eth0 ]
      macaddress: <dirección MAC de eth0>
      addresses:
        - XXX.XXX.XXX.5/29
      dhcp4: 'no'
      dhcp6: 'no'
      gateway4: XXX.XXX.XXX.1

Primero, crearé br0.

Crearé un contenedor conectado a br0.

Estoy configurando el perfil predeterminado de lxd para que se conecte a br0.

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

Configuraré la red para el contenedor como de costumbre.

# 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

Sin embargo, no se conecta…

root@c1:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes de datos.
Desde 133.242.60.197 icmp_seq=1 Host de destino inalcanzable
Desde 133.242.60.197 icmp_seq=2 Host de destino inalcanzable
Desde 133.242.60.197 icmp_seq=3 Host de destino inalcanzable
^C
--- estadísticas de ping a 8.8.8.8 ---
5 paquetes transmitidos, 0 recibidos, +3 errores, 100% de pérdida de paquetes, tiempo 4088ms pipe 4

Voy a intentar configurar una dirección MAC virtual para 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

¡Finalmente pude comunicarme con el exterior!

root@c1:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes de datos.
64 bytes desde 8.8.8.8: icmp_seq=1 ttl=118 tiempo=18.1 ms
64 bytes desde 8.8.8.8: icmp_seq=2 ttl=118 tiempo=18.2 ms
64 bytes desde 8.8.8.8: icmp_seq=3 ttl=118 tiempo=18.3 ms
^C
--- estadísticas de ping a 8.8.8.8 ---
3 paquetes transmitidos, 3 recibidos, 0% de pérdida de paquetes, tiempo 2002ms
rtt min/avg/max/mdev = 18.120/18.195/18.267/0.060 ms

Puedo usar cuatro direcciones, por lo que si se trata de hasta cuatro contenedores en una misma red L2,
parece que se puede comunicar asignando direcciones IP directamente utilizando un puente.

Sin embargo, dado que esto se aleja completamente del propósito original,
parece mejor dejarlo en “¡Funciona, interesante!”