PiwiLAbruti

De rechanger quoi ? @AlainMd Tes questions sont révélatrices : Tant que tu ne feras pas l'effort de te renseigner sur le fonctionnement d'IPv6, tu n'arriveras à rien.

Tous mes équipements utilisent IPv6 par défaut sauf deux switches (Netgear GS105PE) qui ne supportent que IPv4 pour l'accès à l'interface d'administration. Le saut vers IPv6 est fait depuis que les opérateurs l'ont déployé jusqu'à la box de l'abonné il y a plusieurs années maintenant. Tous utilisent IPv6 par défaut et IPv4 est relégué au second plan puisqu'il est souvent encapsulé dans un tunnel IPv6 (4in6) IPv6 est activé par défaut sur les box, donc les équipements du réseau local obtiennent automatiquement une adresse IPv6 globale (2000::/3) en plus de l'adresse locale (fe80::/10). Il faut obligatoirement activer les pares-feux sur tous les équipements de votre réseau, ajuster les règles de pare-feu du NAS (similaire à ce qui est déjà fait pour IPv4), et faire pointer vos noms de domaine vers des adresses IPv6 (en plus de l'IPv4) : device.domain.tld AAAA 2abc:defg::wxyz device.domain.tld A a.b.c.d Vous ne risquez pas de bloquer quoi que ce soit puisque IPv6 vient en plus d'IPv4. Donc tout ce qui fonctionne actuellement en IPv4 continuera de fonctionner. Attention si vous utilisez un routeur derrière la box, selon l'opérateur il peut être nécessaire d'indiquer à la box de déléguer un /64 à votre routeur (voir le site lafibre.info).

Visiblement, les failles trouvées étaient suffisamment critiques pour mettre à jour DSM 6 qui n'est plus supporté depuis le 1er octobre 2024. J'ai pu mettre à jour mon NAS de backup secondaire (un DS109 qui refuse de mourir 😆).

Ça doit être faisable avec deux taches planifiées, une pour stopper le paquet avant la sauvegarde (synopkg stop <nomDuPaquet>) et une autre pour le lancer après la sauvegarde (synopkg start <nomDuPaquet>).

Une fois de plus IPv6 n'a pas besoin d'être appliqué à tous les appareils du réseau. Ce qui fonctionne actuellement en IPv4 continuera de fonctionner ainsi. Le but est de pouvoir joindre le NAS en IPv6 depuis l'extérieur.

Il ne faut pas chercher à reproduire ce que vous faites en IPv4 avec IPv6, le fonctionnement est différent (et souvent plus simple qu'en IPv4). Par exemple, chaque équipement a sa propre adresse IPv6 publique. Il n'y a donc plus de ports à "ouvrir" car il n'y a plus de NAT. Il y a suffisamment de ressources sur internet pour expliquer le fonctionnement d'IPv6, Wikipédia le documente d'ailleurs très bien : https://fr.wikipedia.org/wiki/IPv6#Adresse_IPv6 (surtout le tableau qui fait le parallèle entre les réseaux IPv4 et IPv6 pour mieux identifier les adresses) https://fr.wikipedia.org/wiki/IPv6#Attribution_des_adresses_IPv6 (pour comprendre le fonctionnement de SLAAC) Rien qu'avec ce peu d'information, vous comprendrez à quoi servent les adresses IPv6 renseignées dans les interfaces de vos équipements, dont le NAS, et comment elles sont constituées. Un tutoriel "IPv6 et NAS Synology" ne servira à rien puisqu'il n'y a rien à configurer dans le NAS, à part le pare-feu mais c'est identique à ce qui se fait déjà en IPv4.

Je ne comprends pas le problème, IPv6 ne remplace pas les adresses IPv4 existantes.

En attendant une IPv4 full-stack, pourquoi ne pas utiliser IPv6 pour accéder au NAS ?

Pour compléter la remarque de @Mic13710 sur le masquage de confidentialité : https://kb.synology.com/fr-fr/SurveillanceStation/help/SurveillanceStation/camera_settings_masking?version=9

De manière générale, il vaut mieux laisser le maximum de rôles à la caméra (détection de mouvements, falsification, zones de confidentialité, …). À ma connaissance, Surveillance Station ne permet pas de définir des zones de confidentialité. Elles sont configurable sur la caméra uniquement. La caméra peut communiquer à Surveillance Station les détections de mouvement : Article relatif : Pour activer la détection de mouvement à l'aide des algorithmes intégrés à la caméra

C'est ce qui devait également poser problème à WireGuard. ProTip : Si tu ne souhaites pas faire passer tout ton trafic internet par le VPN du NAS, il faut décocher la case précédente et ajouter une route statique vers 192.168.1/24 sur le client. C'est automatisable avec un script ip-up comme sur Linux en créant le fichier de script /etc/ppp/ip-up et en le rendant exécutable : chmod 0755 /etc/ppp/ip-up Contenu du script : #!/bin/sh /sbin/route add 192.168.1.0/24 -interface $1 Ainsi, à chaque connexion au VPN, le script sera automatiquement exécuté et seul le trafic à destination du réseau 192.168.1/24 passera par le VPN. Dans WireGuard, cette configuration est possible en retirant les destinations 0.0.0.0/0 et ::/0 indiquées dans l'instruction AllowedIPs et en y ajoutant 192.168.1.0/24.

Le réglage Envoyer tout le trafic sur la connexion VPN doit être activé, sans quoi les réseaux autres que 10.8.0.0/29 seront injoignables. Sans surprise, ce sont les mêmes symptômes qu'avec Wireguard. As-tu essayé avec un iPhone ?

IPSec/L2TP est bien plus capricieux à configurer que WireGuard. Vu les soucis déjà rencontrés avec WireGuard, je te souhaite bonne chance 😅

Quelle est l'application Wake On Lan que tu utilises exactement ? Tu dois y renseigner l'adresse l'adresse IP publique de la box et l'adresse MAC de la machine à réveiller. Je ne pourrais pas t'aider plus si tu n'appliques pas ce que j'ai indiqué :

300Mbit/s plutôt, ce qui fait un peu moins de 40Mo/s (attention aux unités : 1 octet = 1 Byte = 8 bits).

Je ne vais pas faire un cours sur les réseaux ici. Pour moi l'objectif est que ton WoL fonctionne, c'est tout. Il est inutile d'utiliser WireGuard pour envoyer un paquet WoL car ce dernier n'a rien de bien confidentiel. Donc fais les tests sans WireGuard. Seul le WoL doit être activé sur la Freebox. S'il existe une redirection de port concernant le WoL (udp/7 ou udp/9), il faut la supprimer. Le paquet WoL doit être envoyé à destination de l'adresse IP publique de la box (ou un nom de domaine pointant vers cette adresse). La box se chargera ensuite de la diffusion du paquet sur le réseau local, ce que j'ai décrit comme "redirection implicite" (c'est concrètement ce qui est activé par l'option WoL de la box). Toutes les machines connectées au réseau local reçoivent ce paquet WoL, mais seule celle dont l'adresse MAC correspond à celle indiquée dans le paquet l'interprêtera.

Est-ce que les interfaces réseau du NAS et du PC indiquent bien 1Gbit/s pendant les chutes de débit ? Ca peut aussi se vérifier au niveau de la box si elle affiche la vitesse de ses ports Ethernet.

Peu importe que le NAS ait une IP fixe sur la box ou non. Hors du réseau local, c'est le proxy WoL de la Freebox qui se charge de transmettre le paquet WoL en broadcast sur le réseau local. Il n'y a pas besoin non plus de définir une redirection de port (udp/9) car il est implicite lorsque le proxy WoL est activé. C'est d'ailleurs probablement l'origine du problème rencontré.

Le déploiement a été rapide par rapport à d'habitude, la mise à jour m'a été proposée en automatique aujourd'hui (2 jours après l'annonce, contre au moins 3 semaines habituellement).

Comment as-tu configuré le WoL sur la Freebox ? (c'est différent de la bidouille faite sur une Livebox)

Synology ne supporte pas les versions de PHP antérieures à la 5.6. @Eric Plontz a donné une solution.

Même vers des appareils autres que le NAS ? (toujours adressés en 192.168.1.x) Cest-à-dire ?

Ça donne quoi ?

Une fois connecté, tu dois voir les règles de routage suivantes sur ton Mac (commande netstat -rn dans le Terminal) : Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique 192.168.27.64 255.255.255.224 On-link 192.168.27.88 5 192.168.27.88 255.255.255.255 On-link 192.168.27.88 261 192.168.27.95 255.255.255.255 On-link 192.168.27.88 261 192.168.1.0 255.255.255.0 On-link 192.168.27.88 5 192.168.1.255 255.255.255.255 On-link 192.168.27.88 261 Essaye également de faire un ping vers différentes machines de ton réseau distant (192.168.1.x).

Avec le fichier de configuration suivant, seul le trafic à destination des réseaux indiqués dans AllowedIPs est envoyé sur le VPN : [Interface] PrivateKey = <base64> Address = 192.168.27.x/32 DNS = 212.27.38.253 MTU = 1360 [Peer] PublicKey = <base64> Endpoint = <publicIP>:<port> AllowedIPs = 192.168.27.64/27, 192.168.1.0/24 PersistentKeepalive = 30 PresharedKey = <base64> Je viens de tester et ça fonctionne parfaitement. Il est toujours étrange que le réseau 192.168.27.64 soit en /24 dans ta configuration alors que j'ai un /27. Je ne comprends toujours pas les conditions dans lesquelles tu fais les tests, mais ça pourrait être à l'origine du problème que tu rencontres.