dd5992

Merci Jeff pour cette astuce qui m'a permis de mettre à jour mes DS413 et DS411J qui refusaient de me proposer l'upgrade. Ça marche très bien pour les deux.

Tu peux vérifier également que le pare-feu de ton NAS ne filtre pas les connexions entrantes sur le port 80 pour les IP des serveurs de Let's Encrypt (les IP de Let's Encrypt sont 64.78.149.164 et 66.133.109.36).

Bonjour, Ce tuto peut paraitre rébarbatif, mais peut intéresser tous ceux qui se sentent concernés par une ou plusieurs de ces problématiques : Redondance d'accès à un réseau local (pour des professionnels peut-être - à noter que pour eux, on peut imaginer une variante utilisant plusieurs fournisseurs d'accès pour compléter la redondance), Utilisation de DNS locaux ou globaux, IPV6 sécurisé, reverse-proxies @Jeff777ou moi seront heureux de partager avec vous d'autres variantes qui seraient plus appropriées pour votre cas. Ce qui nous intéresseraient dans un premier temps serait de discuter des cas d'utilisation que vous pourriez envisager et de vos différentes réactions. Il y a aussi quelques questions en suspens, par exemple, quand une adresse est accessible à la fois en IPV4 et IPV6, comment se fait le choix au niveau des DNS. N'hésitez pas! Je m'aperçois aussi que nous avons omis de parler dans la partie sécurité de la possibilité de filtrage des accès de chaque redirection grâce aux profils de contrôle d'accès. Quelqu'un les a-t-il déjà utilisés?

