Richard Dern

Neuro-atypique | Écrivain | Développeur Web

Ne rien faire sans l'ambition du spectaculaire, mais se rappeler que l'intensité de l'échec est proportionnelle à l'ambition de la tentative.

Mon réseau

J’avais envie d’honorer une vieille tradition geek : présenter mon réseau, son architecture, son contenu, etc. Deux objectifs sont poursuivis : un objectif de mémoire - un jour, je relirai cet article avec nostalgie… - et un objectif d’échange - si vous trouvez des infos intéressantes ici, ou si vous avez des idées d’amélioration.

Il n’y a aucun lien d’affiliation dans mes articles, et celui-ci ne fait pas exception.

Généralités

Je suis client free depuis 2004. Malgré l’arrivée de la fibre dans ma commune, free ne figure pas encore dans les FAI disposant d’une offre commerciale, et je n’ai aucunement l’intention de changer juste pour avoir la fibre.

En conséquence, mon débit actuel est d’environ 13 Mbits/s en descendant et 1 Mbits/s en montant. Cela peut vous sembler peu si vous êtes habitués à la fibre, mais honnêtement, on n’en souffre pas.

On est deux à utiliser Internet : moi de toute façon, et mon épouse, particulièrement depuis la pandémie de Covid-19, avec beaucoup de visio-conférences. Malgré cela, ni elle ni moi n’avons de problèmes de débits, de latences ou de lenteurs avec Internet ou avec le réseau en général.

Nous n’avons pas de téléphone fixe : mon épouse a le forfait mobile illimité et moi le forfait mobile gratuit (je n’utilise mon portable que pour recevoir des appels). Nous ne regardons pas la télévision « conventionnelle », exclusivement la VoD via Netflix, Amazon Prime et AppleTV+. Pour un replay occasionnel, on utilise Molotov.

Freebox

Ma Freebox est une Révolution configurée en bridge (j’attends la fibre pour la renouveler). Je dispose d’une adresse IPv4 « full-stack », demandée dès que l’option était disponible, et de l’IPv6 natif.

Topologie simplifiée

Voici la topologie simplifiée (et plutôt conventionnelle) de mon réseau. Je n’ai pas mis les machines « clientes ». Le switch est un TP-Link TL-SG1016.

Topologie simplifiée de mon réseau

Wifi

J’ai deux Synology MR2200ac configurés en mesh. Cela confère un certain nombre d’avantages :

  • toute la configuration de mon réseau sans-fil se fait depuis une seule interface (ce n’est pas spécifique à Synology)
  • je n’ai à configurer qu’un seul SSID sur toutes mes machines, qu’elles utilisent la bande de 5GHz, 2.4GHz, en wifi g, n ou ac
  • la connexion est stable, même en basculant d’un point d’accès à l’autre

Avant cela je disposais de deux RT1900ac et la configuration était pénible et instable à l’usage en l’absence du mode mesh.

En outre, j’ai mis en place un vieux TP-Link TL-WA801N en guise d’extension du réseau à l’usage quasi exclusif de la station météo située à l’extérieur.

Outils communs

Sur toutes les machines « serveurs », à l’exception du routeur, j’ai installé cockpit et dnsmasq.

Vous me reprocherez sûrement de ne pas être un vrai barbu, mais j’aime bien avoir une UI. Je dirai même, j’en ai besoin : j’ai un besoin primaire de « voir » mes machines, via des graphiques et des icônes, des tableaux et des couleurs. C’est un choix personnel et sensible, en aucun cas une prérogative au fonctionnement de mon réseau. C’est à ce besoin primaire que répond cockpit, qui me permet d’ailleurs d’accéder à l’ensemble des machines de mon réseau depuis la même interface, ainsi qu’à leur shell, et à différentes statistiques et fonctionnalités que j’aime bien avoir à portée de main.

Toutefois, je reproche à cockpit quelques manquements, en particulier l’état SMART des dispositifs de stockage qui le supportent, ou la température des composants.

J’installe aussi dnsmasq afin de limiter les requêtes au serveur DNS principal. dnsmasq fait alors office de simple cache pour chaque machine. Le but n’est pas tellement de limiter les connexions réseau (bien que cela constitue un corollaire appréciable) mais surtout de limiter les accès disque sur le serveur DNS principal qui est un Raspberry Pi dont le support de stockage est une carte SD.

Routeur

