Auteur Sujet: SFR: Routage vers 1.1.1.1 problématique (Lu 19600 fois)

K-L · « **Réponse #24 le:** 24 avril 2020 à 09:45:51 »

Citation de: buddy le 24 avril 2020 à 09:25:34

Bonjour,
pour ceux qui ont eu des problèmes, vous n'utilisez "que" 1.1.1.1 ?
vous n'avez pas mis 1.0.0.1 en secondaire (ou un DNS d'un autre service - Google, OpenDNS, Quad9, DNS FDN, ....).

Si, j'ai bien 1.0.0.1 en secondaire.

buddy · « **Réponse #25 le:** 24 avril 2020 à 09:46:58 »

Et du coup, tu as quand même eu des soucis de connexions ?
il ne bascule pas automatiquement sur le 2nd en cas de panne ?

K-L · « **Réponse #26 le:** 24 avril 2020 à 09:48:15 »

Si mais je pense que je n'ai pas dû mettre les deux DNS sur toutes mes machines (flemmard que je suis) car cela n'a pas impacté tous mes ordis. Mais je comrprends mieux pourquoi maintenant.

vivien · « **Réponse #27 le:** 24 avril 2020 à 15:53:56 »

Petit traceroute depuis ma connexion câble, c'est comme vous tous revenu, grâce a un salarié de SFR qui a réussi à escalader la chose (pas facile la veille d'un week-end avec confinement) :

$ mtr -bzrwc100 1.1.1.1 Start: 2020-04-24T15:30:41+0200 HOST: vivien Loss% Snt Last Avg Best Wrst StDev 1. AS??? _gateway (192.168.0.1) 0.0% 100 0.3 0.8 0.2 28.4 3.3 2. AS??? ? ? 100.0 100 3. AS21502 evy1rj-ge-1-1-5.200.numericable.net (195.132.10.177) 0.0% 100 7.0 8.3 5.9 30.8 3.7 4. AS15557 13.229.154.77.rev.sfr.net (77.154.229.13) 0.0% 100 7.5 7.3 5.9 10.2 0.8 5. AS15557 246.137.136.77.rev.sfr.net (77.136.137.246) 0.0% 100 8.6 8.6 7.5 15.6 1.0 6. AS15557 226.10.136.77.rev.sfr.net (77.136.10.226) 0.0% 100 10.8 9.3 8.2 12.8 0.8 7. AS15557 226.10.136.77.rev.sfr.net (77.136.10.226) 0.0% 100 9.3 8.8 7.9 11.3 0.6 8. AS13335 141.101.67.254 0.0% 100 11.0 17.8 9.1 81.7 15.2 9. AS13335 one.one.one.one (1.1.1.1) 0.0% 100 9.3 13.5 9.2 55.8 10.3

kazyor · « **Réponse #28 le:** 24 avril 2020 à 16:24:18 »

Citation de: DamienC le 23 avril 2020 à 22:49:34

Sans doute aucune idée une simple hypothèse.
Je me rappel qu'il y a quelques années maintenant j'avais posté un problème similaire de bouclage réseau mais vers un site du gov US.
J'ignore comment cela est possible.

Ici : https://lafibre.info/sfr-espace-technique/probleme-de-routage-gt-tracert-nist-gov/
A l'époque, c'était un bug sur la nouvelle version (6.2.3) déployée sur un ASR9010.

Pour hier, j'ai l’impression que petrus n'est pas mal sur ses hypothèses.

Solidus · « **Réponse #29 le:** 24 avril 2020 à 20:07:49 »

Sinon pour revenir sur les DNS de cloudfare 1.1.1.1, le gain rapidité et confidentialité est significatif ? couplé à un vpn ?

petrus · « **Réponse #30 le:** 24 avril 2020 à 20:33:54 »

cloudflare et confidentialité dans la même phrase, pas mal

https://iscloudflaresafeyet.com

K-L · « **Réponse #31 le:** 25 avril 2020 à 08:26:05 »

Citation de: petrus le 24 avril 2020 à 20:33:54

cloudflare et confidentialité dans la même phrase, pas mal

https://iscloudflaresafeyet.com

Ouais, en même temps, moi aussi j'aurais pu pondre une page sur Internet avec un article à charge.

La phrase marrante de la page : Instead of the user directly connecting to the intended website, the user is connected to Cloudflare's servers instead.

Voil, tout est dit

Zweit · « **Réponse #32 le:** 25 avril 2020 à 09:04:44 »

Vu que CF agit en tant que reverse proxy pour pas mal de sites, cette phrase est parfaitement vraie

K-L · « **Réponse #33 le:** 25 avril 2020 à 11:21:58 »

Citation de: Zweit le 25 avril 2020 à 09:04:44

Vu que CF agit en tant que reverse proxy pour pas mal de sites, cette phrase est parfaitement vraie

Je n'ai pas dit qu'elle nétait pas vraie, si tu suis mon raisonnement

StardustOne · « **Réponse #34 le:** 25 avril 2020 à 16:38:21 »

Pour ce qui est de la vie privée, je ne connais pas mieux que DNS_over_TLS aka DoT.

Avec comme fournisseur de DNS chiffré, LDN rattaché à FDN, Quad9 et beaucoup d'autres.

Ça se fait en quelques minutes sous Debian et Debian likes avec

Code: [Sélectionner]

apt install stubby
systemctl enable stubby
vi /etc/stubby/stubby.yml
systemctl restart stubby
echo 'nameserver 127.0.0.1' > /etc/resolv.conf
chattr +i /etc/resolv.conf

Ça me parait être une meilleur solution que les DNS de Cloudfare, google, FAI

alain_p · « **Réponse #35 le:** 26 avril 2020 à 12:12:31 »

Il y a une autre solution qui est d'installer son propre résolveur en local. Comme cela on n'interroge personne, et les requêtes ne passent pas par un serveur centralisé. Car même en TLS, c'est déchiffré au bout sur le serveur.

Et installer un résolveur local, c'est très simple avec unbound :
https://korben.info/installer-serveur-dns-unbound.html