Aller au contenu

Messages recommandés

Posté(e)
Il y a 2 heures, PiwiLAbruti a dit :

les requêtes DNS soient chiffrées (DoH, DoT, ...)

Bonsoir,

Pour rebondir est-ce que ça sera un jour possible dans le paquet DNS Server (SRM ou DSM) d'utiliser des DNS chiffrés comme redirecteurs?

Posté(e) (modifié)
il y a 9 minutes, molinadiaz a dit :

Quelle solution de DoT/DoH existe-t-il sur Synology

Sur les routeur (SRM) c'est possible, sauf si on utilise DNS Server 🤔.

Sinon via docker (ou virtualisation) tu devrais pouvoir mettre a place un DoH.

Modifié par maxou56
Posté(e)

@molinadiaz

Bonjour,

Il y a 2 heures, molinadiaz a dit :

EDIT : Y'a vraiment des routeurs qui peuvent physiquement remplacer une box ? Perso, je me suis toujours mis en bridge derrière la box de l'ISP mais j'ai jamais su qu'on pouvait physiquement supprimé la box d'un ISP pour n'avoir qu'un seul et unique périphérique (routeur). C'est possible chez quel ISP, ça ?

Vas voir sur https://lafibre.info tu y trouveras toutes les réponses selon la box donc le FAI :

nlBUIk8.png

Mais ATTENTION c'est vraiment très très "touchy" 🤣 Ce n'est pas pour le premier venu ....

Il y a 2 heures, molinadiaz a dit :

EDIT 2 : après, si mes clients DHCP utilisent actuellement la résolution des noms de mes propres DNS .. qui donc utilise la résolution des noms depuis les DNS de l'ISP ? Le routeur, vraiment ?

Sauf erreur de ma part, il n'y a que le routeur entant que client de ceux-ci MAIS ce n'est pas lui qui fait les requêtes DNS des équipements qui sont derrière lui en aval car le flux de celles-ci ne fait que transiter à travers lui.

Pour protéger ce flux, par exemple sur un routeur Synology RT2600ac, on active la DoH avec un serveur tiers (par exemple NextDNS, regardes aussi les échanges dans le post dont j'ai donné le lien précédemment) et ainsi ton flux de requêtes DNS est crypté entre le routeur et les serveurs DNS de NextDNS, du coup ton FAI ne voit rien de ces requêtes (enfin je l'espère !).

Cordialement

oracle7😉

Posté(e)

@molinadiaz

 J'ai une config avec deux nas  sur le même réseau et je n'ai qu'un seul nom de domaine pour lequel je suis ns et soa. Si j'avais la possibilité de mettre l'un d'eux sur le même réseau je pense que je ferai comme toi avec un deuxième domaine.

Si tu perds un nas les domaines ne sont pas affectés dans l'immédiat mais si cette situation s'éternise tes domaines vont finir par tomber à mon avis. 