Même si le routeur principal ouvre à IPV6, il doit sûrement encore permettre à ton réseau local d'être en IPV4. Ton réseau local doit être en "Double Stack" et faire co-exister les deux. De plus, tu peux choisir de n'utiliser que IPV4 en mettant dans les parties cible des règles de ton reverse-proxy des adresses IPV4 (ou des noms qui ne se résolvent qu'en IPV4. Tu peux aussi désactiver l'IPV6 sur les routeurs et les machines de ton réseau qui le permettent (syno, PC, ...). Tu pourras alors ignorer la problématique IPV6 pour régler ton problème.

La différence ici entre IPV4 et IPV6 est qu'en IPV4, tu as une seule adresse et c'est la box qui dispatche l'accès aux équipements du réseau local avec les redirections de ports du NAT. En IPV6, les machines du réseau local sont accessibles de l'extérieur (sauf si un firewall est actif dans la box) et les redirections de port de la box sont inopérantes, celles des routeurs intermédiaires éventuels également. Pour les règles du pare-feu, il faut parfois faire des règles spécifiques pour IPV6. Par exemple pour dire qu'on accepte telles connexions à l'intérieur du réseau local, on définit le réseau local comme les machines accessibles par des adresses IPV4 locales non routables. Avec IPV6, il faut ajouter le préfixe IPV6 du réseau local (par ex 2a01:xxxx:yyyy:zzzz::/64).

OK merci. Mon objectif ici est de comprendre comment fonctionne la priorité IPV6 sur IPV4. La différence entre ta solution initiale et la mienne (apparemment) peut résider dans cette priorité. Tes tests d'hier semblent montrer que dans le premier cas on garde IPV4 par défaut alors que dans le deuxième, la logique (à vérifier) devrait être que c'est IPV6 (et donc syno2) qui prévaut. C'était quoi? je ne souviens pas l'avoir vu. On peut toujours espérer 😉. De toute façon ta solution fonctionne bien, sauf si tu as des équipements qui sont compatibles IPV6 et qui ne peuvent pas se protéger (Caméra, imprimante réseau,...).

Bravo @Jeff777 C'est très bien que tout marche! Je te propose une légère modif qui pourrait rendre totale la symétrie de la solution. Dis moi si ça te convient. Ça concerne les enregistrements DNS. Actuellement, tu as : En IPV4 : Ton domaine (ndd.fr par exemple) a un enregistrement A uniquement pour ndd.fr et ns.ndd.fr vers ton IPV4 externe. Tes autres domaines sont déclarés avec des enregistrements CNAME vers ns.ndd.fr. En IPV6 : tu as des enregistrements AAAA pour chacun de tes sous-domaines xxx.ndd.fr qui pointent vers l'adresse IPV6 de ton syno2 (dis moi si je me trompe). Ce que je propose : En IPV4: pas de changement. En IPV6 : enlever les enregistrements AAAA de chacun des sous-domaines xxx.ndd.fr et ajouter simplement un enregistrement AAAA vers ton syno2 pour ns.ndd.fr et ndd.fr, qui se retrouvent tous les deux avec une adresse IPV4 et une adresse IPV6. Les enregistrements CNAME définiront les alias des sous-domaines, aussi bien en IPV4 qu'en IPV6. Ton accès "redondant" (par syno1 ou syno2) devrait continuer à fonctionner de la même manière. De plus, si tu fais un tuto sur le sujet (auquel je veux bien contribuer) je te propose d'ajouter une section traitant du problème de firewall. Dans ta solution, une seule adresse IPV6 est accessible de l'extérieur (celle de syno2). Le firewall de la box (maintenant que la freebox en a un, comme la plupart des box) doit être désactivé, car il fonctionne en tout ou rien. Le firewall de syno2 doit donc ouvrir ses ports 80 et 443 à l'extérieur, les autres (syno1 et tes autres équipements) fermant tout traffic IPV6 venant d'internet. Une alternative est d'avoir un routeur entre la box et le réseau local. C'est alors le seul firewall du routeur qui doit être configuré pour n'autoriser en entrée d'internet en IPV6 que le traffic vers les ports 80 et 443 de syno2. C'est cette dernière solution que j'ai implémentée dans mon réseau.

1 Les synos n'ont qu'une adresse IPV6, fixe. 2 pour savoir si un équipement supporte IPV6, se connecter sur le FreeboxOS , ouvrir Périphériques réseau, double cliquer sur l’icône de l'équipement et enfin sur l'onglet connectivité. Il donne seulement l'adresse IPV6 locale, mais si elle y est c'est que l'équipement supporte IPV6. 3 le reverse-proxy du syno2 peut router vers tout (même en dehors de ton réseau local). Il faut seulement indiquer l'adresse correcte et le port. Il n'est pas indispensable d'utiliser les adresses IPV6. Ton réseau local est en double stack V4 ET V6. Mets simplement la stricte même chose que sur le syno1 (pour la destination). tu peux accéder comme ça même les équipements non compatibles avec IPV6. 4 je ne crois pas.

Je suis d'accord avec @Jeff777, ça marche en IPV6 car alors tu peux accéder directement aux machines de ton réseau local, la box ne sert que de routeur en ne prenant pas en compte les redirections de port de ta box. En IPV4, il n'y a qu'une adresse externe et donc le port 443 (https) de cette adresse ne peut pointer que sur une machine. Tu peux rediriger vers différentes machines de ton réseau local avec un reverse-proxy, mais une seule machine peut porter de reverse proxy. Si cette machine est un syno et qu'il est en panne, plus d'accès. Tu peux aussi mettre un Raspberry Pi ou une autre machine, mais d'abord, c'est plus difficile à configurer (il n'y a plus d'interface DSM qui te facilite la tâche, mais c'est possible - voir plus bas) et il reste toujours le problème de la panne de la machine qui porte le reverse-proxy (le Raspberry Pi ici). Quand le reverse-proxy n'était pas encore supporté nativement par DSM (avant la V6) j'avais suivi le tutoriel de @CoolRaoulpour le faire. Je suppose qu'il est possible de s'en inspirer pour l'implanter dans un Raspberry Pi car son OS est un Linux. Le premier article cité par @Jeff777 donne aussi des indications. Pour une solution dans la box, je n'ai rien trouvé dans cet l'article la moindre indication que ce soit possible. Pour revenir sur les tests de @Jeff777, et en particulier : Tu dois pouvoir y accéder par le reverse-proxy de syno2 exactement de la même manière que dans le reverse-proxy de syno1. Dans un reverse-proxy, l'adresse cible est interprétée par ton DNS local. Comme ton réseau local est mixte IPV4/IPV6, tu peux y mettre : soit une IP V4 ou V6 en clair soit une adresse locale disposant d'un enregistrement A, AAAA ou CNAME dans ton DNS local. Je suis sûr car j'ai déjà essayé, y compris avec un équipement qui n'est pas compatible IPV6.