Mon routeur est un AWOW AK34. Il dispose d’un Celeron N3450, 6Go de DDR4, un SSD de 128Go et surtout, deux ports gigabit. Il est installé sous OpnSense.

L’un des ports est relié à la Freebox ; du point de vue de OpnSense, c’est l’interface WAN. L’autre port est relié au switch ; c’est l’interface LAN.

Particularités

IPv6

J’ai eu beaucoup de difficultés à disposer d’un réseau en IPv6 fonctionnel, et même maintenant, tout n’est pas parfait. Bien que tout a l’air de bien fonctionner côté client, je ne me suis toujours pas décidé à rendre disponibles mes sites et services sur IPv6. Je ne comprends pas encore comment ça fonctionne et j’ai peur de compromettre la sécurité du réseau.

En tous les cas, free fait plutôt bien les choses de ce côté puisqu’ils mettent à disposition huit préfixes IPv6. C’est six de plus que ce dont j’ai besoin pour mon réseau à l’heure actuelle, j’aime bien avoir de la marge.

Dans OpnSense, on va dans Interfaces, Overview, et on récupère l’IPv6 « link-local ».

Dans l'interface de configuration de la Freebox, on va dans Paramètres de la Freebox, puis Configuration IPv6. On colle cette IPv6 dans les deux premiers champs « Next Hop ». On déclare ainsi que la Freebox doit envoyer tous les paquets réseau à destination des adresses de ces préfixes à notre propre routeur. On en profite pour noter l’IPv6 de lien local de la Freebox.

De retour sous OpnSense, on va dans Interfaces, [WAN], pour y définir IPv6 Configuration Type à Static IPv6. Plus bas, dans Static IPv6 configuration, on définit l’adresse IPv6 qu’on souhaite attribuer à notre routeur, sachant que <prefixe_1>::1 correspond à l’adresse IPv6 de la Freebox et ne doit donc pas être utilisé. Traditionnellement, je lui attribue donc l’IPv6 <prefixe_1>::2. Il faut encore ajouter une IPv6 Upstream Gateway, qui pointera vers l’IPv6 de la Freebox sus-mentionnée (<prefixe_1>::1 donc).

Même procédure dans Interfaces, [LAN], sauf que cette fois, on utilisera le deuxième préfixe offert par la Freebox, que la Freebox ne dispose pas d’IPv6 sur ce deuxième préfixe, et qu’aucune passerelle n’est à créer. Donc, on va mettre <prefixe_2>::1 dans le champ IPv6 address, et laisser les autres valeurs par défaut.

Dernière étape, il faut aller dans Services, Router Advertisements. Pour chaque interface, [LAN] et [WAN], on configurera comme suit:

Pour le [LAN], on mettra <prefixe_2> dans Advertise Routes.

Il ne reste plus qu’à activer le serveur DHCPv6 sur le LAN.

Problèmes

Les périphériques clients sont incapables d’obtenir une adresse IPv6 fournie par le serveur DHCPv6 d’OpnSense dans la plage que j’ai défini, comprise entre <prefixe_2>::ffff:1 et <prefixe_2>::ffff:ffff, alors qu’ils récupèrent bien l’IPv6 du serveur DNS configuré. Évidemment, le serveur DHCPv6 est désactivé sur la Freebox, et il n’y a pas d’autre serveur DHCPv6 sur le réseau. Cela fait partie des nombreuses choses que je ne comprends pas encore sur l’IPv6…

Firewall

Si je n’ai qu’un seul conseil à donner par rapport à la gestion du firewall sur OpnSense, c’est d'utiliser massivement les alias. C’est simple à gérer, très puissant, et simplifie toute la configuration du firewall. En l’occurrence, je créé deux alias par serveur (un pour l’IPv4, un pour l’IPv6), plus un s’il est accessible depuis l’extérieur, contenant la liste des ports à rediriger.

En outre, je veux que toutes les machines du réseau (en particulier celles dans lesquelles je ne peux pas avoir confiance, telles que le Windows de travail de mon épouse, ou la SmartTV) utilisent mon serveur DNS (un Raspberry Pi) et mon serveur NTP (le routeur lui-même). Pour ce faire, il faut créer des règles de Port Forward dans la configuration du NAT, une pour l’IPv4 et une pour l’IPv6, donc deux par protocole. Ce sont les quatre dernières règles de la capture d’écran suivante.

Problèmes

Ces règles sont facilement outrepassées par DNS-over-TLS.

