#homelab — Blog d'Ange Bonkoski

Quatre blocages en une journée : diagnostiquer couche par couche

Mon, 19 Oct 2026 11:00:00 +0200

Je voulais pouvoir administrer mon serveur et prendre la main sur mon PC fixe depuis n’importe quel navigateur, même sur un téléphone, sans rien installer. C’est le rôle d’Apache Guacamole : un bastion d’accès web.

L’installation m’a pris une journée, et j’ai buté quatre fois. Ce n’est pas le nombre de blocages qui m’a appris le plus, c’est la méthode qui a permis de tous les résoudre.

Comment Guacamole fonctionne

Navigateur ──HTTPS──> Guacamole (interface web)
 │
 v
 guacd ──SSH──> serveur
 └─VNC──> PC fixe

Le navigateur ne parle qu’en HTTPS avec l’interface web. C’est guacd, un petit moteur qui tourne sur le serveur, qui ouvre réellement les connexions SSH ou VNC vers les machines cibles, puis renvoie l’image au navigateur. Une base PostgreSQL garde les comptes et les connexions. Les trois tournent dans des conteneurs Docker, et aucun ne publie de port : on y accède seulement par mon réseau privé Tailscale, avec double authentification.

Blocage n°1 : le certificat qui refusait de se faire

Symptôme : « Internal Error » en enregistrant le nom de domaine dans le reverse proxy.

Le journal : docker logs du reverse proxy montrait la commande de Let’s Encrypt avec --preferred-challenges http, puis Some challenges have failed.

La cause : j’avais oublié de cocher « Use a DNS Challenge ». Le défi HTTP demande à Let’s Encrypt de venir chercher un fichier sur mon serveur depuis Internet… alors qu’aucun port n’est ouvert. Il ne pouvait qu’échouer. Avec le défi DNS, le certificat est arrivé en une minute.

Cet échec avait un bon côté : il prouvait que mon serveur est vraiment injoignable depuis Internet.

Blocage n°2 : la clé SSH « au format inconnu »

Symptôme : la connexion SSH vers le serveur échoue.

Le journal, côté client (guacd) : Unable to extract public key from private key file: Unsupported private key file format.

Le journal, côté serveur (sshd) : une connexion fermée avant authentification, puis une pénalité de 10 secondes pour cette adresse.

La cause : j’avais collé la clé privée sans ses lignes -----BEGIN … et -----END …. Sans elles, impossible de reconnaître le format. Elles font partie de la clé.

Le journal du serveur m’a aussi appris quelque chose : les versions récentes de sshd pénalisent une adresse qui se connecte sans s’authentifier. Pendant le diagnostic, les reconnexions automatiques de Guacamole aggravaient la situation. J’ai dû les couper.

Blocage n°3 : le Bureau à distance… qui n’existait pas

Symptôme : impossible de joindre mon PC fixe en RDP.

La vérification : « À propos de Windows » → Windows 11 Famille.

La cause : l’édition Famille ne peut pas recevoir de connexion Bureau à distance, c’est réservé aux éditions Pro. Plutôt que de payer une licence, je suis passé à VNC avec TightVNC (gratuit), verrouillé par deux protections indépendantes : TightVNC n’accepte que l’adresse du serveur, et le pare-feu Windows aussi.

L'installateur qui ouvre une porte sans le dire

En vérifiant le pare-feu après coup, j’ai trouvé une règle créée par l’installateur de TightVNC : elle autorisait tout le monde à se connecter. Je l’ai désactivée. Toujours relire le pare-feu après avoir installé un logiciel serveur.

Blocage n°4 : « Unable to connect to VNC server »

C’est le blocage le plus instructif, parce que je l’ai résolu en remontant les couches une par une :

Couche	Test	Résultat
Réseau (TCP)	le port 5900 du PC répond-il depuis le serveur ?	oui
Service	le PC renvoie-t-il une bannière VNC (`RFB 003.008`) ?	oui, même depuis le conteneur de `guacd`
Authentification	que dit le journal de TightVNC ?	`Authentication failed`

Le réseau et le service étaient bons. Le problème était à la dernière couche : le mot de passe VNC enregistré dans Guacamole et celui de TightVNC n’étaient pas les mêmes. Je les ai redéfinis des deux côtés à partir de mon gestionnaire de mots de passe, et tout a fonctionné.

Un port ouvert ne prouve qu'une chose

« Le port répond » valide la couche réseau, et rien d’autre. Il faut tester chaque couche : la connexion TCP, puis le service (sa bannière), puis l’authentification.

Le détail qui m’a fait comprendre la NAT de Docker

En configurant les deux connexions, j’ai remarqué que les cibles ne voyaient pas arriver la même adresse :

vers le serveur lui-même, sshd voyait l’adresse interne du conteneur guacd. J’ai donc limité la clé SSH de Guacamole aux réseaux internes de Docker (option from= dans authorized_keys) ;
vers le PC, TightVNC voyait l’adresse du serveur : en sortant vers le réseau local, Docker remplace l’adresse du conteneur par celle de l’hôte (c’est de la NAT). La règle de TightVNC autorise donc le serveur.

Comprendre ce comportement était indispensable pour écrire des règles d’accès qui marchent, et qui restent strictes.

Ce que j’en retiens

Lire les journaux des deux côtés. Le client dit ce qu’il a tenté ; le serveur dit pourquoi il a refusé. Pour SSH comme pour VNC, c’est le serveur qui a donné la cause.
Tester couche par couche, du réseau à l’authentification, au lieu de tout changer en même temps.
Un bloc de clé se copie en entier, lignes BEGIN et END comprises.
Les outils de diagnostic sont temporaires : niveau de journalisation maximal, conteneurs de test… tout a été retiré une fois la cause trouvée.

En installant un simple partage de fichiers, j'ai trouvé trois portes de côté

Mon, 19 Oct 2026 10:00:00 +0200

La veille, j’avais fini de durcir l’accès SSH à mon serveur : connexion par clé uniquement, mots de passe interdits, un seul compte autorisé. J’en étais assez fier.

Le lendemain, je voulais quelque chose de beaucoup plus banal : regarder mes vidéos depuis le Mac et l’iPhone, via un partage de fichiers SMB. En le configurant proprement, je suis tombé sur trois portes que je n’avais jamais notées nulle part. L’une d’elles rendait mon travail de la veille inutile.

Porte n°1 : le partage « admin » qui voyait tout

Mon serveur tourne sous ZimaOS. Son interface crée automatiquement un partage SMB pour le compte d’administration. Je ne m’en étais jamais soucié : je l’utilisais pour transférer des fichiers depuis mon PC.

En le regardant de près, j’ai découvert qu’il donnait accès à tous les disques, en écriture, y compris la partition qui contient les données des conteneurs, les fichiers de configuration… et le fichier authorized_keys, celui qui liste les clés SSH autorisées.

J’ai vérifié en le listant avec smbclient et le seul mot de passe du compte d’administration. Il était bien là, lisible et modifiable.

Autrement dit : quelqu’un qui connaissait ce mot de passe pouvait ajouter sa propre clé par SMB, puis se connecter en SSH. Mon « SSH par clé uniquement » se contournait par la porte d’à côté.

Leçon

Un durcissement ne vaut que si toutes les portes vers la même ressource sont fermées. Protéger SSH ne sert à rien si un autre service permet de modifier les clés de SSH.

Porte n°2 : les lecteurs réseau toujours branchés

Sur mon PC Windows, deux lecteurs réseau étaient connectés en permanence avec ce même compte d’administration : l’un vers le disque externe, l’autre vers la partition de données du serveur.

C’est exactement le scénario qu’exploitent les rançongiciels : ils chiffrent tout ce qu’ils trouvent, y compris les lecteurs réseau. Un simple fichier piégé ouvert sur le PC aurait pu chiffrer le serveur, et avec lui… les données de mes sauvegardes.

Porte n°3 : un deuxième accès distant que je n’avais pas choisi

En nettoyant les identifiants mémorisés sur mon PC, j’en ai trouvé un pour une adresse que je ne connaissais pas. En remontant la piste : ZeroTier, un réseau privé virtuel installé et activé par ZimaOS pour son application « Zima Client ».

J’utilisais déjà Tailscale comme unique accès distant, volontairement. ZeroTier était un deuxième chemin vers le serveur, géré par l’éditeur, que je n’avais jamais décidé d’ouvrir.

Ce que j’ai fait

Des comptes dédiés, avec le minimum de droits. Au lieu du compte d’administration, deux comptes de partage, sans accès SSH ni shell :

Compte	Accès	Usage
Lecture	un seul dossier (les vidéos), lecture seule	mémorisé sur le PC, le Mac et l’iPhone
Dépôt	le dossier de sauvegarde, lecture-écriture	connecté seulement pendant un transfert, mot de passe jamais mémorisé

Le compte de lecture peut rester branché en permanence : un rançongiciel ne peut rien chiffrer avec. Le compte de dépôt, lui, n’existe sur le PC que quelques minutes à la fois.

Désactiver le compte SMB d’administration. Une commande suffit :

