Journal Lorsque la moitié d’internet est down…

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
24
5
juin
2024

Aujourd’hui, j’ai vécu une expérience « intéressante ».

J’ai récemment réinstallé mon laptop principal avec une Debian (directement passée en Sid) que je veux le plus minimaliste possible. Pas de bureau, pas de GNOME. Juste Sway, des terminaux, Firefox et quelques outils comme network-manager.

Depuis cette réinstallation, le laptop n’a pas quitté mon bureau où il fonctionne en ethernet. J’avais quand même testé le wifi et mon ordi se connectait bien, j’accédais à mon blog, pas de problème.

Sauf que cette après-midi, je dois aller dans le salon. Je débranche le cable ethernet, prend mon laptop qui se connecte automatiquement à mon wifi.

Jusque là, tout est normal. Je suis sur sourcehut sans problème, fait quelques recherches sur Kagi mais je réalise que je ne sais plus accéder à mes mails. Protonmail serait-il down? Je tente de vérifier.

Et là que je réalise que plein de sites, dont linuxfr, sont down. Mais d’autres ne sont pas affectés.

Une panne générale d’un lien chez mon fournisseur ?

Ça me semble assez bizzare…

Une intuition subite ! Et si…

Je vérifie !

Oui, tous les sites auxquels j’ai accès sont disponibles… en IPv6 ! J’ai donc réussi, sans le vouloir, à désactiver IPv4. Je retourne dans mon bureau, connecte l’ethernet et tout redevient à la normale.

Franchement, j’ai trouvé ça assez drôle et absurde. Ça m’a permit de voir à quel point nous ne sommes pas encore prêt pour l’IPv6.

Avez-vous déjà vu un truc similaire ?

Bon, à force d’investigation avec plusieurs Wifi et plusieurs tests, j’en suis arrivé à la conclusion suivante :

Si je démarre le service réseau (sytemctl restart networking.service) avec le câble ethernet branché, l’ethernet fonctionne normalement. Si je le déconnecte, le wifi se connecte mais ne fonctionne qu’en IPv6. Les logs sont d’ailleurs explicites (de mémoire, pas verbatim) : « Switching default to wlanXXX for IPv6 and DNS ». (et, du coup, rien ne fonctionne si je me connecte à un wifi sans support d’IPv6).

Par contre, si je redémarre le service réseau sans câble ethernet branché, le wifi fonctionne normalement. Mais si je branche le câble, alors le wifi est down mais le câble ethernet reste down également (selon "ip route"), et cela malgré que le port RJ45 clignote normalement.

C’est un problème qui n’arrive pas sur Ubuntu sur le même laptop donc c’est clairement un bug quelque part dans Debian. Je n’ai touché à rien dans la configuration réseau : je me suis contenté d’installer network-manager. Par contre, comme je n’ai pas GNOME, il me manque peut-être certains paquets.

Y’a-t-il une explication rationnelle à ce comportement ? En informatique, toujours… Il faut juste étendre le concept de rationnalité.