C'est vrai, mais tu le fais une fois seulement, sauf si tu dois en ajouter c'est vrai 😉.

Bon. donc c'est finalement assez proche de ce que je pensais. l'adresse est donc du type syno.ndd.yyy et c'est le .htaccess qui renvoie sur https si la demande est en http. Restent quelques questions : En mode "normal" (si le syno1 est actif) est-ce que c'est l'enregistrement A du ndd qui s'applique (comme wildcard en somme)? Dans ce cas es-tu sûr que c'est bien syno1 qui reçoit la requête et non syno2, du fait de la priorité d'IPV6 par rapport à IPV4? Que se passe-t-il si syno2 est down? Ce serait bien de le tester cette AM aussi si tu peux. C'est pour ça que j'en suis resté au certificat Let's Encrypt générés par le SRM. Il se renouvelle automatiquement et concerne tous les xxx.ndd que j'utilise. J'attends que SRM gère les certificats wildcard automatiquement pour y passer (si ça arrive un jour 😉)

OK, je n'ai pas tout compris donc. Je vois bien comment tu accèdes à travers le syno2 en IPV6 quand syno1 est down. La box est transparente en IPV6 et sert uniquement de routeur (sans NAT) et ton enregistrement AAAA pointe sur syno2. En IPV6, les redirections de port de la box ne sont pas effectives. Donc ça marche. Par contre, je ne vois pas quelle est la chaine quand tu passes par syno1. Quelle adresse http ou https utilises tu? Est elle différente du cas ou syno1 est en panne? Désolé d'insister, mais je crois que ça vaut le coup de décrire complètement une solution et de la comprendre pour qu'elle puisse être mise en place facilement par ceux qui le souhaitent.

Bravo @Jeff777! Il me semble que cette méthode est très proche de celle que je proposais plus haut. Tu as ajouté une amélioration qui consiste à avoir la même adresse en https://xxx.ndd.yy avec si j'ai bien compris un enregistrement DNS A qui pointe vers l'adresse IPV4 du syno1 (à travers la redirection dans la box) et un enregistrement DNS AAAA vers l'adresse IPV6 du syno2. Tu as comme ça une configuration symétrique. En mode sans panne dans le cas ou l'appelant est en IPV6, il ira sur syno2, s'il est en IPV4, il ira sur syno1 et s'il est en double stack (cas le plus courant quand l'IPV6 est disponible pour lui) il ira sur syno2 (priorité de IPV6 sur IPV4). Le doute que j'avais est qu'au cas où un syno est en panne et que c'est celui qui est visé (voir § précédent) il faut être sûr que la connexion bascule sur l'autre ligne. Dans ton test, tu as prouvé que la partie en IPV6 fonctionnait, et donc l'accès se faisait sur syno2. Il faudrait tester le cas où c'est le syno2 qui est arrêté pour voir si la connexion de ton copain (double stack - IPV6 ou sinon IPV4) bascule bien sur IPV4 et donc accède par syno1 et ne reste pas coincé en essayant un accès en IPV6 sur syno2. Je pense que ça devrait marcher. De toute façon, si le PC appelant est en IPV4 seulement et que le syno1 est en panne, ça devrait coincer, mais c'est normal.

Alors, gare au passage à la version 1903 de W10 (je suis encore en 1809). On verra si c'est maintenu en cas d'upgrade.

Si tu restes sur l'idée d'autoriser tout de l'extérieur sauf l'accès au port SSH, il suffit de mettre une règle interdisant l'accès au port SSH entre les règles donnant accès à tout en local et la règle donnant accès à tout de l'extérieur. Dans les règles du pare-feu, la première règle qui correspond à la situation détermine si l'accès est autorisé ou non et les règles suivantes sont ignorées.

Sans désactiver l'attribution aléatoire des adresses par W1, j'ai le même comportement, sauf que l'adresse fixe n'est pas basée sur l'adresse MAC. Elle est fixe et a dû être tirée au sort la première fois et être enregistrée dans la base de registres de W10 (dixit la base de connaissances de Microsoft). l'adresse employée pour les connexions démarrées du PC (en local comme vers internet) est l'adresse temporaire (et c'est en effet ce qui est souhaité). C'est elle qui change environ tous les 9 jours.

