DEBIAN 12 - QEMU-KVM - BRIDGE - Perte connexion après 30 min

Voici un petit guide pour configurer le bridge d'un serveur de machines virtuelles sous DEBIAN 12 qui fonctionne pour OVH, et sûrement d'autres datacenters.

Je le mets ici pour que tout le monde puisse gagner du temps. Rien n'est indiqué dans la procédure officiel d'OVH.
https://help.ovhcloud.com/csm/fr-dedicated-servers-network-bridging?id=kb_article_view&sysparm_article=KB0043733

Pourtant on peut s'arracher les cheveux, vu que le problème n'apparaît qu'après 30 min, sans aucune information.

Contexte:
Après configuration du bridge, cela fonctionne parfaitement pendant +- 30 min. Après le serveur devient inaccessible.  Seul le reboot hardware fonctionne.
Ce qu'il faut savoir c'est que depuis DEBIAN 11, le BRIDGE ne clone plus automatiquement l'adresse MAC de la carte réseau.
Or visiblement l'infrastructure d'OVH déconnecte le serveur du réseau après +-30min si les adresses IP et MAC ne correspondent pas à celles du serveur.
Rien n'est visible dans le log du serveur, à part qu'il continue de fonctionner, mais sans réseau.

Chez OVH, DEBIAN12 utilise netplan par défaut.

1. Il faut récupérer l'adresse MAC de la carte réseau. (car netplan ne peut pas cloner l'adresse d'une autre interface automatiquement.)
   

   ip a

   Prendre le code MAC correspondant à l'adresse de l'interface réseau servant au BRIDGE. (par exemple enp3s0f0)

   2: enp3s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
      link/ether xx:xx:xx:xx:xx:xx

   xx:xx:xx:xx:xx:xx est l'adresse MAC.

2. Le fichier /etc/netplan/xxx.yaml
   

   network:
       version: 2
       ethernets:
           enp3s0f0:
               accept-ra: false
               addresses:
               - xxxx:xxxx:xxxx:xxxx::/64
               dhcp4: false
               gateway6: xxxx:xxxx:xxxx:xxxx:ff:ff:ff:ff
               match:
                   macaddress: xx:xx:xx:xx:xx:xx
               routes:
               -   to: xxxx:xxxx:xxxx:xxxx:ff:ff:ff:ff/128
                   via: '::'
               set-name: enp3s0f0
       bridges:
           br0:
               interfaces: [enp3s0f0]
               dhcp4: true
               #bridge_hw: enp3s0f0 # ne fonctionne pas dans netplan, uniquement dans /etc/network/interfaces
               macaddress: xx:xx:xx:xx:xx:xx

   Remarques:
   - ici, l'IPv6 n'est pas derrière le BRIDGE, donc pas d'IPv6 pour les serveurs virtuels. (libre à vous de le faire)
   - gateway6: est un paramètre déprécié, il faut la modifier dans l'option "routes:" mais c'est la configuration par défaut pour DEBIAN chez OVH est comme ça.
   - le paramètre "bridge_hw" permet définir ou de cloner l'adresse MAC d'un autre interface réseau n'existe pas dans netplan.

3. netplan apply

   Remarque:
   !!! risque de perte de connexion !!! lire ci-dessous pour éviter tout problème.

Il peut être très intéressant, pour gagner du temps (ne pas devoir rebooter le serveur en rescue), d'utiliser un script pour tester la configuration netplan et avoir un retour en arrière si cela ne fonctionne pas.

Pour ce faire on crée 2 fichiers de configurations, 1. une copie de l'original  (on est sûr qu'il fonctionne) et 2. le fichier de test.
Puis utiliser screen ou tmux pour garder le script actif après éventuel déconnexion.

Voici le script (à modifier)

#! /bin/bash

TESTCONFIG=/etc/netplan/10-test_config.yaml.test
WORKINGCONFIG=/etc/netplan/50-cloud-init.yaml.old
CONFIGPATH=/etc/netplan/50-cloud-init.yaml

cp $TESTCONFIG $CONFIGPATH
echo "Applying test config"
netplan apply
echo "Wait 3 sec"
sleep 3
ip a
echo "Do ping check for 5 sec"
ping -q -c5 xxx.xxx.xxx.xxx > /dev/null
if [ $? -eq 0 ]; then
  echo "Config applied and working"
else
  echo "Config not working reverting to working config"
  cp $WORKINGCONFIG $CONFIGPATH
  netplan apply
fi

Remplacer xxx.xxx.xxx.xxx par l'adresse d'un serveur pour tester le ping. (la connexion à internet)
Remplacer les noms de fichiers TESTCONFIG, WORKINGCONFIG et CONFIGPATH par les vôtres.

Puis lancer le script. Tout se fait en utilisateur root ou sudo évidement.