Fondamentaux d'un VPS personnel

Ces notes décrivent une démarche sûre pour mettre en place un serveur personnel : vérifier l’identité de la machine, établir un accès distant sans risquer de se retrouver bloqué, installer l’environnement de conteneurs et un point d’entrée commun, puis valider un premier déploiement applicatif réel avec RSSHub. La phase 3 reste un déploiement miroir : la nouvelle instance RSSHub est utilisable, mais le consommateur de flux existant utilise toujours le RSSHub local ; aucun consommateur de production n’a encore été basculé.

Si vous choisissez encore où exécuter une application, comparez cette approche autogérée avec Cloudflare Workers et le tutoriel Cloud Run de Google Cloud. Ces guides couvrent l’exécution gérée, les permissions, le stockage et la facturation ; cette série se concentre sur l’administration de l’hôte Linux lui-même.

Pour suivre un nom d’hôte à travers les ports et HTTPS jusqu’à l’application, commencez par le parcours d’une requête réseau.

Commencer par la vue d'ensemble : deux portes

Considérez le VPS comme une salle des machines située sur Internet. Il possède désormais deux points d'entrée très différents :

1. La porte d'administration m'est réservée : WSL2 emprunte d'abord la route privée Tailscale, puis OpenSSH vérifie ma clé et ouvre un terminal.
2. La porte du site web est destinée aux visiteurs d'Internet : chaque requête HTTP/HTTPS publique atteint d'abord Caddy, et Caddy décide quel site web ou quelle API doit la recevoir.

Uptime Kuma est un outil d'administration, pas un site web public. Il n'a pas de porte publique ; je crée un tunnel SSH temporaire lorsque j'ai besoin de le consulter.

[Moi : WSL2]
    `-- route privée Tailscale
          `-- porte d’administration OpenSSH verrouillée
                `-- [VPS Ubuntu]

[Visiteur Internet]
    `-- TCP 80/443
          `-- accueil public Caddy
                |-- contrôle de santé de l’infrastructure
                `-- couloir infra-edge -> RSSHub:1200

[À l’intérieur du VPS]
    |-- Docker exécute Caddy, Uptime Kuma et RSSHub séparément
    |-- UFW contrôle les ports de l’hôte qui peuvent recevoir du trafic
    |-- Uptime Kuma attend un tunnel SSH uniquement sur 127.0.0.1:3001
    `-- le port 1200 de RSSHub n’est accessible que dans le réseau Docker, sans publication sur l’hôte

[Environnement local existant]
    `-- consommateur de flux -> RSSHub local (chemin de production et solution de repli)

Trois couches sont souvent confondues :

1. La connectivité réseau détermine si les paquets peuvent atteindre le VPS.
2. OpenSSH fournit une session chiffrée et vérifie l’identité du serveur.
3. L’authentification SSH par clé publique prouve que la personne qui se connecte possède la clé privée correspondante.

Dans cette installation, Tailscale fournit uniquement le chemin réseau privé. C’est toujours OpenSSH sous Ubuntu qui écoute sur le port 22 et vérifie les clés publiques utilisateur. Je n’ai pas activé la fonctionnalité distincte Tailscale SSH.

Vocabulaire

Terme	Signification ici
VPS	Une machine Linux virtuelle fournie par un hébergeur cloud
IP publique	Une adresse routable depuis Internet
IP Tailscale	Une adresse privée 100.x.x.x accessible uniquement au sein du même tailnet
Port	Un point d'entrée de service réseau, comme TCP 22 pour SSH
daemon	Un processus de service qui s’exécute durablement en arrière-plan, comme sshd, tailscaled ou dockerd
systemd	Le système d’Ubuntu qui gère les services, leur état au démarrage et les journaux
UFW	L’outil de gestion du pare-feu de l’hôte Ubuntu
image	Un modèle en lecture seule servant à créer des conteneurs
conteneur	Un processus isolé lancé à partir d’une image, avec son état d’exécution
Compose	Un plugin Docker décrivant des conteneurs, des réseaux et des volumes en YAML

Outils installés ou activés

Les composants ci-dessous ont été installés, activés ou explicitement configurés au cours des phases 1 à 3. L’analogie permet de comprendre leur rôle avant de retenir leur nom technique.

