Vous n'êtes pas identifié(e).
Pages : 1
Si quelqu'un a des idées je suis preneur
Dernière modification par Zinzin (21-08-2019 17:26:32)
Tout ce qui est .rar est share !
Hors ligne
Dernière modification par raleur (21-08-2019 11:01:25)
Il vaut mieux montrer que raconter.
Hors ligne
pas testé , utilisé autre chose que ".local"
Dernière modification par Zinzin (21-08-2019 12:36:28)
Tout ce qui est .rar est share !
Hors ligne
Dernière modification par raleur (21-08-2019 13:02:09)
Il vaut mieux montrer que raconter.
Hors ligne
Idéalement il faudrait faire une capture du trafic (tcdpump, wireshark...) pour comprendre ce qui se passe.
Je vais regarder pour mettre ça en place.
Le poste client est en Jessie ?
Oui
Quel est le contenu de /etc/nsswitch.conf et /etc/resolv.conf ?
Que renvoie la même commande host avec l'option -v
Ça fait la même chose depuis une autre machine ?
Oui exactement, j'ai testé depuis un raspberry et un windows10
Pour préciser la machine 10.11.11.253 est un pihole qui interroge le nas comme serveur dns.
Tout ce qui est .rar est share !
Hors ligne
renvoie la même chose que ping ?
host envoie directement les requêtes DNS alors que les programmes "normaux" comme ping passent par le resolveur de la libc configuré par nsswitch.conf.
la machine 10.11.11.253 est un pihole qui interroge le nas comme serveur dns.
Pourquoi ne pas interroger directement le NAS ?
A quoi correspondent les autres adresses présentes dans resolv.conf ? En principe, tous les DNS définis dans ce fichier doivent être équivalents.
Je me demande aussi pourquoi host n'interroge pas la première adresse. Que donne la commande host en interrogeant explicitement la première adresse ?
Il vaut mieux montrer que raconter.
Hors ligne
Je pense que c'est cette ipv6 qui doit poser problème... si je la commente dans resolv.conf elle réapparaît aussitôt juste en dessous...
J'ai laisser tout les paramètres ipv6 en auto sur mon pfsense, je vais fouiller dedans voir si y a pas un truc qui pourrait correspondre.
EDIT :
Pourquoi ne pas interroger directement le NAS ?
A quoi correspondent les autres adresses présentes dans resolv.conf ? En principe, tous les DNS définis dans ce fichier doivent être équivalents.
PiHole me sers de bloqueur de pub mais j'aurais peut du inverser : nas -> pihole -> fdn ?
J'ai 3 ip distribué par le dhcp pour palier le risque que 1 le pihole tombe et 2 que le nas tombe aussi, mais il est vrai que j'aurai pu mettre juste pihole et fdn
EDIT2 :
J'ai pas trouver d’où peut venir cette ipv6 mais le probleme à l'air de venir de là.
J'ai désactivé l'ipv6 sur le pc avec ces commandes :
Et le ping vers nas.bbr fonctionne
Bon du coup j'ai plus qu'à trouver d'où vient cette ipv6 de malheur !
Merci pour votre aide et mention spécial à raleur pour son debug !
EDIT3 :
Au final j'ai totalement désactivé l'ipv6 sur le pfsense, c'est un peu bourrin mais ça fonctionne pour tout les pc.
Je ferai un debug de l'ipv6 le jour où j'en aurai besoin.
Dernière modification par Zinzin (21-08-2019 17:40:26)
Tout ce qui est .rar est share !
Hors ligne
Je pense que c'est cette ipv6 qui doit poser problème... si je la commente dans resolv.conf elle réapparaît aussitôt juste en dessous...
J'ai laisser tout les paramètres ipv6 en auto sur mon pfsense, je vais fouiller dedans voir si y a pas un truc qui pourrait correspondre.
On l'aurait tout de suite vu avec une capture de trafic.
Cette adresse est probablement annoncée dans les annonces de routeur IPv6 (RA) émises périodiquement par ton routeur IPv6 (pfsense ?) et récupérée par NetworkManager qui l'ajoute aussitôt dans resolv.conf. C'est équivalent à l'option RDNSS dans radvd que j'utilise sur mon propre routeur IPv6 sous Debian.
Au lieu de désactiver IPv6 sur tes postes clients ou serveurs, il serait plus propre de configurer le routeur pour ne pas annoncer cette adresse de DNS dans ses RA.
Attention quand même à la dernière adresse du NS de FDN figurant dans resolv.conf car elle n'est pas équivalente aux autres et ne peut résoudre ton domaine local. Je suppose qu'elle est annoncée par DHCP comme les deux autres ? Si un client s'avisait d'interroger aléatoirement n'importe quel serveur annoncé, ses requêtes pourraient échouer quand il tombe sur le serveur FDN.
Il restait à éclaircir pourquoi le programme host n'interrogeait pas cette adresse, pourtant placée en premier et syntaxiquement valide (la preuve, la commande qui l'interroge explicitement fonctionne) mais la seconde. D'après quelques tests, il semble que host, ainsi que dig, ignore une adresse dans resolv.conf si elle comporte un suffixe %interface. Or ce suffixe est obligatoire pour qualifier une adresse unicast de type link local (commençant par fe80::) car cette plage d'adresse est utilisable sur toutes les interfaces et liaisons. Visiblement le résolveur de la libc n'a pas cette restriction.
Dernière modification par raleur (21-08-2019 19:00:39)
Il vaut mieux montrer que raconter.
Hors ligne
Tout ce qui est .rar est share !
Hors ligne
Pages : 1