sudo smbpasswd -d admin # -d : désactive le compte Samba, sans le supprimer

Mais ZimaOS le réactive à chaque redémarrage. J’ai donc écrit un petit script, lancé par un timer systemd 3 minutes après le démarrage puis toutes les 10 minutes. Il redésactive le compte si besoin, vérifie que c’est bien fait, et me prévient sur Discord quand il a dû intervenir.

Les systèmes qui se « réparent » tout seuls

Sur un système qui régénère sa configuration au démarrage, une correction faite à la main peut disparaître sans prévenir. Il faut soit la rendre persistante, soit la réappliquer automatiquement, et surtout le vérifier après un redémarrage.

Débrancher les lecteurs du PC, et ne plus jamais connecter le compte d’administration depuis un poste.

Retirer ZeroTier : le serveur a quitté le réseau, et le service a été masqué pour qu’il ne puisse plus redémarrer, même par erreur.

Vérifier, avec des tests écrits

J’ai ensuite déroulé une série de tests, notés un par un : chaque compte voit-il seulement ce qu’il doit voir ? Le compte de lecture peut-il écrire ? Les partages sont-ils joignables depuis Internet sans Tailscale ? Le compte d’administration est-il bien désactivé après un redémarrage ? Tous les tests sont passés, depuis le PC, le Mac et l’iPhone.

Ce que j’en retiens

Inventorier les accès, pas seulement les sécuriser. On ne peut pas fermer une porte qu’on ne sait pas exister.
Le moindre privilège, concrètement : un compte par usage, et le minimum de droits pour cet usage.
Se méfier de ce qu’une plateforme active « pour vous ». Une fonctionnalité pratique est aussi une surface d’attaque.
Penser comme un attaquant : « si j’avais ce mot de passe, jusqu’où irais-je ? » C’est cette question qui a fait apparaître la porte n°1.

Mon coffre de mots de passe ne répondait plus, et le réseau n'y était pour rien

Mon, 19 Oct 2026 09:00:00 +0200

Le 20 septembre, mon gestionnaire de mots de passe auto-hébergé a cessé de fonctionner… à moitié. Le coffre s’ouvrait parfaitement dans le navigateur. Mais l’extension Firefox affichait une erreur obscure, et l’application iPhone refusait de se connecter.

J’ai passé des heures à chercher dans la mauvaise direction. Cet article raconte comment j’en suis sorti, et surtout la petite expérience qui a tout débloqué.

Le contexte

J’héberge Vaultwarden sur mon serveur maison. C’est une réécriture légère du serveur de Bitwarden : on garde les applications officielles de Bitwarden (extension, application mobile), mais elles parlent à mon serveur plutôt qu’à celui de l’éditeur.

À l’époque, le trafic passait par Cloudflare, puis par un reverse proxy, avant d’arriver au conteneur.

Le symptôme

Le coffre web : fonctionne.
L’extension Firefox : KDF config response does not contain a valid KDF type.
L’application iOS : « Nous ne sommes pas en mesure de traiter votre demande ».

Le KDF (key derivation function) est la fonction qui transforme le mot de passe maître en clé de chiffrement. Le client demande au serveur quels paramètres utiliser, puis fait le calcul lui-même. L’erreur disait donc : « la réponse du serveur ne ressemble pas à ce que j’attends ».

Pourquoi j’ai accusé le réseau

Ma première intuition : quelque chose entre le client et le serveur abîmait la réponse. C’était plausible, car proxys et CDN modifient parfois le trafic au passage. J’ai donc testé, une par une :

Piste testée	Résultat
Désactiver les protections anti-robots de Cloudflare	Aucun effet
Règle de pare-feu applicatif pour laisser tout passer	Aucun effet
Purger le cache Cloudflare	Aucun effet
Désactiver HTTP/3 et le 0-RTT	Aucun effet
Vérifier la compression de la réponse	JSON propre une fois décompressé
Corriger l’adresse publique déclarée dans la configuration	Vrai défaut, mais pas suffisant

Chaque test prenait du temps, et aucun ne changeait rien.

Le friend test

J’ai fini par emprunter le téléphone d’un proche. Il n’avait jamais été connecté à mon réseau, ni à mon compte iCloud, ni à mon Firefox. J’y ai installé l’application Bitwarden, je l’ai pointée vers mon serveur…

Même erreur, exactement.

Ce test a éliminé d’un coup toutes mes hypothèses réseau. Un problème propre à mon infrastructure, à mon cache ou à mes appareils n’aurait pas touché un téléphone neuf. Le problème venait de ce que tous les clients avaient en commun : la version de l’application.

Le friend test

Quand tout semble suspect, reproduisez le problème sur un appareil qui ne partage rien avec les vôtres. S’il plante pareil, ce n’est ni votre réseau, ni votre configuration locale.

La vraie cause : un contrat de version rompu

Pourquoi le coffre web, lui, fonctionnait-il ? Parce que Vaultwarden sert sa propre interface web, compilée avec lui, à la même version. Elle comprend forcément ses réponses. C’était le pire témoin possible.

L’extension et l’application, elles, sont publiées par Bitwarden et mises à jour automatiquement par les magasins d’applications, sans aucun lien avec mon serveur. Bitwarden avait fait évoluer la structure de la réponse KDF. Les clients avaient adopté le nouveau format ; mon serveur ne le parlait pas encore. Il fallait une version plus récente de Vaultwarden.

Pourquoi la mise à jour n’a pas marché du premier coup

J’ai lancé la mise à jour du conteneur… et rien n’a changé. En relisant mon fichier Compose, j’ai trouvé ceci :

image: vaultwarden/server:1.36.0@sha256:<empreinte>

Docker peut désigner une image de deux façons :

par une étiquette (1.36.0, latest) : un nom qui peut pointer vers une autre image demain ;
par une empreinte (sha256:…) : l’identifiant exact d’une image, qui ne change jamais.

Quand les deux sont présentes, l’empreinte l’emporte. J’avais beau télécharger de nouvelles versions, Docker relançait toujours la même image figée. Une fois l’empreinte retirée et une version récente demandée, l’extension et l’application se sont reconnectées immédiatement.

Épingler n'est pas une erreur, l'oublier si

Figer une image par son empreinte est une bonne pratique de sécurité : on sait exactement ce qui tourne. Le piège, c’est de l’avoir fait sans s’en souvenir. Depuis, chaque service a une politique d’image écrite : figé (et mis à jour à la main) ou suivi automatiquement.

Ce que j’en retiens

Vérifier la compatibilité client/serveur avant de chercher dans le réseau. Quand des clients mis à jour automatiquement cassent, la version est le premier suspect.
Choisir un bon témoin. Un client livré avec le serveur ne prouve rien sur les autres.
Lire le fichier réel avant de mettre à jour. Ce que je croyais avoir configuré et ce qui était écrit n’étaient pas la même chose.
Changer une seule chose à la fois. C’est ce qui m’a permis de repérer le seul vrai défaut parmi mes essais.

CrowdSec, et le test qui ne prouvait rien

Sun, 18 Oct 2026 12:00:00 +0200

J’ai installé CrowdSec sur mon homelab pour une raison simple : je voulais savoir si quelqu’un s’en prenait à mon serveur. L’installation s’est bien passée. Les alertes, elles, n’arrivaient pas sur Discord. Et la commande censée les tester me répondait… rien. Ni succès, ni erreur.

Cet article raconte comment j’ai trouvé la panne, et pourquoi la leçon dépasse largement CrowdSec.

CrowdSec en deux minutes

CrowdSec est un outil de détection d’intrusion. Il fonctionne comme une chaîne :

journaux → analyseurs → scénarios → alerte → notification
(SSH, web) (lisent (reconnaissent (décision) (Discord)
 chaque ligne) une attaque)

Il lit les journaux du serveur : ici, les connexions SSH et les accès au reverse proxy.
Des analyseurs découpent chaque ligne (adresse IP, utilisateur, résultat).
Des scénarios reconnaissent un comportement suspect, par exemple une rafale d’échecs de connexion SSH depuis la même adresse en quelques secondes : une attaque par force brute.
Une alerte est créée, et un plugin l’envoie ailleurs, ici vers un salon Discord privé.

CrowdSec peut aussi bloquer les adresses fautives, grâce à un composant séparé (un bouncer). Je ne l’ai pas installé, volontairement : mon serveur n’a aucun port ouvert sur Internet, donc aucune attaque extérieure ne peut l’atteindre. Mon but était d’apprendre la chaîne de détection et de surveiller ce qui se passe, pas de risquer de me bloquer moi-même.

Le symptôme

CrowdSec propose une commande pour tester une notification :

cscli notifications test http_default

Elle s’exécutait sans erreur. Sa sortie montrait le plugin qui démarre, puis qui s’arrête. Et sur Discord : rien. J’ai relancé plusieurs fois, en modifiant la configuration entre deux essais. Toujours rien.

Séparer les couches

Quand une chaîne de plusieurs maillons ne fonctionne pas, deviner ne sert à rien. J’ai testé chaque maillon seul, en partant du bout.

