La Fibre
Fournisseurs d'accès à Internet mobile et 5G/4G fixe => 5G/4G Bouygues Telecom => 5G/4G Bouygues Telecom => Discussion démarrée par: le 24 juillet 2017 à 13:06:25
-
DNS menteurs chez Bouygues Telecom mobile
Je cherche à comprendre pourquoi le site ZD Net (http://www.zdnet.fr/) ne fonctionne pas sur un PC en partage de connexion avec la 4G Bouygues (alors que cela fonctionne très bien directement sur le mobile)
La réponse est simple : le serveur répond [RST] a mes [ACK]
Je m’aperçois d'une chose : Le DNS ne me renvoi pas vers l'IP habituelle de ZD net :
$ dig www.zdnet.fr
; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.zdnet.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50268
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.zdnet.fr. IN A
;; ANSWER SECTION:
www.zdnet.fr. 7021 IN CNAME wpxy-proxyless.wip-ext.bouyguestelecom.fr.
wpxy-proxyless.wip-ext.bouyguestelecom.fr. 268 IN A 212.195.244.75
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Jul 24 12:54:33 CEST 2017
;; MSG SIZE rcvd: 110
La capture Wireshark :
-
Encore plus fort : Cela fonctionne en modifiant le TTL !
Le DNS ne donne pas la même IP si le TTL est paire ou impaire !
$ dig www.zdnet.fr
; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.zdnet.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51064
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.zdnet.fr. IN A
;; ANSWER SECTION:
www.zdnet.fr. 5977 IN CNAME wpxy-proxyless.wip-ext.bouyguestelecom.fr.
wpxy-proxyless.wip-ext.bouyguestelecom.fr. 118 IN A 62.34.202.116
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Jul 24 13:11:57 CEST 2017
;; MSG SIZE rcvd: 110
Tutoriel pour modifier le TTL :
Bouygues Telecom décompte la consommation du forfait, en présence d'un routeur/partage de connexion coté abonné sur son bonus option illimité le week-end.
Pour avoir le trafic en illimité, même en mode modem (ou avec un routeur 4G) il faut modifier le TTL des PC connecté à ton point d’accès pour avoir l'illimité même sur PC :
- TTL = 63 ou 64 ou 127 ou 128 = facturation (par défaut le TTL est de 64 ou 128)
- TTL autre que 63 ou 64 ou 127 ou 128 = non facturation (enfin je n'ai testé qu'avec un TTL de 65)
Modifier le TTL sur Windows
Commande pour afficher le TTL sous Windows :
netsh int ipv4 show glob
netsh int ipv6 show glob
Changement du TTL sous Windows pour avoir de la data illimitée : (à exécuter avec les privilèges administrateurs)
netsh int ipv4 set glob defaultcurhoplimit=65
netsh int ipv6 set glob defaultcurhoplimit=65
Modifier le TTL sur Linux :
Commande pour afficher le TTL sous Linux :
cat /proc/sys/net/ipv4/ip_default_ttl
64
Commande pour changer le TTL sous Linux pour avoir de la data illimitée :
sudo sysctl net.ipv4.ip_default_ttl=65
Commande pour rendre le changement de TTL persistant au redémarrage sous Linux :
sudo nano /etc/sysctl.conf
Rajouter en début de fichier la ligne :
net.ipv4.ip_default_ttl = 65
Exemple :
(https://lafibre.info/testdebit/ubuntu/201704_etc_sysctl_ttl.png)
Modifier le TTL sur MacOS
Commande pour changer le TTL sous MacOS pour avoir de la data illimitée :
sudo sysctl -w net.inet.ip.ttl=65
Modifier le TTL sur un routeur
Pour les routeurs basés sur Linux, qui permettent de rajouter une ligne iptables, voici la ligne à rajouter pour forcer un TTL de 65 pour tous les périphériques :
iptables -t mangle -I POSTROUTING -o `nvram get wan_iface` -j TTL --ttl-set 65
-
J'ai réalisé de nombreux tests.
Les IP récupérées par le DNS avec TTL de 65 et 64 (62.34.202.116 et 212.195.244.75) ont toutes les deux le même comportement
Mon PC Ubuntu es connecté à mon téléphone en mode modem
- En configurant un TTL de 6 à 62, le site répond bien.
- TTL 63 => non ok
- TTL 64 => non ok
- En configurant un TTL de 65 à 126, le site répond bien.
- TTL 127 non ok
- TTL 128 non ok
- En configurant un TTL de 129 à 255, le site répond bien.
TTL de 62 : le serveur répond
$ sudo sysctl net.ipv4.ip_default_ttl=62
net.ipv4.ip_default_ttl = 62
$ telnet 62.34.202.116 80
Trying 62.34.202.116...
Connected to 62.34.202.116.
Escape character is '^]'.
ok
HTTP/1.1 501 Not Implemented
Content-type: text/html
Content-Length: 219
<HTML><head><meta http-equiv="Content-Type" content="text/html;charset=utf-8"></head><center>Erreur 501<br>Méthode non supportée</center><hr>Le serveur HTTP ne peut pas traiter votre requête.</HTML>
Connection closed by foreign host.
TTL de 63 : Le serveur ne répond pas
$ sudo sysctl net.ipv4.ip_default_ttl=63
net.ipv4.ip_default_ttl = 63
$ telnet 62.34.202.116 80
Trying 62.34.202.116...
telnet: Unable to connect to remote host: Connection refused
TTL de 64 : Le serveur ne répond pas
$ sudo sysctl net.ipv4.ip_default_ttl=64
net.ipv4.ip_default_ttl = 64
$ telnet 62.34.202.116 80
Trying 62.34.202.116...
telnet: Unable to connect to remote host: Connection refused
TTL de 65 : Le serveur répond
$ sudo sysctl net.ipv4.ip_default_ttl=65
net.ipv4.ip_default_ttl = 65
$ telnet 62.34.202.116 80
Trying 62.34.202.116...
Connected to 62.34.202.116.
Escape character is '^]'.
ok
HTTP/1.1 501 Not Implemented
Content-type: text/html
Content-Length: 219
<HTML><head><meta http-equiv="Content-Type" content="text/html;charset=utf-8"></head><center>Erreur 501<br>Méthode non supportée</center><hr>Le serveur HTTP ne peut pas traiter votre requête.</HTML>
Connection closed by foreign host.
Le même comportement est observé que ce soit 62.34.202.116 ou 212.195.244.75.
-
J'ai remarqué ce problème également ce matin sans aller toutefois chercher du côté des DNS >:(
-
La bonne entrée DNS a utiliser est 146.185.42.33
C'est hébergé par AS47841 Oxalide (https://www.oxalide.com/)
$ dig www.zdnet.fr
; <<>> DiG 9.9.5-3ubuntu0.15-Ubuntu <<>> www.zdnet.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16448
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.zdnet.fr. IN A
;; ANSWER SECTION:
www.zdnet.fr. 900 IN A 146.185.42.33
;; AUTHORITY SECTION:
zdnet.fr. 900 IN NS ns10.cbsig.net.
zdnet.fr. 900 IN NS ns11.cbsig.net.
;; ADDITIONAL SECTION:
ns10.cbsig.net. 4697 IN A 62.108.128.10
ns11.cbsig.net. 4697 IN A 62.108.129.11
;; Query time: 113 msec
;; SERVER: 91.194.96.11#53(91.194.96.11)
;; WHEN: Tue Jul 25 07:54:44 CEST 2017
;; MSG SIZE rcvd: 136
-
J'ai recherché l'objectif poursuivit par Bouygues Telecom en forçant le passage par wpxy-proxyless.wip-ext.bouyguestelecom.fr
J'ai vérifié sur la page d’accueil : le contenu n'est pas modifié.
Bref, j'ai du mal à saisir ce qui a motivé un mensonge sur les DNS.
-
Le blocage de ZD Net n'est toujours pas levé.
Autre nom de domaine qui pose problème : authentication.0pb.org (il est nécessaire pour certains sites web, comme par exemple KKO Store) => On est redirigé sur la même IP que ZD Net et l’accès est impossible sans changer son TTL :
$ dig authentication.0pb.org
; <<>> DiG 9.10.3-P4-Ubuntu <<>> authentication.0pb.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 838
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;authentication.0pb.org. IN A
;; ANSWER SECTION:
authentication.0pb.org. 7006 IN CNAME wpxy-proxyless.wip-ext.bouyguestelecom.fr.
wpxy-proxyless.wip-ext.bouyguestelecom.fr. 47 IN A 62.34.202.116
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Aug 03 11:12:04 CEST 2017
;; MSG SIZE rcvd: 122
-
Le problème a été remonté en interne.
Merci pour vos retours.
Cordialement,
Boris de Bouygues Telecom.
-
L’accès à ZD-Net a été rétabli pour le mode modem.
Cordialement,
Boris de Bouygues Telecom.
-
Le site ZD-Net fonctionne, mais l'IP récupérée par le DNS n'est toujours pas la bonne :
$ dig www.zdnet.fr
; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.zdnet.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42883
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.zdnet.fr. IN A
;; ANSWER SECTION:
www.zdnet.fr. 7051 IN CNAME wpxy-proxyless.wip-ext.bouyguestelecom.fr.
wpxy-proxyless.wip-ext.bouyguestelecom.fr. 36 IN A 212.195.244.75
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Oct 05 09:15:57 CEST 2017
;; MSG SIZE rcvd: 110
-
Bonjour,
La réponse DNS de www.zdnet.fr est en accord avec l'éditeur de ZD-Net.
Je ne pense pas pouvoir expliquer la raison ici, sans leur accord.
Si vous les contactez, ils vous expliqueront peut-être.
-
Bonjour,
La réponse DNS de www.zdnet.fr est en accord avec l'éditeur de ZD-Net.
Je ne pense pas pouvoir expliquer la raison ici, sans leur accord.
Si vous les contactez, ils vous expliqueront peut-être.
Ta réponse veux dire que un éditeur peux demander a un FAI de retourner sur son DNS une adresse qui est pas celle officiellement déclarée ? Car la c'est bien le DNS de BT qui donne une réponse erronée.
Un fouisseur de services DNS peux légalement faire pointer une IP n'importe quoi légalement ?
Si je teste avec mes 3 connections et les DNS par défaut assignés par DHCP, K-Net FTTH, Orange ADSL, BT 4G, voila les résultats.
-
Ta réponse veux dire que un éditeur peux demander a un FAI de retourner sur son DNS une adresse qui est pas celle officiellement déclarée ?
Au hasard, pour profiter d'un cache chez le dit FAI ?