Avec les 4 règles de base proposées par @Fenrir dans son tuto, tu as déjà ce qu'il te faut : Les 3 premières règles autorisent tous les accès à partie de ton réseau local et la dernière interdit tout le reste. Tu peux insérer d'autres règles (juste avant la 4ème) si tu veux donner des accès de l'extérieur à certains services. Edit : @Varx et @Jeff777 : Trois messages simultanés pour dire la même chose, c'est assez exceptionnel!

Dans ce cas, le plus simple est de limiter à l'accès au SSH à partir de ton réseau local (à faire en mettant une règle ad hoc dans le pare-feu).

Au sujet de la fréquence de changement de l'adresse IPV6 temporaire sous Windows 10, j'ai remarqué qu'elle change environ tous les 9 jours. Je suis en W10 version 1809. J'ai pu le constater de la manière suivante : A chaque changement, lorsque je me connecte sur mon NAS sur mon réseau local avec une nouvelle IPV6, le Conseiller de Sécurité de DSM m'envoie un message "DSM a détecté un nouveau comportement de connexion sur votre NAS..." en précisant les adresses de connexion. Ces messages sont enregistrés dans le Conseiller de Sécurité sous la rubrique "Analyse de la connexion". La répétition de ces messages est agaçante d'ailleurs.

Peut être avec deux noms de domaines distincts, mais je n'ai jamais testé, mais des enregistrements DNS de type A du genre xxx.ndd.fr et yyy.ndd.fr par exemple peuvent pointer vers la même adresse (IPV4 ou IPV6) - déjà testé une adresse de type xxx.ndd;fr et une adresse de DDNS (par ex zzz.synology.me) peuvent pointer vers la même IP - déjà testé de toute façon, si @Dimebag Darrell n'a qu'une box à laquelle sont reliés les deux synos, les deux noms de domaines pointent vers la même adresse et un seul NAS est accessible (déterminé par la redirection du port 443 dans la box). C'est ce qui diffère avec la solution avec IPV6 ou les deux NAS sont accessibles avec des IPV6 différentes.

Je prends comme hypothèse que l'objectif est l'accès aux syno1 et syno2 de l'extérieur par le port 443 uniquement (en https donc). Dans cette proposition le domaine syno1.ndd:443 ==> localhost:5000 envoie sur le DSM de syno1. Dans la box, le port 443 côté internet doit être redirigé vers de port 443 du syno1. Pour atteindre le syno2, la règle à mettre sur le reverse-proxy de syno1 est syno2.ndd:443 ==> syno2.ndd:5000 le deuxième syno2.ndd est interprété par le DNS local. Cette partie fonctionne. Pour la partie avec un second nom de domaine (ndd2) ce qui pose problème est que en IPV4 le réseau local n'est accessible que par une seule adresse IPV4 externe. Donc pour atteindre notre réseau local, il n'y a pas d'autre choix que de mettre dans l'entegistrement A de ndd2 sur le DNS global, l'adresse IPV4 externe de la box (la même que pour ndd). Sur la box, la redirection du port 443 externe, renverrait vers le même port 443 de syno1, donc pas moyen d'être symétrique et d'envoyer vers syno2, donc pas moyen comme ça de pouvoir atteindre syno2 si syno1 est en panne. Toutefois, ton idée m'a fait penser à une autre solution qui doit fonctionner (sans supplément de coût 😉). En IPV6, on dispose de tout un tas d'adresses externes qui peuvent désigner diverses machines du réseau local; et donc on peut en utiliser une pour atteindre syno2 directement. On garde la première partie de ta solution, en IPV4 comme actuellement (on pourra la passer ensuite en IPV6 pour avoir une symétrie parfaite). Pour la partie avec le second domaine, on utilise l'adresse IPV6 de syno2 (en configurant son pare-feu de manière à n'accepter que des accès internet sur le port 443) on a donc une entrée DNS global AAAA pour *.nnd2 vers syno2. Et là ton idée fonctionne : Un reverse-proxy sur syno2 avec syno1.ndd2:443 ==> syno1.ndd:5000 donnera accès de l'extérieur au DSM du syno1 et syno2.ndd2:443 ==> localhost:5000 donnera accès au DSM de syno2. On peut même éviter le coût du second domaine en utilisant par exemple les domaines syno1a.ndd et syno2a.ndd pour le passage par syno1 et syno1b.ndd et syno2b.ndd pour le passage par syno2.

