Your site will run here. And here, everything is documented.

Symptôme. Reboot de maintenance planifié (mises à jour de sécurité, noyau en attente), le premier depuis des mois. Tout redémarre seul : sites clients en ligne, conteneurs relancés par leurs politiques Docker, le pair qui répond sur le maillage Tailscale. Tout, sauf SSH : « Connection refused » immédiat, sur l’adresse publique comme sur celle du VPN. La machine répond, mais rien n’écoute.

Diagnostic. Une vingtaine de minutes entre le premier refus et le retour de SSH, via la console KVM out-of-band d’OVHcloud (clavier interprété en QWERTY compris). systemctl status ssh donne le verdict : sshd, volontairement restreint à l’adresse du VPN maillé (durcissement zero-trust), a démarré avant que Tailscale ne monte son interface. L’adresse n’existait pas encore, le bind a échoué, sshd a épuisé ses tentatives et est resté couché. Le serveur n’avait jamais redémarré depuis ce durcissement : la panne dormait là depuis des mois.

Correctif. net.ipv4.ip_nonlocal_bind=1 dans /etc/sysctl.d/ : sshd peut se binder sur une adresse qui n’existe pas encore, et n’écoute toujours que sur le VPN. Vérifié par un test qui reproduit les conditions du boot (VPN coupé, sshd redémarré, service actif). Les options écartées et le tradeoff sont détaillés dans la décision complète.

Ce que ça a changé. Un service qui tourne depuis des mois n’a jamais prouvé qu’il savait démarrer : seul un reboot le prouve, et ils font désormais partie de la maintenance régulière. Et le chemin de secours (console out-of-band) reste volontairement indépendant de tout le reste : c’est lui qui a permis de régler l’incident en vingt minutes.

Symptôme. Vendredi 19 juin, mi-journée : plus aucun nom de domaine ne résout sur les appareils du tailnet, alors que la connexion Internet est bonne. Cause immédiate : ces appareils utilisent le DNS interne de la plateforme comme résolveur, et le serveur qui l’héberge ne répond plus.

Diagnostic. Connexion correcte mais résolution muette : le problème est du côté du serveur. Confirmation rapide chez l’hébergeur : incident de refroidissement dans le datacenter de Roubaix, annoncé sur la page de statut d’OVHcloud (source publique). Environ deux heures trente d’indisponibilité vécue pour ce serveur ; la résolution complète de l’incident a pris une douzaine d’heures pour les derniers serveurs touchés.

Correctif. Aucun levier pendant l’incident : la panne est physique, chez l’hébergeur. Le travail utile se fait avant et après.

Ce que ça a changé. Deux enseignements. La dépendance DNS d’abord : faire du serveur le résolveur des appareils du tailnet transforme une panne d’hébergeur en panne de résolution générale sur tous les appareils. Corrigé depuis : un résolveur de secours est déclaré dans la configuration DNS du tailnet, les appareils gardent une résolution si le serveur ne répond plus. Le mono-serveur ensuite : le risque est connu et accepté à cette échelle, et une infrastructure multi-serveurs reste un objectif d’apprentissage (chantier au-delà du mono-serveur). Changer d’hébergeur ne protégerait de rien : ce type d’incident peut arriver partout.

Symptôme. Tous les services privés répondent 403 : coffre de mots de passe, outils internes, dashboards. Les sites publics fonctionnent normalement. Découvert deux jours après le début de l’incident, en remarquant que le coffre de mots de passe ne se synchronisait plus : les services du tailnet ne servent pas tous les jours, la panne est restée silencieuse le temps d’un week-end.

Diagnostic (1 h 30). Les logs du reverse proxy montrent une adresse source en 172.x, celle de la passerelle du réseau Docker, au lieu de l’adresse tailnet du client. Le filtre tailscale-only, qui n’autorise que le réseau privé, refuse donc tout le monde. Remontée de piste : Tailscale s’était mis à jour automatiquement quelques jours plus tôt, et la nouvelle version introduit des règles de marquage de connexions qui, combinées au masquerading existant, réécrivent la source des paquets entrants avant qu’ils n’atteignent les conteneurs.

Correctif. Désactivation persistante du SNAT des routes locales côté Tailscale, sans effet de bord ici puisque ce nœud ne route aucun sous-réseau.

Ce que ça a changé. Deux jours d’incident silencieux sur la moitié de la plateforme, détectés par un hasard d’usage : c’est précisément ce que le chantier observabilité et alerting de la roadmap doit rendre impossible. Leçon complémentaire : une mise à jour automatique peut modifier le comportement réseau à bas niveau ; pour les composants réseau, lire le changelog avant de mettre à jour, quitte à épingler la version.