Messages récents

Pages: 1 2 3 4 5 [6] 7 8 9 10
51
Bbox fibre Installation Bbox fibre / BBox Ultym & lease DHCP en double
« Dernier message par obinou le Aujourd'hui à 08:48:55 »
Bonjour !

Je rencontre un drôle de problème avec ma BBox Wifi 6E (celle en forme de pyramide tronquée).

J'ai chez moi un hôte proxmox , sur lequel je créé & détruit régulièrement des VM.
Les VM sont en pont , en DHCP, classique, avec une plage définie dans la box entre 192.168.166.10 et 192.168.166.90
(J'ai des machines en IP fixe en dehors de cette plage et la box est en 192.168.166.1).

Et de temps en temps, la box affecte la *même* IP à 2 VM.
Et c'est pas juste temporaire : Si j'analyse le trafic et que je reboot l'une ou l'autre des VM, elles reçoivent bien la même IP en DHCP depuis la box.
Elles ont évidemment ni la même adresse mac, ni le même clientid.
En IPv6 le DAD fait son taf et détecte la collision, mais en IPv4, ça gêne absolument pas la box de filer 2x la même IP
et même quand on regarde dans son interface je vois bien les 2 machines, chacune avec son nom, leurs 2 mac, .... et la même IP v4.

Au début je me disait que c'était parce que la plage était pleine, mais même pas il y a des IP (entre 80 et 90) qui n'ont *jamais* été attribuées ,
y compris sur des machines "anciennes" (du point de vue de la liste de la box).

Vous avez déjà vu ça ? J'veux dire, j'ai jamais eu ça avec DNSMasq (qui je crois ping une IP avant de l'attribuer)


J'ai aussi d'autres problèmes avec cette box, entre autre que le nom des machines (clientid) remonte mal donc parfois on peux pinguer /ssh la nouvelle VM par nom et desfois pas,
ou le fait qu'on peux *ajouter* des serveurs DNS mais pas remplacer complètement celui de la box ce qui fait que dans la réponse DHCP il y a les 3,ça devient du round-robin,
et une fois sur 3 tu peux plus résoudre tes noms interne (et on peux pas dire de ne *pas* publier le DNS 192.168.166.1).

Mais bon... ça à la limite c'est "par design" donc j'assume...


edit En fait c'est pire que ca : TOUTE les VM que je créé ou les machines que je connecte sans lease connu en DHCP maintenant se voient attribuer 192.168.166.67, sauf à les forcer en adressage statique.
=> Pour moi ya clairement un bug. L'uptime de la box est de 38 jours . Je vais la rebooter & retester dans 1 mois ? ;-)
52
Bistro Bistro / Je veux lister les "bons" et les "mauvais" FAI pour l'auto-hébergement
« Dernier message par basilix le Aujourd'hui à 08:14:37 »
@Furiousnp :

Beaucoup de gens ne seront pas d'accord avec moi. Mais je vois mal comment maintenir un avis objectif sur plusieurs opérateurs.

Prenons ton opérateur actuel.

Pour moi, la note attribuée à Orange n'est pas fixe. Les critères présentés peuvent évoluer.

MilkyWAN propose un abonnement autour de 60/70€ par mois contre 25€ par mois pour Sosh. Orange propose des débits atteignant
8 Gbps symétrique contre 2 Gbps pour MilkyWAN. Je pense que l'offre MilkyWAN est efficace pour un accès professionnel. On a bien
compris que l'offre Orange Fibre résidentielle n'était pas adaptée pour faire de l'auto-hébergement. Mais les plus techniques peuvent
remplacer leur Livebox avec un peu d'effort et disposer d'une offre de services éventuellement réduite mais quasiment « pro » avec
un bon support. Tout le monde n'y arrive pas mais c'est possible. Je sais aussi qu'il y a une marge de progression pour rendre ce
processus de remplacement de boîtier Internet plus fiable et accessible. En d'autres termes, la note actuelle de 6/10 peut très bien
s'élever à 9/10. Cela rend ce classement moins pertinent.

Je ne comprends pas non plus les qualificatifs employés. Cela arrange de clamer que la méthode n'est pas « officielle » mais cela
recouvre plusieurs réalités. C'est compliqué à suivre et potentiellement contraignant mais issu des standards. C'est d'ailleurs via de
la rétro-ingénierie que cela a été rendu possible. On voit de l'ouverture également avec le support officieux d'Orange.
53
A mon avis, l'une des difficultés lors de ces fuites est de déterminer ce qui a exactement fuité, et pour quels abonnés. Il faut prévenir ceux qui ont été concernés, mais pas 20 millions de personnes si seulement 2 millions sont concernées. Sinon, on inquiète de nombreuses personnes pour rien.

Constater qu'il y a eu une fuite, et que des données sont en vente sur le dark web, c'est une chose, l’ampleur et qui est concerné exactement une autre.
Certes...
Quoi qu'il en soit, et au final, je suis persuadé qu'ils ne savent pas réellement quel est le nombre exact  ::)
54
Normalement il n'y a pas de raison que le SSID change tout seul, mais par exemple je ne vois pas à quoi correspond la "fibre de secours".
Si jamais la Livebox a été réinitialisée à ses réglages d'usine et n'a pas restauré une sauvegarde, alors elle a pu repasser d'un SSID et mot de passe personnalisés à ceux par défaut.

En revanche, le "Type de sécurité" peut être changé par Orange : ils ont passé des Livebox de l'ancienne valeur par défaut "WPA2/WPA3 Personal" à "WPA3 Personal Compatibility".
Donc si jamais c'est la seconde valeur qui est actuellement choisie, il faudrait tester de remettre la première.
55
Pourquoi le SSID serait-il changé à votre avis ? Merci
56
Orange fibre Installation fibre Orange / Décodeur TV-Orange, télécommande, batterie
« Dernier message par hwti le Aujourd'hui à 00:59:16 »
L'image est celle du TV4, celle du décodeur UHD est similaire, mais avec en haut un petit trou pour le micro et une LED.
57
Pour le SSID, s'il avait changé il aurait fallu se reconnecter sur les PC / smartphones aussi (sélection du réseau et saisie du mot de passe).
Dans tous les cas, je suppose qu'il devrait être possible de lister les réseaux Wifi sur l'imprimante et tenter de se connecter à nouveau.

Dans la configuration du Wifi de la Livebox, quelle est la valeur de "Type de sécurité" (dans les paramètres avancés) ?
Peut-être que Orange a changé le réglage pour "WPA3 Personal Compatibility", et que l'imprimante n'aime pas.
58
En effet c'est consternant !  >:(

Et comme indiqué ici : https://www.frandroid.com/marques/sfr/3217085_red-by-sfr-victime-dune-fuite-de-donnees-les-abonnes-prevenus-seulement-7-semaines-apres-lattaque
7 semaines après ils commencent juste à prévenir les clients ... ça mérite une plainte à la CNIL rien que pour ça !

A mon avis, l'une des difficultés lors de ces fuites est de déterminer ce qui a exactement fuité, et pour quels abonnés. Il faut prévenir ceux qui ont été concernés, mais pas 20 millions de personnes si seulement 2 millions sont concernées. Sinon, on inquiète de nombreuses personnes pour rien.

Constater qu'il y a eu une fuite, et que des données sont en vente sur le dark web, c'est une chose, l’ampleur et qui est concerné exactement une autre.
59
Orange ADSL / VDSL / Que faire sans ADSL?
« Dernier message par brupala le Hier à 23:10:54 »
Fin du cuivre par anticipation,
il y en aura d'autres, il y en a déjà eu.
Mais ça n'est pas une raison pour ne pas fibrer, même des logements isolés, par contre le statut dans ce cas est particulier si il n'y a pas d'énergie fournie non plus, il y a un abonnement à l'eau ?
60
Wi-Fi WiFi / Le wifi dans les TGV SNCF
« Dernier message par hwti le Hier à 23:10:17 »
- Si vous laissez la résolution DNS par notre serveur, il y a une surcouche DNS Filter qui pourra bloquer certains domaines considérés comme malveillants/malwares/etc. J’ai lu des cas de problèmes avec du DOT, je suis preneur d’exemples/traces complémentaires, si vous me confirmez par ailleurs le contexte de votre cas d’usage.
Dans les tests décrits plus haut, j'étais sur un PC Linux, et j'ai d'abord chargé le portail captif et autorisé l'accès.
Pour un utilisateur lambda le service peut être considéré comme fonctionnel (le DNS fourni par le réseau répond).

Mais comme il y avait eu des messages ici, j'ai voulu faire des tests :
 - requêtes DNS sur le port 53 (UDP / TCP) vers 1.1.1.1 / 8.8.8.8 / 9.9.9.9, et même "curl -o /dev/null https://appliwave.testdebit.info:53/1G.iso" (donc du TLS sur le port TCP 53) : aucune réponse sur aucun des serveurs
 - tests DoT avec l'outil https://github.com/natesales/q : dns.quad9.net semblait bloqué, unfiltered.joindns4.eu répondait
 - tests DoH manuels, comme par exemple "curl --insecure -H "accept: application/dns-json" "https://cloudflare-dns.com/dns-query?name=example.com&type=A" : Cloudflare / Google / Quad9 sont interceptés par dnsfilter, avec une réponse en HTML, alors que d'autres passent
Donc clairement il y a un blocage du port 53, des blocages DoT, et des interceptions DoH.
Malheureusement j'ai manqué de temps sur la fin, et je n'ai pas sauvegardé les captures, donc je ne sais pas si côté DoT / DoH il s'agissait de DNS menteur (sur la résolution initiale via le DNS de la connexion), d'un blocage d'IP, ou d'un blocage via la reconnaissance du SNI dans le handshake TLS (Client Hello).
Pages: 1 2 3 4 5 [6] 7 8 9 10