2 synology sur le même réseau avec deux noms de domaines différents en Reverse proxy ?

[Jeff777]

Il y a 1 heure, dd5992 a dit :

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.

Non les seuls enregistrements A que j'ai dans la zone publique sont ceux du ndd et ns.ndd tous les autres sont en AAAA. Par contre le .htaccess et le reverse proxy (qui redirige en IPV4) font leur boulot dans le cas où le syno1 est fonctionnel.Le syno2 n'intervient pas.

Dans le cas ou le syno1 n'est pas fonctionnel l'adresse est résolue avec les enregistrements propagés donc pour le syno2 l'adresse IPV6. Pourquoi la box permet la redirection vers le syno2 alors que la redirection est vers syno1 (qui n'est plus là)? Je ne sais pas mais ça fonctionne. Peut-être parce que l'adresse IPV6 pointe directement sur le syno2.

Il y a 1 heure, dd5992 a dit :

si le PC appelant est en IPV4 seulement et que le syno1 est en panne, ça devrait coincer, mais c'est normal.

oui il faut effectivement une connexion IPV6 pour que ça marche 😉

Modifié le 4 juin 2019 par Jeff777

[dd5992]

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.

 

Modifié le 5 juin 2019 par dd5992

[Jeff777]

Il y a 1 heure, dd5992 a dit :

Quelle adresse http ou https utilises tu? Est elle différente du cas ou syno1 est en panne?

Les adresses sont identiques. Je peux utiliser http, https ou rien en préfixe et ça redirige vers du https.

Bon je vais peut être me fendre d'un petit tuto. Mais avant cela j'aimerais bien vérifier tout cela depuis l'extérieur de façon plus exhaustive.

Cet AM je pourrais. Je vais tester les adresses avec les deux synos puis je vais couper le syno1 et les re-tester.

Ce matin panique, je n'y arrivais plus en local....en fait mon certificat wildcard avait expiré (3 mois ça fait court).

Modifié le 5 juin 2019 par Jeff777

[dd5992]

il y a 21 minutes, Jeff777 a dit :

Les adresses sont identiques. Je peux utiliser http, https ou rien en préfixe et ça redirige vers du https.

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 :

1. 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)?
2. 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?
3. Que se passe-t-il si syno2 est down? Ce serait bien de le tester cette AM aussi si tu peux.

il y a 36 minutes, Jeff777 a dit :

mon certificat wildcard avait expiré (3 mois ça fait court).

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 😉)

[Jeff777]

il y a 6 minutes, dd5992 a dit :

C'est pour ça que j'en suis resté au certificat Let's Encrypt générés par le SRM.

Oui mais ça c'est encore plus galère. Il faut saisir toutes les entrées CNAME dans les zones et tous ces domaines dans le certificat. A moins que tu connaisses une astuce 😊

Pour les 3 questions j'essaie de vérifier cet am

[dd5992]

Il y a 1 heure, Jeff777 a dit :

Oui mais ça c'est encore plus galère. Il faut saisir toutes les entrées CNAME dans les zones et tous ces domaines dans le certificat. A moins que tu connaisses une astuce 😊

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

[Jeff777]

 

Pas trop le temps de faire un retour détaillé. Du bon et du moins bon mais en tout cas le but est bien atteint:

Syno 1 et 2 connectés : tout est accessible

Syno 1 seul connecté tout est accessible