Outils me permettant de me connecter en toute sécurité

Outil	Imaginez-le comme	Problème qu'il résout
Serveur OpenSSH	Une porte d'administration verrouillée qui accepte la bonne clé	Confirme que le client détient la clé privée correspondant à une clé publique enregistrée, puis fournit une ligne de commande distante ; la clé privée n'est jamais envoyée au serveur
Tailscale	Une route privée reliant uniquement mes appareils	Permet à WSL2 de trouver le VPS via une adresse privée au lieu d'exposer l'administration à l'ensemble d'Internet
UFW	La liste des visiteurs à la grille d'entrée	Configure le refus des connexions entrantes par défaut et autorise les ports Web publics ainsi que SSH sur tailscale0 ; sous Linux, Tailscale utilise par défaut le mode on, dont les règles de pare-feu évaluées en priorité acceptent le trafic arrivant par tailscale0

Tailscale et OpenSSH sont différents : Tailscale construit la route vers le serveur ; OpenSSH vérifie la clé lorsque j'arrive à la porte.

Outils qui exécutent les services

Outil	Imaginez-le comme	Problème qu'il résout
Moteur Docker	Un gestionnaire d'immeuble pour des pièces isolées	Exécute chaque service dans un conteneur séparé et gère les images, les réseaux et les montages persistants
Docker Compose	Les instructions d'aménagement et de démarrage de chaque pièce	Enregistre l'image, le chemin des données, les ports et la politique de redémarrage dans un seul fichier YAML
Docker Buildx	Un établi pour fabriquer de nouveaux modèles de pièces	Construit des images Docker personnalisées lorsqu'une image existante ne suffit pas ; l'exploitation normale de Caddy et Kuma ne le requiert pas

Les trois fichiers de configuration actuels sont /srv/caddy/compose.yaml, /srv/uptime-kuma/compose.yaml et /srv/rsshub/compose.yaml. Ils sont indépendants, de sorte que redémarrer RSSHub ne redémarre ni l'entrée ni la supervision.

Outils pour l'entrée publique et la supervision

Outil	Imaginez-le comme	Problème qu'il résout
Caddy	Le bureau d'accueil public pour les sites web	Reçoit tout le trafic public sur 80/443, gère les certificats HTTPS et les redirections HTTP, puis envoie chaque requête au bon service
Uptime Kuma	Un veilleur et son tableau de suivi	Vérifie régulièrement les URL de santé et enregistre si les services sont en ligne ; son interface d’administration reste privée
RSSHub	Un bureau de traduction qui transforme les mises à jour de sites en flux	Exécute des routes RSS réelles et utilise ACCESS_KEY pour empêcher des tiers d'utiliser l'instance privée

Caddy et RSSHub rejoignent le réseau Docker nommé infra-edge. Considérez-le comme un couloir interne reliant l’accueil au service web : Caddy trouve RSSHub grâce à l’alias rsshub-prod, sans que le port 1200 de RSSHub soit publié sur l’hôte ou sur Internet. Kuma reste en dehors de ce chemin de proxy et demeure disponible uniquement via son tunnel SSH.

Quand vais-je utiliser chacun d'eux ?

• Se connecter au VPS : connecter Tailscale, puis exécuter ssh ; Tailscale, UFW et OpenSSH fonctionnent ensemble en coulisses.
• Démarrer, arrêter ou inspecter un service : utiliser docker compose ; ne pas modifier directement les fichiers internes de Docker.
• Ouvrir Kuma : créer la redirection locale SSH, puis naviguer vers http://127.0.0.1:3001 ; ne pas rendre le port 3001 public.
• Vérifier le point de terminaison public : ouvrir l'URL HTTPS /healthz servie par Caddy.
• Utiliser RSSHub : un consommateur de confiance appelle le domaine HTTPS avec l'ACCESS_KEY ; la clé ne transite que depuis le fichier .env protégé du VPS vers les consommateurs de confiance, jamais dans les notes publiques ou les URL de supervision.
• Buildx : à utiliser uniquement lors de la construction d'une image personnalisée ; l'exploitation courante en a rarement besoin.

Quatre frontières à retenir