Maillon 1 : Discord reçoit-il quoi que ce soit ?

Un webhook Discord est une simple adresse à laquelle on envoie un message. On peut donc le tester sans CrowdSec. Problème : l’image de CrowdSec ne contient pas curl. Plutôt que d’installer quoi que ce soit, j’ai utilisé un conteneur jetable qui ne contient que curl et disparaît après usage :

docker run --rm --env-file .env curlimages/curl \
 sh -c 'curl -s -o /dev/null -w "%{http_code}\n" \
 -H "Content-Type: application/json" \
 -d "{\"content\":\"Test du webhook\"}" "$DISCORD_WEBHOOK"'

Réponse : 204, et le message est apparu sur Discord. Le webhook fonctionnait. Le problème était donc en amont.

Maillon 2 : CrowdSec lit-il le bon fichier ?

cscli notifications list indiquait bien http_default comme actif. Mais « actif » voulait seulement dire qu’un fichier portait ce nom. En regardant le fichier réellement présent dans le conteneur, sa date et sa taille, j’ai compris : c’était le fichier par défaut livré avec l’image, pas le mien. Ma configuration n’avait jamais été chargée.

« Actif » n'est pas « chargé »

Une commande qui liste une configuration ne prouve pas que c’est la vôtre. Allez voir le fichier réellement utilisé par le programme : sa date de modification et sa taille disent la vérité.

Maillon 3 : la commande de test teste-t-elle vraiment quelque chose ?

En corrigeant le fichier, j’ai aussi compris pourquoi le test restait muet. La commande démarre le plugin, lui confie le message… et s’arrête avant que l’envoi ait eu le temps de se faire. Ma configuration ajoutait en plus un délai de regroupement de 60 secondes avant chaque envoi : le test ne pouvait jamais aboutir. J’ai retiré ce délai, et j’ai cessé de me fier à cette commande.

La vraie preuve : une vraie alerte

Pour prouver que toute la chaîne fonctionne, il faut un test qui la traverse entièrement, comme le ferait une vraie attaque. J’ai donc créé une décision manuelle contre une adresse fictive :

cscli decisions add --ip 203.0.113.99 --reason "test de bout en bout"

L’alerte est arrivée sur Discord en quelques secondes. Puis j’ai supprimé cette décision de test.

Pourquoi 203.0.113.99 ? Parce que cette plage (203.0.113.0/24) est réservée à la documentation : elle n’appartient à personne. C’est une bonne habitude, dans un test comme dans un article, pour ne jamais viser l’adresse de quelqu’un par erreur.

Le piège suivant : les adresses privées

J’ai voulu aller plus loin et simuler une vraie attaque par force brute SSH depuis mon propre PC. Rien ne s’est déclenché. Normal : par défaut, CrowdSec ignore les adresses privées (le réseau local, Docker, Tailscale). Une attaque venant de l’intérieur passe donc sous ses radars.

Pour vérifier qu’un scénario reconnaît bien une ligne de journal, CrowdSec propose cscli explain. On lui donne une fausse ligne avec une adresse de documentation, et il montre chaque étape : quel analyseur l’a lue, quels scénarios se sont activés.

cscli explain --type syslog \
 --log "Oct 18 10:00:00 serveur sshd[1234]: Failed password for invalid user test from 203.0.113.5 port 4242 ssh2"

Ce que j’en retiens

Un test qui ne dit rien ne prouve rien. Ni succès ni erreur, ce n’est pas « ça marche ».
Tester chaque maillon seul, en partant du bout. Le webhook, puis le fichier, puis le plugin : chaque étape élimine une hypothèse.
Préférer une vraie alerte à une commande de test. Elle emprunte le même chemin qu’une attaque réelle.
Connaître les angles morts de son outil. Ignorer les adresses privées est un choix raisonnable, mais il faut le savoir.
Un secret peut fuiter par un message d’erreur. Une erreur d’envoi peut afficher l’adresse complète du webhook, qui suffit à quiconque pour écrire dans mon salon Discord. Avant de partager un journal, je masque toujours ce genre d’information.

La sauvegarde qui s'est évaporée

Sun, 18 Oct 2026 11:00:00 +0200

Le 9 octobre, en cherchant où ajouter une nouvelle tâche planifiée sur mon serveur, j’ai tapé crontab -l. La réponse était vide. Ma sauvegarde nocturne, celle qui protège mon coffre de mots de passe, n’existait plus.

Elle ne s’était pas lancée la nuit précédente. Et aucune de mes alertes n’avait sonné.

Le dispositif de sauvegarde