Syno 2 connecté,  lui seul est accessible (j"espérais atteindre des équipements déclarés avec leur IPV6). Mais j'ai une piste..

Ceci sur PC Win 10  par contre problèmes sur Android

Bonne soirée

[Dimebag Darrell]

donc en résumé, uniquement en IPV6 c'est possible ?!

[Jeff777]

Oui c'est possible en IPV6 et tu n'as pas besoin de deux domaines différents. Maintenant démontrer qu'en IPV4 ce n'est pas possible je n'en suis pas capable 😐

En tout cas je n'y suis pas arrivé. En IPV4,  en cas de panne du syno1, le monde ne connait que l'adresse du domaine via le DNS secondaire, . Donc une requête avec ton nom de domaine amène sur la box. Ce qui doit manquer c'est que la box redirige vers le syno2. 

Pour cela il faudrait un reverse proxy sur la box. Cet article semble dire que c'est possible...mais pas (encore?) à ma portée :

http://cvoisin-domo.blogspot.com/2015/11/box-et-reverse-proxy.html

J'ai aussi trouvé ce site pour rasberry :

https://www.abyssproject.net/2017/02/enfin-un-reverse-proxy-nginx-pour-la-maison/

Mais là on s'éloigne du sujet de ce forum 😁. Et que ce passe-t-il en cas de panne du rasberry ?

Modifié le 6 juin 2019 par Jeff777

[dd5992]

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 :

Il y a 16 heures, Jeff777 a dit :

Syno 2 connecté,  lui seul est accessible (j"espérais atteindre des équipements déclarés avec leur IPV6). Mais j'ai une piste..

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.

Modifié le 6 juin 2019 par dd5992

[Jeff777]

Petit complément sur les tests d'hier:

Pas de connectivité IPV6 avec ma tablette (android 6.0.1). Je précise également que le DHCPV6 sur la box est désactivé et je n'ai pas activé le filtre IPV6 présent dans le dernier firmware de la freebox

Il y a 6 heures, dd5992 a dit :
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

Là mon test c'était syno2 connecté syno1 déconnecté et mon reverse proxy sur syno 2 donnait : https://syno2.ndd==>>localhost:5000.

L'adresse syno2.ndd était interprétée par le DNS secondaire (HE) comme son adresse IP publique IPV6 (réplique de la zone publique de mon DNS du syno) et j'arrivais sur le syno 2 où le reverse proxy renvoyait sur le bon port.

Sauf que pour les autres équipements je n'avais pas fait de reverse proxy, quel âne !

Alors je viens de le faire et comme je me rends compte que si je débranche le syno1 et fait une requête vers le  syno2,  d'après le journal du syno2, mon PC s'y connecte avec une adresse IPCV6 publique (qui est d'ailleurs l'adresse temporaire du PC...à méditer!) je me dis que je suis bien en loopback.
Je fais donc le même essai sur la caméra après avoir renseigné le reverse proxy et là cela ne fonctionne pas.

1:Est-ce qu'il faut enregistrer dans le DNS les adresses temporaires publiques et non les adresses basées sur l'adresse mac (mais mis à part celle de mon PC je ne sais pas comment les trouver. A noter que les syno semblent ne pas avoir d'adresse temporaire ?)

2:Est-ce que la caméra refuse une connexion en IPV6?

3: Est-ce que le reverse proxy du syno2 ne peut pas router vers un autre équipement

4: Est ce que, le DNS secondaire dirigeant vers l'équipement directement, le reverse proxy est shunté et le port 80 est utilisé ? Ce qui n'est pas celui de la cam !

autre raison.......?

Edition 30mn plus tard ::

ça aide beaucoup de résumer ses idées!  C'est l'adresse IPV6 du syno2 qu'il faut enregistrer dans le DNS primaire pour tous les enregistrements AAAA , et là on arriverait bien sur le syno2 puis sur la cam par le reverse proxy. Je teste !

 

Modifié le 6 juin 2019 par Jeff777

[dd5992]

il y a 21 minutes, Jeff777 a dit :

1:Est-ce qu'il faut enregistrer dans le DNS les adresses temporaires publiques et non les adresses basées sur l'adresse mac (mais mis à part celle de mon PC je ne sais pas comment les trouver. A noter que les syno semblent ne pas avoir d'adresse temporaire ?)

2:Est-ce que la caméra refuse une connexion en IPV6?

3: Est-ce que le reverse proxy du syno2 ne peut pas router vers un autre équipement

4: Est ce que, le DNS secondaire dirigeant vers l'équipement directement, le reverse proxy est shunté et le port 80 est utilisé ? Ce qui n'est pas celui de la cam !

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.

Modifié le 6 juin 2019 par dd5992

[Jeff777]

Il y a 15 heures, dd5992 a dit :

1 Les synos n'ont qu'une adresse IPV6.

donc j'avais bon 😊

Il y a 15 heures, dd5992 a dit :

mais si elle y est c'est que l'équipement supporte IPV6.

elle y est

 

Il y a 15 heures, dd5992 a dit :

4 je ne crois pas.

ça c'est vrai

 

mais regarde la fin de mon post précédent que j'ai édité 😉

Je viens d'essayer tout fonctionne en débranchant le syno1.

Et avec la tablette aussi. Donc le problème que j'avais chez mon collègue venait sans doute du paramétrage de sa box.

Bien vu @dd5992 même les équipements qui n'ont pas d'adresse privée IPV6 sur freeboxOS peuvent être joints.

Lorsque je coupe le syno1 il ne faut pas que j'oublie de vider les caches sinon la connexion sur le reverse proxy du syno2 ne se fait systématiquement pas !

Modifié le 7 juin 2019 par Jeff777

[dd5992]

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.

Modifié le 7 juin 2019 par dd5992

[Jeff777]

Oui en IPV4 et IPV6 c'est bien ce que j'ai dans ma zone publique.

Il y a 1 heure, dd5992 a dit :

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.

oui je vais essayer! J'ai toujours un peu la trouille de mettre mon domaine par terre mais je suis téméraire 🤣 

Résultat : ça fonctionne MAIS je crois que je vais garder la config précédente.

Dans la config précédente je n'ai pas enregistré de serveur de nom IPV6. Zonemaster me fait juste un warning sans incidence que les serveurs de nom IPV6 se trouvent dans le même AS (normal je n'ai que les deux d'Hurrican). Lorsque je rajoute le syno2 en serveur de nom ça pourrait résoudre ce warning mais j'ai un commentaire critique qui dit que le syno2 n'est pas accessible sur les ports 53. C'est idiot car le DNS secondaire n'y trouverait rien mais ça fait tâche! Et impossible de rediriger le port 53 sur les deux syno. Quant à changer chez HE le port pour les recopie de zone je ne sais pas faire et suis pas sûr que cela soit possible (en plus seulement sur le ns en IPV6).

Je préfère avoir un test zonemaster correct. Je m'en sers souvent lorsque j'ai un problème de connectivité.En plus je ne vois pas ce qu'apporte ta solution mis à part l'esthétisme 😉. Oui ça évite de saisir toutes les entrées AAAA mais il n'y en a pas tant que cela et de plus on peut faire un copier coller sur l'adresse IPV6 du syno2.

A moins que tu ais une idée 

Il y a 1 heure, dd5992 a dit :

De plus, si tu fais un tuto sur le sujet (auquel je veux bien contribuer)

pourquoi pas

Il y a 1 heure, dd5992 a dit :

Une alternative est d'avoir un routeur

Oui mais suite à un autre sujet que j'avais ouvert sur ce forum j'ai décidé de m'en passer. Je vais attendre que le pare-feu IPV6 de la freebox se muscle un peu 🙄 (de toute manière mon syno 2 il me sert de sauvegarde au syno 1 donc normalement il est remisé dans un placard au sous-sol.....je sais il faudrait mieux l'avoir dans un autre lieu)

Modifié le 7 juin 2019 par Jeff777

[dd5992]

Il y a 4 heures, Jeff777 a dit :

Résultat : ça fonctionne MAIS je crois que je vais garder la config précédente

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.

 

Il y a 4 heures, Jeff777 a dit :

Oui mais suite à un autre sujet que j'avais ouvert sur ce forum j'ai décidé de m'en passer

C'était quoi? je ne souviens pas l'avoir vu.

 

Il y a 4 heures, Jeff777 a dit :

Je vais attendre que le pare-feu IPV6 de la freebox se muscle un peu

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,...).

[Jeff777]

Il y a 3 heures, dd5992 a dit :

La différence entre ta solution initiale et la mienne (apparemment) peut résider dans cette priorité.

En loopback avec le syno1 déconnecté je ne vois pas de différence de fonctionnement entre les deux solutions. C'est juste le Zone master qui est différente.

Il y a 3 heures, dd5992 a dit :

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.

Au niveau du zone master le test interroge les serveurs de nom NS sur les ports 53 . Pour les IPV4 c'est la même chose dans les deux cas tous répondent.

Pour l'IPV6 il n'y a pas d'interrogation du serveur de nom primaire car je le l'ai pas déclaré en AAAA (d'où le warning que les deux serveurs de nom en IPV6 sont sur le même AS car ils sont tous les deux Hurricane).

Dans ta solution le serveur de nom primaire est déclaré en IPV6 comme étant sur le syno2 mais celui-ci n'est pas accessible par le serveur secondaire sur le port 53 (d'où une remarque critique. qui n'est pas grave dans ce cas puisqu'il n'y a pas de zone dans le syno2 à répliquer dans le serveur de nom secondaire.

En résumé, je pense que le fonctionnement est quasi identique dans les deux cas, car lorsque le syno2 est déconnecté seules le dNS secondaire peut répondre aux requêtes et là on ne trouve qu'un renvoi sur les adresses IPV6 :

 

Il y a 3 heures, dd5992 a dit :

C'était quoi? je ne souviens pas l'avoir vu.

https://www.nas-forum.com/forum/topic/63247-intérêt-dun-routeur-avec-une-box/?do=findComment&comment=1319376759

 

Bon la mauvaise nouvelle :

Si tout fonctionne en loopback, mon collègue n'a pas réussi à joindre les adresses de mon réseau sauf pour le syno 2.

Nous allons essayer avec une appli sur le syno2 pour voir si cela vient du reverse proxy. En effet la redirection du syno2 est vers localhost tandis que que les autres équipements sont vers leur IP locale.

Si ça marche avec localhost:7000 par exemple c'est l'IP qui coince si ça ne marche pas c'est le port....enfin je crois 🙄

 

 

[Jeff777]

Retour pour ceux que ça intéresse après nombreux essais avec dd5992 par MP.

La solution de dd5992 qui consiste à ajouter deux entrées AAAA pour désigner le syno2 comme serveur de nom, complétée par une zone publique sur le syno2 accessible seulement en IPV6 donne satisfaction.

Avec .htaccess et reverse proxy sur chaque syno on peut se connecter sur les périphériques et sur dsm, applis syno1 et dsm, appli syno2 (à condition que le syno en question soit présent bien sûr) ceci dans les trois cas de figures (syn1,syno2,syno1 et 2 connectés).

Dans ce cas la zone du syno2 n'est pas répliquée sur le dns secondaire il ne peut y avoir qu'une seule zone publique apparemment, celle du syno1. Par contre le zonemaster avec les deux syno est correct avec quelques "warning" en plus des remarques habituelles sur le DNSSEC et l'enregistrement PTR de ns.nnd en IPV6:

Le zone master avec un seul syno a logiquement des points critiques concernant l'impossibilité de joindre le serveur de nom ns.ndd en ipv6 lorsque syn2 est down et en IPV4 lorsque syno1 est down.

 

Reste à voir si la situation avec seulement le syno2 est stable même à l'expiration des TTL du DNS secondaire. Mais cette situation est un mode dégradé qui n'est pas sensé durer une journée.

Modifié le 9 juin 2019 par Jeff777

[Hitman_11]

Bonjour,

Je suis dans le même cas.

Comme indiqué plus haut j'ai tenté de créer une entré CNAME nnd1 vers nnd2 et je me trouve avec ce message d'erreur.

 

 

[.Shad.]

On ne peut pas CNAME un domaine racine vers un autre domaine racine (un domaine racine est SOA (Start of Authority) de son domaine et doit donc pointer vers une adresse IP, ce sont des conventions).
Tu peux en revanche faire par exemple :

www.ndd.fr            CNAME            ndd.net
ndd.net               A                1.2.3.4

Aucun lien avec le proxy inversé ici par contre, il suffit de configurer les entrées telles qu'on les attend, c'est plutôt un problème de DNS.