MilesTEG1

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 😆

Peut-être fusionner les deux sujets serait une bonne idée ^^

Hello 👋🏻 Dîtes, avez vous des soucis avec le bouncer de Crowdsec qui ne veut pas être télécharger dans l’image swag ?! chez moi ça me fait une erreur (je n’ai plus le terme exact et je suis sûr mobile…) « … mismatch … », et nginx redémarre sans avoir fini son démarrage. Dès lors que j’enlève le mod Crowdsec du docker compose , nginx fini son démarrage. je posterais plus de précision quand j’aurais le pc sous la main.

Lorsque tu actives le 2FA dans DSM tu as plusieurs choix : Si tu choisis la 2ème option : Tu utilises ton application favorite pour la gestion des codes 2FA. Si tu te contentes de scanner le QR-Code, tu n'auras pas la clé TOTP, il faut cliquer sur "Vous ne parvenez pas à le scanner ?" : Si tu n'as pas conservé cette clé en le mettant dans un client qui permet de l'afficher, c'est mort, il faut désactiver le 2FA, et le refaire. Je viens de faire l'essai de désactiver le 2FA sur mon test-user : et bien je n'ai pas eu besoin de rentrer un quelconque code pour cette désactivation...

Je confirme ! et je vais aller plus loin : j’utilise l’authentification en 2 étapes (2FA) pour plusieurs comptes dsm. pour tous j’ai la clé TOTP de mise dans : Vaultwarden/Bitwarden Authy Ms Authenticator Je peux donc utiliser les codes uniques de 2FA générés par une de ces 3 applications. Et pour mon compte administrateur j’ai aussi (en plus) Secure SignIn de Synology de paramétré : ce qui fait que j’ai aussi la possibilité de valider la connexion sans même utiliser le code à usage unique des 3 applications Authenticator ci dessus. bref tout fonctionne (faut que tout soit à la bonne heure aussi). précision importante : c’est à la création de la chaîne TOTP qu’il faut l’ajouter à toutes ces applications en même temps (enfin les unes après les autres ) mais avant de valider en tapant le code données par l’une d’elles.