Mon routeur ne me demande pas de DNS pour l'accès internet j'ai uniquement ceux du DHCP qui sont les adresses locales de mes nas (depuis que j'ai intégré pihole je l' ai remplacé par l'adresse du raspberry avec les adresses locales des nas en dns).

Dans ton cas tu as les adresses de tes nas dans la config DHCP ce sont tes deux nas, ça c'est pour résoudre les requêtes internes. Comme dis @oracle7 les requêtes externes ne font que transiter par le routeur car elles concernent ton domaine (dans ce cas ce sont tes zones qui font autorité).

Dans la config du routeur je mettrai les même redirecteurs que tu as mis dans DNS serveur FDN Clouflare etc... sinon cela risque de faire yoyo si tu mets à nouveau tes IP des nas.

Posté(e) (modifié)

Si tes nameservers tombent, ce n'est pas juste ton NAS qui n'est plus accessible, mais l'entièreté de tes domaines. Tu utiliserais des logiciels différents j'aurais dit ok. Mais là un bug dans DNS Server et c'est tout ton domaine qui est en échec aux yeux du net.

D'où l'intérêt selon moi de prévoir un serveur de nom délocalisé. Tu auras dans ces conditions une vraie redondance (hésite pas à regarder les recommandations de la RFC 2182).

Enfin comme l'a dit @PiwiLAbruti, oui, ton trafic passe forcément par ton FAI, ils peuvent donc voir les paquets qui transitent depuis ton IP. Reste que comme il l'a dit aussi, il faut une sacrée bonne raison pour qu'ils s'intéressent à toi en particulier. Ce qu'on cherche généralement à éviter c'est le blocage DNS éventuel du FAI (faut pas croire non plus qu'ils te bloquent l'accès à plein de choses hein, c'est pas spécialement dans leur intérêt, c'est plus souvent lié à des décisions de justice (PirateBay par exepare)).

A partir du moment où ton routeur utilise des DNS autres que ceux du FAI, et ton DHCP aussi, l'éventuel filtrage DNS effectué par le FAI ne sera plus d'actualité.

Modifié par .Shad.
Posté(e)
Il y a 14 heures, .Shad. a dit :

Enfin comme l'a dit @PiwiLAbruti, oui, ton trafic passe forcément par ton FAI, ils peuvent donc voir les paquets qui transitent depuis ton IP.

Mais si le serveur  DNS est derrière un routeur en DMZ, le FAI ne voit pas les requêtes DNS je suppose, celui qui les voit est le serveur DNS de secours défini dans DNS Server. Je ne voudrais pas que mon FAI sache que je me connecte à Pornhub 😍

Posté(e)
Il y a 16 heures, maxou56 a dit :

[...] est-ce que ça sera un jour possible dans le paquet DNS Server (SRM ou DSM) d'utiliser des DNS chiffrés comme redirecteurs?

J'attends toujours qu'on m'offre une boule de cristal 😄, mais le plus efficace est de faire une demande d'amélioration à Synology pour tenter d'accélérer les choses :

Pour ma part, j'attends que FDN mette en ligne ses serveurs DoT pour commencer à me pencher sur le sujet :

Il y a 16 heures, molinadiaz a dit :

Quelle solution de DoT/DoH existe-t-il sur Synology ? J'ai entendu parler de "DNSCrypt" aussi. Une piste ?

Le plus efficace pour le moment est d'utiliser un relai DNS supportant DoT (via Docker) comme pihole-dot.

DNSCrypt n'a pas fait l'objet d'une standardisation (RFC) contrairement à DoT et DoH, et il est moins fiable que DoT donc on peut l'oublier.

Il y a une liste assez exhaustive des services DNS supportant DNSCrypt, Dot, DoH, ... sur le site de AdGuard :

il y a une heure, CyberFr a dit :

Mais si le serveur  DNS est derrière un routeur en DMZ, ...

Un serveur DNS local est toujours amené à résoudre des enregistrements qu'il ne connaît pas. Il utilise donc ses redirecteurs, donc ces requêtes sont visibles par le FAI.

Posté(e) (modifié)

Bonjour,

On avance. Le DNS du réseau Paris contient 2 zones locales :

  1. domain1.tld
  2. domain2.tld

Depuis le réseau Wi-Fi Madrid, lorsque j'accède via OpenVPN au réseau Paris avec Windows 10 :

  1. résolution domain1.tld OK
  2. résolution domain2.tld OK

Toujours depuis le réseau Wi-Fi Madrid, lorsque j'accède via OpenVPN au réseau Paris avec Android :

  1. résolution domain1.tld OK
  2. résolution domain2.tld PAS OK (d'ailleurs, la résolution de l'IP privée non plus !!)

Pourtant, les connexions VPN sur Windows 10 et Android utilisent le même fichier .ovpn. Une idée d'où ça pourrait provenir ? J'ai le sentiment que la gestion des cartes réseaux virtuelles se fait pas de la même manière sur Windows que sur Android. Et que ça pourrait provenir de ça.

EDIT : pour que ça fonctionne sur Android, je dois commenter (avec un "#") la ligne redirect-gateway def1. À ce moment-là, je peux résoudre les 2 domaines mais c'est embêtant car je ne bénéficie pas de l'IP publique distante. Pas d'autre solution ?

Modifié par molinadiaz
Posté(e)
il y a 30 minutes, molinadiaz a dit :

résolution domain2.tld PAS OK (d'ailleurs, la résolution de l'IP privée non plus !!)

Bonjour,

Vérifie dans ton serveur VPN de Paris quelle est ton adresse de connexion.

Posté(e)
il y a 7 minutes, Jeff777 a dit :

Vérifie dans ton serveur VPN de Paris quelle est ton adresse de connexion.

J'ai bien l'IP publique IPv4 du réseau Madrid dans les 2 cas (Windows ou Android). Le soucis étant partiellement réglé depuis que j'ai commenté la ligne redirect-gateway def1 pour la connexion VPN depuis Android, je pense en déduire que :

  1. Madrid étant sur le sous-réseau 192.168.0 ..
  2. Et Paris étant sur le sous-réseau 192.168.1 ..

La ligne décommentée (et donc active !) redirect-gateway def1 fait en sorte que le serveur de destination doit être utilisé comme passerelle par défaut pour les clients. Avec Windows, pas de problème puisqu'il y a 2 cartes réseau (la physique + la virtuelle OpenVPN). Mais Android, ne gérant possiblement pas les cartes réseaux de la même manière qu'un Windows, ne parvient pas à faire en sorte de joindre la passerelle distante puisqu'elle n'est pas sur le même sous-réseau ! Mon raisonnement semble-t-il correct ?

Le meilleur moyen de s'en rendre compte serait encore de tout mettre sur le même sous-réseau 192.168.0 OU 192.168.1 et de refaire le test.
 

Posté(e)

@molinadiaz

Bonjour,

Pour ton information, voilà ce qui ce passe selon que la ligne "#redirect-gateway def1" est commentée (avec #) ou non :

  • Commentée --> VPN Split-Tunnel : le trafic n'est envoyé via votre réseau que s'il tente d'accéder à une ressource interne. Votre adresse IP lorsque vous naviguez vers un site en dehors de votre réseau sera l'adresse IP du réseau sur lequel vous vous trouvez actuellement.
     
  • Non commentée --> VPN Full-Tunnel : tout le trafic est envoyé via votre réseau domestique. Votre adresse IP pour les requêtes internes et externes sera votre réseau domestique.

En clair cela donne ceci :

pCwMdjy.png

Ceci peut expliquer la différence de comportement que tu rencontres. Maintenant ce que j'en dit ...

Cordialement

oracle7😉

Posté(e) (modifié)

Bonjour @oracle7,

Oui, je n'ai pas de problème de compréhension vis-à-vis des 2 notions. C'est simplement Android qui ne gère pas de la même manière que Windows. Cela semble se vérifier.

EDIT : Et pour preuve ..

Depuis Windows via OpenVPN, mon sous-réseau 192.168.0 est accessible quand je suis connecté sur la passerelle en 192.168.1. La carte réseau virtuelle OpenVPN du Centre Réseau & Partage permet cela.

Sur Android, mon sous réseau 192.168.0 n'est pas accessible quand je suis connecté sur la passerelle en 192.168.1.

Modifié par molinadiaz
Posté(e)

@molinadiaz

Bonjour,

OK, pas de soucis.

Par ailleurs, une petite relecture du TUTP VPN server indique ceci :

Citation

Si vous souhaitez pouvoir accéder à votre NAS, une imprimante IP, une caméra de surveillance, ... via le VPN, vous avez 2 possibilités :

  • vous définissez la connexion VPN comme itinéraire par défaut : c'est simple mais tout le trafic passera par là, avec une connexion fibre à la maison ce n'est pas trop grave, mais en ADSL c'est lent
  • vous spécifiez que tout le trafic à destination de votre réseau local, mais pas le reste, doit passer par le VPN => il faut ajouter une route dans la configuration de votre client
    • Android : c'est à faire dans la configuration de la connexion VPN (tout en bas dans les paramètres de la connexion)
    • iOS : ce n'est pas possible sauf en jailbreak
    • Linux/MacOS : ip route add 192.168.0.0/24 via 10.2.0.0
    • Windows : route add 192.168.0.0 mask 255.255.255.0 10.2.0.0

Peut-être une piste à suivre ...

Cordialement

oracle7😉

Posté(e) (modifié)

@molinadiaz

Bonjour,

Qu'il faille que les deux NAS soient sous un même réseau ne me choque pas plus que cela, au contraire cela me paraît même logique quelque part. Mais en fait, tes serveurs Paris et Madrid sont chacun sur un sous-réseau de la plage 192.168.1.0 (ou 192.168.0.0) mais ils n'en sont pas moins sur des sous-réseaux différents stricto sensus vus qu'ils sont sur des machines distinctes géographiquement, non ?

L'astuce est plutôt dans le fait d'utiliser des @IP dans la même plage, ce qui fait qu'elles sont automatiquement reconnues comme faisant partie de l'un ou l'autre sous-réseau selon comment on les atteint. Je ne sais si je m'exprime bien ...

Sinon, je ne saisi pas bien cette différence d'interface TUN/TAP pour Android.

De ce que je crois avoir compris de ces notions : TUN nous apporte un réseau "tunnelé" et l'interface virtuelle TAP un appareil. En clair, on passe par un réseau "tunnelé" pour atteindre un autre réseau.

Par exemple, lors de la configuration d'un réseau OpenVPN, on reçoit le 10.8.0.6 sur notre client. Le serveur VPN 10.8.0.1 achemine notre demande vers un autre réseau (par exemple 192.168.xx.0/24) derrière et lorsque on utilise TAP, on reçoit l'@IP (192.168.10.10/24) de l'appareil directement de notre réseau cible (192.168.10.x/24).

Sinon, j'ai trouvé cela en complément de ton précédent lien :
 

Citation

 

Une interface TAP est également un nouveau périphérique virtuel de couche 2 mais sans couche 1 qui lui est attachée. Au lieu de cela, un programme peut obtenir un descripteur de fichier représentant la couche physique. Il peut ensuite écrire des données de trame Ethernet brutes dans ce descripteur de fichier et le noyau les traitera comme tout autre paquet Ethernet qu'il reçoit sur une véritable interface physique.

La grande chose au sujet des interfaces TAP est que la couche physique est en mode utilisateur; n'importe quel logiciel avec les autorisations appropriées peut générer des trames Ethernet comme bon lui semble et les insérer dans quelque chose que le noyau traite de la même manière qu'une véritable interface physique. Cela les rend très utiles pour des choses comme les VPN et le tunneling; vous pouvez écrire n'importe quel type de logiciel de tunneling que vous aimez dans l'espace utilisateur et il n'est pas nécessaire de se mêler de l'espace du noyau pour obtenir les trames dans la pile réseau, il vous suffit de créer un périphérique TAP et d'écrire les trames dans son descripteur de fichier.

Les périphériques TUN sont exactement comme les périphériques TAP, sauf qu'ils fonctionnent sur la couche 3 au lieu de la couche 2 et que le logiciel en mode utilisateur doit écrire des paquets IP bruts dans le descripteur de fichier au lieu de trames Ethernet brutes.

 

Un autre lien intéressant ici.

Cordialement

oracle7😉

 

Modifié par oracle7
Posté(e)
il y a 11 minutes, oracle7 a dit :

Mais en fait, tes serveurs Paris et Madrid sont chacun sur un sous-réseau de la plage 192.168.1.0 (ou 192.168.0.0) mais ils n'en sont pas moins sur des sous-réseaux différents stricto sensus vus qu'ils sont sur des machines distinctes géographiquement, non ?

Je suis d'accord avec ça. Mais je vois un autre problème comment est-il possible de faire deux zones privées sur le NAS Paris?

Avec le domaine1 qui est celui du nas je comprends bien mais avec le domaine2 ????

Posté(e)
à l’instant, PiwiLAbruti a dit :

Il suffit de diffuser domaine2 dans une vue différente, non ?

J'aurai fait une zone publique. Une zone privée vers un domaine externe je vois pas trop comment la configurer.

Posté(e)

Hello, je souhaitais savoir si l'un de vous avait expérimenté des problèmes avec la combo DNS Server + Reverse Proxy ?

Pour ma part, après avoir tout configuré, tout fonctionne presque parfaitement en dehors d'un détail : lorsque je reboot le NAS, tous les entrées de reverse proxy associées à des alias définis dans le server DNS tombent

Il suffit alors de modifier/ajouter/supprimer une entrée au reverse proxy pour qu'il utilise de nouveau les alias du serveur DNS

 

Je me demande si c'est un problème de cache/réglage raté quelque part dans le serveur DNS

J'ai vu que pas mal d'entre vous utilisaient ce genre de combo, donc je m'explique mal pourquoi je constate ce bug chez moi (sur 2 NAS différents j'ai le même problème)

Posté(e)
Il y a 7 heures, Finnithnel a dit :

lorsque je reboot le NAS, tous les entrées de reverse proxy associées à des alias définis dans le server DNS tombent

Bonjour,

A mon avis le première chose à faire c'est de reprendre point par point les deux tutos.

Sinon, les alias définis dans le serveur DNS dont tu parles ce sont des enregistrements CNAME ? Dans la zone privée de DNS serveur? ou bien dans une zone publique ?

Pour être sûr que ce n'est pas un problème de cache il faut vider celui de ton navigateur et le cache de résolution avant chaque essai :

Pour vider le cache de résolution faire un fichier .txt à modifier en .bat:

@echo off 
ipconfig /flushdns 
pause

  • 3 semaines après...
Posté(e)

Bonjour à tous,

Merci à Fenrir pour ce tuto bien détaillé. Bon je galère quand même. Je m'explique (je vais essayer d'être clair).

