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: youscribe le 12 octobre 2018 à 16:11:37
-
Bonjour,
Je ne suis pas client Bouygues Telecom mobile, mais je suis le propriétaire du site youscribe.com.
Le site n'est plus disponible pour les clients Bouygues Telecom mobile: ERR_CONNEXION_REFUSED.
- Connecté depuis un téléphone sur le réseau Bouygues Telecom => Erreur
- Connecté depuis le même téléphone en WIFI => OK
- Connecté sur un ordinateur utilisant la connexion partagée du téléphone => Erreur
- Connecté sur le même ordinateur, avec le même partage de connexion, avec un VPN => OK
- Connecté depuis un réseau Free, Orange, SFR, etc. => OK
- Connecté depuis 2 autres téléphones sur le réseau Bouygues Telecom => Erreur
Je précise, au cas où, que je ne blacklist pas les IP Bouygues.
Le problème est visiblement récente, je suppose que le DNS en https n'est pas à jour sur les serveurs de Bouygues Telecom.
Est-ce que quelqu'un sait comment je peux contacter le support Bouygues, n'étant pas un de leur client ?
Si un CM de Bouygues Telecom passe par ici, pouvez-vous remonter le problème svp ?
C'est très handicapant.
Merci
-
je suppose que le DNS en https n'est pas à jour sur les serveurs de Bouygues Telecom.
ouch fracture des yeux
DNS n'a rien a voir avec https (en tout cas directement)
pour faire simple
d'un coté tu parle d'un protocole de résolution de nom/ip (ici www.youscribe.com résout vers 35.186.237.217)
de l'autre d'un protocole d'échange de fichier web via un chiffrement
sur une bbox adsl ça semble marcher (enfin une erreur 404 c'est con ^^):
curl -I https://www.youscribe.com/
HTTP/1.1 404 Not Found
Server: nginx
par contre effectivement sur un mobile bouygues ça ne fonctionne pas
par contre ce n'est pas un problème de DNS:
en faisant un ping depuis mon mobile je résout sur l'ip:
35.186.237.217
la même que sur la bbox fixe mais l'adresse ne ping pas
-
Il faudrait demander un traceroute à un utilisateur Bouygues.. Pour voir exactement où se perdent les paquets
-
Pour info, sur une ligne ei télécom (positionnée sur le réseau Bouygues), j'accède sans problème au site.
-
avec une sim B&You... qui donne une erreur 500 sinon "Le serveur HTTP a rencontré une erreur interne."
-
Si l'erreur est "connection refused" le problème se situe au délà de IP, donc vos ping et traceroute ne servent à rien :)
-
ca marche avec un galet 4G Bytel mais pas avec un smartphone.
sur un chromebook en partage de connexion :
* Trying 2001:860:de06:2002::75...
* TCP_NODELAY set
* connect to 2001:860:de06:2002::75 port 443 failed: Connection refused
* Trying 62.34.202.116...
* TCP_NODELAY set
* connect to 62.34.202.116 port 443 failed: Connection refused
* Failed to connect to www.youscribe.com port 443: Connection refused
* Closing connection 0
peut-etre un probleme de négo TLS ou de valeur de port éphémère?
-
ouch fracture des yeux
DNS n'a rien a voir avec https (en tout cas directement)
Lol
Autant pour moi, erreur de copier/coller avec une phrase supprimée ;D
Pour l'erreur 404, c'est bizarre, car le site est bien up et fonctionnel...
ca marche avec un galet 4G Bytel mais pas avec un smartphone.
sur un chromebook en partage de connexion :
* Trying 2001:860:de06:2002::75...
* TCP_NODELAY set
* connect to 2001:860:de06:2002::75 port 443 failed: Connection refused
* Trying 62.34.202.116...
* TCP_NODELAY set
* connect to 62.34.202.116 port 443 failed: Connection refused
* Failed to connect to www.youscribe.com port 443: Connection refused
* Closing connection 0
peut-etre un probleme de négo TLS ou de valeur de port éphémère?
Merci à tous pour vos réponses.
Et merci kgersen pour la trace. Par contre, ça dépasse mes connaissances réseaux... ça signifie qu'il y a une conf à faire de mon côté ou c'est bien un problème chez Bouygues ?
De ce que je comprends, le DNS serait ok, mais pas le https.
Ce qui signifie que si on essaie de taper sur http://youscribe.com on verra la redirection vers https ?
Je ne sais pas si qqn avec une connexion Buygues Tel peut essayer pour confirmer.
Désolé, je me sens un peu assisté là :-\
-
ca marche avec un galet 4G Bytel mais pas avec un smartphone.
sur un chromebook en partage de connexion :
* Trying 2001:860:de06:2002::75...
* TCP_NODELAY set
* connect to 2001:860:de06:2002::75 port 443 failed: Connection refused
* Trying 62.34.202.116...
* TCP_NODELAY set
* connect to 62.34.202.116 port 443 failed: Connection refused
* Failed to connect to www.youscribe.com port 443: Connection refused
* Closing connection 0
peut-etre un probleme de négo TLS ou de valeur de port éphémère?
C'est donc une simple histoire de serveurs DNS pas à jour. Car l'IP est normalement 35.186.237.217 sans IPv6...
Les serveurs DNS de Bouygues Mobile doivent être bloqués sur d'anciens records dns
-
effectivement c'est un souci de serveurs DNS:
$ dig +short www.youscribe.com
wpxy-proxyless.wip-ext.bouyguestelecom.fr.
62.34.202.116
c'est le dns menteur de Bytel: https://lafibre.info/4g-bytel/dns-menteur-27901/
il faut que Bytel arrete leur conneries la...
-
Kgersen hier soir j'avais bien une réponse avec la bonne ip sur mon tel
Je check tout à l'heure quand j'ai un peu plus de temps
-
La bonne IP est la suivante :
$ dig +short www.youscribe.com
35.186.237.217
Je vois que Bouygues Telecom force le flux à pas par le wpxy-proxyless.wip-ext.bouyguestelecom.fr d’après les informations postées par kgersen.
youscribe avez vous passé un contrat avec Bouygues Telecom, à l'époque où le site youscribe.com était en http pour les autoriser à modifier la réponse DNS pour intercepter le trafic et peut-être modifier des choses à la volée ?
Le site est aujourd’hui en https, j'imagine que cela pose problème à Bouygues Telecom.
-
Bonjour vivien,
Je confirme que c'est la bonne IP.
youscribe avez vous passé un contrat avec Bouygues Telecom, à l'époque où le site youscribe.com était en http pour les autoriser à modifier la réponse DNS pour intercepter le trafic et peut-être modifier des choses à la volée ?
Non, on n'a jamais passé de contrat avec Bouygues Telecom pour faire ce genre de chose.
Mais en trouvant des postes sur divers forums, j'ai l'impression que Bouygues passe par des proxy pour intercepter tout leur trafic et qu'ils ont régulièrement des ratés de mise à jour de DNS ou de conf http/https.
Voici les autre sujets dont je parle:
https://lafibre.info/4g-bytel/dns-menteur-27901/
https://forum.bouyguestelecom.fr/questions/902263-problemes-acces-sites
https://forum.bouyguestelecom.fr/questions/1460272-sites-inaccessibles
https://forum.bouyguestelecom.fr/questions/1558091-site-inaccessible-erreur-7
Merci à tous (pousse en l'air! ...mais je ne trouve pas le smiley ^^)
J'ai plus qu'à signaler le problème à jalerte.arcep.fr + espérer que quelqu'un de bouygues ait l'info rapidement. :/
-
Boris, de Bouygues Telecom, intervient régulièrement sur ce forum, et avait répondu sur autrefois à des sujets similaires (DNS menteurs). J'espère qu'il pourra le faire encore ici.
Au delà de l'aspect DNS menteur, je m'interroge sur un autre point. Comment cela se fait que le proxy Bouygues marcherait en http et pas en https ? Normalement c'est transparent, les deux protocoles, 80 et 443 sont supportés (ex squid), et les deux devraient donc passer sans intervention ?
-
Curieux aussi que le galet 4G de Bytel n'a pas ce souci.
-
Le galet 4G n'a pas le même apn, pas de dns menteur.
Je l'avais déjà dit dans un autre sujet, mais j'ai été envoyé voir ailleurs voir si j'y étais.
Cela ne surprends que ceux qui n'y croient pas...
Mais sur smartphone (même en mode modem), c'est vrai que c'est chiant, pour ne pas dire autre chose.
Il y a aussi des blocages sur SFR mobile, autres sites, autre méthode.
J'ai l'impression qu'il faut éviter de plus en plus d'utiliser les réseaux mobiles dès qu'on veut sortir des applis mobiles...
-
Boris, de Bouygues Telecom, intervient régulièrement sur ce forum, et avait répondu sur autrefois à des sujets similaires (DNS menteurs). J'espère qu'il pourra le faire encore ici.
Au delà de l'aspect DNS menteur, je m'interroge sur un autre point. Comment cela se fait que le proxy Bouygues marcherait en http et pas en https ? Normalement c'est transparent, les deux protocoles, 80 et 443 sont supportés (ex squid), et les deux devraient donc passer sans intervention ?
Les 2 sont bloqués:
HTTP:
~$ curl -4 -I -vvv http://www.youscribe.com/
* Trying 62.34.202.116...
* TCP_NODELAY set
* connect to 62.34.202.116 port 80 failed: Connection refused
* Failed to connect to www.youscribe.com port 80: Connection refused
* Closing connection 0
curl: (7) Failed to connect to www.youscribe.com port 80: Connection refused
HTTPS:
~$ curl -4 -I -vvv https://www.youscribe.com/
* Trying 62.34.202.116...
* TCP_NODELAY set
* connect to 62.34.202.116 port 443 failed: Connection refused
* Failed to connect to www.youscribe.com port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to www.youscribe.com port 443: Connection refused
Comme c'est une interception DNS ,on ne peut savoir si c'est du HTTP ou HTTPS au moment de changer l'IP.
C'est de toute façon un truc qui ne devrait plus exister... qu'ils mentent sur leur propres serveurs DNS ok mais ce n'est absolument pas normal qu'un "dig ... @8.8.8.8" soit modifié par Bytel:
~$ dig +short www.youscribe.com @8.8.8.8
wpxy-proxyless.wip-ext.bouyguestelecom.fr.
62.34.202.116
::)
-
C'est de toute façon un truc qui ne devrait plus exister... qu'ils mentent sur leur propres serveurs DNS ok mais ce n'est absolument pas normal qu'un "dig ... @8.8.8.8" soit modifié par Bytel:
~$ dig +short www.youscribe.com @8.8.8.8
wpxy-proxyless.wip-ext.bouyguestelecom.fr.
62.34.202.116
::)
Ah oui, joli ! On peut parler de tromperie là.
Chez Free :
~$ dig +short www.youscribe.com @8.8.8.8
35.186.237.217
Bien sûr...
P.S : comme les DNS menteurs sont déjà un tromperie, je pense même que l'on peut parler de tromperie aggravée.
-
Vous avez testé depuis un mobile 4G Bouygues
dig +short www.youscribe.com @46.227.16.8
46.227.16.8 est l'IP de LaFibre.info et n’héberge pas de serveur DNS
Comme c'est une interception DNS ,on ne peut savoir si c'est du HTTP ou HTTPS au moment de changer l'IP.
Oui, Bouygues Telecom modifie à la volée le DNS, pour forcer le client à se connecter sur une IP d'un proxy qui doit réaliser du man-in-the-middle. Les attaques man-in-the-middle fonctionnent bien en http, mais pas en https (sauf certificat spécifique sur le client - c'est le cas avec plusieurs anti-virus) d'où mon étonnement de voir un site web en https passer par ce type de plateforme.
Pour moi seuls les sites qui le demandaient étaient interceptés par les opérateurs mobiles et une contrainte est que ce site soit en http et non en https, ce qui permet à l'opérateur de modifier la page pour rajouter les informations demandées par le propriétaire. C'est pour cela que je suis très étonné d’apprendre que Youscribe n'a pas passé de contrat avec Bouygues Telecom.
youscribe, j'ai plusieurs question, pour essayer de comprendre pourquoi Bouygues Telecom renvoi votre trafic sur une plateforme qui doit réaliser du man-in-the-middle :
1/ vous avez un contrat payant avec une société pour le suivit de trafic ? Mon hypothèse est que si vous n'avez pas souscrit en direct avec Bouygues Telecom, cela a peut-être été réalisé par un produit auquel vous avez souscrit auprès d'un tiers (autre que Google).
2/ A une époque il était possible de payer directement sur la facture de l'opérateur mobile ?
3/ Depuis quand votre site est en https ?
4/ Depuis quand êtes vous sur Google Cloud Platform ? (je ne pense pas que Google Cloud Platform soit en mesure de récupérer les informations de tracking rajoutées par les opérateurs mobiles dans les requêtes GET)
-
Bonne idée Vivien, à mon avis ce sont les requêtes sur les ports UDP et TCP 53 qui sont interceptées, donc même sur une adresse IP qui n'est pas un serveur DNS, il devrait y avoir une réponse.
-
Effectivement 'dig @n'importe quelle IP' répond toujours la meme chose...quelle horreur ...
-
Pour moi, si c'est avéré, ce qui semble le cas, c'est un des plus gros scandale vu sur l'Internet français. Rien que pour cette raison, si je ne peux avoir confiance dans la réponse des serveurs DNS que je choisis, et que je peux être redirigé n'importe où, je ne m'abonnerai pas chez Bouygues Telecom.
C'est le négation de la neutralité d'Internet.
-
J'ai activé Private DNS sur mon smartphone (Google Pixel 2 sous Android 9) en mettant: 1dot1dot1dot1.cloudflare-dns.com comme serveur (ca fait du DNS over TLS sur le port 853,voir cet article pour Android P (https://www.techrepublic.com/article/how-to-enable-dns-over-tls-in-android-pie/) et celui-ci pour Cloudflare (https://developers.cloudflare.com/1.1.1.1/dns-over-tls/)).
et la le site https://www.youscribe.com/ marche. exit les bidouilles de Bytel , tout est chiffré y compris la résolution DNS.
Malheureusement la fonctionnalité Private DNS n'est pas utilisé par le partage de connexion d'Android donc le pc/chromebook n’accédera toujours pas au site via le smartphone.
-
J'ai activé Private DNS sur mon smartphone (Google Pixel 2 sous Android 9) en mettant: 1dot1dot1dot1.cloudflare-dns.com comme serveur (ca fait du DNS over TLS sur le port 853,voir cet article pour Android P (https://www.techrepublic.com/article/how-to-enable-dns-over-tls-in-android-pie/) et celui-ci pour Cloudflare (https://developers.cloudflare.com/1.1.1.1/dns-over-tls/)).
et la le site https://www.youscribe.com/ marche. exit les bidouilles de Bytel , tout est chiffré y compris la résolution DNS.
Malheureusement la fonctionnalité Private DNS n'est pas utilisé par le partage de connexion d'Android donc le pc/chromebook n’accédera toujours pas au site via le smartphone.
Voici une liste des serveurs publics utilisables :
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Public+Resolvers
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers
J'espère que Bouygues ne va pas aussi mentir sur la résolution DNS des serveurs connus (1dot1dot1dot1.cloudflare-dns.com => 1.1.1.1 par exemple) à l'avenir, ou rediriger le port 853 sur ces IP, comme il le fait avec le port 53 pour toute destination.
-
Il y a une chose qui m'étonne, pourquoi avoir activé cette interception des requêtes DNS pour le mobile et pas pour le fixe (ADSL...) ? Parce que c'est moins visible ? Avec le partage de connexion, ce n'est plus forcèment le cas. Où est-ce une première étape ?
-
Il y a une chose qui m'étonne, pourquoi avoir activé cette interception des requêtes DNS pour le mobile et pas pour le fixe (ADSL...) ? Parce que c'est moins visible ? Avec le partage de connexion, ce n'est plus forcèment le cas. Où est-ce une première étape ?
A l'origine il me semble que c'était pour compresser les sites (réduction de la qualité des images, ...).
D'ailleurs le nom wpxy-proxyless.wip-ext.bouyguestelecom.fr suggère que c'est pour remplacer le proxy dans l'APN.
-
C'est le wap, pas le dns, pour la compression, et ce n'est plus utilisé depuis des lustres.
Pour le DNS, c'est pour que les clients accèdent à internet, même avec un apn mal configuré.
J'ai la flemme de retrouver l'explication de Boris, mais ce sujet est récurrent:
Il y a eu un sujet l'été dernier pour les dns déjà. Boris avait dit que c'était pour que le net marche même si le apn du mobile était mauvais.
-
Si le DNS mentait pour tous les sites, alors ce serait effectivement un moyen de forcer un passage par un proxy (qui pouvait effectuer la compression avant, je ne sais pas ce qu'il fait actuellement), même s'il n'est pas dans l'APN.
Sauf que ça ne concerne pas tous les sites, et la connexion fonctionne sans.
-
Pouvoir accéder à Internet même si les DNS sont mal configurés, quelle mauvaise excuse, surtout quand tes propres DNS mentent. Dans quel but ?
D'abord, je n'ai jamais eu à m'occuper des DNS sur un mobile, qui sont récupérés par DHCP. Sinon, il faut bien sûr corriger les DNS, pas faire cette horreur !
J'espère que l'ARCEP va intervenir et condamner fermement Bouygues Telecom.
-
Il y a des cas où le dns était vraiment mal configuré, et le mobile ne récupérait rien à la connexion.
Boris expliquait bien cela.
Vivien, ce sujet est trop récurrent, ce serait bien de retrouver et mettre le sujet en question en post-it, stp. ;)
L'interception dns c'est 100% ou 0%, pas de "certains sites".
Le mensonge au résultat, ou le blocage (volontaire ou non) ne concernent qu'une partie des sites, en effet.
-
A noter que l'interception en IPv6 peut avoir une justification : un serveur DNS IPv6 tiers ne ferait probablement pas DNS64, ce qui casserait l'accès IPv4.
Mais s'ils ne compressent plus les sites, je me demande bien quelle est la raison d'avoir un DNS menteur forçant certains sites à passer par wpxy-proxyless.wip-ext.bouyguestelecom.fr.
-
J'espère que l'ARCEP va intervenir et condamner fermement Bouygues Telecom.
+1 pour l'interception dns.
Par contre, le fait que les opérateurs aient tous un dns menteur, c'est une obligation légale (renforcée cette année, sic).
Mais si on pouvait arrêté les interceptions dns, ce serait déjà bien.
-
Effectivement, tout était dans un sujet d'il y a un an, très bien documenté, que j'avais complétement zappé. Il y avait même une interception SMTP. Donc cela ne date pas d'aujourd'hui, et n'a toujours pas été corrigé.
https://lafibre.info/4g-bytel/mitm-as-a-service-chez-byou-des-explications/
-
+1 pour l'interception dns.
Par contre, le fait que les opérateurs aient tous un dns menteur, c'est une obligation légale (renforcée cette année, sic).
Mais si on pouvait arrêté les interceptions dns, ce serait déjà bien.
L'obligation légale est implèmentée de manière différente, ce qui fait qu'elle n'est pas très claire (ça peut être NXDOMAIN, 127.0.0.1, ...).
Mais là ce n'est pas la même chose.
-
Effectivement, tout était dans un sujet d'il y a un an, très bien documenté, que j'avais complétement zappé. Il y avait même une interception SMTP. Donc cela ne date pas d'aujourd'hui, et n'a toujours pas été corrigé.
https://lafibre.info/4g-bytel/mitm-as-a-service-chez-byou-des-explications/
Non, le sujet de base n'est pas celui-ci.
Il fait juste parti de la récurrence du sujet du dns sur mobile Bouygues.
L'obligation légale est implèmentée de manière différente, ce qui fait qu'elle n'est pas très claire (ça peut être NXDOMAIN, 127.0.0.1, ...).
Mais là ce n'est pas la même chose.
Oui, c'est les cas de blocages volontaires (ce qui n'est pas le cas pour le site youscribe.com de ce que je comprends).
Mais l'interception du dns redirige donc vers le DNS de Bouygues... qui a aussi cet aspect.
Le gros jackpot de la somme de tous les soucis que l'on peut avoir en dns, dans ce cas! :-\
-
D'ailleurs le nom wpxy-proxyless.wip-ext.bouyguestelecom.fr suggère que c'est pour remplacer le proxy dans l'APN.
Non, la compression des pages web, réalisée par SFR et Bouygues Telecom à l'époque de la 2G et de la 3G était réalisé sans modification DNS, par le proxy transparent et cela impactait tous les transferts sur le port TCP 80. Le but de cette compression des images et du code HTML était de réduire le temps de chargement.
wpxy-proxyless.wip-ext.bouyguestelecom.fr est utilisé pour autre chose que la compression. La preuve : LEs DNS Bouygues mentent aussi pour le site http://www.zdnet.fr/ qui passe par cette plateforme sans être compressé (j'ai vérifié a plusieurs reprise il y a un an).
Autre site où le DNS force un passage par wpxy-proxyless.wip-ext.bouyguestelecom.fr : authentication.0pb.org (il est nécessaire pour certains sites web, comme par exemple KKO Store)
Dans les deux cas, ce sont des sites en http. Et c'est probablement la raison du non passage en https.
Si vous en trouvez d'autres, je suis preneur.
Avez-vous essayé de modifier le TTL ? Des retours montrent que la réponse DNS peut être différente selon le TTL, ce qui signifie que la réponse DNS n'est pas la même si le site est appelé depuis le smartpone ou depuis un PC connecté en partage de connexion sur le smartphone :
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
-
Bonsoir,
Si j'ai bien compris, 100% des sites sont concernés par cette interception des requêtes DNS sur le réseau mobile BT ?
Mais seuls certains sites sont concernés par le renvoi du trafic http sur un proxy qui doit réaliser du man-in-the-middle ? Et ce, normalement sur une demande spécifique du site à BT ?
1/ vous avez un contrat payant avec une société pour le suivit de trafic ? Mon hypothèse est que si vous n'avez pas souscrit en direct avec Bouygues Telecom, cela a peut-être été réalisé par un produit auquel vous avez souscrit auprès d'un tiers (autre que Google).
2/ A une époque il était possible de payer directement sur la facture de l'opérateur mobile ?
3/ Depuis quand votre site est en https ?
4/ Depuis quand êtes vous sur Google Cloud Platform ? (je ne pense pas que Google Cloud Platform soit en mesure de récupérer les informations de tracking rajoutées par les opérateurs mobiles dans les requêtes GET)
1/ Nous n'avons aucun contrat avec un tier pour du suivi de trafic.
2/ A une époque nous utilisions HiPay pour faire du paiement via facture internet. De mémoire c'était facture internet et non mobile, mais je ne suis pas sûr à 100%. A part ça, je ne vois rien d'autre.
3/ La bascule en https a été faite fin Mai de cette année.
4/ Le passage sur GCloud s'est fait il y a 1 an (Octobre 2017).
Encore merci pour vos tests et votre investissement. :)
-
100% des requêtes DNS sont concernées par ce détournement des requêtes vers les serveurs Bouygues Telecom, mais dans seulement un certain nombre de cas (que je ne connais pas), la réponse est fausse et amène vers le proxy Bouygues.
C'est du Man In The Middle, qui ne marché pas en https dans ce cas.
Mais on peut se demander pourquoi le DNS Bouygues ment dans votre cas, si personne ne l'a demandé (personne ? -> voir si tierce personne, éditeur, vu la nature de votre site, justice..., ne l'a demandé ?).
En tout cas, signalez-le à l'ARCEP pour qu'au moins les interceptions DNS cessent !
-
Mon hypothèse de ce qui a pu se passer :
1/ HiPay à demander que youscribe soit intercepté par les 3 opérateurs mobiles, afin de pouvoir payer sur la facture mobile. Dans le contrat il est demandé que le site soit en http.
2/ Bouygues Telecom met en place une redirection du trafic sur son proxy, via DNS menteur.
3/ Fin du contrat HiPay, mais la redirection reste en place. Youscribe fonctionne toujours car il est en http.
4/ Mai 2018, Youscribe passe en https. Il est impossible de modifier des pages en https et le site devient injoignable depuis Bouygues Telecom mobile.
-
du coup c'est quoi la procédure pour "désintercepter" ce domaine ?
Je remarque aussi que le domaine est hébergé (https://gwhois.org/youscribe.com+dns)chez OVH. Il faut peut-etre passé par eux aussi , ils ont surement déja eu le cas.
Au besoin fait passer le domaine chez Google, via https://domains.google/ vu que le site est déja chez eux.
-
du coup c'est quoi la procédure pour "désintercepter" ce domaine ?
Boris s'occupait d'un peu de tout, avec des contacts internes auprès des bon collègues.
Mais sa dernière visite et dernière intervention du moment date de janvier, et les mp sont fermés vers lui sauf s'il a profité de ne plus venir pour les ouvrir.
Je ne sais pas s'il y a une relève dans ce forum.
-
La mailing liste FRnOG (French Network Organisation) peut aussi être une bonne piste pour ce genre de problèmes. De nombreux professionnels du monde des réseaux et des télécoms y sont abonnés, dont des personnes des différents opérateurs, et probablement Bouygues Telecom :
http://sympa.frnog.org/wss/info/frnog/
Ce sujet devrait beaucoup les intéresser.
-
J'ai entendu dire que Boris ne travaillait plus chez Bouygues, mais c'est bizarre de ne pas avoir eu de message d'adieu :/
-
Ce serait dommage pour Bouygues Telecom et ce forum, car Boris était compétent et très efficace.
-
Bonjour à tous,
Un de nos partenaires qui a un contact direct chez BT a eu un retour.
Message de BT:
Nous procédons à l'exclusion du domaine www.youscribe.com
Impact: Plus d’UID pour tous les services déclarés avec cette URL et pour lesquels nous mettrons ces règles d’exclusion.
Ce qui confirme l'hypothèse de vivien avec HiPay. Sauf si le domaine est "tombé" dans cette config par une erreur de BT, mais ça on ne le saura jamais je pense.
Je vais regarder pour passer les domaines chez google, mais je n'ai pas pris le temps de le faire jusqu'ici, ni des impacts que ça peut avoir sur la prod au moment du changement.
Je reviendrai mettre un post pour clore le sujet quand BT aura fait sa modification.
Encore merci pour tous ces éclaircissements.
-
En ce qui me concerne, ce n'est pas clôt, en tout cas le sujet général qui est l'interception des requêtes DNS chez Bouygues Telecom mobile, et la réponse falsifiée avec en adresse source celle soit disant du serveur interrogé, en fait celle des serveurs BT.
S'ajoute à cela des DNS menteurs, avec une redirection vers un serveur maison proxy, qui fait donc du man in the middle, à l'insu du site (youscribe dans ce cas), et de l'utilisateur.
Cela fait beaucoup et je m'étonne qu'il n'y ait pas plus de réactions à ce sujet des abonnés 4G Bouygues Telecom. Il est probable que le fait que ce soit circonscrit au mobile, sur lesquels la configuration DNS est un peu obscure et intéresse peu les abonnés explique cela.
Mais sur le principe c'est inadmissible, surtout qu'un tiers puisse demander le détournement d'un site qui ne lui appartient pas (peut-être Hipay, mais ce n'est pas sûr).
J'espère donc que l'ARCEP interviendra pour obliger Bouygues à mettre fin à ces pratiques.
Mais le sujet qui décrit le mieux le problème, à ma connaissance, reste le sujet ouvert par Devnull il y a un an et demi (Mars 2017, ce n'est pas neuf...), "DNS et SMTP Bouygues forcé sur le réseau Bouygues mobile". Même si pour le SMTP cela ne semble plus d'actualité.
-
Message de BT:
Nous procédons à l'exclusion du domaine www.youscribe.com
Impact: Plus d’UID pour tous les services déclarés avec cette URL et pour lesquels nous mettrons ces règles d’exclusion.
Merci de ce retour qui confirme mon analyse sur le fait que les sites web ne semblent pas modifiés par le proxy en question.
UID = user identifier
J'imagine que c'est un hash du n° de téléphone ? Cela me semble improbable que ce soit le numéro en clair qui est envoyé, sachant que cela circule en clair sur Internet.
-
Il faudrait que youscribe laisse tourner un serveur http et regarde les headers des requêtes reçues. Ça serait intéressant pour mieux comprendre ...
-
Il écoute déjà sur le port 80, pour rediriger vers le site en https :
$ telnet www.youscribe.com 80
Trying 35.186.237.217...
Connected to www.youscribe.com.
Escape character is '^]'.
GET / HTTP/1.0
Host: www.youscribe.com
Referer: https://lafibre.info
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0
HTTP/1.0 301 Moved Permanently
Server: nginx
Date: Tue, 16 Oct 2018 20:43:52 GMT
Content-Type: text/html
Content-Length: 178
Location: https://www.youscribe.com/
X-UA-Compatible: IE=Edge,chrome=1
Via: 1.1 google
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
Connection closed by foreign host.
Il faut donc juste une capture qui filtre sur le port 80.
-
Et avoir de gentils testeurs chez Bytel mobile :)
@youscribe, on pourrait envisager ce test ?
-
On peut tenter avec n'importe quel serveur, mais ils ne semblent rien envoyer dans les headers par défaut, c'est peut-être limité à une liste.
En utilisant 62.34.202.116, le serveur est contacté par 62.34.202.104, ou 2001:860:de00:3000::86 (IPv6 par défaut, obtenue en testant avec ip.lafibre.info).
$ curl -vvv --resolve httpbin.org:80:62.34.202.116 httpbin.org/get
* Added httpbin.org:80:62.34.202.116 to DNS cache
* Hostname httpbin.org was found in DNS cache
* Trying 62.34.202.116...
* TCP_NODELAY set
* Connected to httpbin.org (62.34.202.116) port 80 (#0)
> GET /get HTTP/1.1
> Host: httpbin.org
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Connection: keep-alive
< Server: gunicorn/19.9.0
< Date: Tue, 16 Oct 2018 23:11:26 GMT
< Content-Type: application/json
< Content-Length: 133
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Credentials: true
< Via: 1.1 vegur
<
{
"args": {},
"headers": {
"Accept": "*/*",
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "curl/7.58.0"
},
"origin": "62.34.202.104",
"url": "http://httpbin.org/get"
}
Le serveur semble aussi pouvoir fonctionner comme proxy HTTP.
C'est presque la même chose qu'avec le DNS menteur : seule la ligne "GET / HTTP/1.1" est remplacée par "GET http://hostname/ HTTP/1.1", mais il suit toujours le header "Host: xxxx" pour savoir à quel serveur il doit faire suivre.
En mode proxy, la méthode CONNECT fonctionne pour le HTTPS (mais dans ce cas bien sûr il ne peut pas y avoir interception).
"curl --proxy 62.34.202.116:80 https://www.youscribe.com" fonctionne par exemple.
Dans ce cas, il utilise bien le serveur donné par "CONNECT www.youscribe.com:443 HTTP/1.1", même si on force "Host: lafibre.info" par exemple.
Pour les noms de domaine qu'il n'arrive pas à résoudre, il retourne une erreur 404 en http, et une redirection en https.
curl -vvv --proxy 62.34.202.116:80 https://nonexistent.domain
* Rebuilt URL to: https://nonexistent.domain/
* Trying 62.34.202.116...
* TCP_NODELAY set
* Connected to 62.34.202.116 (62.34.202.116) port 80 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to nonexistent.domain:443
> CONNECT nonexistent.domain:443 HTTP/1.1
> Host: nonexistent.domain:443
> User-Agent: curl/7.58.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 302 Moved Temporarily
< Location: http://wap.bouygtel.fr/?URL_Origin=nonexistent.domain%2F
< Content-Length: 0
<
* Received HTTP code 302 from proxy after CONNECT
* CONNECT phase completed!
* Closing connection 0
curl: (56) Received HTTP code 302 from proxy after CONNECT
-
On peut tenter avec n'importe quel serveur, mais ils ne semblent rien envoyer dans les headers par défaut, c'est peut-être limité à une liste.
Oui, le proxy ne modifie pas la page, c'est ce que j'avais observé quand j'étais client Bouygues.
Tu as regardé coté serveur ? C'est coté serveur que l'UID est rajouté, sur les requêtes du client.
Je vois que ZD-Net est passé en https => ils n'utilisent plus le proxy Bouygues pour avoir l'UID maintenant ?
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
-
Oui, le proxy ne modifie pas la page, c'est ce que j'avais observé quand j'étais client Bouygues.
Tu as regardé coté serveur ? C'est coté serveur que l'UID est rajouté, sur les requêtes du client.
Comme visible dans ma trace, j'ai utilisé http://httpbin.org/get : il retourne les headers qu'il a reçu dans sa réponse.
Il n'y a rien, donc peut-être qu'ils n'ajoutent un identifiant que pour les serveurs qui sont dans leur liste, et non pas toute page qui passe par leur proxy (ce que j'ai forcé ici, le DNS ne ment pas pour httpbin.org).
Je vois que ZD-Net est passé en https => ils n'utilisent plus le proxy Bouygues pour avoir l'UID maintenant ?
www.zdnet.fr => 146.185.42.33
Le DNS ne ment plus pour ce site effectivement.
-
Et avoir de gentils testeurs chez Bytel mobile :)
@youscribe, on pourrait envisager ce test ?
Bonjour,
Oui, je vais faire le test Vendredi.
Je pourrai récupérer un tel BT, donc je serai autonome pour faire un premier test.
Je vous posterai les résultats de Wireshark.
-
Embêtant ces interceptions(/mitm) pratiquées par Bouygues pour les forfaits mobile...
Au final on se retrouve avec un site inaccessible, a priori suite a un passage de HTTP a HTTPS. Est-ce un cas isolé ? (J'espère)
A moins d'avoir Android 9.0 avec l'option Private DNS (DNS over TLS) configuré et activé on peut dire que l'accès à youscribe.com est impossible pour les clients mobile Bouygues.
Une autre solution peut être d'utiliser l'app Intra (https://play.google.com/store/apps/details?id=app.intra&hl=fr (https://play.google.com/store/apps/details?id=app.intra&hl=fr)) elle permet l'utilisation de DNS over HTTPS pour les téléphones sur Android ou encore utiliser VPN mais c'est pénible de devoir en arriver là et surtout pas a la porté de tout le monde >:(
Je suis dispo si il y a besoin de testeurs
-
y'a pas moyen en changeant l'APN ?
-
curieusement en spammant le dig sur les serveurs Google, j'obtient de temps a autre une autre ip:
~$ dig +short www.youscribe.com @8.8.8.8
wpxy-proxyless.wip-ext.bouyguestelecom.fr.
212.195.244.75
~$ dig +short www.youscribe.com @8.8.8.8
wpxy-proxyless.wip-ext.bouyguestelecom.fr.
62.34.202.116
-
y'a pas moyen en changeant l'APN ?
Si c'est possible de bypass ce blocage en modifiant son APN, je veux bien la méthode :)
Mais on en revient au même point: c'est pas trivial pour les non geeks de changer un APN.
-
L'APN n'y songez pas, vous pouvez mettre n'importe quoi il est modifié à la volée vers le bon APN.
Vous avez testé avec l'APN lafibre.info ? Je pense que le fonctionnement est identique.
kgersen pour les résultats différents, c'est en fonction du TTL ?
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
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.
-
kgersen pour les résultats différents, c'est en fonction du TTL ?
non je ne peux changer le TTL sur le smartphone.
C'est un dig depuis Windows en wifi sur le smartphone qui partage la connexion 4G.
si je spam "dig +short www.youscribe.com" j'obtient toujours la meme IP ( 62.34.202.116 )
si je spam "dig +short www.youscribe.com @8.8.8.8" j'obtient une des 2 IPs...
environ 1/2 seconde entre chaque dig:
~$ dig +short www.youscribe.com @8.8.8.8
wpxy-proxyless.wip-ext.bouyguestelecom.fr.
212.195.244.75
~$ dig +short www.youscribe.com @8.8.8.8
wpxy-proxyless.wip-ext.bouyguestelecom.fr.
212.195.244.75
~$ dig +short www.youscribe.com @8.8.8.8
wpxy-proxyless.wip-ext.bouyguestelecom.fr.
212.195.244.75
~$ dig +short www.youscribe.com @8.8.8.8
wpxy-proxyless.wip-ext.bouyguestelecom.fr.
212.195.244.75
~$ dig +short www.youscribe.com @8.8.8.8
wpxy-proxyless.wip-ext.bouyguestelecom.fr.
212.195.244.75
~$ dig +short www.youscribe.com
wpxy-proxyless.wip-ext.bouyguestelecom.fr.
212.195.244.75
~$ dig +short www.youscribe.com @8.8.8.8
wpxy-proxyless.wip-ext.bouyguestelecom.fr.
212.195.244.75
~$ dig +short www.youscribe.com @8.8.8.8
wpxy-proxyless.wip-ext.bouyguestelecom.fr.
212.195.244.75
~$ dig +short www.youscribe.com @8.8.8.8
wpxy-proxyless.wip-ext.bouyguestelecom.fr.
62.34.202.116
~$ dig +short www.youscribe.com @8.8.8.8
wpxy-proxyless.wip-ext.bouyguestelecom.fr.
62.34.202.116
~$ dig +short www.youscribe.com @8.8.8.8
wpxy-proxyless.wip-ext.bouyguestelecom.fr.
212.195.244.75
~$ dig +short www.youscribe.com @8.8.8.8
wpxy-proxyless.wip-ext.bouyguestelecom.fr.
212.195.244.75
-
Pour moi le TTL ne semble rien changer (ou alors le changement de TTL sur le téléphone n'a pas d'effet sur les requêtes DNS).
J'obtiens aléatoirement l'une ou l'autre des deux IP.
En tout cas je trouve bizarre que le DNS continue de mentir pour www.youscribe.com : il faut plus de deux jours à Bouygues pour l'exclure de la liste ?
-
y'a pas un site ou un outil ligne de commande qui affiche le ttl restant des packets entrants ?
-
Non, ce n'est pas possible, car le TTL se décrèmente a chaque routeur.
Donc il est impossible pour un site web en regardant un TTL de savoir si c'est un client en mode modem ou directement le smartphone.
Par contre l'opérateur qui met sa plateforme juste après le passage au niveau 3 des paquets (car le trafic d'une antenne mobile, les paquets sont encapsulés) il est possible de savoir si le périphérique est en mode modem ou non.
-
J'ai vérifié avec "tcpdump -v udp port 53" en root sur mon téléphone, la valeur de /proc/sys/net/ipv4/ip_default_ttl affecte bien le TTL des requêtes DNS.
En plus du TTL par défaut de 64, j'ai essayé 31, 63, 65, 126, 127 et 255, en interrogeant le DNS de Bouygues ou 8.8.8.8 pour www.youscribe.com.
C'est le DNS menteur qui me répond dans tous les cas, je n'observe aucune différence.
J'arrive également à me connecter à 62.34.202.116 quelle que soit la valeur du TTL (>=5, ce qui correspond au nombre de sauts dans le réseau).
Bref, aucun comportement spécifique en fonction du TTL pour moi.
-
Non, ce n'est pas possible, car le TTL se décrèmente a chaque routeur.
Donc il est impossible pour un site web en regardant un TTL de savoir si c'est un client en mode modem ou directement le smartphone.
Par contre l'opérateur qui met sa plateforme juste après le passage au niveau 3 des paquets (car le trafic d'une antenne mobile, les paquets sont encapsulés) il est possible de savoir si le périphérique est en mode modem ou non.
ca n'était pas ma question. je cherche juste un site/outils qui affiche le ttl restant a l'arrivé, pas celui d'origine.
-
ca n'était pas ma question. je cherche juste un site/outils qui affiche le ttl restant a l'arrivé, pas celui d'origine.
Je ne connais pas de site qui donne l'information.
On peut soit déduire la valeur en connaissant le TTL de départ et en comptant les sauts sur un traceroute/tracepath (sous réserve que le modem n'y touche pas), mais ça peut être incorrect en cas de gestion particulière de certains types de trafic (règle iptables, ...).
Mais de toute façon, même capturant les paquets sur un serveur sur lequel on se connecte, il n'est pas possible de le faire pour des requêtes DNS puisque tout est rerouté vers le serveur de Bouygues.
-
Bonjour,
Je n'ai pas eu le temps de faire la capture Wireshark.
Bouygues Telecom a modifié la config, ça fonctionne de nouveau.
Merci à tous.
-
Bonjour,
Je n'ai pas eu le temps de faire la capture Wireshark.
Bouygues Telecom a modifié la config, ça fonctionne de nouveau.
Merci à tous.
Ohhh :'(
Faut demander un retour arrière ;D
-
S'ils avaient pu en profiter pour arrêter l'interception DNS...
-
Bonjour,
J'ai exactement le même problème sur mon site.
Pour ceux qui veulent effectuer le test et faire des captures (je ne suis pas chez bouygues perso) : https://www.esport-loot.fr
@youscribe : peux-tu me donner les informations de contact Bouygues en MP ? Est-ce résolu rapidement après contact ?
-
Bonjour esportloot,
Le problème se produit depuis que ton site est passé en https ou depuis qu'il est passé en IPv6 ?
Tu es chez OVH, il y a eu un changement d'hébergement ?
L'IPv4 qui doit être utilisée est bien 51.83.33.32 et l'IPv6 2001:41d0:404:200::1fab quel que soit l'opérateur ?
-
Merci pour la réponse Vivien,
Le https est mis en place depuis le lancement en Octobre (NDD néanmoins réservé en 2016 avec à une période un site démo, mais normalement sans consultation depuis Bouygues), mais j'ai pas mal galéré et dû changer le certificat il y a quelques mois. Au lancement il y avait une redirection en place vers une landing page. Je suis sur un VPS OVH que j'administre, et j'ai également effectué quelques modifications au niveau du serveur, notamment pour la mise en place du Cache Varnish. Je n'ai pas de configuration particulière en fonction de l'opérateur, le problème vient bien de chez Bouygues pour moi, les éléments évoqués auparavant dans cette discussion colle parfaitement malheureusement ... Voilà pour les éléments me concernant, du moins les choses qui pourraient avoir généré le problème chez eux. Et d'après mes recherches sur le sujet, j'ai pu voir qu'à certains moment des gros sites comme Castorama et ING Direct avaient aussi été impacté il y a quelques années.
-
Trouvé : ton site ne répond pas en IPv6 (quel que soit l'opérateur).
Les mobiles Orange et Bouygues Telecom étant en IPv6 only, aucun fallback IPv4 n'est possible.
As-tu testé avec un mobile Samsung chez Orange ? Je suis presque sur que cela ne va pas fonctionner.
Il faut juste que corriger la connexion IPv6 :
(https://lafibre.info/images/ipv6/202003_site_inacessible_ipv6_2.png)
Un moyen de vérifier si tu n'a pas de connexion IPv6, c'est SSL Labs : Le site est noté B en IPv4 (il faudrait supprimer TLS 1.0 et TLS 1.1 pour avoir la note A) et non accessible en IPv6 :
(https://lafibre.info/images/ipv6/202003_site_inacessible_ipv6_1.png)
-
Arf, effectivement, je vais regarder tout ça. Merci pour le retour, moi qui pensait que ça provenait de Bouygues. :-[
Je vais tâcher de corriger tout ça ;)
PS : Pas de problème chez Orange dans tous les cas (j'ai redemandé un test), seulement Bouygues malheureusement.
-
@youscribe : peux-tu me donner les informations de contact Bouygues en MP ? Est-ce résolu rapidement après contact ?
Bonjour @esportloot,
J'arrive un peut tard :) mais je réponds quand même à tes questions : Je n'ai pas contacté BT directement, je suis passé par un partenaire qui a un contact privilégié là-bas.
Ca a été résolu en 4 jours.
-
Je ne sais pas quel est le comportement de iOS face à un blocage d'IPv6, mais pour Android, voici la liste des terminaux qui ne peuvent pas charger ton site, il y en a chez Orange, quelques Samsung :
Voici les terminaux concernés, dans leur dernière version logicielle, par une activation d’IPv6 :
(https://lafibre.info/images/ipv6/201911_arcep_barometre_ipv6_mobile_5.png)
4.4. Vers une obligation de compatibilité IPv6 dans les réseaux mobiles
En juillet 2019, l’Arcep a mis en consultation publique un projet de modalités et conditions d’attribution d’autorisations d’utilisation de fréquences dans la bande 3,4 ‑ 3,8 GHz, en France métropolitaine, fréquences qui seront utilisées pour la 5G.
L’Arcep a proposé, dans le projet soumis à consultation publique, une obligation de support d’IPv6, pour les opérateurs qui candidatent à l’attribution de ces fréquences : « Le titulaire est tenu de rendre son réseau mobile compatible avec le protocole IPv6 à compter du 31 décembre 2020 ». L’objectif, tel que précisé dans les motifs, est d’assurer l’interopérabilité des services et ne pas freiner l’utilisation de services uniquement disponibles en IPv6, dans un contexte d’augmentation du nombre de terminaux et d’une pénurie d’adresses IPv4 au RIPE NCC.
-
Merci pour le retour @youscribe !
Et merci pour le détail des appareils, effectivement, le test n'était pas sur un des mobile listé.
-
Trouvé : ton site ne répond pas en IPv6 (quel que soit l'opérateur).
Les mobiles Orange et Bouygues Telecom étant en IPv6 only, aucun fallback IPv4 n'est possible.
Comment ça aucun fallback ipv4 possible ? :o
Le DNS64 et le 464XLAT sont quand même actifs, sinon les clients Orange et Bouygues n'auraient plus accès à 75% du web qui est encore ipv4-only... ce qui serait un TRES GROS problème.
J'ai dû mal à comprendre ta réaction Vivien.
-
la fallback, c'est un mécanisme intégré dans les navigateurs et certains logiciels qui tentent la connexion en IPv6 et qui vont plus ou moins rapidement basculer en IPv4 si le site n'est pas joignable en IPv6. Avec certins il se déclenche après quelques centaines de ms sans réponse, pour d'autres il faut attendre plusieurs secondes avant de basculer en IPv4.
Si vous avez une connexion fixe avec de l'IPv6 vous pouvez faire une capture wireshark : la connexion commence en IPv6 avant de basculer en IPv4 faute de réponse.
Quand on a une connexion IPv6 only (Bouygues et Orange sur le mobile), les sites IPv4 only passent par le DNS64/NAT64 (le DNS64 attribue des IPv6 aux sites IPv4 only, IPv6 qui pointent vers la plateforme NAT64) et les sites IPv6 sont en direct, sans possibilité de passer en IPv4 en cas d'échec en IPv6.
Orange a déjà contacté des sites web qui avaient une IPv6 qui ne fonctionnaient pas, mais ils n'ont visiblement pas contacté esportloot.
Deux actions sont possibles pour esportloot pour que son site soit de nouveau joignable en IPv6 only :
- Réparer l'IPv6 (Je recommande, cela permet d'assurer la meilleur QoS)
- Supprimer l'IPv6 (dans ce cas là, le mobile utilisera toujours de l'IPv6, mais une IPv6 qui ira vers le NAT64 et plus directement chez OVH)
-
Ha ok je comprends mieux, merci pour l'explication.
Mais qu'est-ce qui empêche le navigateur de fallback en ipv4 via l'interface 464XLAT (192.0.0.4) ?
-
Mes souvenirs me reviennent, c'est sur iOS, et non sur Android que l'impossibilité de charger un site avec une IPv6 a été constaté.
Je ne sais pas si sous Android, avec l'utilisation du 464XLAT cela permet un fallback vers IPv4.
-
Du coup ça semble être résolu de mon côté grâce à tes précieux conseils vivien. Merci encore ! :)