Re: ipv6 - nom de domaine sur site mutualisé inaccessible - comment contourner avec linux unbound - google dns - opendns - configuration
Le 06/08/2017 à 23:12, Pascal Hambourg a écrit :
> Le 06/08/2017 à 22:27, G2PC a écrit :
>>
>> J'utilise, je pense, network-manager, en mode graphique, qui me
>> retourne,
>> broadcast : 192.168.1.255
>> masque de sous réseau 255.255.255.0
>> route par défaut 192.168.1.1
>> primary DNS 127.0.0.1
>>
>> cat /etc/resolv.conf
>> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by
>> resolvconf(8)
>> # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
>> nameserver 127.0.2.1
>
> Ce n'est pas l'adresse de DNS retournée par NetworkManager. Peut-être
> forcée par resolvconf.
> Mais dans les deux cas, il s'agit de la machine elle-même, donc un
> serveur DNS local qui tourne sur la machine.
>> Yes, unbound a été installé.
>
>> search 208.67.222.222 208.67.220.220
>
> Cette ligne est aberrante. On ne met pas des adresses IP dans l'option
> search mais des domaines. Cf. man resolv.conf.
>> Ok pour l’aberration , il me faut voir comment la modifier, car,
resolv.conf est généré ( peut être par dhcp, ou, resolvconf )
>
>> A moins que je dois en fait configurer le programme resolvconf, que j'ai
>> découvert hier, mais, je ne l'ai pas utilisé, de moi même, hors, je lis
>> maintenant, juste plus haut, cette ligne : # Dynamic resolv.conf(5) file
>> for glibc resolver(3) generated by resolvconf(8) mais, cela n'explique
>> pas mes difficultés, il me semble. Quoi que, je ne sais pas qui est
>> 127.0.2.1 (?)
>
> C'est la machine elle-même, comme toutes les adresses IP qui
> commencent par 127.
>> Oui, je voulais dire, pour la fin de l'ip, 2.1 , je ne sais pas qui
la crée et l'utilise.
>
>> ip route
>> default via 192.168.1.1 dev wlp60s0 proto static metric 600
>> 169.254.0.0/16 dev wlp60s0 scope link metric 1000
>> 192.168.1.0/24 dev wlp60s0 proto kernel scope link src 192.168.1.15
>> metric 600
>
> RAS.
>
>> iptables-save
>> pas de retour.
>
> Donc pas de règles iptables qui pourraient bloquer des paquets.
>
>> dig www.visionduweb.eu.
>> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.visionduweb.eu.
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32603
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;www.visionduweb.eu. IN A
>>
>> ;; ANSWER SECTION:
>> www.visionduweb.eu. 4767 IN CNAME visionduweb.eu.
>> visionduweb.eu. 4767 IN A 91.216.107.158
>>
>> ;; Query time: 59 msec
>> ;; SERVER: 127.0.2.1#53(127.0.2.1)
>> ;; WHEN: Sun Aug 06 22:16:54 CEST 2017
>> ;; MSG SIZE rcvd: 77
>
> Quel que soit le serveur DNS local qui tourne sur la machine, il fait
> son boulot et donne la réponse. Pas de problème de résolution DNS donc.
>
>> dig www.visionduweb.eu. @8.8.8.8
>
> Sans intérêt, c'était au cas où la commande précédente échouerait.
>
>> sudo tcptraceroute 91.216.107.158 80
>> traceroute to 91.216.107.158 (91.216.107.158), 30 hops max, 60 byte
>> packets
>> 1 192.168.1.1 (192.168.1.1) 14.199 ms 17.828 ms 17.804 ms
>> 2 80.10.115.251 (80.10.115.251) 48.646 ms 51.679 ms 54.955 ms
>> 3 10.123.205.86 (10.123.205.86) 57.371 ms 10.123.205.82
>> (10.123.205.82) 60.028 ms 63.286 ms
>> 4 ae43-0.nridf201.Aubervilliers.francetelecom.net (193.252.98.145)
>> 65.505 ms ae43-0.nridf202.Paris.francetelecom.net (193.252.98.150)
>> 68.439 ms ae43-0.nridf201.Aubervilliers.francetelecom.net
>> (193.252.98.145) 83.064 ms
>> 5 ae43-0.noidf001.Paris.francetelecom.net (193.252.98.234) 85.892 ms
>> ae43-0.noidf002.Aubervilliers.francetelecom.net (193.252.98.238) 86.228
>> ms 86.450 ms
>> 6 193.253.13.202 (193.253.13.202) 86.726 ms 193.253.13.206
>> (193.253.13.206) 33.463 ms 193.253.13.202 (193.253.13.202) 40.527 ms
>> 7 ielo.std-1.rt.hopus.net (37.77.38.13) 41.441 ms
>> ielo.th2-2.rt.hopus.net (37.77.34.5) 49.579 ms ielo.std-1.rt.hopus.net
>> (37.77.38.13) 51.357 ms
>> 8 te-0-0-frpar-th2-a9k1.rt.ielo.net (212.85.145.138) 54.410 ms * *
>> 9 * * *
>> 10 * * *
>> 11 * * *
>> ...
>> 28 * * *
>> 29 * * *
>> 30 * * *
>
> Pas de problème de routage en sortie de ta box. Par contre ça coince
> plus loin en chemin. Ton adresse IP publique est peut-être filtrée, ou
> il y a un problème de routage aller ou retour (impossible de savoir)
> entre Orange et LWS. J'ai fait le tcptraceroute depuis chez moi, les
> routeurs de l'hébergeur n'aident pas, ils ne renvoient aucun message
> ICMP et je reçois juste la réponse du serveur après plusieurs sauts
> sans réponse :
>
> 11 212.51.160.215 (212.51.160.215) 56.091 ms 54.446 ms *
> 12 * * *
> 13 * * *
> 14 * * *
> 15 * * *
> 16 * 91.216.107.158 (91.216.107.158) <syn,ack> 54.855 ms 56.317 ms
>
> Donc impossible de savoir si ça coince sur le serveur ou avant dans
> ton cas.
>
>> Dans le cas d'un blocage avant la box orange, on l'aurait vu ? Filtre
parental ou autre routeur ?
>> Ce serrait donc entre orange et LWS ?
Merci de ton expertise.
Reply to: