J’ai depuis un peu plus de 2 mois, le routeur GL.iNet Flint 2 (GL-MT6000), dont j’aimerais vous faire un petit compte rendu qui m’a été souvent demandé ces dernières semaines (certains se reconnaitront 😉), sous forme de mini-test (mini-test parce que je ne détaillerais pas toutes les fonctionnalités de ce routeur, car je ne les utilise pas au quotidien ou que je n’ai pas de quoi les tester).
1. Contexte, le pourquoi du changement de routeur
Il y a un peu plus de deux mois, j’ai acheté un nouveau routeur, le GL.iNet Flint 2 (GL-MT6000), pour remplacer mon ancien Synology RT2600AC, encore parfaitement fonctionnel, mais limité au gigabit et au Wi-Fi 5 (AC).
À la maison, j’ai de plus en plus d’appareils compatibles Wi-Fi 6 (smartphones, mini-PC, Mac), et j’ai donc voulu en profiter pleinement sur mes périphériques. De plus, mon réseau filaire est optimisé pour les 2,5 GbE grâce à des switchs Multi-Gig 2,5 GbE. J’ai donc souhaité exploiter le débit de 2,5 Gb/s que me fournit le port de la Freebox Pop sur mon réseau local, ce qui était impossible avec le Synology RT2600AC.
1.1 Pourquoi un routeur derrière une box ?
Vous vous demandez peut-être pourquoi utiliser un routeur en plus de la box de mon fournisseur d’accès Internet. La raison est simple : ne pas dépendre du matériel fourni par le FAI, notamment en cas de changement de ce dernier ou de box.
J’ai déjà eu des déboires avec une connexion fibre défaillante quand j’avais une Livebox 4 chez Orange. Un redémarrage de la box avait complètement mis hors service mon réseau local : plus de Wi-Fi, plus de serveur DHCP, etc. C’est à ce moment-là que j’ai décidé d’acheter un routeur, le RT2600AC à l’époque, pour éviter de dépendre entièrement du matériel du FAI.
Le routeur reste fonctionnel, peu importe la box, qu’elle soit en panne ou non. Il suffit de configurer la box pour placer le routeur en DMZ ou en mode bridge. Personnellement, je n’ai jamais réussi à faire fonctionner correctement la Freebox avec le RT2600AC en mode bridge, donc je passe par la DMZ. C’est simple et efficace.
1.2 Wireguard
Une dernière chose qui m’a poussée à changer de routeur, c’est l’absence de support du protocole WireGuard sur les routeurs Synology (comme sur leurs NAS). Il serait temps que Synology se décide à l’implémenter, car WireGuard est devenu une référence en matière de VPN de nos jours.
Voilà pour le contexte expliquant mon changement de routeur. Passons maintenant à un mini-test qui prendra la forme d’un compte rendu.
2. Le Flint 2 et ses spécifications techniques
N’ayant pas pensé à prendre des photos lors du déballage, je vous propose celles issues du dossier de presse téléchargeable sur le site de GL.iNet :
Nous avons donc un routeur équipé d’un port 2,5 GbE pour le WAN (en entrée donc) et un autre port 2,5 GbE WAN/LAN, qui peut être utilisé soit comme entrée (WAN), soit comme sortie pour le réseau local (LAN). À cela s’ajoutent 4 ports 1 GbE, ce qui est assez classique pour ce type de routeur.
C’est principalement la présence de ces deux ports 2,5 GbE qui a motivé mon choix pour remplacer le Synology. Grâce à eux, je peux enfin exploiter pleinement la connexion 2,5 GbE de ma Freebox Pop sur l’ensemble de mon réseau local. J’ai également parié sur une amélioration des performances Wi-Fi. Nous verrons plus loin si cela se vérifie.
À l’arrière du routeur, on trouve un bouton de reset, en plus des ports Ethernet, mais il n’y a pas de bouton ON/OFF, ce qui est regrettable pour un appareil de ce type. Toujours à l’arrière, on retrouve les antennes Wi-Fi assez massives, mais robustes.
Sur la face avant, une seule LED est présente, mais étrangement, il n’y a aucune mention de son utilité dans la documentation. Enfin, sur le côté gauche, on dispose d’un unique port USB 3.0.
3. Le firmware et l’interface graphique de gestion du Flint 2
3.1. Parlons firmware
Ce routeur est vendu comme étant parfaitement compatible avec OpenWRT. Voici d’ailleurs le lien vers la page officielle : [OpenWrt Wiki] GL.iNet GL-MT6000. Cependant, par défaut, le routeur est livré avec une interface graphique propriétaire, développée par GL.iNet, qui vient se superposer à OpenWRT. L’interface de gestion native d’OpenWRT, LUCI, reste néanmoins accessible.
Il est également possible de passer sur une version d’OpenWRT sans cette interface supplémentaire, pour une expérience OpenWRT « pure ».
Voici les liens vers les firmwares :
- GL.iNet (dernière version 4.6.4) : Télécharger ici
- Purement OpenWRT (dernière version 23.05.4) : Téléchargement ici
La dernière version du firmware fourni par le fabricant est basée sur une ancienne version d’OpenWRT : la 21.02 (exactement OpenWrt 21.02-SNAPSHOT, r15812+1075-46b6ee7ffc). Il est regrettable que le firmware soit si ancien, alors qu’une version 23.05.4 d’OpenWRT est déjà disponible.
Une mise à jour vers la version 4.7 du firmware GL.iNet est prévue courant novembre, mais je n’ai pas trouvé plus d’informations à ce sujet pour l’instant.
Cependant, dans la section téléchargement de GL.iNet, on voit qu’une version basée sur OpenWRT 24 est déjà en Release Candidate (dernière version avant la version finale) :
3.2. Présentation de l’interface graphique de GL.iNet
Lors de l’installation du routeur, j’ai pu prendre quelques captures d’écran des premières étapes, ce qui donne un aperçu de l’interface graphique GL.iNet.
À l’installation, il n’y a pas de français disponible… Il faut attendre que le routeur soit opérationnel pour pouvoir installer ce qu’il faut pour avoir la traduction dans notre langue française. Voici comment faire :
Enfin, voici quelques captures de différentes parties de l’interface :
Je ne me souviens plus s’il est possible de changer le port de l’interface graphique lors de l’installation initiale, mais cela reste faisable dans la section Système/Sécurité. On peut y modifier le port SSH, ainsi que les ports HTTP et HTTPS.
Remarque sur GoodCloud
GoodCloud est un service similaire au compte Synology, permettant de regrouper différents périphériques pour une gestion centralisée via le cloud. Cependant, je trouve ce service trop limité en termes de fonctionnalités et d’intérêt, surtout pour un utilisateur particulier.
Voilà ce à quoi j’ai accès :
L’une des utilités de GoodCloud est de recevoir une notification lorsque le routeur devient hors-ligne, puis lorsqu’il redevient disponible. Cela permet de savoir quand la connexion Internet est interrompue puis rétablie. Toutefois, le choix des notifications me semble trop basique et limité.
3.3. Présentation de l’interface graphique Luci de OpenWRT
Je ne détaillerai pas ici toute l’interface LUCI, car elle est bien documentée sur le site d’OpenWRT. N’étant pas un utilisateur fréquent, je ne la maîtrise pas totalement. Cependant, sachez qu’elle permet de contrôler le routeur de manière encore plus fine, avec un accès complet à tous les réglages.
Pour accéder à l’interface LUCI, il suffit de se rendre dans les paramètres avancés de l’interface GL.iNet.
LUCI est un peu plus désordonnée et peut sembler surchargée. L’interface est surtout bien moins lisible et donc moins accessible pour un novice. Le message d’alerte est d’ailleurs assez clair : mieux vaut éviter de s’y aventurer si l’on ne sait pas exactement ce que l’on fait.
La version LUCI d’OpenWRT est donc bien plus complète, mais également bien plus complexe à utiliser. Je me demande si je ne devrais pas passer à une version « vanilla » d’OpenWRT, sans la surcouche GL.iNet, car certaines applications, comme AdGuard Home ou BanIP, ne sont pas du tout à jour sur le firmware embarqué par GL.iNet. Il me semble d’ailleurs que la version d’AdGuard Home date de 2023 !
Mais d’un autre côté, si c’est uniquement pour AdGuardHome, je peux m’en passer, voire utiliser un script de mise à jour disponible sur le forum de GL.iNet.
Cela dit, j’ai lu sur leur forum qu’il est fortement déconseillé de mettre à jour les applications via LUCI ou directement via le firmware GL.iNet, sous peine de « briquer » le routeur. Je pense qu’il est préférable de suivre ce conseil, même si, jusqu’à présent, toutes les applications et dépendances que j’ai mises à jour n’ont causé aucun problème.
J’espère simplement que les futures versions du firmware GL.iNet seront accompagnées des dernières versions des applications que je souhaite utiliser (comme ipBan et AdGuard Home).
Maintenant que les présentations sont faites, examinons les débits de ce routeur, que ce soit en Wi-Fi, en filaire ou via une connexion VPN.
4. Les débits sont-ils conformes aux attentes et promesses ?
4.1. Les débits en filaire
Pour tester les débits en filaire, j’ai utilisé l’application iPerf3 depuis plusieurs machines différentes, ainsi que directement sur le routeur lui-même. Afin d’exploiter le port 2,5 GbE entre mon routeur (situé dans mon salon) et mes NAS et ordinateurs (dans mon bureau), j’ai plusieurs switchs multi-gig reliés entre eux par un câble réseau Cat. 5e :
- Un Asustor Switch’nstor (ASW205T) ;
- Deux Davuaz 8 Ports 2.5G Base-T et 1 Port Uplink 10G SFP, reliés entre eux par un câble SFP+ 50 cm.
Les périphériques utilisés ne possédant pas tous un port réseau 2,5 GbE, j’ai recours à des adaptateurs USB-RJ45 2,5 GbE pour les deux Mac et pour mon Synology DS920+. L’Asustor AS6704T et les mini-PC possèdent, quant à eux, au moins un port 2,5 GbE.
Quelles que soient les configurations utilisées (Mac, NAS, mini-PC), les résultats sont très similaires.
Voici les résultats obtenus entre le NAS Asustor AS6704T et le routeur, avec le serveur iPerf3 installé sur le routeur (les résultats sont similaires si le serveur est sur le NAS) :
- Le NAS envoie les données :
- Le routeur envoie les données :
On constate que les débits depuis le routeur vers un périphérique sont très proches du maximum de la norme 2,5 GbE, mais dans l’autre sens, les débits sont un peu plus faibles. Dans ma configuration, cela n’est pas très gênant, car les NAS et les mini-PC communiquent entre eux via un switch 2,5 GbE et non pas par le routeur, donc les transferts ne sont pas impactés par cette baisse de vitesse de réception du routeur. Je ne parviens pas à expliquer cette diminution.
4.2. Les débits en Wi-Fi
Pour tester les débits en Wi-Fi, j’ai utilisé mon MacBook Air M2 ainsi que mon iPhone 15, tous deux compatibles Wi-Fi 6. Pour mon MacBook Air, j’ai utilisé à la fois iPerf3 et l’application SpeedTest, tandis que pour mon iPhone, j’ai uniquement utilisé SpeedTest. Pour les deux tests iPerf3 réalisés (voir ci-dessous), le MacBook Air se trouvait à 50 cm du routeur :
À la même distance, j’ai obtenu ces débits avec SpeedTest, qui sont similaires à ceux du test iPerf3 :
Pour les tests Wi-Fi à d’autres distances, j’ai choisi d’utiliser uniquement SpeedTest.
J’ai regroupé tous les résultats dans le tableau ci-dessous :
On remarque que les débits sont plutôt bons, en tout cas bien meilleurs que ceux que j’avais avec le Synology RT2600AC (ce qui est normal, étant donné que ce dernier n’était qu’en Wi-Fi 5). Logiquement, ces débits décroissent en fonction de la distance et des obstacles.
J’ai gagné en couverture Wi-Fi avec ce GL.iNet, car dans une pièce située à l’étage, complètement à l’opposé de l’emplacement du routeur (à environ 12 m, avec dalle en béton armé et cloisons), je n’avais presque pas de Wi-Fi avec le Synology. En revanche, avec le GL.iNet, la situation est beaucoup améliorée, avec des débits convenables.
Je précise que j’ai mis la puissance maximale pour les deux types de Wi-Fi :
4.3. Les débits via les serveurs VPN
4.3.1. Avec le serveur VPN Wireguard |
4.3.2. Avec le serveur VPN OpenVPN |
|
|
|
|
|
|
 |
 |
Pour information, voilà les débits Speedtest sans connexion VPN depuis mon MBA au moment des tests précédents (VPN) :
Les débits via VPN promis par GL.iNet (voir capture ci-contre) sont presque respectés en ce qui concerne WireGuard. Les débits en OpenVPN sont même dépassés, ce qui est étonnant.
J’ai lancé une connexion vers ces serveurs VPN depuis mon réseau local, car je ne dispose pas d’une connexion 5G suffisamment performante, en veillant à rediriger tout le trafic par le serveur VPN.
Il faudrait que j’essaie avec une bonne connexion 5G, mais la couverture chez moi n’est pas suffisante…