This site uses cookies! Learn More

Ce site utilise des cookies !

En continuant à utiliser ce site, vous vous engagez à nous permettre de stocker des cookies sur votre ordinateur.

 

Si nous utilisons des cookies et retenons des données anonymes, c’est pour nous aider à mieux gérer notre mesure d’audience, aider nos partenaires commerciaux à nous rémunérer et nos partenaires publicitaires à proposer des annonces qui vous correspondent.

 

Grâce à ces cookies, le forum est en mesure de savoir qui écrit un message et utile pour le système d'authentification.

 

En cliquant sur « J'accepte », vous acceptez l'utilisation par NAS-Forum de cookies publicitaires et de mesure d'audience fine.

dd5992

Membres
  • Compteur de contenus

    89
  • Inscription

  • Dernière visite

  • Jours gagnés

    2

dd5992 a gagné pour la dernière fois le 9 mai

dd5992 a eu le contenu le plus aimé !

À propos de dd5992

  • Rang
    Novice Syno
  • Date de naissance 29/07/1955

Profile Information

  • Gender
    Male
  • Location
    Ile de France

Visiteurs récents du profil

980 visualisations du profil
  1. dd5992

    [Tuto] Reverse Proxy

    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.
  2. dd5992

    [Tuto] Reverse Proxy

    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).
  3. 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,...).
  4. 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.
  5. 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.
  6. 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.
  7. C'est vrai, mais tu le fais une fois seulement, sauf si tu dois en ajouter c'est vrai 😉.
  8. 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 😉)
  9. 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.
  10. 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.
  11. Alors, gare au passage à la version 1903 de W10 (je suis encore en 1809). On verra si c'est maintenu en cas d'upgrade.
  12. 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.
  13. 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.
  14. 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!
  15. 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).