- config actuelle:

  1. routeur synology RT2600ac avec ddns chez ovh (pour connexion de l’extérieur)
  2. 1 nas syno  avec divers services
  3. 1 nas unraid avec divers services et lab :
  • un nginx pour gérer mes sous domaines sur mes divers serveurs/services donc redirection sur ip:port
  • toute la maison pointe sur un docker adguard home qui pointe sur 1.1.1.3 pour les requêtes web sortantes

-->quickconnect coupé récemment après lecture de ton tuto de Sécurité.

 

ça marche bien mais voulant ajouter un serveur de mail l'idée du DNS Serveur à la maison me plaisait bien(en complément de adguardhome) C'est peut être ridicule, dites moi...

-Ou je veux aller :

  1. routeur synology avec ddns chez ovh (pour connexion de l’extérieur) et dns serveur(adguard home utilisera ce DNS)
  2. Pas besoin de sortir sur internet pour consulter les serveurs interne.
  3. nginx sur un unraid pour transférer les sous domaines de l’extérieur sur bonne ip et port

 

Comme les ports de mes services ne sont pas tous 8080 ou 443, j'ai un problème :

  • depuis l’extérieur pas de souci en utilisant sousdomaine.mondomaine.ovh
  • depuis l'intérieur je dois maintenant utiliser une url sousdomaine.mondomaine.ovh:port

Il y a un moyen de faire cohabiter nginx et dns server sans gérer 2 liens différents?

Je suis développeur et non spécialiste réseau alors si mon idée est ridicule ou que je manque de précision merci de me le dire.

🙂

Franck

 

 

Posté(e)

@taxesurleprix74

Bonjour,

  1. Comme sur tout forum, il est d'usage que les nouveaux membres passent par la rubrique [PRESENTATION] pour faire la leur. Certains ici, y sont sensibles et de plus cela facilite les réponses en fonction du niveau de compétences du membre et de ses équipements. Cela dit, rassures-toi il n'est pas trop tard pour bien faire ...

  2. Peut-être que la solution serait de mettre en place un Reverse Proxy : voir TUTO : Reverse Proxy (attention sous DSM6, il est préférable de passer par Apache plutôt que nginx).

  3. Pour ton idée de Server Mail hébergé, comme tu as manifestement une @IP externe dynamique (déduit du ddns ovh), je t'invite à regarder ce TUTO : Configurer « MailPlus Server » avec une @IP dynamique Orange. A toi d'adapter la configuration au modèle de ta box. A l'interface près les fonctions sont facilement transposables.

Cordialement

oracle7😉

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.