DNS

J’utilise unbound sur OpnSense, mais uniquement pour l’association entre le nom des machines et leur adresse attribuées par le serveur DHCP. Toutes les autres requêtes DNS sont envoyée au serveur DNS interne qu’on verra plus tard. Pour que le routeur lui-même utilise ce serveur, j’ai renseigné ses IP v4 et v6 dans System, Settings, General, et j’ai désactivé Allow DNS server list to be overridden by DHCP/PPP on WAN : je ne veux pas utiliser les serveurs DNS de mon FAI (ni « aucun » autre, en fait : on verra plus tard ce que j’entends par là).

Sauvegarde de la configuration

J’utilise un plugin très pratique, à installer depuis System, Firmware, Plugins : os-git-backup. Il fait exactement ce que son nom entend : il sauvegarde automatiquement toute la configuration d’OpnSense dans un dépôt git, dès qu’une modification survient et avant application de toute mise à jour.

IPS/IDS

J’ai activé l'IPS (Suricata), en mode IDS, mode dans lequel Suricata doit bloquer les intrusions qu’il détecte. Cependant, dans l’onglet Alerts, je ne vois pas de mention des paquets bloqués - seulement Allowed dans la colonne Action. Je ne sais pas si c’est normal.

Performances

Je dois dire que je suis agréablement surpris par les performances de cette machine, en particulier malgré l’activation de l’IDS. La charge moyenne est inférieure à 0.40, l’utilisation CPU reste sous les 5%, la consommation mémoire sous les 1.5Go, et l’espace disque utilisé est de 2.5G, de quoi assurer une durée de vie conséquente au SSD de 128Go (en théorie).

Serveur DNS

Le serveur DNS est hébergé sur le serveur domotique. C’est un pi-hole dans un container docker, et unbound en tant que serveur récursif. Tout est expliqué dans la documentation de pi-hole.

Supprimé le 12/03/2021 Le serveur DNS est un Raspberry Pi 4 2Go (malgré mes déceptions concernant cette machine) sur lequel j’ai installé Raspberry Pi OS Lite 32 bits, pi-hole et unbound.

pi-hole en tant que tel se contente de vérifier que les domaines dont on lui demande la résolution figurent (ou pas) dans ses listes de blocage. Il transfère la résolution des domaines non-bloqués à un serveur tiers. Je veux que ce serveur tiers soit le mien, et pas Google ou CloudFlare. D’où l’installation de unbound, qui va agir en tant que serveur DNS récursif.

C’est très facile à faire, tout est expliqué dans la documentation de pi-hole.

À l’heure actuelle, j’ai 2 047 579 domaines blacklistés. Sur 24h, il y a eu 54 000 requêtes provenant de 31 clients (dont 12 500 provenant du Windows du boulot de mon épouse, c’est deux fois plus que mon serveur web principal, quatre fois plus que mon propre poste de travail sous macOS…), et 9 274 requêtes bloquées. Le tout avec une charge moyenne de 0 (!) et une consommation mémoire de 6.4%. Plutôt pas mal, je trouve…

NAS

Mon NAS est un Synology DS216play sur lequel j’ai notamment installé Gitea, ce même Gitea depuis lequel vous pouvez télécharger les sources de mes différents projets. Il est doté de deux SSD Samsung 860 EVO de 500Go. Il est intéressant de noter que je n’utilise que 93Go des 460 de disponibles : je ne stocke pas de vidéos (j’ai une blu-ray-thèque très conséquente, plus la VoD déjà mentionnée) ni de musique (je ne suis pas très consommateur de musique et celles que j’aime sont sur CD).

Reverse-proxy

Le reverse-proxy est hébergé sur le serveur web public (voir plus bas).

Supprimé le 12/03/2021 Le reverse-proxy est aussi un Raspberry Pi 4 de 2Go sous Raspberry Pi OS Lite 32 bits. La seule application installée est le serveur Caddy.

J’aurai pu héberger le reverse-proxy sur OpnSense. Après tout, entre ha-proxy et nginx, il y a le choix. Par contre, cela représente un risque (probablement mineur) en terme de sécurité, mais surtout, c’est incroyablement compliqué.

