bolbol
/
nas-runbooks
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
nas-runbooks/hermes-nyora/vps-contabo-reinstall-tails...

5.8 KiB
Raw Blame History

VPS Contabo — Réinstallation complète + bascule Tailscale (07/07/2026)

Tags: nyora, vps, contabo, wireguard, qbittorrent, tailscale, kill-switch, incident

Contexte

Le tunnel wg-admin custom (bastion WireGuard maison pour l'admin) est tombé en panne silencieuse après ~2 jours d'usage, y compris pour le peer NAS pourtant stable jusque-là. Cause racine : SaveConfig = false sur wg-admin.conf efface tout peer ajouté à chaud au moindre redémarrage du service — combiné à un accès VNC Contabo lui-même devenu inaccessible, plus de porte d'entrée du tout. Décision : réinstallation complète + remplacement du bastion custom par Tailscale.

Nouvelle architecture

  • Accès admin : Tailscale (tailscale up --ssh), plus de conteneur wg-admin custom, plus de piège SaveConfig.
  • Fallback sans dépendance logicielle : règle ufw restreinte à l'IP fixe de Nabil (41.62.145.144, à vérifier/mettre à jour si IP FAI change) sur ports 22 et 8080.
  • VPN torrent : wg0 natif (VPN Unlimited France, B4837_fr_wg.conf, Table = off obligatoire) + qBittorrent-nox + kill-switch iptables (user dédié qbtuser, table de routage 51820) — architecture inchangée, cf runbook vps-contabo-wireguard-qbittorrent-natif.md, toujours valide.

Piège rencontré : mcp-nas (conteneur Docker sur le NAS) ne peut pas router vers le tailnet

Le conteneur mcp-nas est isolé dans son propre namespace réseau Docker (172.17.0.0/16), séparé de l'interface tailscale0 du NAS host, même après installation de Tailscale sur le NAS lui-même. Accès mcp-nas→VPS via IP publique reste nécessaire tant que l'IP forwarding + NAT entre docker0 et tailscale0 n'est pas configuré côté host, ou tant qu'un conteneur dédié ne tourne pas en network_mode: host. Non résolu, à corriger si accès permanent Claude→tailnet nécessaire.

Piège rencontré : tailscale up non-interactif ne remonte pas l'URL d'auth dans stdout via SSH

tailscale up --ssh bufferise silencieusement en sortie non-TTY (SSH sans pty, backgrounding). L'URL d'auth apparaît uniquement dans journalctl -u tailscaled (grep 'AuthURL is'), jamais dans les logs de redirection stdout classiques. Solution : toujours vérifier via journalctl plutôt que d'attendre un fichier de log qui restera vide.

Anomalie non résolue, sans impact prod

Tests manuels (su -s /bin/bash qbtuser -c 'curl ...') échouent systématiquement en TCP sortant via wg0 (SYN part, jamais de réponse), alors que le vrai service qbittorrent-nox.service sous systemd fonctionne normalement (DHT connecté, 77 nœuds). Cause non identifiée (contexte cgroup/session su vs scope systemd probable). Ne pas utiliser su/runuser comme test de validation du kill-switch — vérifier plutôt via l'API qBittorrent (/api/v2/transfer/info, connection_status).

Séquence de déploiement validée (à rejouer telle quelle en cas de nouvelle réinstallation)

  1. chpasswd nouveau mot de passe root (l'ancien a toujours circulé en clair au moins une fois, à changer systématiquement après tout accès partagé)
  2. Clé SSH dédiée oversight (ssh-keygen -t ed25519), ajout authorized_keys, test avant de continuer
  3. curl -fsSL https://tailscale.com/install.sh | sh (attendre le verrou apt/dpkg post-boot, jusqu'à 300s, unattended-upgrades actif juste après reinstall)
  4. tailscale up --ssh --hostname=<nom> en arrière-plan, récupérer l'URL via journalctl -u tailscaled | grep 'AuthURL is'
  5. scp direct des fichiers de déploiement depuis le NAS (/mnt/docker/hermes-platform/hermes-nyora/data/workspace/contabo-vps/) vers le VPS via IP publique (avant tout verrouillage firewall)
  6. setup-wireguard.sh puis setup-qbittorrent.sh (scripts inchangés, toujours valides)
  7. Changer les identifiants WebUI qBittorrent par défaut via API (/api/v2/app/setPreferences)
  8. En tout dernier : verrouillage ufw (22 + 8080 restreints à tailscale0 + IP fallback), jamais avant d'avoir confirmé Tailscale fonctionnel des deux côtés

Fichiers

Scripts réutilisés tels quels depuis contabo-vps/setup-wireguard.sh et contabo-vps/setup-qbittorrent.sh — aucune modification nécessaire, la partie VPN/kill-switch n'a jamais été en cause dans l'incident.

Suite (07/07/2026, soir) — cause reelle identifiee et resolue

Le WebUI restait inaccessible depuis Safari/Chrome sur Mac (ERR_CONNECTION_REFUSED) meme apres Tailscale fonctionnel, alors que curl simple reussissait (HTTP 200). Test decisif : 5 curl en parallele depuis le Mac -> 5 echecs (000), alors qu'une requete seule passe toujours. Meme signature que l'incident wg-admin initial du 05/07 (deja documente a l'epoque : "connexions sequentielles OK, paralleles KO").

Cause reelle : NAT agressif Tunisia Telecom qui casse les connexions concurrentes sortantes, independamment du tunnel utilise en dessous (wg-admin custom hier, Tailscale aujourd'hui). Ni qBittorrent, ni le kill-switch, ni la config Tailscale n'etaient en cause — tout le travail de diagnostic reseau/iptables/UID de la session precedente etait hors-sujet par rapport a la vraie cause.

Fix : tunnel SSH local multiplexe au lieu d'un acces navigateur direct.

ssh -L 8080:localhost:8080 root@100.94.90.119

puis http://localhost:8080 dans le navigateur. Une seule connexion TCP vers le VPS, le navigateur multiplexe dessus au lieu d'ouvrir plusieurs connexions paralleles qui declenchent le bug NAT.

Lecon a capitaliser : cette solution etait deja la Solution 1 recommandee dans le tout premier diagnostic (05/07), avant meme la bascule Tailscale et la reinstallation complete du VPS. Le symptome "sequentiel OK / parallele KO" est un signal fort et suffisant a lui seul pour aller direct au tunnel SSH local, sans reinvestiguer tunnel/firewall/kill-switch a chaque fois qu'il reapparait avec un acces web direct depuis ce reseau.