Vous êtes admin réseau et vous en avez marre de jongler entre différents outils pour calculer un masque de sous-réseau, vérifier un enregistrement DNS, ou tester une config DHCP ?
Ça tombe bien puisque
Networking Toolbox
débarque avec tous les outils réseau dont vous avez besoin dans une seule interface plutôt propre et carrée.
Le projet est développé par
Alicia Sykes
, une développeuse qui a déjà pas mal de projets open-source à son actif et son idée c’est de regrouper plus d’une centaine d’utilitaires réseau au même endroit, sans dépendances tierces, sans tracking, et avec une interface qui fonctionne aussi bien sur desktop que sur mobile.
Le site propose des outils dans cinq grandes catégories. Du calcul de sous-réseaux, avec des calculateurs IPv4 et IPv6, de la planification VLSM, des outils CIDR pour convertir des masques ou générer des plages IP. Ensuite, les diagnostics réseau : lookups DNS, vérifications TLS, tests de connectivité, analyses HTTP et email. Vous avez aussi des générateurs pour DHCP et DNS, avec création d’enregistrements, validation DNSSEC, et configuration de zones complètes. Et bien sûr, tout un tas d’utilitaires divers pour convertir, valider, et manipuler des données réseau.
Ce qui est pratique, c’est que vous pouvez bookmark n’importe quel outil avec un clic droit. Ça le rend accessible offline et l’épingle en haut de votre page d’accueil. Si vous utilisez souvent les mêmes choses, ça évite de naviguer dans les menus à chaque fois. L’interface supporte ausis plusieurs langues, plusieurs thèmes visuels, et se contrôle entièrement au clavier.
Niveau techno, c’est du Svelte avec TypeScript, compilé en SvelteKit. Les calculs se font côté client, donc pas de latence serveur et le code est publié sous licence MIT. Vous pouvez donc le déployer sur votre propre infrastructure si vous ne voulez pas utiliser l’instance publique.
3 options principales s’offrent à vous : un conteneur Docker qui se lance avec une ligne de commande, un déploiement sur des plateformes cloud comme Vercel ou Netlify, ou un build statique que vous hébergez où vous voulez.
Pour Docker, c’est hyper fastoche. Vous tapez
docker run -p 3000:3000 lissy93/networking-toolbox
et l’interface est alors accessible sur localhost:3000. Si vous préférez compiler depuis les sources, le repo est ici sur
Codeberg
. Vous le clonez, vous installez les dépendances avec yarn, et vous lancez le serveur de dev avec yarn dev. Le projet se compile en build statique, en build Node.js, ou avec des adaptateurs pour GitHub Pages et autres hébergeurs statiques…
Le plus intéressant, c’est que Networking Toolbox propose aussi une API gratuite, sans clé, sans restrictions CORS. Si vous développez vos propres outils ou scripts d’automatisation réseau, vous pouvez interroger l’API directement sans config particulière pour par exemple, convertir un masque, valider une plage IP, ou générer un enregistrement DNS programmatiquement !
Voilà, si vous administrez des réseaux ou si vous étudiez les infras, testez-le. Je pense que vous gagnerez du temps et vous arrêterez de chercher “subnet calculator” sur Google toutes les cinq minutes.
Vous streamez une vidéo sur votre iPad, tout va bien, et puis ça lag. Pas beaucoup hein, juste une petite micro-saccade bien en rythme toutes les deux secondes. Ce n’est pas la faute de votre routeur et pourtant vous avez beau pinger votre réseau local, ça saute de 3 ms à 90 ms… Bienvenue dans le monde merveilleux d’AWDL, la technologie Apple qui transforme plus d’un milliard d’appareils en mini-pollueurs du spectre WiFi.
Christoff Visser, ingénieur au labo de recherche d’Internet Initiative Japan, a eu ce problème et en a parlé lors de sa dernière
présentation à la conférence RIPE 91
. Il était en train de streamer un jeu avec
Moonlight
quand ça s’est mis à sauter à intervalles réguliers. Ça l’intrigue, alors il fait ce que ferait n’importe quel ingénieur réseau qui se respecte… Il sort Wireshark et commence à tout sniffer.
Et là, surprise… Son iPad saute entre les canaux WiFi.
Mais pas aléatoirement, hein… précieusement toutes les deux secondes. C’est alors qu’il comprend que le coupable est le protocole AWDL (Apple Wireless Direct Link). Vous voyez AirDrop, cette app magique qui vous permet d’envoyer des fichiers entre iPhone et Mac sans rien configurer ? Handoff, qui vous laisse continuer votre mail de l’iPhone sur le Mac ? Sidecar, pour utiliser votre iPad comme second écran ? Hé bien toute cette magie Apple repose sur ce protocole propriétaire non-documenté qui tourne en permanence sur vos appareils.
Voici comment ça marche… Pour que deux appareils Apple puissent se parler n’importe où dans le monde, ils doivent d’abord se trouver. Apple a donc défini ce qu’on pourrait appeler des canaux sociaux : le canal 6 pour le 2,4 GHz, les canaux 44 et 149 pour le 5 GHz. Ce sont si vous voulez, des points de rendez-vous. Vos appareils sautent alors régulièrement sur ces canaux pour vérifier si quelqu’un veut leur parler, puis reviennent sur le canal de votre réseau WiFi.
Sauf que si vous êtes un admin réseau malin, vous n’utilisez PAS ces canaux parce que tout le monde les utilise. Vous scannez le spectre, vous trouvez un canal vide, et vous configurez votre réseau là-dessus pour éviter les interférences. Logique, non ?
Bah non. Pas avec Apple.
Parce que vos appareils Apple, eux, ils s’en foutent. Ils vont QUAND MÊME sauter sur les canaux 6, 44 ou 149 pour checker si quelqu’un veut leur parler, puis revenir. Hop. Toutes les deux secondes. Que vous utilisiez AirDrop ou pas. Que vous ayez d’autres appareils Apple à proximité ou pas. En permanence !
C’est dingue non ? Du coup, on se retrouve avec ces micro-coupures et une latence qui explose. Visser a découvert que ce problème est remonté sur les
forums utilisateurs depuis 2019
. Les gens se plaignent, mais personne ne comprend vraiment ce qui se passe parce qu’Apple ne documente pas AWDL et que ces paquets sont invisibles sur votre propre machine. Du coup, diagnostiquer ça est presque impossible.
Visser a donc contacté Apple via leur Feedback Assistant et il n’a obtenu aucune réponse. Même après sa conf à RIPE91, Apple a gardé le silence…
Bref, le “ça marche tout seul” d’Apple a un coût sauf que ce n’est pas Apple qui le paie. C’est nous, les admins réseaux et tous les autres appareils sur le réseau. Apple a optimisé l’expérience de SES utilisateurs en externalisant le problème sur l’infrastructure WiFi des autres.
Alors y’a t-il des solutions ?
Bah justement. Vous avez trois options mais je vous préviens, elles sont toutes pourries.
Option 1 : Désactiver AWDL avec sudo ifconfig awdl0 down. Cool, ça marche sauf que vous perdez AirDrop, Handoff, Sidecar, et toutes les fonctionnalités cools qui font qu’un iPhone est un iPhone. Autant acheter un Android à ce tarif…
Option 2 : Configurer votre réseau WiFi sur les canaux 6, 44 ou 149. Utiliser les mêmes canaux que tout le monde pour éviter que vos appareils Apple ne sautent est donc une bonne option, même si ces canaux sont souvent saturés.
Et au Japon, le 149 est carrément interdit
!
Option 3 : Vivre avec en totale acception de votre sort. Vous devez accepter que vos appareils Apple sont des gros dégueulasses qui vont polluer le WiFi, accepter ces micro-latences et accepter que votre admin réseau va vous poursuivre avec un couteau dans les couloirs de la boite quand il aura lu mon article.
Et comme ce n’est pas un problème de matériel, acheter un nouveau routeur WiFi 7 ne changera rien puisque le problème, c’est la communication directe entre VOS appareils. Apple pousse même le
RFC 9330
(L4S) pour réduire les délais réseau, mais ça ne résoudra rien non plus parce qu’AWDL, c’est du peer-to-peer et ça bypass votre routeur.
Quelqu’un n’a même pas besoin d’être connecté à votre réseau pour foutre le bordel. Il peut juste passer à côté de vous dans un café, déverrouiller son iPhone, et boom, votre réseau va glitcher quelques secondes pendant que vos appareils négocieront avec le sien.
Visser a donc présenté tout ça en espérant que les admins réseau et les FAI soient enfin informés du souci et puisse répondre enfin aux utilisateurs qui rencontrent ce problème invisible. Donc, voilà, la prochaine fois que votre connexion WiFi merdera sans raison, regardez autour de vous et comptez les iPhones et autres appareil Apple car chacun d’eux est en train de jouer à saute-moutons entre les canaux de votre réseau.
Plus d’un milliard d’appareils qui font ça en permanence, partout dans le monde, c’est pas rien quand même…
J’avais besoin de WiFi dans un local technique pour brancher des caméras de surveillance parce que mes routeurs sont à l’opposé de la zone à couvrir et finalement la solution la plus fiable et la moins prise de tête que j’ai trouvé, ça a été de passer par mes bons vieux câbles électriques.
Devolo m’a donc envoyé ses
Magic 2 WiFi 6 Next
en test (Le multiroom kit avec trois adaptateurs), et je les ai vraiment trouvé pas mal. Le kit se compose d’une prise LAN que vous branchez à votre routeur en ethernet, et de deux prises WiFi que vous placez là où vous voulez chez vous. Et le tout communique via votre réseau électrique (technologie CPL ou powerline pour les intimes), et diffuse du WiFi 6 avec mesh intégré.
L’installation prend deux minutes chrono. Vous branchez les trois prises, vpous attendez un peu que toutes les diodes passent au blanc, puis avec l’app devolo Home Network, vous configurez tout ça. Aucune bidouille, aucun paramétrage manuel puisque les trois adaptateurs sont détecté tout seuls et créent alors un réseau mesh transparent.
Attention ne branchez JAMAIS vos adaptateurs CPL sur une multiprise car ça crée des perturbations qui massacrent les perfs. Branchez-les directement sur une vraie prise murale, et ensuite vous pourrez utiliser la prise intégrée aux boitiers pour brancher votre multiprise par-dessus.
Le gros atout du CPL face au mesh WiFi classique, c’est sa stabilité. Un mesh WiFi pur va fluctuer selon les interférences, les murs, les voisins qui balancent du 2.4 GHz à fond. Alors que là, le backhaul (la connexion entre les prises) passe par les câbles électriques à 2400 Mbps max, donc zéro fluctuation. Le WiFi 6 diffusé ensuite monte jusqu’à 3000 Mbps (574 Mbps en 2,4 GHz + 2402 Mbps en 5 GHz), avec du roaming automatique entre les prises.
Par contre, je vais être clair, les performances dépendent énormément de la qualité de votre installation électrique. Si votre maison date de Mathusalem avec un câblage pourri, vous n’atteindrez jamais les débits théoriques. C’est le seul point noir du CPL… ça dépend énormément de votre install électrique.
Ensuite, j’ai mesuré les performances avecc ma configuration. Même étage que le routeur je suis environ 500 Mbps en CPL et au premier étage je suis entre 330 et 415 Mbps selon où je me trouve. Du coup, pour mes caméras de surveillance ou se faire un film en streaming 4K, c’est largement suffisant et surtout ultra-stable.
Si vous regardez bien, sous chaque prise WiFi il y a deux ports Ethernet gigabit, ce qui est parfait si vous avez des appareils filaires à brancher (NAS, switch, caméras PoE avec injecteur…etc) et tout le réseau est extensible puisque vous pouvez ajouter autant de prises Devolo que vous voulez partout chez vous pour couvrir une surface gigantesque.
Le système Devolo embarque également tout ce qu’on attend d’une solution de routeurs / répéteurs modernes : un chiffrement WPA3 pour la sécurité, du WiFi invité pour vos potes histoire de pas leur filer votre mot de passe principal, contrôle parental avec programmation horaire, et Airtime Fairness pour que vos appareils rapides ne soient pas ralentis par le vieux smartphone de belle-maman. Tout se pilote bien sûr via l’app devolo Home Network, disponible sur iOS et Android.
Pour ceux qui ont des connaissances pointues en CPL, sachez que ce système utilise la techno G.hn qui est plus rapide et plus stable que l’ancien HomePlug AV2. Donc si vous avez de vieux adaptateurs CPL qui traînent, autant les offrir à quelqu’un qui n’en a pas parce que la différence de performances est énorme. Le G.hn gère carrément mieux les perturbations et offre des débits très supérieurs.
Voilà, alors si vous êtes comme moi et que vous avec une maison ancienne avec des murs épais, plusieurs étages, ou des zones où le WiFi ne passe juste pas genre loin dans le jardin, suffit d’avoir l’électricité et vous êtes opérationnel. Par contre, si vous vivez dans un appart récent avec des murs en placo, un simple système mesh WiFi fera probablement l’affaire pour moins cher.
Maintenant le truc qui pique un peu mais quand on aime on ne compte pas, c’est le prix.
Comptez environ 400-470 euros le kit Multiroom (3 adaptateurs)
selon les revendeurs. C’est cher, mais quand l’alternative c’est de tirer des câbles Ethernet à travers toute la baraque ou de galérer avec un mesh WiFi capricieux dans une vieille baraque, ça se défend. Et Devolo offre une garantie de trois ans, donc vous êtes tranquille.
Donc voilà, pour mon local technique et mes caméras WiFi, le Devolo Magic 2 WiFi 6 Next fait très bien le job. Après c’est comme tout, c’est une solution miracle mais pour des cas comme le mien où le WiFi classique ne suffit pas et que les distances sont trop grandes, ça change la vie ! Et maintenant j’ai un super wifi pour bosser dans le jardin et faire mes tests de caméras !
Un logiciel pour remplacer Synergy (pour contrôller plusieurs ordinateurs avec un seul clavier/souris, du moment que les ordinateurs sont sur le même réseau local.) (Permalink)
kdig est un utilitaire en ligne de commande issu de la suite Knot DNS, développé par le registre CZ.NIC. Il se présente comme une alternative moderne au traditionnel dig (issu de BIND9). Son intérêt principal réside dans la prise en charge des protocoles DNS sécurisés (DNSSEC, DoT, DoH) et une sortie en JSON facilitant l’automatisation. […]
Il y a exactement deux mois, un incident était survenu suite à un redémarrage brutal du serveur hébergeant les conteneurs de production et de développement ayant entraîné une attribution inattendue d’adresses IP. Et des réponses techniques 502 Bad Gateway pour notre lectorat.
Ce 26 août, vers 15:22, un message peu engageant est arrivé par pneumatique sur nos téléscripteurs (via Signal pour être précis) : « Tiens c’est bizarre j’ai perdu accès au site. Et au serveur oups. » L’après-midi et la soirée furent longues.
Le serveur répond au ping et permet les connexions TCP port 22, mais pas le SSH. Et les services web ne répondent plus. Souci matériel ? Noyau en vrac ? Attaque en cours ? Les spéculations vont bon train.
La connexion au serveur revient par intermittence, permettant à un moment d’exécuter quelques commandes, à d’autres d’attendre longuement pour l’affichage d’un caractère ou l’exécution de la commande tapée.
Le premier contact réétabli avec le serveur est assez clair (une forte charge) :
(dernier redémarrage le week-end précédent, mais surtout une charge système moyenne respectivement de 50, 205 et 261 sur les 1, 5 et 15 dernières minutes)
Initialement on suppose qu’il s’agit d’un trop grand nombre de requêtes ou de certaines requêtes tentant des injections de code sur le site (bref le trafic de fond plutôt habituel et permanent), et on ajoute des règles de filtrage péniblement et lentement pour bloquer les IP qui ressortent le plus dans nos logs.
Le site est alors inaccessible pendant plusieurs périodes. On arrête et relance ensuite plusieurs fois les services en pensant avoir ajouté suffisamment de filtrage, mais rapidement le serveur se retrouve englué. Les services sont alors arrêtés plus longuement le temps d’analyser les logs au calme. Au calme inclut notamment ne pas juste disposer d’une connexion ssh depuis un smartphone, mais plutôt d’un clavier et d’un grand écran par exemple, de l’accès à tous les secrets et toute la documentation aussi.
Finalement le trafic n’est pas énorme (en volume total) et si les requêtes hostiles sont bien présentes, rien ne semble inhabituel. Par contre les processus de coloration syntaxique partent en vrille, consommant chacun un processeur et aspirant allègrement la mémoire disponible. Avant d’être éliminés par le noyau Linux.
La console est remplie d’élimination de processus de ce type :
Mais si rien n’a changé niveau logiciel sur le conteneur LXC de production et si les requêtes ne sont pas inhabituelles, qu’est-ce qui peut bien écrouler le serveur et créer ces processus gourmands ?
Eh bien des requêtes habituelles…
Pendant les phases d’attente lorsque le serveur ne répondait plus vraiment, nous avons noté qu'une nouvelle entrée de suivi a été créée (merci BAud et merci RSS/Atom pour nous avoir permis de la voir alors que le serveur ne répondait déjà plus). Elle indique que la coloration syntaxique ne marche plus sur le site. Notamment l’exemple donné dans la documentation.
Pourtant le rendu fonctionne en testant en ligne de commande avec pygmentize.
Mais oui en testant l’exemple donné via le site, il est créé un processus Python2 pygment qui commence à se gaver de ressources.
Et en regardant les différents contenus et commentaires créés sur le site autour de l’incident, en filtrant sur ceux contenant des blocs avec de la coloration syntaxique, la dépêche (alors en préparation) sur G'MIC 3.6 apparaît. Et en testant cette dépêche, il est bien créé quatre processus Python2 pygment qui se gavent de ressources et ne semblent jamais vouloir se terminer. À rapprocher par exemple d’une page qui a été servie en 6785.9978s.
OK, le souci vient de requêtes tout à fait habituelles de coloration syntaxique, reste à comprendre pourquoi ces processus tournent mal.
La boucle sans fin
Un petit strace pour suivre les appels système en cours sur un des processus infernaux relève une boucle assez violente :
Il semble y avoir une immense itération sur des descripteurs de fichiers, en vue de les fermer, mais à l’aveugle, sans savoir s’ils existent réellement.
En regardant le code du composant utilisé (pygments), il semble n'y avoir qu'un seul appel à close() :
# close fd's inherited from the ruby parentimportresourcemaxfd=resource.getrlimit(resource.RLIMIT_NOFILE)[1]ifmaxfd==resource.RLIM_INFINITY:maxfd=65536forfdinrange(3,maxfd):try:os.close(fd)except:pass
Donc on itère sur tous les descripteurs entre 3 et le maximum déterminé…
Un demi-million de fois ici donc. L’objectif initial de la boucle est de fermer les descripteurs de fichiers provenant du processus Ruby père, issue du fork via Open3.popen3. La version suivante du composant la remplace d’ailleurs par un ajout de l'option :close_others, qui précisément « modifie l’héritage [des descripteurs de fichiers du processus parent] en fermant les non-standards (numéros 3 et plus grands) ».
Sur une Debian 12, la limite du nombre de fichiers par défaut, c’est 1 048 576. C’est déjà probablement bien plus que la valeur qui prévalait à l’époque où a été écrit la boucle Python (on avait des limitations à 4096 à une époque reculée). Mais il s’avère que durant le week-end l’hôte du conteneur de production a été migré en Debian 13. Sans modification du conteneur de production pensions-nous. Sans modification directe du conteneur de production. Mais quid d’une modification indirecte ? Par exemple si la limite par défaut des « Max open files » était passée à 1 073 741 816 sur l’hôte, soit 1024 fois plus que quelques jours auparavant. Et donc des boucles nettement plus longues voire sans fin, sans libération de mémoire.
On ne peut mettre à jour le composant pygments dans l’immédiat, mais on peut limiter les dégâts en abaissant la limite du nombre de descripteurs de fichiers à quelque chose de raisonnable (i.e. on va gaspiller raisonnablement des cycles CPU dans une boucle un peu inutile mais brève…). Une édition de /etc/security/limits.conf, un redémarrage du conteneur de production et on peut vérifier que cela va nettement mieux avec cette réparation de fortune.
Une dernière page d’epub ?
Le conteneur LXC portant le service epub de production a assez mal pris la surcharge du serveur, et vers 20h08, systemd-networkd sifflera la fin de la récré avec un eth0: The interface entered the failed state frequently, refusing to reconfigure it automatically (quelque chose comme « ça n’arrête pas d’échouer, débrouillez-vous sans moi »). Le service epub est resté en carafe jusqu’au 27 août vers 13h31 (merci pour l’entrée de suivi).
Le serveur était très occupé. Au point de n’avoir pas le temps de mettre à jour les graphiques de temps en temps.
Rétrospectivement les processeurs du serveur ont travaillé dur : 140 de charge sur le graphique (mais avec des pics jusque 260 d’après la commande uptime), contre moins de 5 en temps normal (un petit facteur de 28 à 52 ô_Ô)
Et l’utilisation de la mémoire montre aussi de brutaux changements de comportement : libération intempestive de mémoire (Free, en vert), utilisation mémoire plus importante que d’habitude (Used, en jaune), là où le comportement normal est d’avoir le maximum en cache (Cached, en orange) et des processus tellement peu consommateurs en RAM que cela n’apparaît normalement pas.
Mesures préventives et correctives
Dans les actions en cours ou à prévoir :
mettre à jour la documentation pour disposer facilement et rapidement des informations pour les connexions aux cartes d’administration ou les procédures de blocages d’IP
procéder à la montée de version des composants (yapuka, épineux sujet de la dette technique à éponger)
vérifier l’efficacité des limitations CPU/mémoire mises sur certains conteneurs LXC et les étendre aux autres
mettre des limites sur des processus particuliers (comme ceux de pygments)
ajouter le déploiement des limites par utilisateur dans le code Ansible
corriger la collecte rrd des métriques concernant les interfaces réseau
remonter les alertes OOM qui ne sont pas normales
comprendre la surconsommation mémoire ? (les boucles actives expliquent la consommation processeur, mais pour la mémoire ?)
Bonus inattendu pour l’incident précédent du 26 juin 2025
De façon cocasse, ce nouvel incident et le temps passé à parcourir les différents logs ont permis de retrouver les infos de la carte d’administration distante et d’expliciter l’origine du redémarrage serveur intempestif. À quelque chose malheur est bon, si on peut dire. Ceci n’est pas une invitation pour un prochain incident.
Vous voulez améliorer nettement votre Wi-Fi à la maison, sans sacrifier votre vie privée ? Bonne nouvelle : on peut aujourd’hui obtenir d’excellentes perfs avec des routeurs et systèmes mesh récents qui tournent officiellement sous OpenWrt. Je vous propose une sélection 2025 claire, triée par RouteurOpenWrt et Système MeshOpenWrt, chacun en 3 niveaux de budget, avec un gros chapitre dédié OpenWrt & vie privée.
Ce qu’il faut savoir en 2 minutes
OpenWrt, c’est un système alternatif pour routeurs. Vous gagnez en contrôle, sécurité, mises à jour, et vous coupez la télémétrie superflue.
En 2025, le choix solide reste le Wi-Fi 6 (et 6E pour quelques cas). Le Wi-Fi 7 avance mais reste peu supporté proprement sous OpenWrt côté “tout-en-un”.
Si votre logement est grand ou à étages, partez sur un système mesh (deux ou trois nœuds), sinon un bon routeur suffit.
Si vous avez de la fibre ≥ 1 Gb/s, prenez un modèle avec au moins un port 2,5 GbE pour ne pas brider le débit.
La sélection des systèmes proposés dans cet article est conforme à la Table Of Hardware préconisé par OpenWrt
Pourquoi OpenWrt (et en quoi ça protège mieux votre vie privée)
OpenWrt remplace le logiciel d’origine du routeur par un système ouvert et maintenu.
Concrètement :
Mises à jour régulières et correctifs de sécurité rapides.
Aucune collecte commerciale par défaut.
DNS chiffré (DoH/DoT/DoQ) pour éviter que vos requêtes soient lisibles en clair.
Blocage des pubs et traqueurs au niveau du réseau (tous vos appareils en profitent).
VPN WireGuard directement sur le routeur (télétravail, déplacements).
Réseaux invités et VLAN pour isoler les objets connectés.
Mesh/roaming standardisés (802.11r/k/v et 802.11s) pour une vraie continuité entre nœuds.
Remarque simple : quand on parle “version stable” d’OpenWrt en 2025, on vise la branche 24.10.x. Installez la dernière révision disponible, point.
Comment choisir en routeur ou système Mesh en 30 secondes ?
Pour savoir si vous avez besoin d’un Routeur (appareil seul) ou d’un système Mesh (Plusieurs Routeurs Interconnectés) voici de quoi vous aider à choisir très simplement. Une fois que vous savez vers quoi vous orienter, rendez-vous dans la section qui vous correspond.
Surface < 100 m², peu d’obstacles → Routeur seul suffira.
De 100 à 180 m² / étage → Routeur puissant ou Mesh 2 nœuds.
> 180 m² ou murs épais → Mesh 3 nœuds, idéalement backhaul Ethernet entre les nœuds.
Beaucoup d’appareils (30+) → privilégiez Wi-Fi 6 en 4×4 et un CPU récent (MediaTek Filogic ou Qualcomm).
ROUTEURS OpenWrt — Les meilleurs choix 2025
J’ai déjà rédigé un article pour présenté les meilleurs solutions de WiFi Mesh Multiroom, et je vous invite à le consulter si vous rechercher des solutions natives grand publics. la sélection qui suit est focus sur les solutions compatibles OpenWrt, donc pour ceux qui recherchent une solution ou la transparence et le contrôle de sa vie privée est primordiale.
Routeur simple et efficace pour un petit budget. Le Wi-Fi 6 tient bien la charge pour 10 à 20 appareils, avec une portée correcte en appartement. Les ports Gigabit suffisent pour une fibre à 1 Gb/s, et OpenWrt s’installe sans prise de tête. Idéal pour activer DNS chiffré, ad-blocking et un réseau invité sans ralentir la connexion.
Format mini, perfs maxi pour sa taille. On apprécie le port 2,5 GbE et la facilité de configuration sous OpenWrt, y compris en mode voyage ou point d’accès d’appoint. Idéal pour une chambre, un bureau ou une résidence secondaire. Ça consomme peu, ça chauffe peu, et ça fait le job proprement.
Routeur discret qui passe partout, avec une radio Wi-Fi 6 très propre pour une maison standard. OpenWrt lui va bien : stabilité, bonnes vitesses et options utiles (réseau invité, contrôle parental basique). Si vous voulez un appareil qu’on installe et qu’on oublie, c’est typiquement celui-là. Excellent rapport simplicité/performances.
Haut de gamme (2,5 GbE, VPN rapide, maison > 150 m² en solo)
Un des meilleurs routeurs grand public récents compatibles OpenWrt. On a du 2,5 GbE pour le WAN et le LAN, un Wi-Fi 6 4×4 musclé et un CPU qui encaisse bien le VPN. Parfait pour un foyer très connecté ou pour lisser la latence avec du SQM. C’est puissant sans être compliqué à vivre au quotidien.
Routeur costaud, taillé pour les foyers qui veulent du 2,5 GbE partout et un VPN rapide. Le Wi-Fi 6 4×4 couvre large et reste stable, même avec beaucoup d’appareils. OpenWrt est natif dans l’ADN du produit, donc les fonctions avancées s’activent facilement. Un excellent choix “performance/praticité”.
Carte routeur pensée avec l’équipe OpenWrt pour être ouverte et durable. On y trouve du 2,5 GbE, du M.2 pour évoluer, et une base MediaTek moderne. Ce n’est pas le plus “plug-and-play” du lot, mais on contrôle tout et on apprend en chemin. Idéal si vous aimez comprendre votre réseau de A à Z.
Tableau — Routeurs (2025)
Modèle (année)
Wi-Fi
Ports RJ45
Pour qui ?
Pourquoi lui
Cudy WR3000 (2023–2025)
AX3000
1×WAN 1G + 3×LAN 1G
Budget < 100 m²
Simple, stable, parfait pour DoH + Adblock
GL-MT3000 (2023)
AX3000
1×2,5G + 1×1G
Nomade / annexe
Compact, facile à configurer
ASUS RT-AX59U (2024)
AX4200
4×1G
Maison standard
Radio propre, bonne portée
ASUS TUF-AX6000 (2024)
AX6000 4×4
WAN 2,5G + LAN 2,5G + 1G
Famille connectée
Débits élevés + faible latence
GL-MT6000 Flint 2 (2023)
AX6000 4×4
2×2,5G + 4×1G
Réseau 2,5 GbE
Très bon en VPN/WireGuard
OpenWrt One AP-24.XY (2024)
AX (2×2/3×3)
2,5G + 1G
Passionnés
Ultra-ouvert, évolutif (M.2)
SYSTÈMES MESH OpenWrt — couverture multi-pièces
Comment raisonner
Backhaul Ethernet (câble entre nœuds) : toujours mieux. Ça libère la radio pour vos appareils et évite les chutes de débit.
Backhaul radio : préférez un kit tri-bande si vous ne pouvez pas câbler.
Mesh OpenWrt : fonctionne en 802.11s (vrai maillage) et roaming 802.11r/k/v pour des bascules invisibles d’un nœud à l’autre.
Bon compromis prix/perfs pour 3 à 5 pièces. Le Wi-Fi 6 est efficace et OpenWrt offre les fonctions utiles (réseau invité, ad-blocking, DNS chiffré). Idéalement, reliez les deux boîtiers en backhaul Ethernet pour garder un Wi-Fi rapide sur tous les appareils. Vérifiez la révision matérielle compatible avant achat.
Un kit récent, discret, et facile à poser. Avec OpenWrt, on active rapidement les réglages de sécurité et le roaming, sans complexité. La couverture est homogène dans une maison de 120 à 180 m². En filaire ou en radio, le maillage reste stable pour le streaming, les visios et le jeu léger.
La valeur sûre pour les grandes surfaces sans câbles. La troisième bande sert de voie dédiée entre nœuds, donc le Wi-Fi reste fluide même en backhaul radio. OpenWrt est mature sur ce modèle, avec un roaming propre entre satellites. C’est le choix “sans surprise” pour une maison exigeante.
Astuce “Mesh DIY” : deux routeurs identiques (ex. 2× RT-AX59U ou 2× TUF-AX6000) reliés en Ethernet, avec 802.11r activé. Dans beaucoup de maisons, c’est plus stable et plus rapide qu’un mesh 100 % radio.
Tableau — Systèmes mesh (2025)
Modèle (packs)
Wi-Fi
Backhaul recommandé
Pour qui ?
Pourquoi lui
Cudy M3000
AX3000
Ethernet
Maison 3–5 pièces
Prix doux, simple à déployer
D-Link M30 Aquila
AX3000
Radio ou Ethernet
120–180 m²
Installation facile, débit stable
Linksys Velop MX4200
AX4200 tri-bande
Radio si pas de câble
Grandes maisons
Bon backhaul sans fil
Mise en route OpenWrt : le “kit privacy” en 7 étapes (5–15 min)
Changez le mot de passe admin dès la première connexion.
Mettez à jour vers la dernière révision 24.10.x disponible pour votre modèle.
Activez WPA2-AES ou WPA3 pour le Wi-Fi (évitez WPA/WEP).
DNS chiffré : installez un paquet DoH/DoT (ex. https-dns-proxy ou smartdns), choisissez un résolveur sérieux (Cloudflare, Quad9).
Bloquez pubs/trackers : installez adblock ou adblock-fast et chargez une liste légitime (par ex. oisd).
Créez un réseau invité séparé pour les objets connectés (SSID + mot de passe dédiés).
VPN (option) : si vous bossez à distance, configurez WireGuard en client vers votre fournisseur VPN, ou en serveur pour accéder chez vous.
Bonus performance : si votre box opérateur est obligatoire, mettez-la en mode bridge (ou DMZ vers le routeur OpenWrt), pour que le routeur OpenWrt gère vraiment le réseau.
Questions fréquentes
Qu’est-ce que Wi-Fi 6, 6E, 7 ?
Wi-Fi 6 = plus d’efficacité et de portée.
Wi-Fi 6E ajoute la bande 6 GHz (plus propre mais portée un peu plus courte).
Wi-Fi 7 va plus loin (agrégation de canaux, MLO), mais les routeurs “OpenWrt-friendly” sont encore rares en 2025.
Je veux juste que ça marche, sans prise de tête. Je choisis quoi ? Logement standard : ASUS RT-AX59U. Grand logement sans câble : Linksys Velop MX4200. Réseau domestique 2,5 GbE ou gros usage VPN : ASUS TUF-AX6000 ou GL-MT6000.
Et si j’ai déjà une box opérateur ? Gardez la box pour l’accès Internet, mais confiez le Wi-Fi et le routage à l’appareil OpenWrt. Idéalement, mettez la box en bridge ou en DMZ vers le routeur OpenWrt.
Wi-Fi 7 : j’achète maintenant ? Pas si vous voulez absolument OpenWrt “propre”. Préférez un bon Wi-Fi 6 maintenant. Vous ne perdrez pas grand-chose en usage réel, et vous gagnerez en stabilité.
Conseils d’achat rapides
Vérifiez la révision exacte du produit avant d’acheter (nom, version matérielle).
Prévoyez un switch 2,5 GbE si vous avez déjà un NAS/PC en 2,5 Gb/s.
Câblez ce que vous pouvez (surtout les nœuds mesh).
Un seul SSID par bande dans la plupart des cas : c’est plus simple, et le roaming fonctionne mieux.
Je me note ça sous le coude (pas pratique : faut 'ach'ment se contorsionner !) pour évaluer ma connexion internet.
J'apprécie que cela soit directement dans un navigateur. Par ailleurs, outre les informations usuelles : paquets ASC/DESC perdus/retardés, le ping et la gigue, j'aime bien que l'on puisse configurer le test, notamment avec des préconfigurations (stream, jeu, visio, …).
Je me suis récemment acheté pour 15 et quelques euros un boîtier à brancher sur la TV (ou tout autre écran avec entrée HDMI) et qui permet d’y diffuser une vidéo depuis son smartphone. À la façon d’un chromecast, mais pour beaucoup moins cher, et sans la dépendance à un fournisseur externe, ou un autre réseau.
Par ailleurs j’avais le TripMate sous le coude depuis longtemps.
Prochainement je serai pendant un certain dans un environnement sans internet, mais avec une TV et l’envie de regarder des films.
Du coup j’ai préparé un setup qui fonctionne où je lis sur un disque-dur (DD) branché sur le TripMate (TM) un film téléchargé à l’avance et le diffuse sur la TV. Tout ceci sans-fil ! Le seul branchement est de DD au TM, et le boîtier à la TV.
Par ailleurs j’ai acheté un boîtier audio qui se branche sur une prise jack d’un côté, et en bluetooth (BT) de l’autre. Il fonctionne dans les deux sens (Tx/Rx) : mon cas-d’utilisation (UC) est de diffuser la TV sur une enceinte BT ; mais un autre UC est de diffuser sur son auto-radio de la musique depuis un smartphone par exemple.
Bref, je suis content de mon installation et je me suis amusé à modéliser cela avec plantuml ; cela donne le bousin en lien, et avec le code source suivant :
@startuml
database DisqueDur as DD
cloud Internet as Int
node TripMate as HT
node BoîtierTV as BTT
node BoîtierSon as BTS
node EnceinteBT as EBT
interface Bluetooth as BT
[DD] - USB: Vidéo+Audio
USB - [HT]
[HT] .. WiFi1
[HT] . [Wifi3]
Wifi3 . Int: Web\n(éventuellement)
WiFi1 .. [Smartphone]: Vidéo+Audio + Web
[Smartphone] .l.> WiFi2: Vidéo+Audio
WiFi2 .l. [BTT]
[BTT] --> HDMI: Vidéo+Audio
HDMI --> [Écran]
[Écran] -r-> Jack: Audio\n(éventuellement)
Jack -> [BTS]
[BTS] .u.> BT
BT -r-> EBT
@enduml
Connexion
Entrée de gamme (Wi-Fi solide, fibre ≤ 1 Gb/s)
Milieu de gamme (maison standard, fibre 1 Gb/s)
Haut de gamme (2,5 GbE, VPN rapide, maison > 150 m² en solo)