@Dimebag Darrell: J'ai déjà vu dans un post ici (pas moyen de retrouver où) qui décrivait l'implémentation d'un reverse-proxy sur un Raspberry Pi qui redirigeait les requêtes sur l'un ou l'autre des deux synos du réseau local. Ça semble correspondre à ce que tu cherches. Si l'un des synos est en panne, l'autre reste accessible. Par contre, il y a une possibilité de panne commune. Si le Raspberry Pi est planté, tu n'accèdes plus à aucun de tes synos. Une autre possibilité (avec une meilleure redondance) c'est d'avoir 2 fournisseurs d'accès, avec deux box, qui permettent d'accéder au même réseau local. Avec un jeu de ndd qui pointe sur l'adresse externe de la première box qui pointe vers le reverse-proxy du premier syno, et un second jeu de ndd qui pointe sur l'adresse externe de la seconde box et qui pointe vers le reverse-proxy du second syno. Tu es alors protégé contre : la panne d'un des synos, l'autre est toujours accessible par l'autre chemin la panne d'un des réseaux (box ou panne isp), les deux synos sont accessibles par l'autre réseau. Il faut faire attention à n'avoir qu'un seul serveur DHCP actif ou mieux, affecter les IP du réseau local manuellement ainsi que les passerelles par défaut. La seule possibilité de panne commune est le switch sur lequel sont branchées les deux box, mais les switches de marque sont rarement en panne. Cela étant, c'est plus cher...

Dans ma config avec Numéricable, j'avais le DDNS synology associait xxx.synology.me à mon adresse IP externe (variable). Le CNAME associait mon yyy.ndd.fr à xxx.synology.me (je n'utilisait pas de wildcard dans le CNAME). les deux adresses yyy.ndd.fr et xxx.synology.me me renvoyaient à mon adresse IP externe (variable), même en cas de changement d'adresse IP externe par mon ISP. j'accédais à mon nas en https sur le port 443. Une redirection de port dans ma box renvoyait sur le port d'entrée du reverse-proxy du nas (en donnant l'adresse IP de mon nas sur ton réseau local), par exemple redirection du port 443 en entrée de la box vers l'IP 192.168.0.3 (celui de mon nas) port 443 la commande du reverse proxy du nas envoyait yyy.ndd.fr vers le port de l'appli du nas (localhost:7000 pour filestation) comme tu l'avais fait dans ta version N-1. Les deux premières étapes peuvent être intégrées en utilisant un prestataire de type OVH comme le suggère @Zeus. Toutes les étapes sont donc définies pour acheminer le flux d'internet vers le port 7000 par ex de ton nas. Note : C'est le nom qui est utilisé lors de la requête initiale qu'il faut utiliser dans le champ source de la règle du reverse-proxy (ici yyy.ndd.fr). Le CNAME ne transcrit pas le nom en cachant le nom d'origine, ce nom est conservé jusqu'à l'entrée dans le reverse-proxy. Bien sûr il est aussi possible de mettre une règle pour accéder à un service à partir de xxx.synology.me, mais le paramêtre source de la règle devra alors être xxx.synology.me. les deux peuvent co-exister.

C'est ça! Il faut attendre que la propagation ait lieu. Tu peux tester avec nslookup pour voir si tu récupères bien ton adresse externe actuelle.

Il me semble que lorsque j'étais chez Numéricable (pas d'adresse fixe), j'avais utilisé le DDNS de synology pour avoir une adresse du style xxx.synology.me qui pointe vers mon adresse externe et j'avais enregistré chez mon fournisseur de domaine (bookmyname) un enregistrement CNAME qui pointait vers mon adresse en www.synology.me, et ça fonctionnait.