Pour le moment, le mystère reste entier !

  • # Conflit de services

    Posté par  . Évalué à 6.

    Ce ne serait pas un conflit entre Network Manager et le service networking de Debian ?

    Ou alors ils n'arrivent pas à relancer dhcpc après la première connexion…

    • [^] # Re: Conflit de services

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      Ce n’est a priori pas DHCP parce que revenir à l’ancienne connexion, physiquement, fonctionne (et, d’après les logs, il acquiert une nouvelle IP).

      Par contre, le conflit entre NM et le service networking de Debian, c’est une idée intéressante. Mais, depuis le passage à Systemd, je suis complètement à la ramasse donc je n’ai aucune idée de comment fonctionne le système networking de Debian.

      Ça m’intéresse de creuser parce que, si c’est un bug, ce serait intéressant que je le remonte pour le corriger. Mais faut que j’arrive à l’isoler.

      Mes livres CC By-SA : https://ploum.net/livres.html

      • [^] # Re: Conflit de services

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        Sur Mastodon, j’apprend deux choses :

        1. IPv6 fonctionne sans DHCP donc ta piste DHCP est bien plus pertinente que ce que je ne pensais.

        2. Le service networking Debian n’utilise pas Systemd (contrairement à ce que je croyais) mais il est possible de l’activer. Je me demande du coup si network-manager ne s’attend pas à systemd et que les deux entrent en conflit à cause de ça.

        https://wiki.debian.org/SystemdNetworkd

        Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: Conflit de services

      Posté par  (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 06 juin 2024 à 16:40.

      J’ai compris !

      Tu avais 100% raison.

      La page https://wiki.debian.org/NetworkManager indique que NetworkManager ne gère pas les interfaces définies dans /etc/network/interface.

      Or, j’ai installé cette machine avec le câble Ethernet branché, ce qui a autoconfiguré l’interface. La supprimer de /etc/network/interface résout immédiatement tous les problèmes.

      La question est de savoir si, du coup, c’est un bug de network-manager ou pas de pas trop savoir quoi faire.

      Mes livres CC By-SA : https://ploum.net/livres.html

      • [^] # Re: Conflit de services

        Posté par  . Évalué à 9.

        C'est le comportement attendu depuis des années, et c'est bel et bien documenté.

        Il y a tout de même un piège, car en effet l'interface qui a servi à l'installation a un traitement différent des autres. C'est peut-être ça qu'il faut remonter à Debian.

        Il y a un autre cas de figure subtil, c'est la différence entre allow-hotplug et auto. L'installeur Debian va mettre allow-hotplug, ce qui est pratique pour les trucs USB amovibles, mais pas super pour les trucs intégrés.

        L'effet de bord principal est que le "systemd-networkd-wait-online" ne "bloque" pas sur les interfaces qui sont déclarées avec allow-hotplug (puisque la présence de l'interface est optionnelle). La conséquence est que les services qui ne savent pas "reprendre" correctement sur un événement réseau se retrouvent dans un état bof-bof.

        • [^] # Re: Conflit de services

          Posté par  (site web personnel, Mastodon) . Évalué à 6.

          L’effet documenté est que "network-manager ne s’occupe pas des interfaces déclarées dans /etc/network".

          Mais alors, pourquoi ai-je eu des histoires absurdes d’IPv6 et de réseau intermittent ? Pour être compatible avec la doc, l’effet attendu serait:

          • connexion ethernet : network manager me dit "interface non gérée par NM"
          • connexion wifi : fonctionne avec NM

          Switcher de l’un à l’autre ne devrait, du coup, pas poser de problème.

          En réalité, je pense qu’il y a un vrai sac de nœud car NM m’indiquait quand même être connecté normalement via Ethernet (ce qui ne devrait pas être le cas) et, lors du passage de l’un à l’autre, c’était le bordel total.

          Peut-être qu’un comportement par défaut « sain » serait de considérer qu’un seul et unique gestionnaire de réseau ne peut être actif à la fois. À l’installation de network-manager (ou de connman ou de systemd-networkd), Debian me proposerait de choisir le gestionnaire par défaut pour les interfaces réseaux.

          (d’ailleurs, j’ai testé l’installation de connman : la simple install du paquet a fait disparaitre le réseau complètement. )

          (évidemment, il devrait être possible pour les cas particuliers d’avoir plusieurs gestionnaires mais cela ne devrait pas être le défaut)

          Qu’en penses-tu ?

          Mes livres CC By-SA : https://ploum.net/livres.html

          • [^] # Re: Conflit de services

            Posté par  . Évalué à 4. Dernière modification le 07 juin 2024 à 02:42.

            Oui, tu as raison, j'ai relu ta description du problème et on dirait que NM a du mal à reconfigurer le client DHCP, vu qu'il n'en est pas totalement propriétaire :-/.

            Je me pose quand même des questions :

            • à quoi ressemblait le /etc/network/interfaces pour l'Ethernet ?
            • que raconte nmcli device status quand il y a l'interface filaire déclarée dans /etc/network/interfaces ?
            • est-ce que cette interface Ethernet est sur un adaptateur USB, et donc disparaît quand tu déplaces le laptop ?

            Vu que tu es en SID, tu es peut-être sur une faille sismique temporaire liée à des changements dans la gestion du réseau sur Debian :).

            • [^] # Re: Conflit de services

              Posté par  (site web personnel) . Évalué à 8. Dernière modification le 07 juin 2024 à 08:35.

              Moi la question qui me turlupine, c'est pourquoi Debian a migré sous Systemd mais a conservé ses scripts de gestion du réseau…

              Sous Fedora, même un mixant systemd-networkd pour mes bridges/interfaces nspawn et NetworkManager pour le reste, je n'ai jamais eu aucun problème.

              • [^] # Re: Conflit de services

                Posté par  (Mastodon) . Évalué à 5.

                Le travail est en cours pour la prochaine version.
                NetworkManager n’a jamais été capable de gérer la configuration ifupdown alors qu’il est interopérable avec d’autres systèmes de configuration du réseau (ceux issus de l’écosystème RedHat).

                • [^] # Re: Conflit de services

                  Posté par  (site web personnel) . Évalué à 5.

                  NetworkManager n’a jamais été capable de gérer la configuration ifupdow

                  Il l'est mais de manière partielle.

                  D'ailleurs au boulot j'ai eu une blague à ce sujet car le pont est mal pris en charge par exemple et la documentation n'est pas claire sur ce qu'il gère bien ou pas dans ce fichier.

                  • [^] # Re: Conflit de services

                    Posté par  (site web personnel) . Évalué à 2.

                    sur ce qu'il gère bien ou pas dans ce fichier

                    tu veux dire qu'il le gère mal1 :-)

                    en gros, c'est pas encore génialement documenté, et il est difficile de voir ce qui est effectivement ou réellement géré (ou pas).

                    Pour le ifupdown, c'est ce que je constate aussi côté Mageia (en même temps, nous héritons de pas mal de choses de Fedora, le plus souvent en bien :D).

                    J'ai aussi le souci (mais là c'est plutôt côté kernel je crains) que les métriques données par ip route ne sont plus réellement suivies (c'est ce qui priorise l'utilisation d'ethernet quand disponible en même temps que le wifi, une métrique plus basse privilégiant cette interface) : quand j'ai l'ethernet et le wifi ensemble, il a tendance à passer par le wifi, même pour des téléchargements lourds :/ ça se voit avec un gkrellm dans un coin du bureau. Bref, c'est pas sec (que ce soit lié à l'intégration par les distributions ou à network-manager).
                    Alors que bon, si je m'embête à brancher l'ethernet, c'est bien pour que ça soit privilégié (entre un débit à 8 Mo/s max et un débit pouvant monter à 80 Mo/s et plus parfois ya pas photo…).

                    1. ah cette notion de bien et de mal, avec ses connotations, mais je m'égare… ↩

              • [^] # Re: Conflit de services

                Posté par  . Évalué à 3.

                Moi la question qui me turlupine, c'est pourquoi Debian a migré sous Systemd mais a conservé ses scripts de gestion du réseau…

                Je vois deux raisons :

                • [^] # Re: Conflit de services

                  Posté par  (Mastodon) . Évalué à 3.

                  NetworkManager n'a rien à voir avec systemd.

                  Je pense que c'est simplement par compatibilité ascendante et que tout le monde n'est pas fan de nm.

                  • [^] # Re: Conflit de services

                    Posté par  . Évalué à 4.

                    Yep, je répondais à :

                    pourquoi Debian a migré sous Systemd mais a conservé ses scripts de gestion du réseau

                    La config réseau aurait pu migrer dans les fichiers .link de systemd. Mais du coup grosse adhérence à systemd, ce qui n'a pas été acté.

                    Donc le futur du réseau sur Debian c'est possiblement netplan, qui peut prendre systemd-networkd et NetworkManager comme cibles, si j'ai bien tout suivi ce qui est dit dans le lien donné par Hobgoblins Master un peu plus haut.

  • # Forcer IPv6 par une loi

    Posté par  (site web personnel) . Évalué à 1.

    Il faudrait une loi mondial pour forcer IPv6 partout.

    Y en a marre de dépendre d'une adresse IPv4 publique pour exister.

    Les entreprises n'utilisant pas encore IPv6 doivent recevoir une lourde amende.

    • [^] # Re: Forcer IPv6 par une loi

      Posté par  . Évalué à 10. Dernière modification le 07 juin 2024 à 08:00.

      Je n'ai pas pu m'en empêcher :)

          $> dig AAAA zoobab.wikidot.com

    ; <<>> DiG 9.18.27 <<>> AAAA zoobab.wikidot.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60275
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;zoobab.wikidot.com.        IN  AAAA

    ;; AUTHORITY SECTION:
    wikidot.com.        300 IN  SOA ns-532.awsdns-02.net. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

    ;; Query time: 151 msec
    ;; SERVER: 127.0.2.2#53(127.0.2.2) (UDP)
    ;; WHEN: Thu Jun 06 09:47:12 CEST 2024
    ;; MSG SIZE  rcvd: 139

    • [^] # Re: Forcer IPv6 par une loi

      Posté par  . Évalué à 7.

      Surtout que ça alimente un marché totalement virtuel(ex : https://auctions.ipv4.global/).
      Amazon rachète a tour de bras des plages d’IPv4 pour ses serveurs et te les revendent 43$/an !!!! ils ont un véritable trésor de guerre.

    • [^] # Re: Forcer IPv6 par une loi

      Posté par  (site web personnel) . Évalué à 4.

      Il y a aussi plusieurs FAI qui ne permettent pas à leur clients d'avoir de l'IPv6.

      Et, sur smartphone, il faut parfois activer des options, mais ça, c'est de plus en plus rare.

      Toutes les complexités réseaux que j'ai eu, c'était uniquement en IPv4 et à cause de ses limitations.

      Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

      • [^] # Re: Forcer IPv6 par une loi

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        J’ai configuré l’IPv6 chez mon FAI (ce n’était pas le cas par défaut) mais, par contre, je n’ai pas IPv6 sur mon téléphone quand je fais hotspot. C’est dommage.

        Mes livres CC By-SA : https://ploum.net/livres.html

      • [^] # Re: Forcer IPv6 par une loi

        Posté par  (site web personnel, Mastodon) . Évalué à 4.

        Je suis chez un petit opérateur mobile indépendant ( neibo.be ) mais, par curiosité, je me suis demandé sur le plus gros opérateur mobile belge supportait IPv6.

        J’ai trouvé ça qui date d’il y a 4 ans.

        https://fr.forum.proximus.be/archives-2019-65/ipv6-4g-mobile-52850

        C’est démoralisant

        (En gros, qqn demande quand il pourra travailler avec IPv6 depuis sa connexion mobile et plusieurs réponses lui disent toutes "nous n’avons pas de date à communiquer" )

        Mes livres CC By-SA : https://ploum.net/livres.html

        • [^] # Re: Forcer IPv6 par une loi

          Posté par  . Évalué à 5. Dernière modification le 06 juin 2024 à 22:51.

          Je sais pas y'a 4 ans mais maintenant en 4G avec Proximus tu as une ipv6.

          • [^] # Re: Forcer IPv6 par une loi

            Posté par  (site web personnel, Mastodon) . Évalué à 4.

            Merci pour l’info. J’ai cherché et ce n’est indiqué nulle part.

            J’espère que mon opérateur (qui dépend de Mobistar/Orange) y passera bientôt.

            Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: Forcer IPv6 par une loi

      Posté par  (site web personnel) . Évalué à 3.

      Historiquement, il faut quand même reconnaître que "le gouvernement devrait imposer une config spécial sur les routeurs", ça n'a pas trop de traction auprès des libristes.

    • [^] # Re: Forcer IPv6 par une loi

      Posté par  . Évalué à 1.

      Encore faut-il qu’IPv6 soit implémenté correctement dans les box.
      La plupart du temps c’est bancal avec aucune option configurable comme le firewall non désactivable et c’est impossible de faire de l’auto hébergement…

      Virgin Media m’a fait le coup récemment, leur nouvelle box est IPv6 only et on peut rien en faire. J’ai du demander pour repasser en IPv4

  • # Pour LinuxFR

    Posté par  . Évalué à 10.

    Je t'encourage à voter pour l'entrée correspondante du suivi: #899 Support IPv6

    • [^] # Re: Pour LinuxFR

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      C’est fait !

      Mais je suppose que si ce n’est pas encore le cas, c’est pour une bonne raison.

      Mes livres CC By-SA : https://ploum.net/livres.html

      • [^] # Re: Pour LinuxFR

        Posté par  . Évalué à 4. Dernière modification le 06 juin 2024 à 10:41.

        Si j'ai bien compris c'est parce qu'on peut voter une fois par IP par jour aux sondages, et cette fonctionnalité indispensable n'a pas beaucoup de sens en IPv6.

        • [^] # Re: Pour LinuxFR

          Posté par  (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 06 juin 2024 à 10:58.

          J’ose espérer que ce n’est pas ça qui bloque l’implémentation d’IPv6 pour linuxfr…

          EDIT :

          "Honnêtement, il faudrait surtout qu'un admin ait envie de s'y coller… Et la fondation Free peut fournir de l'IPv6." (Benoit Sibaud, 6 avril 2012)

          https://linuxfr.org/news/evenement-g6-ipv6-11-avril-2012-paris#comment-1338963

          Mes livres CC By-SA : https://ploum.net/livres.html

          • [^] # Re: Pour LinuxFR

            Posté par  (site web personnel) . Évalué à 7.

            Je confirme que ce n'est pas le point bloquant, c'est juste noté comme « pense-bête » ou « à ne pas oublier » en cas d'activation de l'IPv6. Le fait que zéro tests aient été faits avec IPv6 jusqu'à il y a peu (j'ai ajouté des tests sur les services epub et img, ce qui est loin de couvrir l'ensemble des services du site) et le fait que l'IPv6 ne soit pas actuellement activée sur nos serveurs sont par contre de vrais points bloquants (en attendant qu'ils ne le soient plus).

            • [^] # Re: Pour LinuxFR

              Posté par  (site web personnel) . Évalué à 10.

              Je te propose de ne pas tester et de laisser les utilisateurs de Linuxfr.org le faire à ta place, tu le sauras bien assez vite avec un journal, un forum ou une dépêche pour se plaindre ou remercier ;-)

              « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

              • [^] # Re: Pour LinuxFR

                Posté par  (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 06 juin 2024 à 14:33.

                Les vraies moules poussent en production sans tester. Tester, c’est pour les \_o<

                Mes livres CC By-SA : https://ploum.net/livres.html

  • # Y’a-t-il une explication rationnelle à ce comportement ?

    Posté par  (site web personnel) . Évalué à 6.

    Y’a-t-il une explication rationnelle à ce comportement ?

    Les gros joueurs qui étaient déjà là sont confortablement installés avec leur IPv4 et n'ont pas vraiment d'intérêt à se faire chier à « prendre le risque » d'implémenter IPv6. Les seuls qui ont un vrai intérêt à utiliser IPv6 sont ceux qui sont à court d'IPv4. En Amérique du Nord et en Europe, les entités qui sont dans ce cas ont une relativement petite part de marché et peu d'influence sur l'écosystème. Donc le fait qu'IPv4 reste dominant dans une grosse partie du monde est très rationnel.

    Pour tes problèmes de Debian unstable, je sais pas. Ça me semble une question pour les forums et/ou les mailing lists Debian.

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Lorsque la moitié d’internet est down…

    Posté par  . Évalué à 2.

    s/"la moitié d’internet"/"l'ancien internet"/

    *splash!*

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.