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