Rechercher dans la communauté

Bonjour, J'ai constaté un souci assez étrange avec mes 2 VMs, et trop concomitant avec la MAJ de SWAG (mon reverse proxy) pour ne pas être liés. Tout d'abord le contexte. J'ai deux VM depuis peu dans VMM : Home Assistant OS Promox Backup server Les deux sont en temps normal accessible via leur IP, mais aussi via le nom de domaine que j'ai paramétré dans le reverse proxy SWAG (installé en macvlan, avec interface virtuelle en supplément, merci @.Shad. pour le super tuto 👋🏻). Ce matin, watchtower m'a mis à jour SWAG vers 5h. En me levant je constate que Home Assistant n'est plus accessible via son adresse IP, alors qu'à minuit ça l'était. Je vois que SWAG a été mis à jour, et je tente de trouver pourquoi ça ne fonctionne plus... Sans vrai succès. Je relance les VM, et après un autre reboot pour HA, tout redevient accessible. Entre temps, j'ai relancé mon script de création de l'interface virtuelle, qui n'a pas renvoyé d'erreur, donc mon interface virtuelle avait sauté elle aussi. En temps normal, ça ne devrait avoir d'impact que sur le reverse proxy, et donc les noms de domaines. Donc mon hypothèse est qu'il y a quelque chose qui a fait foirer la connexion LAN du NAS. Ce qui est confirmé par les log dans le centre des journaux : Mon LAN3 est mon interface réseau principale, via un adaptateur USB 2,5GbE connecté sur un swtich 2,5GbE. Le LAN1 est connecté à un autre switch Gb, mais l'interface est désactivée quand LAN3 est fonctionnelle. J'ai un script lancé toutes les 30 minutes par le planificateur de tâche qui s'occupe de vérifier que LAN3 est fonctionnel et désactive les autres interfaces quand c'est le cas, et réactive LAN1 si LAN3 est KO. Et en rédigeant ces lignes, j'ai fait quelques recherches dans les logs de DSM et c'est en réalité vers 2h du matin que ça foiré. Voilà la sortie de mon script lancé vers 2h00:01 : (1) already root => As VMM is installed and Open vSwitch is activated, all physical interfaces will be managed with the virtual one (ovs_ethX). => So when we'll see ethX, ovs_ethX will be managed as well. => eth0, eth1 : will be deactivated if 'eth2' is up and running. Try n°1 package r8152 is turned on , version is 2.17.1-1 pkgctl-r8152 active_status = active pkgctl-r8152 load_status = loaded pkgctl-r8152 enable_status = enabled The driver status is OK ! No need to do something more. gateway is = 192.168.2.1 Gateway 192.168.2.1 IS NOT accessible ! The driver need to be restarted or reloaded ! [pkgctl-r8152] done reload-or-restart. Try n°2 package r8152 is turned on , version is 2.17.1-1 pkgctl-r8152 active_status = active pkgctl-r8152 load_status = loaded pkgctl-r8152 enable_status = enabled The driver status is OK ! No need to do something more. The driver is still not OK on the 2nd try ! That's not good... It means the eth2 isn't working... So let's reactivate the eth0 interface. Reactivation of eth0. Done. Ipv6 on interface ovs_eth0 is already deactivated. Reactivation of eth0 because of Open vSwitch installed with VMM. -> ovs_ should be up now. You can connect the NAS on 192.168.2.200 in order to sort things out... Reactivation of eth1. Done. Ipv6 on interface ovs_eth1 is already deactivated. Reactivation of eth1 because of Open vSwitch installed with VMM. -> ovs_ should be up now. You can connect the NAS on 169.254.26.251 in order to sort things out... => Exiting script now. Sending Gotify Notification... On voit que le script à bien détecté un souci et à réactivé l'interface eth0 (LAN1). 30 min plus tard, le script réactive mon interface LAN3 (eth2) et désactive LAN1 et tout refonctionne (enfin pas les VMs) (Note : je pense qu'il faut que ce script relance la création de l'interface virtuelle si jamais eth2 a été down... sinon mon SWAG ne fonctionnera plus correctement, et ça c'est un autre souci... que je devrais résoudre avec quelques lignes de code supplémentaires) : (1) already root => As VMM is installed and Open vSwitch is activated, all physical interfaces will be managed with the virtual one (ovs_ethX). => So when we'll see ethX, ovs_ethX will be managed as well. => eth0, eth1 : will be deactivated if 'eth2' is up and running. Try n°1 package r8152 is turned on , version is 2.17.1-1 pkgctl-r8152 active_status = active pkgctl-r8152 load_status = loaded pkgctl-r8152 enable_status = enabled The driver status is OK ! No need to do something more. gateway is = 192.168.2.1 gateway 192.168.2.1 is accessible ! No need to do something more. Deactivation of ipv6 on interface ovs_eth2 in 5s... ovs_eth0 is still up and running. Shutting down now. eth0 is still up and running. Shutting down now. ovs_eth1 is still up and running. Shutting down now. eth1 is still up and running. Shutting down now. Le souci est donc localisé entre 2h00:01 et 2h30 ce matin. En fait loin de la MAJ de SWAG comme initialement pensé... L'investigation continue : pourquoi diable ma connexion a sauté ?! Le switch 2,5GbE, récemment mis ? Ça me parait étonnant, car mon autre NAS ne m'a pas rapporté de déconnexion... ni le NUC branché lui aussi dessus... Hmmm... un autre switch du réseau... peu probable... mais le tout abouti donc au routeur. Il n'y a que lui qui peut avoir merdé, et fait que mon interface du NAS récupère une adresse APIPA, donc pas de serveur DHCP... Regardons les logs du routeur. Diantre, mais il a rebooté ce #@$... Et là, je me souviens que j'ai programmé un reboot 😅 Bon bah voilà, fautif trouvé... 🤣 le routeur qui reboot 🫣🙄 Me reste à décaler un peu le reboot entre deux exécutions de mon script de vérification d'interface, et à coder un peu sur le lancement de la recréation de l'interface virtuelle du NAS en cas de réactivation de eth2. Voilà pour ma petite histoire 😆