C’est une question philosophique qui appelle à de nombreuses réflexions. Pour commencer, OpnSense est un système BSD, pas nécessairement réputé pour être accessible. Si GNU-Linux joue clairement la carte du grand public depuis longtemps maintenant, et est sorti du carcan des geeks, BSD est clairement plus élitiste, dans la mesure où l’utilisateur est totalement libre de ses choix - et on ne le tient pas par la main… Cela se traduit par des interfaces ultra-complètes, des options à profusion et richement documentées, des menus et sous-menus, des onglets et des sous-onglets (dans OpnSense en tout cas).

Avec cette liberté vient le problème de la complexité. On est tellement libres de faire ce qu’on veut qu’on ne sait pas comment faire les choses les plus simples. Je n’ai jamais réussi à faire fonctionner ni ha-proxy ni nginx avec Let’s Encrypt sur OpnSense en tant que reverse-proxy, parce que je ne comprends pas le tiers des options qui me sont offertes, ni comment elles interagissent les unes avec les autres.

Je ne blâme pas OpnSense pour ça, au contraire. Mais à l’echelle du système d’exploitation, je trouve que cela créé un fossé entre le geek hobbyiste et le professionnel, fossé comblé par un support technique payant dans le cas de pfSense et raison principale pour laquelle je lui préfère OpnSense depuis quelques années : je trouvais OpnSense plus accessible au geek hobbyiste. C’est toujours vrai pour l’ensemble du système d’exploitation, mais ces plugins spécifiques au cas d’usage du reverse-proxy sont clairement destinés à des personnes qui maitrisent ha-proxy et nginx sur le bout des doigts, ce qui n’est pas mon cas. Ce que moi je veux, en tant que geek hobbyiste, c’est une application qui me demande le moins possible, mais qui propose des fonctionnalités complètes et complexes si je veux creuser le sujet.

C’est ce que m’offre Caddy. En une soixantaine de lignes de configuration en JSON, j’ai réglé l’accès à l’ensemble de mes sites publics, avec du Let’s Encrypt partout, et des valeurs par défaut optimisées et relativement sécurisées, sans prise de tête avec les éventuels certificats auto-signés de certains services internes incapables de fonctionner sans. Et si je veux lui demander plus que ça, je peux : c’est dans la documentation.

Le premier contact avec Caddy ne pourrait pas être plus simple, alors que les plugins d’OpnSense offrent par défaut une complexité rebutante et anxiogène : si je configure mal une option, ou que j’en oublie une autre, j’ouvre une potentielle faille de sécurité sans le savoir. Je ne dis pas que Caddy est plus sûr que les autres… Je dis que c’est peut-être plus difficile de commettre une erreur d’inattention avec Caddy que nginx ou ha-proxy sur OpnSense.

Serveur web public

C’est un Kodlix GN41. Processeur Celeron N4100, 8Go de DDR4. J’y ai installé un SSD Samsung 750 EVO de 120Go, afin d’économiser les 64Go d’eMMC intégrés (et pour une question évidente de rapidité). Je suis très surpris par les performances de cette machine : la charge moyenne est d’environ 0.30 avec une utilisation CPU inférieure à 5%, et moins de 3Go de mémoire utilisée. Pourtant, les applications que j’y ai installé ne sont pas particulièrement légères :

Sans compter leurs dépendances (particulièrement PostgreSQL et Redis). Cette machine héberge également mes sites statiques (dont celui que vous êtes en train de lire). Je vous laisse apprécier la rapidité d’accès à mes services, en n’oubliant pas que ma connexion montante est limitée à 1 Mbits/s.

C’est Caddy qui fait office de reverse-proxy. J’utilise GoAccess pour générer quelques statistiques de fréquentation.

Serveur domotique

Le serveur domotique est un Beelink T34, doté d’un Celeron N3450, de 4Go de mémoire vive et de 64Go de eMMC. J’y ai installé Home Assistant dans sa variante « container Docker », donc pas supervisé et pas d’accès aux add-ons. Ça rend toute la configuration un peu plus complexe - encore que - mais au moins, j’ai accès à mon système pour y faire ce que je veux, et en particulier une chose que ne me permet pas de faire Home Assistant dans ses variantes OS et Supervised : disposer d’un serveur CalDAV.