Chaque nuit à 3 h 30, un script sauvegarde les données importantes du serveur avec restic, un outil qui produit des sauvegardes chiffrées, dédupliquées et versionnées. Le script :

fait une copie cohérente de la base de données du coffre, sans l’arrêter ;
l’envoie dans le dépôt restic, sur un disque séparé ;
supprime les anciennes versions selon une règle de rétention ;
vérifie un échantillon des données ;
signale « tout va bien » à ma supervision (Uptime Kuma), seulement si toutes les étapes ont réussi.

Uptime Kuma attend ce signal. S’il ne reçoit rien pendant 26 heures, il m’envoie une alerte sur Discord. Sur le papier, une sauvegarde manquée ne pouvait donc pas passer inaperçue.

La chronologie

Moment	Ce qui s’est passé
8 oct., 3 h 30	Dernière sauvegarde réussie.
8 oct., 17 h 40	Je redémarre le serveur pour valider un changement de configuration SSH, sans aucun rapport avec les sauvegardes.
9 oct., 3 h 30	Aucune sauvegarde. Aucun message.
9 oct., après-midi	Plusieurs redémarrages pour d’autres travaux. Uptime Kuma affiche toujours « en ligne ».
9 oct., 17 h 40	Je découvre par hasard que la tâche planifiée a disparu.

Première énigme : où est passée la tâche ?

Mon serveur tourne sous ZimaOS, un système conçu pour faire tourner des conteneurs. Pour être robuste, il ne ressemble pas à une distribution Linux classique :

Zone	Comportement
`/` (le système)	en lecture seule
`/etc` (la configuration)	modifiable et conservée
`/var`	en mémoire vive (tmpfs) : vidée à chaque démarrage
la partition de données	modifiable et conservée

Or, quand on crée une tâche avec crontab -e, cron l’enregistre dans /var/spool/cron/. Sur ZimaOS, ma tâche vivait donc dans la mémoire vive. Elle a fonctionné parfaitement jusqu’au premier redémarrage, qui l’a effacée sans un bruit.

Attention

Sur un système dont /var est en tmpfs, crontab -e semble fonctionner : la tâche s’affiche, elle se lance, tout a l’air normal. Le problème n’apparaît qu’au redémarrage suivant, parfois des semaines plus tard.

Deuxième énigme : pourquoi aucune alerte ?

C’est la question qui m’a le plus appris. Deux défauts se sont cumulés.

Un script qui ne se lance pas ne peut rien signaler. Mon script envoie « échec » quand une étape échoue. Mais là, il n’a jamais démarré. Il ne restait que le délai de 26 heures pour me prévenir.

Le chien de garde redémarrait avec ce qu’il surveillait. Uptime Kuma tourne sur le même serveur. À chaque redémarrage de l’après-midi, son compte à rebours de 26 heures repartait de zéro. Il aurait fini par m’alerter… si j’avais arrêté de redémarrer.

Leçon

Un chien de garde doit vivre ailleurs que ce qu’il garde. Quand le serveur tombe, la supervision qui tourne dessus tombe avec lui.

La correction : un timer systemd

Puisque /etc est conservé, la tâche doit être déclarée là. J’ai remplacé la ligne cron par un timer systemd : un couple de deux petits fichiers.

Le service dit quoi lancer :

# /etc/systemd/system/sauvegarde.service
[Unit]
Description=Sauvegarde restic nocturne

[Service]
Type=oneshot
ExecStart=/chemin/vers/sauvegarde.sh

Le timer dit quand le lancer :

# /etc/systemd/system/sauvegarde.timer
[Unit]
Description=Lance la sauvegarde chaque nuit à 3 h 30

