[TUTO] DNS Server

[oracle7]

@Vinky

Bonjour,

C'est bon maintenant, j'ai trouvé mon erreur.

En fait c'était dans la définition du NS en ressources. Il ne fallait pas mettre l'@IP inversée complète mais juste les 3 premiers "octets". Soit "2.168.192.in-addr.arpa   NS   86400   ns.ndd.tld" et là çà passe.

La résolution inverse marche :

Citation

/volume1$ nslookup 192.168.2.10
Server:        192.168.2.1
Address:    192.168.2.1#53

10.2.168.192.in-addr.arpa    name = nas1.ndd.tld.

Cordialement

oracle7😉

[PiwiLAbruti]

@oracle7 Comme je l'ai déjà dit, la résolution inverse présente peu d'intérêt à part pour quelques rares protocoles qui s'en servent pour de la sécurité (et c'était d'ailleurs particulièrement lourdingue en terme de performances).

@Vinky La commande nslookup permet de résoudre presque tous les types d'enregistrements DNS et pas uniquement les types les plus courants (A, AAAA, et CNAME).

[olilitje]

Le 29/01/2017 à 01:58, Fenrir a dit :

N'oubliez pas de modifier votre serveur DHCP pour qu'il renseigne vos clients sur l'adresse de votre serveur DNS.

Bonjour,

Peut-on m'aider et donner des informations détaillées à cette étape ? (à la fin de l'explication sur le cache DNS local)

Merci !

[maxou56]

Il y a 19 heures, olilitje a dit :

Peut-on m'aider et donner des informations détaillées à cette étape ?

Bonsoir,

Pour que appareils utilisent le serveur DNS, il faut renseigner l'IP de celui-ci.

Donc soit tu modifis manuellement sur chaque appareil le DNS, pour mettre l'IP du serveur DNS.

Soit tu modifis l'IP du DNS dans le serveur DHCP, pour qu'il soit distribué automatiquement aux différents périphériques.

C'est la box internet qui attribue les IP?

Si oui il faut modifier son serveur DHCP pour mettre en 1 l'IP du serveur DNS et laisser le 2 vide.

Par contre sur certaines box ce n'est pas possible, ou c'est incompatible avec des fonctions (décodeur TV...).

Modifié le 4 septembre 2020 par maxou56

[Sudo]

Le 30/01/2017 à 19:28, Fenrir a dit :

Personne n'a testé mon tuto pour le moment ?

@Mic13710 Dans ton cas niveau perf, comme c'est ton er-x qui fait le travail, tu ne devrais effectivement pas avoir bcp de pertes, mais ça reste dommage.

 

Bonsoir @Fenrir, je suis entrain d'essayer le nas juste pour le réseau local.

ci-joint, une capture d'écran du fichier que j'obtiens quand je fais nslookup nas-forum.com 192.168.178.250 ( Adresse de mon nas, j'ai la rréponse ci-dessous :

C:\>nslookup nas-forum.com 192.168.178.250
Serveur :   UnKnown
Address:  192.168.178.250

Réponse ne faisant pas autorité :
Nom :    nas-forum.com
Address:  94.23.33.37

C:\>

la, je ne sais pas si cela fonctionne ou pas. je veux juste me limiter au dns local.

[PPJP]

Bonsoir

Votre DNS serveur fonctionne correctement.

[maxou56]

Il y a 18 heures, Sudo_Root a dit :

je suis entrain d'essayer le nas juste pour le réseau local.

nslookup nas-forum.com 192.168.178.250

Bonsoir,

En spécifiant l'ip pour nslookup cela teste un serveur DNS (correspondant à l'IP indépendamment du DNS configuré), cela  ne signifie pas que c'est bien celui-ci qui est utilisé par le réseau.

Modifié le 23 octobre 2020 par maxou56

[Sudo]

Le 23/10/2020 à 20:36, maxou56 a dit :

Bonsoir,

En spécifiant l'ip pour nslookup cela teste un serveur DNS (correspondant à l'IP indépendamment du DNS configuré), cela  ne signifie pas que c'est bien celui-ci qui est utilisé par le réseau.

Bonsoir @maxou56

je viens de refaire un autre test comme tu peux le voir sur la capture ci-dessous.

la première a été faite le DNS sur le nas en arrêt

et la deuxieme commande avec le DNS fonctionnel sur le nas.

 