J’utilise en effet CalDAV pour gérer l’automatisation de l’éclairage et du chauffage de la maison. Ça me permet un contrôle précis et facile, non seulement des horaires mais aussi des profils d’éclairage ou de chauffage. Grâce à cette méthode, je peux définir les dates et heures pendant lesquelles je veux certaines scènes d’éclairage. Je définis un éclairage « type » pour toute l’année, mais un éclairage type « chaudron ardent » (flamme orangée vacillante) pour tout le mois d’octobre, et « chaudron magique » (flamme violette) pour le 31 ! Ça me permet également de planifier un mode hors-gel pour le chauffage pendant une absence prolongée, en plus des modes « Présent » et « Absent » pour le reste de l’année. Une configuration aussi fine me permet de faire des économies d’énergie, même si ces économies sont difficiles à chiffrer de part l’irrégularité de la météo (on a chauffé beaucoup plus cette année que l’année dernière, à cause d’un froid particulièrement prononcé), la variation des tarifs et abonnements à l’électricité, etc.

Après avoir testé un certain nombre de solutions, j’ai fini par opter pour Radicale. J’ai ajouté le module RadicaleInfCloud, afin d’avoir une solution complètement autonome : même si les chances sont maigres, dans le cas hautement improbable où j’aurai en même temps besoin de modifier le calendrier de l’éclairage ou du chauffage et que je n’ai pas accès à un de mes ordinateurs, pas besoin de configurer un client (en particulier, de se souvenir de l’URL pour accéder aux calendriers, un point particulièrement pénible parce qu’elle varie en fonction des serveurs et des clients…)

J’ai intégralement conçu et manufacturé toute la domotique de mon logement. J’ai dessiné les circuits imprimés, et je les ai réalisés grâce à la bonne vieille méthode du bain au perchlorure de fer, apprise plus de vingt ans plus tôt en cours de technologie…

Ma domotique est donc constituée des éléments suivants, tous construits autour d'ESP8266 :

  • 1 station météo

Elle fait ma fierté, parce que j’ai passé beaucoup de temps à la concevoir et qu’elle fonctionne parfaitement bien et sans interruption depuis près de deux ans.

Elle dispose de son propre système de régulation de température et d’humidité, basé sur un contrôleur de ventilateurs PWM (et de deux ventilateurs Noctua, de 8cm en aspiration sur le dessous et 12cm en extraction sur le dessus), d’une résistance PTC de 80℃ (disposée sur un vieux radiateur de processeur afin de répartir la chaleur dans le boitier) et d’un capteur SHT31-D, afin de s’assurer que l’alimentation et l’électronique soient maintenues à des températures et humidité relative acceptables (c’est-à-dire, selon les normes de fonctionnement préconisées par les constructeurs des différents éléments constitutifs de l’électronique de la station). Le contrôleur de ventilateurs et la résistance sont pilotés par des MOSFET IRLZ34N (placés chacun sur un circuit imprimé, en haut à gauche de l’image ci-dessus)

Elle dispose d’un capteur de luminance TSL2561, d’un capteur de température, humidité relative et pression atmosphérique BME280, et d’un capteur d’orage MOD-1016.

Une alimentation de 12V 5A fourni le courant à l’ensemble des composants. J’ai choisi cette puissance pour tenir compte de la résistance chauffante et des ventilateurs. De plus, une alimentation capable de délivrer plus que ce dont elle a besoin signifie souvent qu’elle chauffe moins. À l’exception du BME280 et du MOD-1016, tous les composants de la station météo prennent place dans un boitier spécifique planqué sous la véranda. Le BME280 et le MOD-1016 sont placés dans un boitier de ma conception, basé sur des tuyaux de 10cm de diamètre : une section droite centrale contient un circuit imprimé sur lequel les capteurs sont enfichés, et une section coudée à 90 degrés de chaque côté, ouverture vers le bas. Ainsi, les capteurs sont à l’air libre, mais protégés des intempéries. Ils sont reliés à la station principale par un câble ethernet blindé, qui fait transiter le signal I2C et l’alimentation.

  • 5 thermostats

Ils disposent de deux modes, « Présent » et « Absent ». Les plages horaires de chaque mode sont définies dans un calendrier spécifique à chaque thermostat. L’ESP8266 présent dans chaque boitier mural contrôle simplement un relais, et capte la température et l’humidité de la pièce via un SHT31-D.

  • 7 lumières, dont 6 bandeaux de LEDs et une prise Sonoff S20

J’ai défini deux entrées dans Home Assistant, respectivement pour l’extinction et l’allumage « inconditionnel » de l’éclairage. Ainsi, quoiqu’il arrive, les lumières automatisées (certaines ne le sont pas parce que ce n’est pas nécessaire) ne s’allumeront jamais dans cette plage horaire (typiquement entre 2h30 et 5h45, soit entre l’heure à laquelle je me couche et celle à laquelle mon épouse se lève).

