Cette Livebox est vraiment bonne à jeter (l’opérateur avec ?)

Cet article a été publié il y a 3 ans 3 mois 28 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

UPDATE DU 01/03/2021 : Une mise à jour 4.01.12 installé le 17 février a permis de corriger le tir du Hairpinning. Le reste des griefs est toujours d’actualité, et les travaux pour trouver un remplaçant n’ont pas trop avancé :/

J’avais déjà évoqué quelques frustrations par rapport au retour en arrière fonctionnel de la Livebox 4 face aux Freebox dans mon billet sur le passage à la fibre. Il se trouve que non seulement, je n’ai pas pu faire grand chose de plus pour l’instant, mais une mise à jour poussée et forcée en mon absence a carrément empiré les choses. Comment est-ce possible en 2020 ?

Petit rappel de la situation : je suis déjà dans une situation bizarre qui est que j’utilise le service DHCP de mon NAS plutôt que celui intégré car il ne permet pas de contrôler la définition des résolveurs DNS. Orange fait en effet le choix d’imposer les siens, officiellement pour se conformer aux décisions de justice qui consistent à mentir en permanence à ces abonnés (d’ailleurs le droit est rigolo, ils sont condamnés à bloquer des sites alors qu’ils n’en sont pas les administrateurs, qui eux restent inattaqués, Benjamin Bayart l’avait très bien décrit).

Ce que je n’avais pas détaillé par contre, c’est que mon monitoring externe, qui surveille essentiellement la disponibilité du NAS il faut bien l’avouer, ne fonctionnait plus après ce passage chez Sosh. Là aussi, c’est rigolo, mais le ping entrant est bloqué, hors pour valider la présence ou pas d’une machine avant d’aller interroger ses ports, LibreNMS tente un ping (qui a le bon goût d’être très léger). Pas pratique donc, surtout quand on teste l’interrogation SNMP et que tout fonctionne sans problème :/ J’avais pu là encore « contourner » le souci, en basculant le pare-feu de la Livebox en mode personnalisé, qui propose une case « autoriser le ping depuis l’extérieur ». Et magie, ça fonctionnait de nouveau :

Et le reste ne posait pas de problème non plus. J’en étais donc resté là, reprenant mes activités (mon boulot surtout, encore en télétravail), et relançant une petite recherche de temps en temps pour trouver une solution qui ne relève pas du bricolage du dimanche.

La mise à jour de décembre : Joyeux Noël de merde !

J’ai passé la fin novembre et une bonne partie du mois de décembre chez ma mère, donc à distance, tout fonctionne à merveille : git, smokeping, nas, j’accède à tout ce dont j’ai besoin en cas de besoin. Et puis au détour d’une discussion sur Telegram avec Édouard, on évoque un nouveau souci avec la Livebox, en gros, on arrive plus à communiquer avec les services exposés via NAT sur l’adresse IP publique de la box. Il parle de DNS Loopback, c’est en fait du Hairpinning dont on parle, donc de NAT (et vous savez comme j’aime le NAT…) et qui semble-t-il a sauté avec la mise à jour déployée mi-décembre. Pour les non-anglophones, j’expose les ports 80 et 443 que je redirige vers mon master kube, si depuis mon laptop en wifi (donc en local) je tape l’adresse IP publique de la connexion sur ces ports-là, la box est censée rediriger la connexion vers la machine cible locale — le master kube donc–, comme elle le fait quand les connexions viennent réellement de l’extérieur. Sauf que non. Un problème que j’avais déjà avec la box NordNet de l’enfer de ma maman, et dont je pensais être épargné chez moi, avec un matériel que je pensais mieux maîtrisé. Mais un rapide test en me connectant en SSH sur une VM et un test curl rapide me le confirment, ça ne fonctionne plus !

