Fondamentaux d'un VPS personnel

Cette série suit le VPS depuis un socle sécurisé jusqu'à sa première véritable charge de travail miroir : vérifier la machine, préserver l'accès distant, fermer le SSH public, ajouter une entrée partagée et une supervision privée, puis valider le chemin applicatif avec RSSHub. La nouvelle instance est utilisable, mais un 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.

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.

[Me: WSL2]
    `-- private Tailscale road
          `-- locked OpenSSH management door
                `-- [Ubuntu VPS]

[Internet visitor]
    `-- TCP 80/443
          `-- Caddy public reception desk
                |-- infrastructure health check
                `-- infra-edge corridor -> RSSHub:1200

[Inside the VPS]
    |-- Docker runs Caddy, Uptime Kuma, and RSSHub separately
    |-- UFW controls which host ports may receive traffic
    |-- Uptime Kuma waits on 127.0.0.1:3001 for an SSH tunnel
    `-- RSSHub port 1200 exists only inside the Docker network

[Existing local environment]
    `-- feed consumer -> local RSSHub (production path and fallback)

Trois couches sont essentielles : la joignabilité réseau, le protocole OpenSSH et l'identité de l'hôte, et l'authentification par clé publique de l'utilisateur. Tailscale fournit ici le chemin réseau privé ; OpenSSH sous Ubuntu écoute toujours sur le port 22 et authentifie l'utilisateur. Le produit distinct Tailscale SSH n'est pas activé.

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 au sein d'un tailnet
Port	Un point d'entrée de service réseau, comme TCP 22 pour SSH
daemon	Un service de longue durée tel que sshd, tailscaled ou dockerd
UFW	L'interface frontale du pare-feu hôte d'Ubuntu
image / conteneur	Un modèle en lecture seule / une instance en cours d'exécution de ce modèle
Compose	Un plugin Docker décrivant les applications en YAML

Outils installés ou activés

Les composants ci-dessous ont été réellement installés, activés ou explicitement configurés au cours des phases 1 à 3. Commencez par l'analogie, puis associez-y le 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	Refuse par défaut les connexions entrantes non sollicitées et n'autorise que les ports Web publics ainsi que SSH arrivant via l'interface Tailscale

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 d'instructions 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, puis envoie chaque requête au bon service
Uptime Kuma	Le veilleur et tableau d'état	Vérifie de manière répétée les URL de santé et enregistre si les services sont en ligne ; son écran de gestion reste privé
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 allant de l'accueil à la charge de travail Web : Caddy résout l'alias rsshub-prod, tandis que RSSHub n'ouvre aucun port hôte ni port public. 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 d'environnement 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.

Trois 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 lié à l'hôte ; seul Caddy peut l'atteindre via infra-edge.

« 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 Compose, les liaisons réelles de Docker et 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é.
• Tester les modifications avec une nouvelle connexion ; une ancienne session peut survivre à une règle de pare-feu défectueuse.
• Ne jamais publier de mots de passe, clés privées, jetons, codes de récupération, adresses réelles ou empreintes.

Les exemples utilisent des variables de substitution :

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

Après les phases 1 à 3, le VPS dispose d'un hôte Ubuntu mis à jour, d'OpenSSH par clé uniquement sur Tailscale, de TCP 80/443 public via Caddy, de Docker avec Buildx et Compose, d'une supervision Kuma privée, et d'une charge de travail miroir RSSHub épinglée par digest avec cache en mémoire, ACCESS_KEY, et aucun port hôte. La santé publique, le refus non authentifié, une route réelle authentifiée, la supervision et le redémarrage d'application ont tous été vérifiés.

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 restauration, la migration de l'ordonnanceur et la décision de retirer la solution de secours locale relèvent de la phase 4.

Mes lectures · Les notes ouvertes sont mémorisées dans ce navigateur.