En outre, les lumières automatisées ne s’allument que si la luminance extérieure fournie par la station météo est en dessous d’un certain seuil que je peux définir pour chacune d’entre elles. Enfin, le calendrier me permet de définir les plages horaires pendant lesquelles elles doivent présenter une scène particulière. J’ai défini quatre types d’ambiance : heures de passage (pour un éclairage à pleine puissance), éclairage normal, éclairage tamisé, et éteint.

Un bandeau de LEDs est contrôlé par un capteur de mouvement de type PIR, dont la seule dépendance est la luminance extérieure : même en présence de mouvement, il ne s’allumera pas s’il fait encore jour. Un autre bandeau est uniquement contrôlé par un bouton poussoir. Un dernier ne peut être contrôlé que par Home Assistant.

Au niveau électronique, chaque contrôleur pilote simplement trois MOSFETs (également des IRLZ34n), et dispose de deux entrées (pour un bouton ou un capteur de mouvement). C’est mon premier projet électronique à usage réel.

  • 2 horloges

J’aime bien avoir l’heure partout où je suis. Si j’ai la date complète, et la température extérieure, c’est encore mieux… Alors j’ai conçu deux horloges dotées d’un écran LCD 16x2 piloté en I2C par un ESP8266. Rien de compliqué, rien qui nécessite un circuit imprimé, juste quelques câbles.

  • 1 bouton d’appel

Utilisé pour que mon épouse puisse me signifier sans hurler à travers toute la maison qu’elle va faire dodo quand je suis enfermé dans mon bureau… Quand elle appuie sur son bouton d’appel, j’ai une alerte sur mon tableau de bord. Un appui de ma part sur le tableau de bord éteint sa LED pour lui signifier que j’arrive.

  • 1 bouton « Linge »

Pour que mon épouse puisse m’indiquer s’il y a du linge à étendre ou à passer au lave-linge, je lui ai créé un petit boitier logé près de la machine à laver, dérivé du bouton d’appel, et doté de deux boutons et deux LEDs. Cela provoque l’affichage d’un avertissement sur mon tableau de bord.

Tous ces périphériques tournent sur des ESP8266. En conséquence, j’ai installé ESPHome qui gère tout ça via de simples fichiers de configuration yaml, et connecte le tout à Home Assistant. Ça rend tout le processus très agréable et facile à utiliser et maintenir au quotidien.

J’ai également installé une caméra sous motionEyeOS sur un Raspberry Pi 0W. Elle transmet le flux vidéo à Home Assistant via un container docker motionEye.

Les données de la station météo sont envoyées à un container InfluxDB, ce qui me permet d’utiliser ensuite Grafana afin de visualiser ces données à long terme.

Tableau de bord

Le tableau de bord que je mentionne depuis avant est une tablette Asus T100TA. Elle m’a coûté des peines infinies à faire fonctionner sous debian sid, en particulier à cause de l’UEFI 32 bits démarrant un système 64 bits, et du chipset wifi non supporté par défaut.

J’ai installé openbox et chromium dessus, en mode kiosk. Par contre, c’est très lourd, et la connexion réseau est très instable. Je suis obligé de la redémarrer au moins une fois par jour, et c’est évidemment très pénible. Mais quand elle fonctionne, elle fonctionne bien, alors je ne me risque pas à essayer d’installer autre chose.

Station de travail

Ma station de travail est un Mac mini M1. Là encore, vous allez sûrement me critiquer vertement. C’est Apple, c’est pas Libre, etc. Et je vous répondrai ceci.

Je suis passionné d’informatique depuis que j’ai cinq ans (j’en ai presque 40). J’ai touché à tout ou presque (grand bien m’en fasse, je n’ai jamais vu un AS400 de ma vie). J’ai passé un gros tiers de ma vie informatique à bidouiller des machines sous Windows, toutes versions depuis 3.1 jusqu’à Windows 10, en passant par Windows 2000, Server 2003, Home Server, etc. À la grande époque des versions pirates, j’ai touché à tout l’écosystème Microsoft, y compris ISA, Exchange, etc.

