Perte connectivité IPv4, IPv6 OK; conflit IPv4 full-stack ?

[Seb.7 (Auteur du topic)]

Bonjour,

depuis le 7/11, je subis temporairement des pertes totales de connectivité IPv4 : chaque épisode dure plusieurs jours, pendant lesquels je ne peux atteindre l'espace IPv4 que par brèves plages de quelques minutes. La connectivité IPv6 n'est quant à elle jamais affectée.

Je n'ai pas récemment modifié la configuration de ma Freebox, les derniers changements remontent à 2023 et concernaient la délégation de préfixes IPv6. La Freebox est en mode bridge depuis toujours, et je dispose d'une IPv4 full-stack depuis à peu près aussi longtemps (l'interface Freebox OS confirme "Ports 0 à 65535").

Derrière la Freebox se trouve un routeur FreeBSD, dont la configuration n'est elle aussi que rarement touchée : elle est déployée via ansible, et l'historique des changements associés ne montre aucune modification de fond sur les 15 derniers mois.

Le 15/11 j'ai ajouté à mon suivi LibreNMS un test de connectivité, depuis le routeur, via un simple `ping -c 3 185.34.33.4` (`laquadrature.net`, en sautant la case "serait-ce le DNS ?") toutes les 5 minutes. J'insiste sur le fait que lors des coupures c'est bien l'ensemble de l'espace IPv4 qui est inatteignable, et pas seulement la cible du test.
Voici quelques graphiques associés montrant les pertes de paquets au cours du temps, d'abord de manière générale puis plus finement sur les trois dernières heures de la coupure en cours :

https://pasteboard.co/6JhipiEmcBhm.png
https://gcdnb.pbrd.co/images/6JhipiEmcBhm.png

https://pasteboard.co/JdSFtYS2L8rf.png
https://gcdnb.pbrd.co/images/JdSFtYS2L8rf.png

Le problème n'est pas limité à l'ICMP : la couche IP est affectée, et aucune connexion TCP ni UDP ne peut être établie. C'est ce qui rend le problème trivial à remarquer, puisque les sites Web ne servant pas de trafic via IPv6 deviennent alors injoignables. Adieu lemonde.fr, duckduckgo.com, leboncoin.fr, etc.

Pour caractériser un peu mieux le problème et confirmer qu'il ne se situe pas plus loin, lors des coupures je ne parviens même pas
à toucher le gateway que la Freebox déclare (via DHCP) :

[Homer54]

Bonjour, tout d'abord, tu es nouveau ici, tu ne pourra donc pas répondre avant quelques jours (filtre antispam). Tu peux toutefois faire un MP...

[menelas29]

[DG33600]

Bonjour,
Je ne comprends pas la moitié du quart des problèmes rencontrés, mais en tous cas chapeau pour tes recherches préalables et les infos apportées.
Bienvenue à toi, je cède la place aux autres

[loggoi]

[BreizhBOX]

Vous partez bille en tête en sous-entendant que le problème serait OBLIGATOIREMENT sur la Freebox ou le réseau Free, or on n'en sait rien du tout.

On procède par élimination. On doit d'abord vérifier que le problème ne vient pas de votre routeur FreeBSD

Donc dans un premier temps vous déconnectez le routeur FreeBSD, et vous testez directement sur la Freebox si besoin en rétablissant le mode routeur, en paramétrant des DNS Google (8.8.8.8), Cloudflare (1.1.1.1) ou QUAD (9.9.9.9) vu que l'on sait que les DNS de Free c'est une grosse daube qui emm..erdent régulièrement les Freenautes.

En revanche si vous n'étiez pas au courant, il faut retirer les DNS OpenDNS qui ne proposent plus ses services en France suite à son refus de se conformer aux lois françaises notamment sur l'injonction de bloquer certains sites de piratage, de délinquance....

Au demeurant, il y a eu une floppée de problèmes sur les appareils Android Samsung quelques mois auparavant si on laissait l'appareil se paramétrer par défaut. Il fallait forcer un prestataire DNS comme Google ou Cloudflare... je soupçonne en fait que la DNS par défaut des Android Samsung était OpenDNS, ce qui ne posait qu'un problème localisé en France.

Pour certains utilisateurs c'était transparent car il me semble que dans le cas de Bouygues Mobiles, l'opérateur impose ses DNS en filtrant les DNS tierces (source : info UF). Pour Orange et SFR, je ne sais pas trop, pour Free Mobile, on reste libre d'utiliser les DNS de son choix. Donc Bouygues et tous les MVNOs basés sur Bouygues... ce sera niet pour moi vu que je veux pouvoir utiliser le réseau mobile pour connecter s'il le faut des serveurs.

A voir dans votre de cas si ça n'aurait pas un lien.

Les DNS Google ne sont pas forcément les plus rapides, mais elles sont très fiables. Dans le cadre d'un test, il est de bonne pratique de tester d'abord avec les DNS Google, ou Cloudflare. Ce dernier ayant ma préférence pour une utilisation régulière car Cloudflare n'étant pas un moteur de recherche ils n'ont aucun intérêt à biaiser leur solveurs DNS. Pour Google, outre le pistage, il peut toujours y avoir des tentations commerciales d'orienter le moteur de recherche, même si rien n'a jamais été prouvé à ce jour, en revanche il y a bien eu une mini polémique plusieurs années auparavant concernant OpenDNS, ce qui aura sans doute incité IBM à financer le projet indépendant et libre "Quad DNS", OpenDNS n'étant pas indépendant car appartenant à CISCO.

Si le problème disparaît ça signifie que le problème se situe sur votre routeur, et dans ce cas là on ne peut pas vous aider
Ce problème peut être logiciel ou hardware

ENCORE UNE FOIS :

Le mode bridge sur la Freebox N'A PLUS AUCUNE UTILITE à part s'attirer régulièrement des emm...erdes, réduire inutilement les fonctionnalités de la Freebox.

Donc arrêtez une fois pour toute avec ces bêtises de geekeux impubères. Le mode bridge avait une utilité sur la Freebox v5 qui avait un souci connu au niveau de son parefeu, depuis la Revolution CA N'A PLUS AUCUNE UTILITE à part se pavaner sur les forum en jouant les KEKE de service...

"je connais, je suis un spécialiste, je suis un crack... mais au secours je demande votre aide"

La bonne pratique est de cascader les routeurs, et de mettre le routeur FreeBSD en DMZ dans Freebox OS. La DMZ a été prévue pour ça, ça n'a pas été inventé pour les cochons, mais ça c'est pour l'IPv4.

Pour l'IPv6, on n'active pas l'option pare-feu de la Freebox, ça ne sert à rien tant que ces fainéants de développeurs ne fourniront pas la possibilité d'ouvrir et rediriger les ports IPv6 comme en IPv4. Dans ce cas la Freebox ne filtre pas du tout le trafic IPv6 en réseau local, elle le filtre uniquement pour elle-même mais pas pour les hôtes réseau

Pour le Prefix IPv6, on peut activer le Next Hop IPv6 sur le second sous réseau (jamais le premier qu'on réserve à la Freebox) vers l'adresse de lien local IPv6 du routeur FreeBSD (fe80.....), et dans ce cas, c'est le routeur FreeBSD qui gérera intégralement l'adressage de l'IPv6 sur le segment concerné ([2axx:xxxx:xxxx:xxx1:/64], ([2axx:xxxx:xxxx:xxx0:/64] étant réservé à la Freebox, du moins c'est fortement conseillé si on veut garder un système résilient, la Freebox pouvant servir d'itinéraire de secours si le routeur FreeBSD tombe en rade, d'où encore une fois l'intérêt d'arrêter cette lubie du "bridge" qui ne vous fait gagner qu'un milliardième de secondes par requête, 0,000000000000...1 secondes en terme de ping)

Même en ne touchant jamais à un système Linux ou FreeBSD, il arrive fréquemment que les systèmes tombent en rade avec pour principales causes

- un problème hardware naissant
- un problème de mise à jour. Il y a beaucoup de "kéké" qui installent des systèmes Linux (plus rarement BSD) MAIS QUI NE LES METTENT JAMAIS A JOUR (ou trop rarement), ce qui est une pratique exécrable, déjà sur le plan de la sécurité

Un cas pratique assez simple qui est déjà arrivé sur la Freebox elle-même et qui devrait vous faire BEAUCOUP réfléchir avant de partir bille en tête sur des biais méthodologiques.

Une personne nous revient ici et indique que depuis quelques temps elle ne parvient plus à accéder au partage Samba de sa Freebox depuis son Mac ou Windows. Elle jure ici que JUSTEMENT elle n'a pas mis à jour sa Freebox récemment ce qui écarterait selon elle un problème de firmware.

En fait.... le protocole Samba SMB 1 avait été banni depuis un certain temps pour des raisons de sécurité que ce soit sous Windows, Mac ou Linux (on peut toujours forcer le protocole pour accéder à d'anciens appareils qui ne peuvent être mis à jour en SMB2, mais le protocole SMB1 n'est plus accessible par défaut)

L'intéressé visiblement mettait rarement à jour ses systèmes, mais d'une manière ou d'une autre, à un moment donné il y a été obligé, ainsi d'un seul coup son poste Windows et / ou Mac ont bloqué l'accès à sa Freebox qui était toujours en SMB1 et il envoie ici un message assez lunaire alors que toute la communauté savait ici que d'une le protocole SMB1 était banni depuis un certain temps déjà (plusieurs années en fait) sur des systèmes Windows (à jour), et depuis quelques mois (pas depuis quelques jours) la Freebox avait un nouveau firmware qui implémentait le SMB2... on a pleuré de nombreuses années auprès des développeurs sur le bug tracker en mettant en avant cette aberration en terme de sécurité.

Pour résoudre le problème, il fallait donc mettre à jour la Freebox. Il fallait ensuite activer ce protocole dans Freebox OS

Un exemple simple qui montre que ce n'est pas parce que l'on ne touche pas à un système qu'il n'engendrera pas de soucis tout simplement parce que les protocoles ne cessent d'évoluer, certains protocoles sont bannis pour être remplacés par d'autres, certains logiciels sont dépréciés pour être remplacés.

Récemment les distributions Linux ont pratiquement toutes banni le serveur cache de base de données Redis en raison d'un changement de licence, Redis appartenant depuis longtemps à une entreprise privée commerciale, au profit de Valkey qui reste un projet sous licence BSD, indépendant et libre désormais appuyé par les plus grandes entreprises comme IBM, HP, Red Hat... ce qui requiert de configurer le nouveau serveur. Ce type d'événement n'a rien d'isolé, c'est la vie de Linux, de BSD...

Et demain beaucoup de distributions vont bannir par défaut X11 au profit du seul Wayland, il est déjà prévu que les prochaines versions de Gnome et KDE (plasma 7) ne supporteront que Wayland, les fidèles de X11 devront s'adapter.

J'ai des connaissances sur Linux et BSD, je peux vous certifier que refuser de mettre à jour ses systèmes, non seulement c'est une mauvaise pratique en terme de sécurité, mais régulièrement de façon naturelle, le système va se mettre en rade en raison justement de l'évolution permanente des protocoles réseau, des logiciels, de là même façon qu'une mise à, jour régulière pourra provoquer les mêmes désagréments, mais la deuxième solution reste largement préférable à un système rarement mis à jour mais prêtant le flanc à des attaques via des failles de sécurité non bouchées.

Il y a trop de gens qui continuent à utiliser des versions dépréciées de pfsense basées sur des versions anti-déluviennes de FreeBSD. Pfsense, comme FreeBSD doivent être mis à jour régulièrement, et à chaque mise à jour, il peut y avoir des changement "sensibles" qui peuvent expliquer des dysfonctionnements.

Il y a 99% de chances que votre problème se situe au niveau de votre routeur FreeBSD
Si vous aviez une réelle maîtrise de votre routeur BSD... vous n'auriez pas eu besoin de nous pour résoudre votre problème.

Les gens qui utilisent BSD savent en général (ou devraient savoir) mieux que quiconque que les systèmes doivent être régulièrement mis à jour.

Les systèmes "purement locaux" qui n'ont donc jamais un accès à Internet, oui on peut ne pas les mettre en jour même si dans l'exemple de Samba ça peut quand même poser problème, et ce sera en fait le cas de nombreux appareils domestiques comme l'électroménager.

Mais un système ayant accès à Internet est un système CRITIQUE qu'il faut surveiller et mettre à jour constamment, et certaines mises à jour peuvent impliquer de revoir certains paramétrages en raison de l'évolution naturelle des systèmes, des normes.

[Seb.7 (Auteur du topic)]

Bonjour,

tout d'abord Merci à tous pour votre accueil.

loggoi :
Le problème persiste en repassant la Freebox en paramètres d'usine, c'était mon premier test et j'aurais du le préciser.

BreizhBOX :
J'ai déjà bien procédé par élimination. Ma démarche exclut notamment que le problème puisse venir d'un quelconque DNS : regardez à nouveau la nature de mon test de base.
Merci pour vos conseils détaillés sur l'IPv6, le mode bridge, et les problématiques de mises à jour logicielles (sur ce point, mes systèmes sont mis à jour quotidiennement, je faisais simplement remarquer dans mon post initial que la *configuration*, notamment réseau, de mon routeur n'avait pas subi de changement récent).
Je ne suis pas venu me "pavaner sur les forum en jouant les KEKE de service" (et je peux vous assurer que j'ai "une réelle maîtrise de [mon] routeur BSD"), simplement exposer un rapport de problème détaillé et soutenu par des observations factuelles.

Pour revenir sur ces dernières, même si ma configuration était à la source du problème, cela ne pourrait pas expliquer comment mon IPv4 fixe pointe, au fur et a mesure du temps, vers des installations *différentes* et qui ne sont clairement pas les miennes (cf. dans mon premier post les 2 captures `nmap` réalisées depuis l'extérieur).

--
Seb