#diagnostic — 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.

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.