Suite à ça, je me suis laissé tenter par GNU-Linux. Pendant un deuxième gros tiers de ma vie informatique, j’ai bidouillé des Mandrake, des Knoppix, des RedHat, des Suse, pour finir par adopter définitivement debian. Je passais des heures à essayer de faire fonctionner un modem USB, à essayer et échouer à compiler le noyau, à desespérer devant mon incapacité à faire fonctionner correctement une carte graphique ou une carte son un peu exotique. Et bien que j’ai fini par pouvoir travailler confortablement avec debian et KDE, je ne pouvais me résoudre à supprimer purement et simplement Windows pour jouer (ce que je n’ai réussi à faire que récemment).

Tout ça, jusqu’au jour où j’ai acheté un iPhone à mon épouse. Puis son iPad. Puis mon iPad. Puis l’AppleTV 4. Puis mon MacBook Pro 13" Retina 2015. Puis une AppleTV 4K. Puis mon Mac mini M1. Mon amour pour cet écosystème n’a fait que grandir. Parce qu’enfin, après les deux premiers tiers de ma vie à bidouiller l’informatique, je pouvais enfin utiliser l’informatique. Tout fonctionne. Pas de hack, pas de configuration étrange, pas de bizarrerie que je dois exécuter sans comprendre. Pardonnez-moi l’expression, mais : « ça juste marche ». Le moment où je n’avais plus envie de bidouiller mais simplement utiliser est venu.

Et quand j’ai vu la conférence d’Apple annonçant sa première puce maison depuis… je ne sais pas combien d’années puisqu’avant l’iPhone de mon épouse, je n’avais cure d’Apple que je détestais presqu’encore plus que Microsoft, j’ai su qu’il me fallait le Mac mini M1, surtout considérant son prix. Si cette machine tenait ses promesses et qu’elle coutait bien ce qu’ils annonçaient, ça allait être énorme.

Et le fait est que c’est énorme. Cette puce est monstrueuse en termes de performances, comparativement à sa consommation électrique. C’est réellement la révolution qu’ils promettaient. Ce Mac mini M1 est probablement le meilleur investissement de toute ma vie, et vous pouvez me croire, j’en ai eu des ordinateurs (et j’en ai encore, bien plus que listé ici…).

Et même via la couche de compatibilité Rosetta 2, même avec plein d’applications lancées en même temps, tout va plus vite. Tout est quasi instantané. C’est magique. Ça fonctionne, c’est simple, intuitif, esthétique (même si c’est personnel). Mon double-écran en 2x 240Hz fonctionne sans problème, ma souris SteelSeries Rival 3 et mon clavier Corsair Strafe RGB fonctionnent sans soucis (même si c’était déjà le cas avec le MacBook Pro). J’ai enfin du plaisir à utiliser mon ordinateur. Contextuellement, ma station de travail doit m’aider, pas se mettre sur mon chemin. Un serveur, oui, ça se configure aux petits oignons, je prends mon temps pour l’installer et le paramétrer. Mais ma machine de travail doit fonctionner, tout de suite, et ne doit pas nécessiter mon attention toutes les deux secondes pour autre chose.

Station de jeu

Ma station de jeu est un Core i7 7700k, doté de 16Go de DDR3, de deux nVIDIA GT1070 8Go, et d’un Crucial MX500 de 1 To. Elle tourne sous debian stable, avec XFCE4, steam, firefox, et… c’est tout. Et tout fonctionne parfaitement bien. Le travail fait sur Proton par steam est excellent : tous mes jeux se lancent sans problème de compatibilité et avec d’excellentes performances. Je n’ai pas eu besoin de hack ou de configurations exotiques : tout fonctionne out-of-the-box. Je peux enfin me passer définitivement de Windows, qui n’existe plus que sur la machine de travail de mon épouse.

Consommation électrique

Je dispose d’un onduleur Eaton Ellipse 1200 Pro qui présente la caractéristique intéressante de me fournir la consommation réelle de ce qui est branché dessus. Ainsi, je peux dire que mes trois serveurs x86, les deux Raspberry Pi 4, un des deux MR2200ac, le switch et le NAS consomment au total un maximum de 47W. Je trouve que c’est très satisfaisant. L’onduleur pourrait ainsi fonctionner pendant une heure à une heure-et-demi sur batterie si une coupure de courant devait survenir. Largement de quoi voir venir…

Évolutions

J’écris cet article en partie parce que je viens de reconstruire l’ensemble de mon réseau. Les trois machines principales de l’infrastructure (l’AK34, le GN41 et le T34), les point d’accès sans-fil, même les SSD du NAS ont moins d’un an. Donc je vois peu de changement à venir.

