OpenWrt in a BOX

OpenWrt in a BOX

L’histoire…

D’OpenWrt

L’histoire d’OpenWrt est fortement liée au routeur Linksys WRT54G. Ce routeur fut le premier à profiter d’une solution ouverte basée sur une Linux et fortement orientée pour le routage. Je crois que pour les routeurs il a un avant et un après OpenWrt. Des distributions similaires sont apparues sur des matériels compatibles, comme DD-WRT ou Tomato. Cela permet en gros de débloquer toutes les fonctionnalités possibles des routeurs outrepassant même la puissance hardware brute que l’on peut exploiter (et cela peut être effectivement un problème).

Aujourd’hui les firmwares des constructeurs reposent finalement plus ou moins tous sur une base d’OpenWrt. L’effort de développement est donc facilité pour tous ces constructeurs.

L’argument commercial principal de ces routeurs, c’est essentiellement l’augmentation des débits du Wi-Fi. Ce qui est malheureusement un très mauvais prétexte, mais marche très bien car la plupart des box font l’impasse d’antennes limitant le débit dans une maison assez grande… Les utilisateurs se retrouvent parfois avec une solution plus complète mais pas si facile que ça à configurer (et dont la portée peut être similaire aux BOX opérateurs).

De mes envies

Comme nous sommes toujours limités par les fonctionnalités offertes par les Box des opérateurs, les solutions sont parfois de déporter une partie de l’intelligence sur un serveur externe. Le principal problème que cela peut poser c’est la disponibilité de ce serveur, la puissance de celui-ci et la volonté de fournir (ou non) cette puissance supplémentaire alors qu’un petit routeur peut faire l’affaire. De mon côté j’avais plutôt envie d’externaliser ces fonctionnalités dans un équipement qui consomme pas beaucoup d’énergie et n’ayant pas de dépendance avec mon serveur principal (si celui-ci est éteint, l’accès à internet continue de fonctionner).

J’ai commandé un TP-Link Archer C7 pour commencer les investigations. J’ai trouvé que les fonctionnalités et que l’ergonomie est suffisamment bonne pour un service sans prise de tête. Le problème de ce petit routeur c’est que le processeur est un simple MIPS qui n’est finalement pas très puissant. Difficile pour lui d’ouvrir un flux VPN en plus de ses fonctionnalités de routage d’autant que toutes ses fonctionnalités d’accélération réseau sont désactivées en passant sur un firmware Open Source.

N.B : J’ai vu qu’il était possible d’overclocker pas mal ce petit routeur. Cela peut donc est une bonne alternative pour ceux qui veulent une solution à moindre coût mais « tweaké à mort ».

J’ai donc décidé d’aller taper un peu plus haut et plus fort et même si normalement le Linksys WRT3200ACM est plus que conseillé, voir même le Turris Omnia. J’ai décidé d’aller explorer des horizons inconnus en allant sur un modèle qui n’est malheureusement pas pleinement supporté par OpenWrt. Il reste donc « bloqué » dans une version maintenant obsolète. Ce routeur est le GL-iNet Flint (GL-AX1800). Je l’ai choisi car c’est un quad core ARM, et ces temps-ci je suis plutôt ARM maximaliste et il n’est pas cher.

Les fonctionnalités utiles

Je ne vais parler que des fonctionnalités qui sont importantes pour moi.

Firewall

Le premier point le plus évident est qu’il est possible d’avoir accès à un firewall avancé, permettant de définir des règles plus précises que celles définissables avec les BOX des opérateurs.

DNS Dynamique

Si comme moi, vous n’avez pas une IP fixe il est possible d’avoir accès à un service qui met à jour l’IP fournie par l’opérateur dans un service du style « DNS Dynamique », ou même au niveau du registrar si vous avez acheté un domaine particulier.

VPN

Aujourd’hui les services VPNs deviennent légion sous l’excuse d’une « confidentialité retrouvée ». Aujourd’hui cela peut être intéressant si vous assainissez votre charte de présence sur Internet. J’ai donc implémenté ce type de service sur mon réseau, cela fera l’objet d’un billet plus détaillé.

Sur ce routeur Wireguard et OpenVPN sont bien évidemment supportés.

Serveur DHCP

Je n’en avais pas forcément l’utilité, mais comme je le disais plus haut, j’avais envie de délester au maximum mon serveur. Donc cela peut être un plus si le routeur porte toutes les fonctionnalités. Cela peut être par contre dérangeant si celui-ci tombe en panne… (Faut-il que j’en commande un autre ?)

Serveur DNS : AdGuard Home

J’ai abordé sur ce billet plus détaillé l’intégration d’AdGuard Home dans un réseau domestique. Cela permet de mettre en place une plus grosse confidentialité sur les requêtes DNS et de passer par DoH (DNS over HTTPS). Cela permet de limiter le DNS sniffing des opérateurs. Par contre les requêtes sont « visibles » par le fournisseur final, donc il faut bien le choisir. A priori Quad 9 serait plutôt bien positionné.

Routes statiques

Lorsque le réseau devient un poil plus compliqué avec des machines virtuelles ou du Docker sur certains hôtes il peut être intéressant au niveau du routeur de définir des routes statiques pour savoir comment atteindre ces services…

Répartition de charge en sortie

Le support de multiples WAN peut être intéressant lorsque l’on veut mettre en place un failover entre la fibre et la 5G par exemple. Dans mon cas ce sera de mettre en place un « choix » entre ce qui passe dans le VPN et qui passe par la liaison FAI traditionnelle. Sans vouloir être pointilleux et mettre des « kill switch » à tout va, le plug-in MWAN3 fait très bien l’affaire.

Les problèmes

Je vais aborder rapidement les problèmes rencontrés spécifiquement avec ce routeur, si quelqu’un passe par là et veut comprendre s’il rencontre les mêmes problèmes :

  • LuCI qui n’est pas installé par défaut, et qui doit être réinstallé à chaque mise à jour (comme tout plugin additionnel).
  • Mise à jour du routeur problématique : certaines corrections mises en place à cause du décalage entre l’interface de GL-iNet, et ce qui est faisable sous LuCI (par exemple le support des VLANs, d’autres réseaux que le WAN/Réseau interne/Réseau invité).
  • Le plugin MWAN3 ne fonctionne pas bien et certaines lignes dans les tables de routage sautent. Il suffit de les ajouter manuellement dans le « Hotplug Script » de la configuration avancée.
  • Le Dynamic DNS ne fonctionne pas, car il est implémenté par défaut qu’avec le service de GL-iNet. Il suffit de modifier les scripts de démarrage dans « /etc/init.d/ddns ». Et de modifier la condition de lancement du script (qui par défaut ne se lance qu’avec le service de GL-iNet).
  • Par défaut le service OpenVPN ne démarre que si on utilise le service de GL-iNet, il faut donc forcer le démarrage dans le script de démarrage du routeur « Local Startup ».
/etc/init.d/openvpn reload 2>/dev/null
  • Et certainement d’autres problèmes…

L’avenir

Sur les forums de GL-iNet, l’avenir semble bien orienté vers une mise à jour vers la dernière version d’OpenWrt. Il faut donc laisser du temps à l’équipe de développement pour effectuer la migration vers quelque chose de beaucoup plus stable (avec on l’espère un noyau plus récent). Une fois ce travail effectué je pense que ce petit routeur à moins de 100€ sera vraiment intéressant et rentable pour quiconque cherche une solution domestique flexible et suffisamment puissante. C’est un petit pari sur l’avenir, mais comme je me plais à le dire « No Risk, no reward ».