Pire, en tentant une connexion HTTPS, c’est le certificat de l’interface d’administration de la Livebox qui est présentée ! En un sens, et encore heureux, ce n’est pas un énorme problème de sécurité, puisque le NAT fonctionne parfaitement depuis l’extérieur, ça ne se produit que si on est connecté de l’intérieur. Mais du coup, tout ce qui est paramétré pour taper sur un DNS public, DNS qui en plus est mis à jour automatiquement parce que pas d’IP fixe — oui, toujours en 2020 — (je partagerai peut-être le playbook d’install de ddclient que j’ai fait pour le dynhost OVH), ben tout ça ne fonctionne plus dès qu’on repasse derrière la bobox. N’étant pas chez moi à la découverte de ce nouveau coup de poignard dans le dos, et pour l’instant n’ayant pas de services hébergés communiquant entre eux via les entrées publiques (ce qui viendra quand j’implémenterai Keycloak), j’ai patienté pour mon retour. Le seul contournement que j’ai pu trouver, c’est une modification forcée du fichiers hosts de la machine pour mentir à mon PC et dire que certains des domaines « publics » pointent en fait sur une IP privée, celle du master kube toujours; on peut aussi, si on a un résolveur DNS maison, l’appliquer à ce niveau pour en bénéficier sans reconfigurer chaque appareil. Une nouvelle bidouille sur un tableau de bidouilles déjà beaucoup trop rempli à mon goût.

Je suis rentré jeudi midi juste avant Noël, j’avais donc autre chose à faire (comme passer l’après-midi à bosser). Samedi matin, je finis de rebrancher le gros PC, relance quelques softs, et là, nouveaux problèmes : Client Steam en PLS, Battle.net en mode Hors ligne. Lapin compris. Steam dispose d’un journal texte dans ses dossiers, je vais voir, et je découvre ça :

C’est pas beau, même si on est content d’utiliser un peu d’IPv6 (promis je m’arrange pour que ça soit le cas l’année prochaine pour le blog et son Matomo), je découvre qu’il tente de se connecter en UDP. C’est surprenant, surtout pour des étapes simples d’authentification du client, et surtout quand on sait que le client Steam est surtout constitué d’un cœur Chromium, un navigateur web donc, le web étant basé sur TCP. Mes soupçons se tournent donc vers un souci de flux réseau. Je ressors ma configuration VPN perso, sur laquelle le client OpenVPN gueule allègrement parce que les options mises en places y’a plus de 10 ans sentent la naphtaline en terme de sécurité (compression lzo, cipher BF-CBC, et le certificat date un peu et sa clé doit pas être jojo). L’idée, c’est de tester si la connexion Steam à travers le VPN fonctionne aussi, car je n’ai aucun indice sur les forums ou Twitter qu’il y a un incident en cours.

Je n’arrive même pas jusque là. Le VPN fail aussi misérablement, avec le même symptôme à savoir que ça reste bloqué à une certaine étape, attendant inlassablement une réponse; et là, je redécouvre que mon VPN aussi tente une connexion UDP à l’extérieur. C’est donc définitivement un souci avec la bobox, et ma première idée se tourne vers le pare-feu. La bascule en mode personnalisé n’avait pas posé de souci particulier à l’époque, mais quand on a plusieurs services en carafe, c’est soit un souci avec le matériel réseau, soit un souci avec l’opérateur en face, et ça, je l’aurai vu sur Twitter ou autre. Je rebascule le pare-feu dans le mode par défaut, à savoir « Moyen », Et là, instantanément, le VPN se connecte ! Je confirme dans la foulée avec une connexion Steam et Battle.net, qui se connectent quasi instantanément. Je rebascule sur le mode personnalisé, tout cassé.

J’ai tenté le support Chat. Voilà.

Après tout, j’ai déjà réussi à me débloquer pour mon abonnement Xbox Live de cette manière, donc pourquoi pas ? Oui mais nous sommes en France, et mon abonnement n’est qu’un abonnement Sosh, ça peut faire toute la différence.

Et en effet, ça n’a pas été de tout repos. Déjà, si vous utilisez uBlock Origin, au départ vous n’avez même pas le bouton pour démarrer le chat. Mmmmok… Je désactive temporairement, je lance le chat, on commence par me demander mon nom et le numéro de ligne pour démarrer, et quand je pose ma question, on m’arrête pour me redemander ces infos plus quelques autres supplémentaires. Au passage c’est pas la peine de me demander tout de suite ce qui ne vas pas si c’est pour ne pas répondre tout de suite. Dès que j’ai fini d’exposer le souci d’hairpinning, réponse :