• Seul le trafic public TCP 80/443 entre, et il atteint Caddy en premier.
• SSH transite uniquement par le réseau privé Tailscale ; le SSH public reste bloqué.
• Kuma écoute uniquement sur le 127.0.0.1:3001 propre au VPS et se consulte via un tunnel SSH.
• Le port 1200 de RSSHub n’est pas publié sur l’hôte. Caddy y accède via infra-edge ; l’hôte Docker et les autres conteneurs de ce réseau peuvent aussi y accéder à l’adresse du conteneur.

« UFW actif » seul ne prouve pas que les ports Docker sont sécurisés, car Docker a ses propres règles de redirection de ports. Pour chaque nouveau service, vérifiez les ports déclarés dans Compose, les adresses et ports effectivement publiés par Docker, puis le résultat d’une connexion depuis une autre machine. Le guide d'ajout de services contient les commandes, et le Journal de construction contient la chronologie de déploiement.

Parcours de lecture

1. Architecture et sécurité
2. Accès SSH et durcissement
3. Réseau Tailscale et OpenSSH
4. UFW sans verrouillage
5. Moteur Docker et Compose
6. Guide d'exploitation
7. Tmux en pratique
8. Ajouter des services à côté d'un bot existant
9. Déploiement miroir de RSSHub en production

Invariants de sécurité

• Étiqueter chaque commande comme étant locale à WSL2 ou distante sur le VPS.
• Ne jamais supprimer le dernier chemin SSH vérifié.
• Après une modification de SSH ou du pare-feu, tester avec une nouvelle connexion ; une ancienne session peut survivre à une règle de pare-feu défectueuse.
• Ne jamais placer de clés privées, mots de passe, jetons d’authentification ou codes de récupération dans la sortie des commandes, les notes, Git ou les conversations. Ne pas publier non plus d’adresses réelles ni d’empreintes.

Variables d’exemple

Cette série utilise des valeurs de substitution à la place des informations réelles de la machine :

VPS_USER=ubuntu
VPS_PUBLIC_IPV4="<public-ip>"
TAILSCALE_IPV4="<100.x.x.x>"
LOCAL_SSH_PUBLIC_KEY="$HOME/.ssh/id_ed25519.pub"

Ne pas enregistrer de mot de passe, de clé privée ou de clé d’authentification Tailscale dans ces variables.

Ce qui est en place aujourd’hui

Après les phases 1 à 3, mon VPS dispose des éléments suivants :

• Un système Ubuntu mis à jour, avec le bon nom d’hôte et le bon fuseau horaire.
• OpenSSH configuré pour l’authentification par clé publique seule, sans connexion directe de root.
• Des sessions OpenSSH fonctionnelles sur le réseau privé Tailscale.
• Les ports TCP 80/443 accessibles publiquement pour l’entrée web, tandis que le port 22 n’est plus ouvert à tous.
• Docker, Buildx et Compose opérationnels, avec Caddy, Uptime Kuma et RSSHub dans des projets Compose indépendants.
• Caddy comme unique entrée publique vers les conteneurs, tandis que l’interface d’administration de Kuma reste limitée à l’adresse de bouclage.
• RSSHub exécuté à partir d’une image officielle épinglée par digest, avec un cache en mémoire, ACCESS_KEY et aucun port publié sur l’hôte.
• Des contrôles de santé HTTPS publics, le refus des requêtes non authentifiées, une route réelle authentifiée, la supervision et le redémarrage de l’application, tous vérifiés.
• Les configurations des services et leurs données persistantes sous /srv ; un répertoire de données ne constitue pas une sauvegarde.
• Tmux pour maintenir les sessions d’administration, avec l’ajout progressif de services sous forme de projets Compose indépendants.

La configuration de production du consommateur de flux, ses données persistantes, son ordonnanceur et le RSSHub local restent inchangés. La bascule des consommateurs, la preuve de sauvegarde et de restauration, la migration de l’ordonnanceur et la décision de retirer la solution de repli locale relèvent de la phase 4.

Documentation officielle

• Ubuntu : serveur OpenSSH
• Ubuntu : pare-feu
• Tailscale : SSH sur Tailscale
• Docker : installer Docker Engine sur Ubuntu
• Caddy : démarrage rapide avec HTTPS
• Uptime Kuma : documentation du projet
• RSSHub : projet officiel

Mes lectures