[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true

[Install]
WantedBy=timers.target

La ligne Persistent=true est le vrai gain par rapport à cron : si le serveur était éteint à 3 h 30, la sauvegarde est lancée dès le démarrage suivant au lieu d’être simplement sautée.

On active le timer, puis on vérifie la date du prochain lancement :

sudo systemctl daemon-reload
sudo systemctl enable --now sauvegarde.timer
systemctl list-timers sauvegarde.timer

Je n’ai pas considéré le problème réglé avant de l’avoir prouvé : un redémarrage, puis systemctl list-timers à nouveau. Le timer était toujours là.

L’erreur pendant la correction

J’ai aussi fait une erreur en corrigeant. J’ai deux scripts aux noms proches : celui qui fait la sauvegarde complète, et un petit outil qui transmet ses arguments à restic. Mon premier service lançait… le second. Résultat : le journal ne contenait que l’aide de restic.

Depuis, ma documentation distingue clairement les deux, avec une phrase pour chacun : ce qu’il fait, et quand on l’utilise.

Ce que j’en retiens

Un changement peut casser quelque chose qui n’a rien à voir avec lui. J’avais redémarré pour tester SSH, pas les sauvegardes.
Connaître son système avant d’y appliquer ses habitudes. crontab -e est un bon réflexe sur une Debian, un piège sur ZimaOS.
Une absence de nouvelles n’est pas une bonne nouvelle. Le silence peut vouloir dire « tout va bien » comme « rien ne s’est lancé ».
Vérifier les tâches planifiées après chaque redémarrage, au moins tant qu’on n’a pas prouvé qu’elles survivent.

Il me reste un chantier ouvert : déplacer ce chien de garde hors du serveur, pour qu’une panne complète déclenche enfin une alerte.

Zéro port ouvert : Cloudflare Tunnel pour le public, Tailscale pour le privé

Sun, 18 Oct 2026 10:00:00 +0200

Pendant des semaines, mon serveur maison était joignable depuis Internet de la façon la plus classique qui soit : deux redirections de ports sur ma box, le 80 et le 443, vers un reverse proxy. Ça marchait. Et c’est justement le problème : ça marchait pour tout le monde.

Aujourd’hui, ma box n’a plus aucune redirection. Mon portfolio est toujours en ligne, et j’accède toujours à mes services privés depuis mon téléphone en 4G. Voici comment, et surtout pourquoi.

Le point de départ

Mon homelab est un vieux PC portable sous ZimaOS, qui fait tourner une dizaine de services dans des conteneurs Docker : mon portfolio, un gestionnaire de mots de passe (Vaultwarden), de la supervision, un filtre DNS…

Pour les rendre accessibles de l’extérieur, j’avais fait ce que font la plupart des tutoriels :

un enregistrement DNS qui pointe vers l’IP publique de ma box ;
une redirection des ports 80 et 443 de la box vers le serveur ;
un reverse proxy (Nginx Proxy Manager) qui répartit les requêtes entre les services selon le nom de domaine demandé.

Pourquoi ce n’était pas acceptable

Un port ouvert, c’est une porte d’entrée que n’importe qui peut essayer de pousser. Et sur Internet, quelqu’un essaie en permanence : des robots balayent toutes les adresses IPv4 en continu, à la recherche d’un service mal configuré ou pas à jour.

Trois choses me gênaient en particulier :

mon coffre de mots de passe était joignable par le monde entier. Il était protégé par un mot de passe maître et une double authentification, mais une seule faille dans Vaultwarden aurait suffi ;
mon IP publique apparaissait dans mon DNS. N’importe qui pouvait savoir où se trouve mon serveur, et donc ma connexion personnelle ;
toute la sécurité reposait sur un seul logiciel, le reverse proxy, en première ligne face à Internet.

Je me suis fixé une règle simple : ce qui doit être public l’est ; tout le reste ne doit même pas être visible.

L’idée : inverser le sens de la connexion

Une redirection de port, c’est la box qui accepte des connexions entrantes. Le pare-feu de la box, lui, bloque déjà tout ce qui entre sans avoir été demandé. Il suffit donc de ne rien lui demander d’accepter.

Le principe est le suivant : c’est le serveur qui ouvre lui-même une connexion sortante vers un service extérieur, et c’est par ce tuyau déjà ouvert que les visiteurs arrivent. Vu de la box, il n’y a qu’une connexion sortante, comme quand vous ouvrez un site web. Rien n’entre.

J’ai utilisé deux outils construits sur cette idée, un pour chaque usage.

Le chemin public : Cloudflare Tunnel

Mon portfolio doit rester accessible à n’importe quel recruteur, sans logiciel à installer. Pour lui, j’utilise Cloudflare Tunnel.

Un petit conteneur, cloudflared, tourne sur le serveur. Au démarrage, il ouvre une connexion chiffrée vers Cloudflare et la garde ouverte. Le domaine pointe vers Cloudflare, plus vers ma box :

Visiteur → DNS → Cloudflare (pare-feu applicatif, cache)
 → tunnel (connexion sortante ouverte par le serveur)
 → cloudflared → serveur web du portfolio

Le fichier Compose tient en quelques lignes. Le jeton qui identifie le tunnel n’y est pas écrit : il est lu dans un fichier .env séparé, lisible seulement par son propriétaire.

services:
 cloudflared:
 image: cloudflare/cloudflared:latest
 restart: unless-stopped
 command: tunnel --no-autoupdate run
 environment:
 - TUNNEL_TOKEN=${TUNNEL_TOKEN}  # lu dans .env, jamais en clair ici

Au passage, mon IP publique a disparu du DNS : on ne voit plus que celles de Cloudflare.

Le prix de ce confort

Cloudflare termine le chiffrement TLS : il voit passer le trafic du site en clair avant de le renvoyer dans le tunnel. Pour un portfolio public, ça ne me dérange pas. Pour un service qui manipule des données sensibles, c’est une vraie question de confiance. C’est d’ailleurs pour ça que mon coffre de mots de passe n’emprunte pas ce chemin.

Les chemins privés : Tailscale

Pour tout le reste (coffre de mots de passe, administration, partage de fichiers, SSH), il n’y a qu’un seul public : moi. Pas besoin de les exposer au monde ; il suffit que mes appareils puissent les joindre.

Tailscale crée un réseau privé chiffré (basé sur WireGuard) entre mon serveur, mon PC, mon Mac et mon iPhone. Chaque appareil reçoit une adresse dans une plage réservée, qui n’a de sens que sur ce réseau. Et là encore, chaque appareil n’ouvre que des connexions sortantes : aucune redirection n’est nécessaire.

Restait un détail : je voulais garder une vraie adresse, avec un vrai certificat HTTPS, pour que les applications de mon gestionnaire de mots de passe fonctionnent comme avant. La solution tient en trois morceaux.

1. Un DNS qui pointe vers une adresse privée. Le sous-domaine du coffre renvoie l’adresse Tailscale du serveur. Tout le monde peut lire cet enregistrement, mais cette adresse ne mène nulle part si l’on n’est pas dans mon réseau Tailscale.

2. Un certificat obtenu sans port ouvert. Let’s Encrypt doit vérifier que je contrôle bien le domaine avant de délivrer un certificat. La méthode habituelle (le défi HTTP) consiste à venir chercher un fichier sur mon serveur… ce qui est impossible, puisque plus rien n’est joignable. J’utilise donc le défi DNS : le reverse proxy crée lui-même un enregistrement temporaire dans ma zone DNS, grâce à un jeton d’API Cloudflare limité à cette seule zone.

3. Un relais pour le port 443. Sur mon serveur, l’interface de ZimaOS occupe déjà le port 80, et le reverse proxy écoute sur d’autres ports. C’est Tailscale qui reçoit le 443 sur son interface et le relaie vers le reverse proxy :

tailscale serve --bg --tcp 443 tcp://localhost:<port-https-du-proxy>

La commande à ne jamais lancer

tailscale serve reset efface tous les relais configurés. Je l’ai appris en la lançant : mon coffre est devenu injoignable jusqu’à ce que je recrée le relais.

Vérifier, plutôt que supposer

Une fois les redirections supprimées dans l’interface de la box, je n’ai pas considéré que c’était fini. J’ai vérifié chaque promesse depuis l’extérieur, avec mon iPhone en 4G (donc hors de mon réseau local) :

Test	Tailscale coupé	Tailscale actif
Portfolio	accessible	accessible
Coffre de mots de passe	injoignable	accessible
IP publique de la box	aucune réponse	—
Partages de fichiers	injoignables	accessibles

J’ai aussi balayé l’adresse IPv6 publique du serveur. Contrairement à l’IPv4, une adresse IPv6 désigne directement la machine, sans traduction d’adresse par la box : c’est un oubli classique. Résultat : tous les ports testés fermés ou filtrés.

L'échec qui prouve que ça marche

Plus tard, en ajoutant un nouveau service, j’ai oublié de cocher le défi DNS : la demande de certificat en défi HTTP a échoué. Let’s Encrypt n’avait pas pu joindre mon serveur depuis Internet. Cette erreur était la meilleure preuve possible que l’isolement tenait.

Ce que j’en retiens

Ne pas confondre « accessible » et « exposé ». Mes services privés sont accessibles partout où je vais, mais ne sont exposés à personne.
Séparer les chemins selon le public. Un visiteur anonyme et moi n’avons pas besoin d’emprunter la même porte.
Tester depuis l’extérieur. Depuis le Wi-Fi de la maison, tout semble toujours fonctionner. C’est en 4G qu’on voit ce qui est vraiment exposé.
Chaque choix a un coût. Le tunnel me rend dépendant de Cloudflare : si le conteneur cloudflared s’arrête, le portfolio tombe. Ma supervision me prévient dans ce cas.

Il reste une limite que j’assume : à l’intérieur de mon réseau local, les services écoutent encore sur toutes les interfaces. La prochaine étape est de réduire aussi cette surface-là.