Spi Posté(e) le 16 mai 2017 Posté(e) le 16 mai 2017 Si tu fais un nslookup sur ns.mia.lcl tu obtiens quoi? 192.168.0.1 est ton serveur et 192.168.0.5 une autre ressource si je comprends bien? Dans les liste ip sources tu as bien mis l'adresse 192.168.0.0 ? Et on sait jamais....Le statut des zones est bien activé? :) 0 Citer
Sartog Posté(e) le 16 mai 2017 Posté(e) le 16 mai 2017 (modifié) il y a 9 minutes, Spi a dit : Si tu fais un nslookup sur ns.mia.lcl tu obtiens quoi? 192.168.0.1 est ton serveur et 192.168.0.5 une autre ressource si je comprends bien? Dans les liste ip sources tu as bien mis l'adresse 192.168.0.0 ? Et on sait jamais....Le statut des zones est bien activé? :) Merci Spi pour tes réponses. 192.168.0.1 est mon routeur sur lequel le paquet DNS Server est activé. 192.168.0.65 est un raspberry avec une solution domotique dessus. Les listes IP source (dans Résolution, paramètre de la zone et Vue) sont toutes de la sorte : (Le PC avec lesquels je fait les tests est en 192.168.0.25). Le statut de la zone est bien activé. Voici ce que me retourne le nslookup sur ns.mia.lcl > ns.mia.lcl Serveur : UnKnown Address: 192.168.0.1 *** UnKnown ne parvient pas à trouver ns.mia.lcl : Non-existent domain Modifié le 16 mai 2017 par Sartog 0 Citer
Fenrir Posté(e) le 16 mai 2017 Auteur Posté(e) le 16 mai 2017 (modifié) @Spi Au moins ça prouve que les vues font leur travail Par contre je viens de m'apercevoir qu'il y avait une faute dans mon tuto (personne ne s'en est aperçu) => Dans ta zone directe, il te manque un enregistrement, le "naked domain" : truc.info A 172.16.1.X En local ce n'est pas grave, mais en publique il y a 3 enregistrements obligatoires : le SOA : le nas te le créé, mais tu peux/dois l'ajuster les NS (il en faut 2) : ça tu as compris le domaine lui même => si ton domaine est truc.info il faut créer un enregistrement : truc.info A une.adresse.ip.publique Si l'ip est la bonne, fais pointer tes CNAME dessus plutôt que sur ns.truc.info, c'est plus "esthétique" et ça te permet de bouger le ns sans devoir modifier les autres enregistrements. Dernier point, en local tu peux mettre des TTL plus court si besoin. @Sartog il y a 27 minutes, Sartog a dit : Je créé ma Zone Master comme indiqué avec le Nom de domaine fictif souhaité (j'ai testé avec .local, .home, .home.lcl, sans succès). Le 29/01/2017 à 01:58, Fenrir a dit : nb : il ne faut jamais utiliser le suffixe ".local", même en interne Utilise plutôt .maison (ou un truc qui a peu de chance d'exister sur Internet). Mais techniquement, ton .lcl devrait fonctionner de ce que je vois. Par contre il y a peut être une subtilité avec le RT, il doit probablement faire serveur DNS cache par défaut, il y a peut être un conflit (ssh : netstat -luntp | grep 53). À tout hasard, dans la conf il doit bien y avoir un endroit où tu configures ses serveurs DNS à lui (en tant que client), demande lui d'utiliser 127.0.0.1 pour tester Modifié le 16 mai 2017 par Fenrir 0 Citer
Spi Posté(e) le 16 mai 2017 Posté(e) le 16 mai 2017 @Fenrir Merci pour les précisions! Mais du coup justement je ne peux actuellement pas créer cet enregistrement car je ne suis pas en ip fixe... J'utilise le DDNS d'OVH et j'attends de changer de provider pour voir si je pourrais avoir une ip fixe, du coup en attendant je ne peux pas le créer. @Sartog Je n'avais pas compris que tu étais sur un routeur, je t'avoue que je ne les connais pas du coup je manque un peu de vue sur le sujet... Il y'a un routeur et un Syno en fait? Avec le DNS géré par le routeur? 0 Citer
Fenrir Posté(e) le 16 mai 2017 Auteur Posté(e) le 16 mai 2017 Ok pour le DDNS Son routeur est un synology 0 Citer
Sartog Posté(e) le 16 mai 2017 Posté(e) le 16 mai 2017 (modifié) il y a 29 minutes, Fenrir a dit : @Sartog Utilise plutôt .maison (ou un truc qui a peu de chance d'exister sur Internet). Mais techniquement, ton .lcl devrait fonctionner de ce que je vois. Par contre il y a peut être une subtilité avec le RT, il doit probablement faire serveur DNS cache par défaut, il y a peut être un conflit (ssh : netstat -luntp | grep 53). À tout hasard, dans la conf il doit bien y avoir un endroit où tu configures ses serveurs DNS à lui (en tant que client), demande lui d'utiliser 127.0.0.1 pour tester Merci Fenrir pour ta réponse. Pour le .local, oups !! Heureusement que je suis passé sur autre chose rapidement. Pour le netstat, voici le résultat : HomeRouteur1> netstat -luntp | grep 53 tcp 0 0 192.168.4.1:53 0.0.0.0:* LISTEN 14544/named tcp 0 0 192.168.0.1:53 0.0.0.0:* LISTEN 14544/named tcp 0 0 192.168.2.1:53 0.0.0.0:* LISTEN 14544/named tcp 0 0 IPExterne:53 0.0.0.0:* LISTEN 14544/named tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 14544/named tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 14544/named tcp 0 0 ::%8:53 :::* LISTEN 14544/named udp 0 0 192.168.4.1:53 0.0.0.0:* 14544/named udp 0 0 192.168.0.1:53 0.0.0.0:* 14544/named udp 0 0 192.168.2.1:53 0.0.0.0:* 14544/named udp 0 0 IPExterne:53 0.0.0.0:* 14544/named udp 0 0 127.0.0.1:53 0.0.0.0:* 14544/named udp 0 0 127.0.0.1:31067 0.0.0.0:* 32539/vpnauthd udp 0 0 127.0.0.1:31068 0.0.0.0:* 32539/vpnauthd udp 0 0 0.0.0.0:38350 0.0.0.0:* 4153/avahi-daemon: udp 0 0 192.168.0.1:5351 0.0.0.0:* 22781/miniupnpd udp 0 0 0.0.0.0:5353 0.0.0.0:* 4153/avahi-daemon: udp 0 0 ::%1:53 :::* 14544/named Le 192.168.4.1 est un réseau invité imposé par le RT. Le 192.168.2.1 est le réseau WAN 2 qui ne sert que de connexion de secours en cas de perte de l'ADSL). Pour le paramétrage des serveurs DNS, je n'ai trouvé que 2 endroits (et impossible d'y mettre 127.0.0.1) : Modifié le 16 mai 2017 par Sartog 0 Citer
Fenrir Posté(e) le 16 mai 2017 Auteur Posté(e) le 16 mai 2017 (modifié) Tu n'as pas fais le netstat en root, du coup il manque une colonne. Celle du "p" pour avoir les process associés Refais la commande en root (ou avec sudo), puis coupe le paquet DNS server et relance la commande. Pour les DNS externes, évite d'utiliser ceux de Google ou de Cisco (=opendns), ceux de FDN sont bien plus propres. (et en passant, supprime ton adresse IP publique des commandes) Modifié le 16 mai 2017 par Fenrir 0 Citer
Sartog Posté(e) le 16 mai 2017 Posté(e) le 16 mai 2017 (modifié) il y a 14 minutes, Fenrir a dit : Tu n'as pas fais le netstat en root, du coup il manque une colonne. Refais la commande en root (ou avec sudo), puis coupe le paquet DNS server et relance la commande. Pour les DNS externes, évite d'utiliser ceux de Google ou de Cisco (=opendns), ceux de FDN sont bien plus propres. (en passant, supprime ton adresse IP de commandes) Merci Fernrir pour le rappel concernant l'IP Publique que j'avais laissé ! Sudo n'existe pas sur le RTT, mais je suis bien connecté en root par contre. Voici le résultat avec le paquet activé puis le paquet désactivé : ---- PAQUET DNS SERVER : START ---- HomeRouteur1> netstat -luntp | grep 53 tcp 0 0 192.168.4.1:53 0.0.0.0:* LISTEN 14544/named tcp 0 0 192.168.0.1:53 0.0.0.0:* LISTEN 14544/named tcp 0 0 192.168.2.1:53 0.0.0.0:* LISTEN 14544/named tcp 0 0 IP.Externe.133:53 0.0.0.0:* LISTEN 14544/named tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 14544/named tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 14544/named tcp 0 0 ::%8:53 :::* LISTEN 14544/named udp 0 0 0.0.0.0:35360 0.0.0.0:* 23193/avahi-daemon: udp 0 0 192.168.4.1:53 0.0.0.0:* 14544/named udp 0 0 192.168.0.1:53 0.0.0.0:* 14544/named udp 0 0 192.168.2.1:53 0.0.0.0:* 14544/named udp 0 0 IP.Externe.133:53 0.0.0.0:* 14544/named udp 0 0 127.0.0.1:53 0.0.0.0:* 14544/named udp 0 0 127.0.0.1:31067 0.0.0.0:* 32539/vpnauthd udp 0 0 127.0.0.1:31068 0.0.0.0:* 32539/vpnauthd udp 0 0 IP.Externe.255:137 0.0.0.0:* 23153/nmbd udp 0 0 IP.Externe.133:137 0.0.0.0:* 23153/nmbd udp 0 0 192.168.0.255:137 0.0.0.0:* 23153/nmbd udp 0 0 192.168.0.1:137 0.0.0.0:* 23153/nmbd udp 0 0 192.168.2.255:137 0.0.0.0:* 23153/nmbd udp 0 0 192.168.2.1:137 0.0.0.0:* 23153/nmbd udp 0 0 0.0.0.0:137 0.0.0.0:* 23153/nmbd udp 0 0 IP.Externe.255:138 0.0.0.0:* 23153/nmbd udp 0 0 IP.Externe.133:138 0.0.0.0:* 23153/nmbd udp 0 0 192.168.0.255:138 0.0.0.0:* 23153/nmbd udp 0 0 192.168.0.1:138 0.0.0.0:* 23153/nmbd udp 0 0 192.168.2.255:138 0.0.0.0:* 23153/nmbd udp 0 0 192.168.2.1:138 0.0.0.0:* 23153/nmbd udp 0 0 0.0.0.0:138 0.0.0.0:* 23153/nmbd udp 0 0 0.0.0.0:5353 0.0.0.0:* 23193/avahi-daemon: udp 0 0 ::%1:53 :::* 14544/named ---- PAQUET DNS SERVER : STOP ---- HomeRouteur1> netstat -luntp | grep 53 tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 3114/dnsmasq tcp 0 0 ::%8:53 :::* LISTEN 3114/dnsmasq udp 0 0 0.0.0.0:35360 0.0.0.0:* 23193/avahi-daemon: udp 0 0 0.0.0.0:53 0.0.0.0:* 3114/dnsmasq udp 0 0 127.0.0.1:31067 0.0.0.0:* 32539/vpnauthd udp 0 0 127.0.0.1:31068 0.0.0.0:* 32539/vpnauthd udp 0 0 IP.Externe.255:137 0.0.0.0:* 23153/nmbd udp 0 0 IP.Externe.133:137 0.0.0.0:* 23153/nmbd udp 0 0 192.168.0.255:137 0.0.0.0:* 23153/nmbd udp 0 0 192.168.0.1:137 0.0.0.0:* 23153/nmbd udp 0 0 192.168.2.255:137 0.0.0.0:* 23153/nmbd udp 0 0 192.168.2.1:137 0.0.0.0:* 23153/nmbd udp 0 0 0.0.0.0:137 0.0.0.0:* 23153/nmbd udp 0 0 IP.Externe.255:138 0.0.0.0:* 23153/nmbd udp 0 0 IP.Externe.133:138 0.0.0.0:* 23153/nmbd udp 0 0 192.168.0.255:138 0.0.0.0:* 23153/nmbd udp 0 0 192.168.0.1:138 0.0.0.0:* 23153/nmbd udp 0 0 192.168.2.255:138 0.0.0.0:* 23153/nmbd udp 0 0 192.168.2.1:138 0.0.0.0:* 23153/nmbd udp 0 0 0.0.0.0:138 0.0.0.0:* 23153/nmbd udp 0 0 0.0.0.0:5353 0.0.0.0:* 23193/avahi-daemon: udp 0 0 ::%1:53 :::* 3114/dnsmasq Modifié le 16 mai 2017 par Sartog 0 Citer
Fenrir Posté(e) le 16 mai 2017 Auteur Posté(e) le 16 mai 2017 Première chose, pas demain la veille que je conseillerais un RT. Un routeur/firewall grand public qui laisse le netbios écouter coté WAN ... (j'ose espérer que le fw bloque bien le trafic) À première vu, dnsmasq est remplacé par bind (named), donc il ne devrait pas y avoir de conflit à ce niveau (sauf nat farfelu de la part de syno, mais j'en doute) C'est donc un souci de conf (de ta part ou de celle de syno). Le souci c'est que si le paquet est comme celui de DSM, la conf est éclatée en plein de fichiers dans : /volume1/@appstore/DNSServer/named/etc Le fichier d'entrée est named.conf, ensuite il faut suivre les includes (attention, tu es dans un chroot, donc /etc = /volume1/@appstore/DNSServer/named/etc). La conf de bind est très facile à lire, tu devrais la comprendre aisément. Tu peux aussi tester le nslookup directement depuis le syno en ssh : nslookup server 192.168.0.1 nas-forum.com ns.mia.lcl Comme je n'ai jamais eu ce routeur entre les mains, je peux difficilement t'aider plus via le forum. 0 Citer
Sartog Posté(e) le 17 mai 2017 Posté(e) le 17 mai 2017 Il y a 11 heures, Fenrir a dit : Première chose, pas demain la veille que je conseillerais un RT. Un routeur/firewall grand public qui laisse le netbios écouter coté WAN ... (j'ose espérer que le fw bloque bien le trafic) À première vu, dnsmasq est remplacé par bind (named), donc il ne devrait pas y avoir de conflit à ce niveau (sauf nat farfelu de la part de syno, mais j'en doute) C'est donc un souci de conf (de ta part ou de celle de syno). Le souci c'est que si le paquet est comme celui de DSM, la conf est éclatée en plein de fichiers dans : /volume1/@appstore/DNSServer/named/etc Le fichier d'entrée est named.conf, ensuite il faut suivre les includes (attention, tu es dans un chroot, donc /etc = /volume1/@appstore/DNSServer/named/etc). La conf de bind est très facile à lire, tu devrais la comprendre aisément. Tu peux aussi tester le nslookup directement depuis le syno en ssh : nslookup server 192.168.0.1 nas-forum.com ns.mia.lcl Comme je n'ai jamais eu ce routeur entre les mains, je peux difficilement t'aider plus via le forum. Bonjour Fenrir et, une nouvelle fois, merci pour tes réponses. J'ai profité d'un voyage en train ce matin pour me remettre sur ce problème (en VPN) et tester le nslookup en ssh, et là ça fonctionne .... Du coup, je test de nouveau sur mon PC le nslookup ... ça fonctionne ... Je tape jeedom.mia.lcl dans l'explorateur web ... ça fonctionne ... Apparemment, la nuit porte conseil aussi pour le RT Je verrais ce soir, en local, si ça fonctionne également. Citation Un routeur/firewall grand public qui laisse le netbios écouter coté WAN ... (j'ose espérer que le fw bloque bien le trafic) Je ne m'y connais pas en netbios, donc je ne sais pas ce que cela génère comme risque. Pour le FW, je ne suis pas expert non plus dans ce domaine, mais en comparaison de ce que j'avais avant, je peux dire que c'est une passoire et que les règles servent à boucher les trous de cette dernière J'essais de le rendre le plus étanche possible. 0 Citer
Spi Posté(e) le 17 mai 2017 Posté(e) le 17 mai 2017 @Sartog Peut-être tout simplement que ton cache sur le pc ne s'était pas encore mis à jour et que du coup il ne demandait pas l'info au routeur? Quand tu fais des modifs sur le paquet et que tu testes depuis un pc tu peux toujours utiliser ipconfig /flushdns pour vider ce cache et être sur qu'il monte bien chercher l'info sur le DNS. :) @Fenrir J'étais un peu fatigué hier soir et en relisant ton dernier message sur ma config il me vient un doute, concernant l'enregistrement naked domain. Il y a donc toujours une erreur dans ma config? Même si ce n'est pas grave au niveau local autant faire un truc propre et prendre les bonnes habitudes, du coup si je dois modifier quelque chose tu peux me le préciser stp? Merci d'avance! 0 Citer
Fenrir Posté(e) le 17 mai 2017 Auteur Posté(e) le 17 mai 2017 nslookup n'utilise pas le cache local normalement Rajoute juste un enregistrement de type A qui pointe sur ton ip est dont le nom est le domaine géré : Il y a 22 heures, Fenrir a dit : Dans ta zone directe, il te manque un enregistrement, le "naked domain" : truc.info A 172.16.1.X 0 Citer
Spi Posté(e) le 17 mai 2017 Posté(e) le 17 mai 2017 (modifié) 172.16.1.1 dans mon cas, qui est l'ip de mon Syno où est le DNS, correct? Et si à un moment j'ai une ip fixe je remplacerais cet enregistrement par l'ip fixe côté WAN? Modifié le 17 mai 2017 par Spi 0 Citer
Sartog Posté(e) le 17 mai 2017 Posté(e) le 17 mai 2017 Bon, malheureusement le test en local n'est pas concluant Le plus "drôle" : en local chez moi, je me connecte en VPN chez moi (donc je sors pour re-rentrer), et bha là ça fonctionne Il faut que j'aille voir les fichier de conf, comme tu l'as indiqué Fenrir, parce que là je ne comprends pas. 0 Citer
Fenrir Posté(e) le 17 mai 2017 Auteur Posté(e) le 17 mai 2017 @Spi tu peux mettre l'IP de ton choix, ça n'a d'importance que si tu te sers de ce nom. @Sartog à ta place je commencerai par vérifier les filtres car en relisant ce que tu as posté, je m'aperçoit que tu n'as pas respecté mes reco, j'ai recommandé de mettre 4 réseaux, ce n'est pas un hasard : et idem coté firewall Pas certain que ça soit la cause de ton problème, mais quand ça fonctionne depuis un point A mais pas depuis un point B, toutes choses égales par ailleurs, c'est généralement qu'il y a un filtrage sur B. 0 Citer
Spi Posté(e) le 17 mai 2017 Posté(e) le 17 mai 2017 (modifié) Dernière petite question pour moi me concernant... Je n'avais pas pensé à quelque chose mais en mettant le serveur DNS je ne peux plus accéder à mon deuxième nas. :/ Il n'est géographiquement pas au même endroit que l'autre, du coup pas le même LAN... srv01.domaine.com | srv02.domaine.com Les deux sur DDNS OVH, qu'est-ce que je dois faire pour pouvoir le contacter de nouveau? Dans le DHCP les deux DNS configurés sont le Syno et 80.67.169.12, qui apparemment ne se met pas aussi vite à jour que les autres DNS. :/ Je peux peut-être faire une redirection spéciale pour ce domaine là seulement? Modifié le 17 mai 2017 par Spi 0 Citer
Fenrir Posté(e) le 17 mai 2017 Auteur Posté(e) le 17 mai 2017 Il te suffit de créer l'enregistrement DNS correspondant : srv02.domaine.com 3600 IN CNAME le.dyndns.qui.va.bien 0 Citer
Spi Posté(e) le 17 mai 2017 Posté(e) le 17 mai 2017 Je suis perdu là, sur ovh j'ai configuré le domaine srv02.domaine.com, il faut créer un identifiant/pass et dans le Syno dans l'onglet accès externe j'ai ajouté OVH comme provider DDNS avec ces identifiants. Mais dans le DNS, je ne peux rien lui rajouter, je n'ai pas une ip ou autre vers laquelle me diriger. Du coup j'ai manqué une info. ^^ 0 Citer
Fenrir Posté(e) le 17 mai 2017 Auteur Posté(e) le 17 mai 2017 Tu as mal compris ma réponse, mais j'ai mal compris ton problème. Admettons ceci : ton domaine est : domaine.com ton ddns est : srv02.autre.chose => tu fais un alias (CNAME) de srv02.domaine.com vers srv02.autre.chose Par contre, si ton dyndns est aussi en exemple.com, alors il faut être plus malin . C'est très facile à faire, mais très long à expliquer, le principe est celui que j'utilise ici : http://www.nas-forum.com/forum/topic/55206-tuto-dns-server/?do=findComment&comment=1319318099 3 manières de faire (au choix même si elles peuvent fonctionner de concert) : tu créés une zone srv02.domaine.com (ce nom en entier) de type forward et comme redirecteur tu indiques les NS d'OVH dans ta zone domaine.com, tu indiques que les NS de srv02.domaine.com (ce nom en entier) sont ceux d'OVH tu créés une zone srv02.domaine.com (ce nom en entier) de type direct et tu indiques dedans que les NS sont ceux d'OVH Dans un cas comme dans l'autre, il faut régler les vues en mettant cette zone en prioritaire par rapport à la zone domaine.com (donc au dessus dans la liste). Si tu comprends bien les 3 méthodes et que tu es capable de les appliquer, c'est que tu as franchi un palier dans ton apprentissage du DNS (au sens architecture du terme). 0 Citer
Spi Posté(e) le 17 mai 2017 Posté(e) le 17 mai 2017 Parfait j'ai level up!! Je cherchais justement cette notion de forwarder (à la base j'avais fait quelques labos avec des DNS sur Windows Server), j'ai testé les deux premières et ça marche au poil. Finalement j'ai gardé la deuxième (qui ne nécéssite pas de changer les vues), parce-que sinon la commande nslookup ne donnait plus le nom du serveur DNS! Tout beau tout propre niveau config, merci! 0 Citer
Fenrir Posté(e) le 17 mai 2017 Auteur Posté(e) le 17 mai 2017 @Spi : le niveau suivant c'est DNSSEC, mais ce n'est pas géré par le syno (bind le gère, l'interface de syno non) 0 Citer
Kadesty Posté(e) le 19 mai 2017 Posté(e) le 19 mai 2017 (modifié) Bonjour, Tout d'abord merci pour ce tuto Fenrir, j'ai enfin pu mettre en place un serveur DNS fonctionnel. Du moins en partie... car le wifi n'est pas impacté par la zone DNS mais tout fonctionne bien sur mon PC branché en ethernet. Donc quand je me connecte avec mon smartphone en wifi, je vois bien l'ip du téléphone (192.168.1.5) qui a été donnée par le DHCP du syno et avec l'ip du nas (192.168.1.1) comme DNS primaire. Mais si je tape nas.home, ça me dit adresse introuvable. Si je tape l'ip du nas, c'est ok. Si je fais un lookup sur nas.home, ça me retourne : A: ns.home./192.168.1.1 CNAME: nas.home. ns.home. Si je fais un ping sur nas.home, pas de retour. J'ai fait ces tests avec l'application android DNS tools. Je me demande comment c'est possible qu'un lookup trouve l'ip associé à nas.home mais que le ping ne fonctionne pas ? Modifié le 19 mai 2017 par Keverage 0 Citer
Fenrir Posté(e) le 19 mai 2017 Auteur Posté(e) le 19 mai 2017 Que donne le nslookup sur ton pc ? 0 Citer
Kadesty Posté(e) le 19 mai 2017 Posté(e) le 19 mai 2017 Sur mon pc : nslookup nas.home Serveur : UnKnown Address: 192.168.1.1 Nom : ns.home Address: 192.168.1.1 Aliases: nas.home 0 Citer
Fenrir Posté(e) le 19 mai 2017 Auteur Posté(e) le 19 mai 2017 (modifié) J'ai réfléchi un bon moment avant de me rappeler d'un truc => Je pense que c'est tout simplement ton ordiphone qui ne se sert pas des DNS envoyés par le DHCP, mais utilise des DNS codés en dur (au hasard, ceux de Google). Certaines versions d'android on ce détestable comportement. Je n'y fais jamais attention chez moi car j'intercepte toutes les requêtes DNS sortantes et les redirige vers mes propres serveurs. Tu as 5 possibilités dans ce cas (aucune n'est simple, merci Google ) : fixer les DNS manuellement, mais ça impose aussi de fixer l'IP utiliser un vrai nom de domaine combiné à des vues intercepter le trafic DNS vers 8.8.8.8 et 8.8.4.4 pour le rediriger vers ton nas configurer ton android pour passer par un vpn (celui du nas par exemple), dans ce cas la conf dns semble respectée si ton téléphone est rooté, tu as des applis qui permettent de changer les DNS Si tu trouve une autre manière de faire (je n'ai pas beaucoup cherché), n'hésites pas à nous en faire part. ------------ Même si ce n'est probablement pas la cause de ton problème, le .home fait parti des tld que j'éviterai d'utiliser pour des questions de sécurité, plutôt qu'un long discours, un article : https://umbrella.cisco.com/blog/blog/2014/04/23/malicious-gtld-squatting/ Il n'existe que 4 tld dispo pour un usage interne : .test, .example, .invalid et .localhost En pratique, même si dans mon tuto je n'ai été très loquace à ce sujet, il vaut mieux utiliser un vrai nom de domaine de premier niveau ou de second niveau (lan.monvraidomaine.fr). J'ai éditer mon tuto pour être plus explicite à ce sujet. Modifié le 20 mai 2017 par Fenrir 0 Citer
Messages recommandés
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.