J’aimerais bien, à l’occasion, virer le SSD du routeur pour le mettre sur le serveur domotique en remplacement de son stockage eMMC : un SSD lui profiterait plus qu’au routeur, où je pourrais installer OpnSense sur une carte SD ou une clé USB sans risquer de la flinguer au bout de six mois.

Je pense que la prochaine machine à remplacer sera le NAS, qui commence à se faire vieux, et qui est fortement limité par son CPU. Et je pense que j’opterai pour un mini-PC, comme les trois autres serveurs. J’aime bien ce format : je peux disposer de bons CPUs, économes en énergie mais assez puissants pour être versatiles. Il faudra donc que je veille à me doter de bons boitiers externes pour y loger les SSD. Une autre solution, moins coûteuse, pourrait consister à rassembler au sein d’un même serveur les usages du NAS et d’autre chose (peut-être le serveur domotique). Ça sera à tester au niveau des performances.

Du côté du routeur toujours, j’aimerais arriver à mettre en place une QoS. Je n’ai pas compris comment fonctionne le shaping sur OpnSense. J’aimerais, par exemple, que jusqu’à 8 Mbit/s de ma bande passante totale soit allouée à la VoD, ou qu’un maximum de 70% de ma bande passante montante soient destinés en priorité à mon serveur web, afin de m’assurer que mes visiteurs puissent consulter mes sites et services confortablement, sans nuire à mon propre usage du réseau.

Mise à jour du 09/03/2021, 13:18

Le Journal Du Hacker a cassé mon Internet 🤣. Suite à la publication de cet article, ma bande passante a beaucoup souffert… Ce qui m’a incité à me pencher sérieusement et urgemment sur la question de la QoS (Traffic shaping).

C’est grâce à cette conversation que j’ai pu m’en sortir. Merci à @badprocess@mastodon.social pour son aide !

Donc au final, j’ai mis en place une limitation du traffic montant depuis mon serveur web. Sur 1 Mbits/s, il peut utiliser au maximum 700 Kbits/s. Ça se passe dans Firewall, Shaper, et on ajoute un Pipe, une Queue et une Rule comme suit:

Il faudra encore que je creuse pour le shaping pour la VoD mais je comprends un peu mieux comment ça marche, et surtout, ça a résolu les problèmes (inédits) que j’ai rencontré suite à cet afflux “massif” de visiteurs…

Mise à jour du 10/03/2021, 00:00

Après plusieurs heures d’investigation, j’ai fini par trouver le problème, et le Journal du Hacker est hors de cause 😅

Par défaut, OpnSense surveille les passerelles du WAN. En IPv6, c’est directement la Freebox, mais en IPv4, c’est l’IP du serveur DHCP qui m’a attribué mon IPv4 (généralement x.x.x.254 chez free). Or, il me semble que free ne permet plus le ping passerelle depuis quelques années déjà, et j’avais configuré OpnSense pour faire ses ping sur une autre adresse IPv4 (en l’occurrence, chez OVH).

Sauf que quand OpnSense détecte que ces pings sont hors de certains seuils, il désactive la passerelle. Or, l’IP surveillée avait, semble-t’il, quelques soucis, entrainant pertes de paquets et latence très élevée.

Je m’étonnais de la régularité du phénomène, mais en fin de compte, ça prend tout son sens : OpnSense ping une fois par minute…

J’ai changé l’IP à surveiller - temporairement - pour une IP censée être stable et fonctionnelle, 8.8.8.8, qui appartient à Google, et que je voulais donc éviter. Et là, tout est rentré dans l’ordre : une latence normale, et plus de pertes de paquets.

Une mise en pratique de la Loi de Murphy : ça survient pile quand je me fais linker par Le Journal du Hacker…

Mise à jour du 12/03/2021

Les problèmes de ping que j’avais étaient malheureusement dûs à l'incendie qui a ravagé le site d’OVH à Strasbourg. J’ai complètement désactivé le ping de connexion.

Entre temps, j’ai sorti les deux Raspberry Pi 4 du réseau. J’estime que Raspberry Pi OS est trop instable et bloaté, et la charge CPU/mémoire des applications que je faisais tourner dessus ne justifie pas l’emploi de machines dédiées. Caddy est donc désormais sur le serveur web, et pihole sur le contrôleur de domotique.