Salut 👋🏻 met ton chemin d’accès entre guillemets "…". la ligne de commande n’aime pas les espaces dans les chemins d’accès car ça fait des arguments supplémentaires que ne sait pas interpréter la commande. d’ailleurs je pense que ta commande doit retourner des erreurs, non ? @Rites es-tu aussi sur de ne pas avoir besoin de paramètres aurez que -r ? ( https://doc.ubuntu-fr.org/rsync ) Je lance de temps à autre ce genre de commande : rsync -avXh --progress --syno-acl --stats --exclude={'@eaDir','#recycle','~$*.*','~*','~*.tmp','desktop.ini','.DS_Store'} --log-file=/volume2/TEMP/rsync_transfer.log /volume1/Dossier-Source/ /volume1/Dossier-Destination/

Haaa merci beaucoup pour ce retour 😊 Si tu as le temps , pourrais tu détailler tes erreurs ? (Et si tu as envie , le faire sur GitHub dans une issue) ca pourrait servir à d’autres 😉

Ha ! Je n’avais pas saisi que tu avais 2 nas sur le switch 🤣 merci synology de faire les pingres à ne pas vouloir inclure du 2,5G de base sur les nas ! la concurrence eux l’ont bien saisi 😅

Un seul supplémentaire suffira je pense 🤔

Oui c’est exactement pour ça que j’ai fait le script : le faire une porte d’entrée de secours si l’interface usb plante . perso j’en ai que le porte lan1 (donc eth0) connecté à un switch gigabit en plus de l’interface usb qui elle est connectée à un switch 2,5G. Le deuxième port réseau du nas (eth1 donc lan2) lui reste non branché à un switch. Mais il se fait désactiver quand même par le script.

Qu'entends-tu par "pas connectés" ? Pas de câble raccordé ? Câble raccordé, mais interface "down" (via un ifconfig ethX down) ? Si pas de câble connecté, mon script ne pourra pas connecter le câble 🤣 Mais dans tous les cas, si l'interface USB est KO, mon script réactive toutes les interfaces de la liste données dans les premières variables. Si l'interface USB est online et que le ping vers la passerelle par défaut passe sans soucis, alors le script désactive toutes ces interfaces inutiles (eth0...) Regarde ce que j'ai : Mais si le script détecte lors d'un de ses lancements automatiques que mon adaptateur USB est KO (pilote ou autre), il va me réactiver LAN1 et LAN2 (donc eth0 et eth1).

Hello @Jeff777 Je ne sais si avec mon script pour l'interface USB 2,5G tu aurais encore ou plus du tout ces erreurs... C'est à tenter. Précision : mon script n'agit que sur l'interface de l'adaptateur USB, et les autres interfaces réseau en les coupant si celle de l'USB est fonctionnelle. Tu peux essayer le script, sans paramétrer de tâche déclenchée/planifiée au boot pour le lancer. Ainsi si ça te coupe tout accès, un reboot et hop, c'est re-là. Dernière chose, ton interface macvlan, est-ce que tu l'as liée à ton interface réseau de l'adaptateur USB ? Même chose pour ton interface virtuelle ? Si oui aux deux, il faut que tu lances ton script d'interface virtuelle bien après mon script sinon elle risque de se créer sur une interface non encore UP.

@Jeff777J'ai fait une MAJ pour gérer l'installation de VMM et de Open vSwitch. S'il y a des cobayes pour tester 😉

Hello, pour répondre à cette partie de ton problème, ça peut se corriger en demandant à Free, via ton compte en ligne, une iPv4 full stack c’est à dire avec tous les ports. Car là tu as une iP partagées donc que 1/4 des ports dispos. pour la partie wireguard je n’ai jamais réussi à la faire fonctionner sur mon nas… mais vu que tu as une Freebox, elle peut faire office de serveur wireguard 😊

@LeloloMême chose pour moi , j’ai trop pris mes habitudes avec Portainer. l’utilisation de mon instance gitea pour stocker les docker-compose.yml et l’importation depuis ce gitea dans portainer est très pratique. J’utilise aussi l’agent portainer sur un autre nas (l’asustor) pour lui déplacer dessus des conteneurs. j’ai moi aussi une version entreprise gratuite (licence pour 5 noeuds). et l’affichage des images à jours ou non est très pratique.

@sypqys faudrait sur tu lises un peu sur les notions d’adresses iP. Car là, sans ces notions, tu vas galérer tout le temps. ipv4 : qu’est-ce qu’une adresse privée ? Quelles sont les plages d’adresses privées ? qu’est-ce qu’une adresse de réseau docker ? adresse localhost ? meme chose pour l’ipv6 , que je ne recommande pas dans un lan privé qui n’a pas besoin de quantité astronomique d’adresses iP.

Ici aussi il y a un tuto, fait par @.Shad.. cherche dans la section tutoriels. (indice : le sujet doit être un truc du genre : centralisation des conteneurs docker)

Je me suis dit y’a tien ça pourrait être une bonne idée d’essayer une version web de piwigo , car je n’ai moi aussi jamais réussi a faire fonctionner la version docker,.. mais la version de php nécessaire me bloque… 7.4 ! alors que cette version est déclassée et considérée comme vulnérable… ca ne fonctionne pas avec la dernière version de php du syno 8.1 (si elle est dispo ) ?

Je verrais si l’une ou l’autre fonctionne 😇 merci pour les recherches 😊

@.Shad. En étudiants les différents fichiers de configuration du nginx du syno et ceux de Swag, j'ai trouvé ces différences : Et c'est à peu près tout. Je ne me vois pas trop refaire tout un bloc avec les mêmes choses...

@.Shad.il faudra que je regarde ça , mais vu ce que tu dis , j’ai peur que ça ne soit pas vraiment possible de changer le mime type s’il est défini différemment dans le nginx.conf … À moins qu’il soit possible de faire une exclusion et de placer dans le .conf du routeur la elle chose que sur le RP de dsm…

@.Shad. J'ai tenté tous les navigateurs à ma disposition : Ms Edge, Brave, Firefox, Safari. Et tous refusent de me charger la page... J'ai tenté d'ajouter ça dans le .conf de SRM : proxy_hide_header X-Content-Type-Options; Mais sans effet... Je viens de tenter autre chose. J'ai fait une réécriture DNS différente pour mon domaine associé à SRM : je l'ai fait pointer sur le NAS, et donc son reverse proxy à lui. Et là, ça fonctionne, même s'il y a quelques erreurs : C'est étonnant... Je vais laisser comme ça pour le moment, mais ça m'enquiquine que ça ne fonctionne pas alors que pour DSM , Photos, etc... ça marche impec.

Hello @.Shad. @oracle7 @maxou56 J'aurais besoin de vos lumières si vous le voulez bien 😉 J'utilise SWAG depuis pas mal de temps, et une des dernières MAJ fait que mon RP pour SRM ne fonctionne plus : j'ai une page blanche... Aucune erreur, mais page blanche. La console me donne ceci que je ne sais pas interpréter pour élaborer une correction... Voilà mon srm.local.conf : ## Version 2021/05/18 # make sure that your dns has a cname set for <container_name> and that your <container_name> container is not using a base url # Note for DSM Applications (Package) # As SWAG is installed in macvlan mode, you have to set the virtual IP for $upstream_app # set $upstream_app 192.168.2.230 server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name rt2600ac.*; include /config/nginx/ssl.conf; client_max_body_size 0; # enable for ldap auth, fill in ldap details in ldap.conf #include /config/nginx/ldap.conf; # enable for Authelia #include /config/nginx/authelia-server.conf; # GeoIP Blocking with Maxmind Docker-MOD include /config/nginx/maxmind-geoblock_and_LAN.conf; # Restrict access to some IPs only (LAN & VPNs) include /config/nginx/ACL.IP-LAN.conf; # Custom error pages include /config/nginx/error_pages.conf; # Custom error files access_log /config/log/nginx_not_crowdsec/access_syno_RT.log; error_log /config/log/nginx_not_crowdsec/error_syno_RT.log; location / { # enable the next two lines for http auth #auth_basic "Restricted"; #auth_basic_user_file /config/nginx/.htpasswd; # enable the next two lines for ldap auth #auth_request /auth; #error_page 401 =200 /ldaplogin; # enable for Authelia #include /config/nginx/authelia-location.conf; include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app 192.168.2.1; set $upstream_port 9000; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } } J'ai tenté avec et sans le http2 pour les listen, via le port http ou le https pour le upstream_port et proto... Mais rien n'y fait, c'est blanc. Le ACL.IP-LAN.conf contient les restrictions d'accès suivantes qui ne semblent pas poser de souci puisque la page se charge : ## ACL.IP-LAN.conf # For my Synology DSM, I created an Access Control Profiles to restrict access only to LAN and VPN IP adresses # This Access Control Profile is a file in the /etc/nginx/conf.d folder # But for SWAG-Nginx, it must be with another file. # Allow all from LAN IPs allow 192.168.2.0/24; allow 192.168.1.0/24; # Allow all from VPNs IPs allow 192.168.10.0/24; allow 192.168.11.0/24; allow 192.168.12.0/24; allow 10.7.0.0/24; # Deny all deny all; J'arrive bien à accéder à SRM via l'IP du routeur. Je ne sais pas comment corriger mon accès via SWAG. Est-ce que l'un de vous saurait m'aider ? Merci d'avance.

Ha non je n’ai pas vérifié si le qrcode scanne était correctement rendu dans les paramètres. je regarderais si je trouve comment faire 😊

OK je comprends ^^ J'ai aussi pensé à cela. Et oui, j'ai transféré le port 51820 vers l'IP du NAS dans mon routeur '(qui est en dmz de ma freebox pop), ce qui a ouvert le port dans le pare-feu du routeur. Ce port est bien sûr ouvert dans le parefeu du NAS. Je retenterais plus tard de tout refaire.