On est pas rendu. On arrive à me détecter ceci dit un soi-disant problème de connectivité entre l’ONT et la box. L’ONT, pour ceux qui découvrent le domaine de la fibre, c’est un boitier qui fait la conversion entre la partie physique en fibre optique et une prise RJ45 « Ethernet » classique. Le câble qui opère la fameuse connectivité est neuf, deux mois, et la connexion a tourné très fort dès mon retour (transferts entre mon NAS et celui de ma mère), et ne présente aucun signe d’instabilité (15 jours sans déconnexion), mais on refuse de planifier une « intervention avec les experts » tant que ce « problème imaginaire » n’est pas réglé. Sauf que sans me prévenir ou me demander, on me redémarre la Livebox, ce qui met fin à la discussion puisque au-delà de la coupure prolongée que ça engendre, je change d’adresse IP évidemment ! ddclient fait admirablement son taf et mes DNS sont à jour. Sans surprise, malgré avoir transmis mon numéro de mobile, personne ne me rappelle.

Je suis en vacances, et dans l’immédiat j’ai autre chose à faire que de retenter ce genre de conneries, donc on contourne : je mens via le fichier hosts (sous Windows et Linux) en indiquant l’adresse IP du master kube pour certaines entrées DNS normalement publiques, le tout sur une seule ligne pour pouvoir commenter rapidement si besoin. Et j’active une maintenance sur LibreNMS pour éviter qu’il me pourrisse Telegram en indiquant que le NAS est down. Si j’ai bien un truc à faire, c’est me pencher sur l’utilisation de Prometheus en remplacement de LibreNMS finalement, même si je ne suis pas fan du tout HTTPS par principe.

Tout pour décourager l’auto-hébergement et le contrôle

Je n’ai pas la liste comparative des règles de pare-feu qui étaient en place avant la mise à jour et après. Il n’y a non plus aucune justification technique à la désactivation du hairpinning, à part vouloir décourager une fois de plus l’hébergement de services persos à domicile, et on sait qu’Orange & co adorent quand vous utilisez votre connexion à sens unique, comme à la grande époque du Minitel. Sauf s’ils considèrent que ça pouvait impacter l’utilisation de certaines fonctions de la box TV maison, et tant pis si on flingue un écosystème derrière. Vous avez de la domotique maison ? Mais vous savez qu’on a aussi une gamme pour brancher sur votre Livebox ? On vous le fait même par abonnement pour que ça coute moins cher (mais on vous dit pas que plus rien fonctionne quand on paie plus).

Le problème, c’est que mes différentes recherches semblent m’indiquer que j’ai besoin d’un master réseau pour pouvoir faire sauter cette calamité de box pour disposer du bon niveau de connectivité (surtout IPv6), la configuration semble plus que compliquée pour des néophytes, sans parler du matériel nécessaire qui a besoin de fonctions spécialisées comme la gestion des VLAN, et je pense que c’est voulu. Au moins avec Free c’est clair et net, l’authentification se fait avec l’identification matérielle de la box (qui pour rappelle n’appartient pas à l’abonné mais est prêtée à titre gratuit — sauf le player Devialet, mais le player seulement), donc en dégroupage total pas d’alternative à part le mode bridge, sachant qu’il propose aussi un mode DMZ.

Cette DMZ est aussi une alternative possible sur la Livebox, mais ça implique d’avoir deux matériels branchés au lieu d’un, et la consommation induite n’est pas nulle pour des appareils destinés à rester branché H24; oui parce que si j’avais une IP fixe encore, je pourrais dire « coupe la nuit », mais là c’est cuit, et ça me gave de changer tous les jours d’IP, surtout après 14 ans de « vrai » réseau. Et passer son temps à allumer/éteindre un appareil électronique lui fait aussi beaucoup de mal au fil du temps.

La recherche continue donc pour retrouver la maîtrise et la fonctionnalité normale d’un réseau local, pour quelqu’un qui fait un peu de l’internet plutôt qu’en être un simple spectateur/consommateur. En attendant, à part vous conseiller d’éviter un opérateur qui ne vous veut pas du bien, j’ai bien peu d’espoir pour l’Internet ouvert qui était pourtant un bien beau rêve. Trop peut-être…