est ce à dire que le DNS fonctionne `?

[.Shad.]

maison.fritz.box c'est l'adresse de ton NAS ? ou de ta fritzbox ?
 

[Sudo]

Il y a 6 heures, .Shad. a dit :

maison.fritz.box c'est l'adresse de ton NAS ? ou de ta fritzbox ?
 

Bonjour @.Shad..

j'ai deux routeurs sur mon réseau.

celui du fournisseur qui est s’appelle fritz.box

et le deuxième qui a pour nom Maison. et c'est lui qui est utilisé dans mon réseau

Modifié le 26 octobre 2020 par Sudo_Root

[Toukite]

Bonjour,

Je possède un synology sur lequel j'ai suivi les différents tuto du forum (sécurité, vpn, dns, reverse proxy).

Jusqu'à la semaine dernière, j'étais chez Free et avais une ip fixe. J'ai également un ndd chez OVH qui pointait vers mon ip fixe.

Je pouvais taper n'importe quel service de mon nas (par exemple filestation), avec l'url file.ndd.com, et ce peu importe ma connexion (local, externe, vpn), bref, tout allait bien !

Jusqu'à aujourd'hui, en passant chez Orange et une ip dynamique, où je rencontre un comportement étrange après reconfiguration (utilisation du dyndns ovh, et redirection des ports sur la livebox, ...):

si je suis chez moi en wifi et que je tape file.ndd.com, le nas a l'impression que je le tape depuis l'extérieur avec l'ip publique de ma box, alors qu'avant, il comprenait que j'avais une ip locale 192.168.x.x

Conséquence: le pare-feu (ou bien les profils d'accès du reverse proxy si je coupe le pare-feu) bloquent.

Même problème lorsque j'active le vpn depuis mon tel par exemple, je me connecte, pas de pb, mais il ne considère pas que mon tel fait partie du réseau local (donc toutes les règles où j'ai autorisé les ip 10.0.0.0/255.0.0.0 comme on voit sur les tuto, il s'en fou, car pour lui je viens de l'extérieur).

La seule modif effectuée c'est le changement de box donc c'est forcément lié à ça, mais je n'arrive pas à comprendre ce comportement, si quelqu'un peut m'expliquer ce serait génial !

En espérant ne pas avoir été trop fouilli dans ma description du problème :)

Merci d'avance !

[.Shad.]

Ta box ne gère simplement pas le loopback. C'est ce qu'un serveur DNS est entre autres choses sensé corriger.

Vu que c'est le sujet dans lequel tu poses ta question, est-ce que tu as bien mis en place une zone de résolution locale, et est-ce que c'est bien l'adresse IP locale du NAS qui est poussée par ton serveur DHCP à ses clients ?

[Toukite]

Merci pour cette réponse rapide !

Donc si je comprends bien, quand un périphérique connecté sur le réseau domestique n'est pas reconnu en tant que périphérique local, mais en temps que périphérique extérieur, cela revient à dire que la box ne gère pas le loopback, c'est ça ?

Ce qui est étrange, c'est qu'à des endroits comme ici (https://lafibre.info/orange-les-news/le-loopback-sur-les-livebox-5/), ils disent que le loopback est géré par la Livebox 5 depuis la récente v3.3.14, et j'ai vérifié, j'ai bien cette version là.

Bref, quoi qu'il en soit, je comprends que je peux m'affranchir de ce pb en finalisant correctement ce tuto de DNS Server.

Pour le moment, seule la partie 1 (cache DNS local) est réalisée (elle l'était déjà avant le changement de box). Mais j'ai l'impression que ce n'est plus pris en compte avec la nouvelle box, je pense que ça vient de cette phrase: "N'oubliez pas de modifier votre serveur DHCP pour qu'il renseigne vos clients sur l'adresse de votre serveur DNS.", pour laquelle j'avoue ne pas bien savoir ce qu'il faut faire (je n'avais rien eu à faire avec la freebox revolution). Aujourd'hui, le DHCP de la LB 5 ne semble pas paramétrable, et je n'ai rien fait de particulier sur le DHCP côté synology (j'ai peut-être loupé un morceau de tuto ?)

Sinon, j'ai essayé après changement de box de faire la partie 2 (zone DNS locale) que je n'avais pas fait avant, mais j'ai l'impression que quoi que je mette dans le paramétrage, ce n'est pas pris en compte.

Merci encore pour le coup de main !

[.Shad.]

Vu que ta box est ton serveur DHCP, elle attribue des IP aux périphériques locaux qui en font la demande, mais pas seulement, elle fournit aussi une adresse de passerelle (qui permet aux périphériques de s'émanciper du réseau local, c'est la box elle-même qui joue ce rôle) et des serveurs DNS.

Normalement, tu dois avoir un onglet dans ta box qui te permet a minima de savoir quels sont les IP qui sont fournis aux clients DHCP. Si tu veux que tes clients utilisent le serveur DNS du NAS, il faut que son IP soit celle renseignée dans la partie Serveur DNS primaire des réglages du serveur DHCP.

En l'état de ta mise en place, ça va te permettre de bénéficier d'un cache, c'est-à-dire que lorsque tu vas aller sur mettons www.clubic.com, le serveur DNS va interroger les serveurs que tu as mis dans les adresses de redirection, car évidemment ton petit NAS n'est pas en mesure de savoir par lui-même quelle est la ou les IP de www.clubic.com

Il va stocker l'IP renvoyée dans le cache, et pourra répondre de lui-même lorsque d'autres clients lui poseront la question.
Alors évidemment, quand tu demandes xxx.synology.me, ton serveur DNS ne sait pas quoi en faire, vu que la zone DNS qui régit ce domaine est hébergée sur les serveurs de Synology. L'utilisation d'un DDNS permet de dire que cette adresse correspond à ton IP publique.

C'est là qu'intervient le loopback. Si c'est ta box qui fait office de serveur DNS pour tes clients, elle va remarquer qu'elle émet une requête depuis ton IP publique, et qu'en réponse on lui renvoie son IP publique, et donc elle va s'affranchir de sortir du réseau et te renvoyer directement vers le bon périphérique de ton réseau local (en se basant sur les règles de NAT).

Si tu n'as pas de loopback, et bien tu continueras de passer par Internet tant que tu utilises le nom de domaine Synology.
Si tu mets en place une zone locale, tu vas pouvoir dire toi même que xxx.synology.me correspond non pas à ton IP publique, mais à l'IP privée de ton NAS 192.168.x.x

Toutes les requêtes que le serveur DNS du NAS ne sera pas capable de résoudre par lui-même continueront d'être renvoyées vers les redirecteurs.

TL;DR : Il te faut comprendre pourquoi tu n'arrives pas à exploiter le loopback de ta box, peut-être une option à cocher ?Autrement, il te faut arriver à définir l'IP de ton NAS comme serveur DNS dans les réglages de ton serveur DHCP. Et mettre en place une zone locale xxx.synology.me pour résoudre localement les adresses qui doivent l'être.

[Drickce Kangel]

Hello à tous,

J'ai pu réaliser de précédent tuto avec succès (VNP, Sécu, Reverse proxy, Certificat).

Celui-là, je ne sais pas pourquoi mais je me mets une pression car je me rends compte que je ne maîtrise pas du tout.

Avant de me lancer, j'aimerai être sûr et faire un récap avec vous pour m'assurer que j'ai quand bien compris ce qu'il faut faire.

Pour info, je suis chez Free avec une IP Fixe.

Donc, si je comprends bien je dois:

1. Paramétrer mon DHCP Local
2. Paramétrer mon DNS
3. Désactiver le DHCP de Free une fois que tout est "ok"

Là où je me perd un peu, c'est surtout au niveau des IPs, entre IP fixe, IP DNS, IP VPN, IP, IP....

Est-ce que c'est possible que quelqu'un qui a fait le tuto avec Freebox révolution m'accompagne sur ce sujet?

Merci d'avance

 

[.Shad.]

Le 07/12/2020 à 13:35, Drickce Kangel a dit :

Pour info, je suis chez Free avec une IP Fixe.

Donc, si je comprends bien je dois:

1. Paramétrer mon DHCP Local
2. Paramétrer mon DNS
3. Désactiver le DHCP de Free une fois que tout est "ok"

Salut,

Le DHCP ne sert qu'à fournir l'IP de ton NAS (qui héberge une zone DNS) comme DNS primaire à ses clients (dans l'absolu ça fait bien d'autres choses, mais dans le cas qui t'intéresse j'entends).
La plupart des box ne permettent même pas changer les DNS que le DHCP (celui de la box) distribue, ce qui n'est pas le cas des Freebox de ce que j'ai pu voir, c'est une très bonne nouvelle.
D'un point de vue DHCP tu auras juste à préciser comme DNS primaire (dans les paramètres du serveur DHCP de la box !! pas les paramètres DNS de la box) l'IP de ton NAS. Et tous les périphériques qui obtiennent leur IP via DHCP utiliseront le NAS comme serveur DNS local.

Le DNS est sûrement le tutoriel le plus dur à comprendre dans son entièreté sur ce forum, prend le temps de te renseigner comme le préconise Fenrir sur la signification des nombreux termes relatifs au protocole DNS. Les consignes seront déjà moins obscures. 🙂 

Modifié le 15 décembre 2020 par .Shad.

[Drickce Kangel]

il y a 3 minutes, .Shad. a dit :

Salut,

Le DHCP ne sert qu'à fournir l'IP de ton NAS (qui héberge une zone DNS) comme DNS primaire à ses clients (dans l'absolu ça fait bien d'autres choses, mais dans le cas qui t'intéresse j'entends).
La plupart des box ne permettent même pas changer les DNS que le DHCP (celui de la box) distribue, ce qui n'est pas le cas des Freebox de ce que j'ai pu voir, c'est une très bonne nouvelle.
D'un point de vue DHCP tu auras juste à préciser comme DNS primaire (dans les paramètres du serveur DHCP de la box !! pas les paramètres DNS de la box) l'IP de ton NAS. Et tous les périphériques qui obtiennent leur IP via DHCP utiliseront le NAS comme serveur DNS local.

Le DNS est sûrement le tutoriel le plus dur à comprendre dans son entièreté sur ce forum, prend le temps de te renseigner comme le préconise Fenrir sur la signification des nombreux termes relatifs au protocole DNS. Les consignes seront déjà moins obscures. 🙂 

@.Shad. tu as complètement raison. Merci du conseil car je me suis locké hors de mon NAS m'obligeant à une réinitialisation de DSM. Du coup, effectivement, je vais vraiment prendre le temps. Me documenter, etc...

[TuringFan]

Bonjour à tous et joyeuses fêtes de fin d'année,

J'ai suivi ce tutoriel avec succès mais je me permets je me rends compte aujourd'hui qu'après avoir pensé le comprendre à l'époque je n'en avais qu'une vision partielle. Je viens donc affiner ici ma compréhension du sujet.

Je ne m'attends pas à une réponse exhaustive sur toutes mes questions mais agrégats des morceaux de réponses des uns et des autres me permettra d'avancer.

Description de ma configuration :

• FAI : Orange fibre particulier via Livebox (IP dynamique)
• Routeur Synology en DMZ de ma LiveBox avec redirection de ports dont 80 et 443
• NAS Synology derrière le routeur avec ports ouverts dont 80 et 443
• Serveur DNS avec définition d'une zone locale sur le Routeur avec des redirections de type A depuis des URL en "service.ndd.tld" vers le NAS
• Zone DNS publique définie chez mon Registrar (OVH) avec les redirections équivalentes : de type CNAM depuis des URL en "service.ndd.tld" vers "ndd.tld"  
• DynDNS définie chez mon registrar (OVH) et sur mon Routeur
• Web station installé sur le NAS
• Redirection HTTP vers HTTPS désactivée sur le NAS
• HTTP/2 activé sur le NAS
• Reverse proxy qui passe en entrée soit par le port HTTP 80 soit par le port HTTPS 443 puis pointe vers des ports HTTP pour chaque service (avec parfois une restriction de profil qui impose une IP VPN/LAN)

J'ai également un fichier php à la racine de Webstation (/web/index.php) :

<?php
$http_host = $_SERVER['HTTP_HOST'];
// 307 Temporary Redirect
header("Location: https://$http_host",TRUE,307);
exit;
?>

Mes questions :

1. Est-ce utile d'avoir un DDNS chez OVH et sur mon routeur ?
    
2. Mon routeur étant en DMZ de la Livebox est-il nécessaire de créer sur ma Livebox des règles de transferts de ports type NAT/PAT ? Je pensais initialement que non mais je commence à douter au regard de mes dernières lectures. Si oui et dans l'hypothèse de vouloir atteindre un service hébergé sur mon NAS faut il (i) créer des règles de transfert vers mon routeur qui possèdera lui même les mêmes règles de transfert vers le NAS ou (ii) créer des règles de transfert directement vers mon NAS ?
    
3. J'accède souvent à mes services via différents canaux : portail web et/ou clients mobile et/ou clients PC. Je croyais que le reverse proxy permettait une redirection "totale" des flux or je commence à comprendre (i) que les clients mobiles/PC demandent parfois l'ouverture de ports spécifiques en plus du reverse proxy (ex : port 6690 pour Drive sur PC) et que (ii) même avec un accès portail web fonctionnel pour un service, des ports spécifiques doivent parfois être ouverts pour permettre la pleine utilisation du service (ex : activation des ports SMTP / IMAP / POP3 pour l’hébergement d'un serveur de messagerie).
   1. Est il possible de tout faire passer par le port de reverse proxy (y compris 6690, SMTP/IMAP/POP3 dans mes exemples) ?
   2. Est-il possible de "court-circuiter" l'entrée en HTTPS du reverse proxy pour atteindre les applications via ces ports spécifiques qui sont peut être moins sécurisées ?
   3. On dit souvent le port HTTP est moins sécurisé que le port HTTPS grâce aux mécanismes de certificats. Qu'en est il de ces ports spécifiques : sont ils plus ou moins sécurisés que les ports sources HTTP/HTTPS du reverse proxy ?
       
4. J'accède via mon reverse proxy et le port HTTPS à DSM (interface du NAS) via "nas.ndd.tld" et à RSM (interface du Routeur) via "rt.ndd.tld" et j'ai remarqué qu'en tapant "rt.ndd.tld" dans un navigateur cela fonctionnait sans problème et que la redirection vers "https://rt.ndd.tld:8001" se faisait automatiquement. En revanche en tapant "nas.ndd.tld" j'arrive vers une page d'erreur de Web Station : je dois alors taper "https://nas.ndd.tld" pour que cela fonctionne.
   1. Pourquoi une t-elle différence de comportement ?
   2. Pourquoi l'URL du Routeur fait elle apparaitre un numéro de port et pas celle du NAS ?
       
5. In fine, dans l'hypothèse ou je souhaite pouvoir atteindre mes services hébergés sur le NAS indifféremment depuis le WAN/VPN/LAN.
   1. Quelles sont les règles que je dois utiliser dans les champs URL des navigateurs et dans les formulaires de connexions des clients PC/mobiles ?
   2. J'ai en effet tendance à utiliser "service.ndd.tld" systématiquement mais je constate pour les clients que parfois le port doit être précisé et parfois "nas.ndd.tld" est suffisant : pourquoi ? 

Merci d'avance à tous,

[oracle7]

@TuringFan

Bonjour,

Je te donne ici ma vision des choses, mais je peux me tromper et avoir mal compris/assimilé certaines notions, aussi j'espère que l'on me corrigera pour fournir la bonne explication.

1 - Quand le routeur ou le NAS sur le quel le DDNS est configuré, constate/détecte un changement d'@IP externe, il informe automatiquement le DynDNS chez OVH qui prend en compte cette nouvelle @IP externe afin que ton domaine pointe dorénavant sur cette nouvelle @IP externe. Voilà le mécanisme de façon très simpliste.

2 - Comme toi, je le croyais aussi mais à l'usage, force est de constater qu'il faut tout de même faire du NAT vers le routeur qui lui transférera de la même façon vers le NAS les ports en question. Tu ne peux pas faire du NAT "direct" de la LB vers le NAS car la LB ne voit pas le NAS puisqu'ils ne sont pas tous les deux sur le même sous-réseau.

3 - Certaines applications, pour leur propre fonctionnement interne, nécessitent des ports particuliers (Drive, MailPlusServer, etc...) ouverts dans le pare-feu du Routeur et/ou du NAS. L'usage de ces ports particuliers, est à dissocier du flux "courant" de données lié à ces applications et passant par leurs ports "standards". Du coup, pour Q3.1 et Q3.2 : Non.

Pour Q3.3 : la doc Synology n'est pas très explicite sur le sujet, mais j'imagine que la communication interne via ces ports est toute aussi sécurisée que l'application elle-même, non ? Sinon l'application en elle-même pourrait présenter des failles qui auraient déjà été exploitées depuis longtemps par des malfaisants, et je pense que cela se saurait ...

4 - Même constat chez moi, la différence de comportement ne serait-elle pas dûe à DSM et SRM eux même, certes très proches mais différents quand même sur certains points de part la nature de leur fonction respective.

Q4.1 : Je n'ai pas d'explication, du moins je ne la connais pas.

Q4.2 : Pareil : j'imagine que c'est aussi lié à la différence entre SRM et DSM.

5 - Q5.1 : En tout cas, pour les applications mobiles c'est un fait : il faut ajouter le port à l'URL. Mais quand on l'as compris, à mon humble avis, ce n'est pas si contraignant que cela.

Q5.2 : Je ne sais pas.

Cordialement

oracle7😉

[.Shad.]

il y a 11 minutes, oracle7 a dit :

2 - Comme toi, je le croyais aussi mais à l'usage, force est de constater qu'il faut tout de même faire du NAT vers le routeur qui lui transférera de la même façon vers le NAS les ports en question. Tu ne peux pas faire du NAT "direct" de la LB vers le NAS car la LB ne voit pas le NAS puisqu'ils ne sont pas tous les deux sur le même sous-réseau.

Quand un périphérique A met dans sa DMZ un périphérique B, tous les ports qui ne sont pas par ailleurs redirigés par A vers un autre périphérique sont redirigés automatiquement vers B. Donc il n'y aucun besoin de faire du NAT pour un périphérique dans une DMZ, c'est redondant et donc inutile.

il y a une heure, TuringFan a dit :

Est il possible de tout faire passer par le port de reverse proxy (y compris 6690, SMTP/IMAP/POP3 dans mes exemples) ?

Pas que je sache, tout simplement parce que certaines requêtes émises à l'extérieur de ton réseau s'attendent à trouver un port donné à destination : 25, 587, etc...

Il y a 2 heures, TuringFan a dit :

Est-il possible de "court-circuiter" l'entrée en HTTPS du reverse proxy pour atteindre les applications via ces ports spécifiques qui sont peut être moins sécurisées ?

Ca dépend d'où tu regardes, depuis un PC local rien n'empêche de le bypasser pour les applications Synology.
En IPv4 depuis l'extérieur le NAT remplit ce rôle de frontend.

Je crois qu'il y a un gros malentendu sur la définition de port sécurisé, le port HTTPS l'est par défaut pour de la navigation. Le port 54256 peut parfaitement l'être aussi... tant que j'ai un certificat serveur à opposer au client, muni ou non d'un certificat lui aussi. Un peu de lecture : http://www.steves-internet-guide.com/ssl-certificates-explained/
Le port 6690 utilisé par Synology Drive se fait sur base d'une transaction TLS, donc le transfert des informations est chiffré.

Il y a 2 heures, TuringFan a dit :

• Pourquoi une t-elle différence de comportement ?
• Pourquoi l'URL du Routeur fait elle apparaitre un numéro de port et pas celle du NAS ?

C'est que le routeur fait une redirection automatique, case que l'on conseille de décocher dans le NAS quand on met en place un proxy inversé.
Pour le NAS, nas.ndd.tld est sensé t'amener vers quoi ?

Il y a 3 heures, TuringFan a dit :

In fine, dans l'hypothèse ou je souhaite pouvoir atteindre mes services hébergés sur le NAS indifféremment depuis le WAN/VPN/LAN.

1. Quelles sont les règles que je dois utiliser dans les champs URL des navigateurs et dans les formulaires de connexions des clients PC/mobiles ?

 

Je n'ai rien compris. 😝

Il y a 3 heures, TuringFan a dit :

J'ai en effet tendance à utiliser "service.ndd.tld" systématiquement mais je constate pour les clients que parfois le port doit être précisé et parfois "nas.ndd.tld" est suffisant : pourquoi ? 

Si le port de l'application que tu souhaites atteindre est différent du port de base (le cas de toutes les applications DS sauf DS Photo), il faut le préciser car si tu ne mets rien, les applications DS chercheront à atteindre le port dédié. Le domaine que tu entres dans l'applications DS ne suit pas la convention de navigation où pas de port en http = 80 et pas de port en https = 443.

[TuringFan]

Bonjour @oracle7 et @.Shad.,

Avant tout bonne année !

Merci pour vos réponses très utiles.

Le 29/12/2020 à 18:40, oracle7 a dit :

1 - Quand le routeur ou le NAS sur le quel le DDNS est configuré, constate/détecte un changement d'@IP externe, il informe automatiquement le DynDNS chez OVH qui prend en compte cette nouvelle @IP externe afin que ton domaine pointe dorénavant sur cette nouvelle @IP externe. Voilà le mécanisme de façon très simpliste.

Très clair.

Le 29/12/2020 à 18:40, oracle7 a dit :

2 - Comme toi, je le croyais aussi mais à l'usage, force est de constater qu'il faut tout de même faire du NAT vers le routeur qui lui transférera de la même façon vers le NAS les ports en question. Tu ne peux pas faire du NAT "direct" de la LB vers le NAS car la LB ne voit pas le NAS puisqu'ils ne sont pas tous les deux sur le même sous-réseau.

Visiblement notre première interprétation était la bonne selon @.Shad.

Le 29/12/2020 à 18:40, oracle7 a dit :

3 - Certaines applications, pour leur propre fonctionnement interne, nécessitent des ports particuliers (Drive, MailPlusServer, etc...) ouverts dans le pare-feu du Routeur et/ou du NAS. L'usage de ces ports particuliers, est à dissocier du flux "courant" de données lié à ces applications et passant par leurs ports "standards". Du coup, pour Q3.1 et Q3.2 : Non.

Ok. Et sauf erreur de ma part ces ports sont listés ici. Par ailleurs dans la gestion des applications sur le NAS il est possible de choisir un unique port en HTTP et/ou un unique port en HTTPS : je comprends donc qu'il s'agit ici uniquement d'un accès via portail Web donc et que cela n'a rien à voir avec les clients (PC et/ou mobiles). Est-ce exact ?

Par ailleurs d'un point de vue purement théorique il n'y a aucune contre indication à changer le port du moment que l'on reste cohérent dans l'URL utilisé pour atteindre la cible ou la source du reverse proxy (si on en a un) mais en pratique c'est est déconseillé car cela introduit une complexité de gestion sans apport véritable de sécurité (scan de port très rapide). Est-ce Exact ?

Enfin je crois comprendre que l'on peut choisir à sa convenance le HTTP ou le HTTPS pour la source et le destination du reverse proxy mais que l'on opte souvent pour une source en HTTPS et une destination en HTTP (pour ne pas double chiffrer et donc préserver de la performance tout en étant sécurisé). Il existe néanmoins quelques exceptions comme par exemple (la seule que je connais pour le moment) Vidéo Station qui doit utiliser du HTTP car le transcodage fonctionne mal en HTTPS.

Le 29/12/2020 à 18:40, oracle7 a dit :

Pour Q3.3 : la doc Synology n'est pas très explicite sur le sujet, mais j'imagine que la communication interne via ces ports est toute aussi sécurisée que l'application elle-même, non ? Sinon l'application en elle-même pourrait présenter des failles qui auraient déjà été exploitées depuis longtemps par des malfaisants, et je pense que cela se saurait ...

Réponse apportée par @.Shad. ci-dessous.

Le 29/12/2020 à 21:07, .Shad. a dit :

Je crois qu'il y a un gros malentendu sur la définition de port sécurisé, le port HTTPS l'est par défaut pour de la navigation. Le port 54256 peut parfaitement l'être aussi... tant que j'ai un certificat serveur à opposer au client, muni ou non d'un certificat lui aussi. Un peu de lecture : http://www.steves-internet-guide.com/ssl-certificates-explained/
Le port 6690 utilisé par Synology Drive se fait sur base d'une transaction TLS, donc le transfert des informations est chiffré.

Merci, je vais faire cette lecture.

Petite question subsidiaire alors :

• mon port 6690 est ouvert sur mon NAS et transféré par mon Routeur (en DMZ de ma LiveBox fibre)
• j'ai un reverse proxy (sans condition de profil) sur mon NAS dont la source est le port HTTPS 443 et la destination le localhost sur le port 10002 en HTTP
• dans mon client Drive pour PC la cible indiquée est "drive.ndd.tld:6690"
• dans mon client Drive pour mobile la cible indiquée est "drive.ndd.tld"

Aucun problème d'accès via le portail web et/ou le client mobile via une IP WAN/VPN/LAN en revanche sur le client PC la synchronisation ne se fait qu'en IP VPN/LAN, impossible en IP WAN ! Pourquoi ?

Si mon hypothèse précédente sur l'utilisation exclusive d'un reverse proxy pour le HTTP/HTTPS et donc un portail web est juste cela veut il donc dire que je dois utiliser une autre cible dans mon client PC tel que "nas.tld.ndd" (qui pointe vers l'interface du NAS) et/ou ndd.tld qui résout mon IP externe via mon DDNS ?

Pour info j'ai essayé cela sans succès aussi. J'ai donc remonté ce point au support Synology et je suis en attente d'un retour concret.

Le 29/12/2020 à 21:07, .Shad. a dit :

C'est que le routeur fait une redirection automatique, case que l'on conseille de décocher dans le NAS quand on met en place un proxy inversé.

Évidement, j'aurais dû y penser !

Le 29/12/2020 à 21:07, .Shad. a dit :

Pour le NAS, nas.ndd.tld est sensé t'amener vers quoi ?

L'interface de mon NAS : le DSM.

Le 29/12/2020 à 21:07, .Shad. a dit :

Je n'ai rien compris.

Pardon, mal formulé. Je souhaitais savoir d'une façon générale quel format doit avoir l'URL demandée dans la fenêtre de connexion des clients : faut il préciser http/https, le port, etc. ?

Tu as donc répondu après et je comprends qu'il faut toujours construire l'URL sans le http/hhtps, avec l'IP externe (ou le domaine) et avec le numéro de port.

Merci encore à vous deux,

NB : Je vous prie de bien vouloir m'excuser par avance si je dérive trop par rapport au sujet initial et si ce post n'est pas au bon endroit. Dans ce cas indiquez moi ou le mettre et je le déplacerais.

[olivierm83]

Bonsoir tout le monde,

J'aurais une question sur ce sujet de serveur DNS, qui va peut-être vous paraître bête mais je ne suis pas super à l'aise au niveau de la sécurité et réglage du pare-feu.

Pour expliquer la situation, cela fait déjà plusieurs mois que j'essaie de me battre pour mettre en place ce serveur DNS afin de pouvoir accéder à mon NAS via mon nom de domaine et ce que je sois connecté en 4G ou en Wi-Fi sur mon réseau local. J'ai essayé de suivre à la lettre ce tuto mais je n'ai jamais réussi à faire en sorte que cela fonctionne.

J'ai finalement pris la décision de passer le modem routeur de mon opérateur en mode bridge et d'acheter un routeur séparé. J'ai pris un Asus RT-AX82U, car il m'a semblé voir qu'il supportait le loopback et pourrait donc résoudre mon problème.

Malheureusement cela ne fonctionnait toujours pas avec ce nouveau routeur, j'ai donc décidé de remettre les mains à la pâte pour essayer de mettre en place ce serveur DNS sur mon Synology.

N'arrivant toujours pas à faire fonctionner ce serveur DNS, je me suis mis à essayer plusieurs choses et je me suis aperçu que cela fonctionnait si je désactivais le pare-feu sur le Synology.
J'ai donc essayer de comprendre ce qui bloquait dans les paramètres de mon pare-feu. Il me semble avoir enfin compris que mon problème était la plage d'adresse IP local que j'autorisais qui n'était pas configurée correctement.
En fait, mon routeur est réglé pour une plage d'adresse IP allant de 192.168.1.20 à 192.168.1.254 pour le DHCP. J'ai donc réglé le pare-feu de mon Synology selon cette plage, et ce qui fait donc que l'adresse IP de mon routeur n'était pas autorisée étant donné que son adresse IP est 192.168.1.1
Si j'élargie donc cette plage d'adresse IP dans les règles du pare-feu du Synology pour mettre de 192.168.1.1 à 192.168.1.254, tout fonctionne très bien.
Et cela même si je désactive le serveur DNS du Synology via le centre de paquet. Il semble donc que mon nouveau routeur accepte le loopback, mais qu'il fallait que j'autorise son adresse IP dans le pare-feu du Synology.

Mais j'aimerais juste avoir votre avis qui est certainement plus expert que le mien... Est-il bien correcte que je mette l'adresse IP de mon routeur dans la plage d'adresse IP des règles de mon pare-feu sur le Synology?
Je ne prends pas de risque d'attaques supplémentaires qui serait perçue comme ok par le pare-feu car il ne verrait que l'adresse IP de mon routeur?

Désolé si ma question vous parait bête et que c'est logique pour vous. Je ne veux juste pas prendre de risque n'étant pas super au clair de la manière dont fonctionne le routage etc...

Merci d'avance pour votre aide.

Très bonne soirée.

[.Shad.]

Salut,

Ce n'est pas une bête question du tout. Déjà avant tout si une personne malveillante est passée outre ton routeur, c'est qu'elle a visiblement pu accéder à ton réseau wifi. Dans ce cas elle aura une IP dans la plage DHCP et tu ne bloqueras rien du tout avec ta règle actuelle.

Ce que tu peux éventuellement faire, mais ça me semble un peu paranoïaque, c'est faire une réservation d'IP pour tous tes périphériques, et les placer dans une plage déterminée, par exemple à partir de 150. Et établir une règle dans le pare-feu du NAS en adéquation. Les périphériques qui n'auraient pas d'IP réservée seraient incapables d'accéder au NAS. Mais encore une fois je pense que c'est too much.

Si tu as limité l'exposition des services du NAS au strict nécessaire, que tu as désactivé l'uPnP sur ton routeur, mis une clé WPA suffisamment costaud, etc... Tu devrais être tranquille.

Modifié le 19 février 2021 par .Shad.

[olivierm83]

Salut,

Merci beaucoup pour ta réponse rapide.

J'ai une réservation d'adresse IP pour mes périphériques, mais ce n'était pas dans ce but là. C'était simplement pour ne pas avoir de changement d'adresse IP sur certains périphériques sur lesquels cela peut être contraignant (NAS, imprimante, PC-serveur multimédia)

Mais même si je restreins mes règles à la plage d'adresse IP de mes périphériques, il n'empêche que je dois autoriser les même ports pour l'adresse IP 192.168.1.1 de mon routeur pour que cela fonctionne. 

Mon inquiétude était plus sur le fait qu'une attaque ou requête venant depuis internet (donc depuis un appareil non connecté au Wi-Fi) puisse paraître comme provenant de l'adresse IP 192.168.1.1 du point de vue du pare-feu du NAS.

Mais autrement oui, sur le pare-feu j'ai limité les ports autorisés aux services que j'utilise. 
Et ma clé WPA comporte 12 caractères et est jugée d'une qualité de 61 bits (d'après le logiciel Keepass). Je pense que c'est pas trop mal.

L'uPnP était activé sur le routeur, mais je l'ai maintenant désactivé. Pour être honnête, j'ai essayé de lire un article pour comprendre ce qu'apportait l'uPnP, mais je n'ai pas vraiment compris quelles fonctionnalités ou possibilités j'allais "perdre" en le désactivant.

Enfin merci pour ta réponse, je vais donc laisser l'adresse IP de mon routeur dans les règles de mon pare-feu et comme ça mon problème d'accès via le nom de domaine est résolu.

Merci pour cette confirmation.

Très bonne soirée

[.Shad.]

L'uPnP permet à un périphérique de demander automatiquement l'ouverture des ports dont il a besoin.
Typiquement une PS4 qui hébergerait une partie de jeu, etc...

Pratique, mais je te laisse imaginer les possibilités pour un malware, il peut ouvrir ton réseau local au monde entier. 😉 

Modifié le 19 février 2021 par .Shad.