Réseau Tailscale et OpenSSH

Le rôle de Tailscale ici

Tailscale relie les appareils à un réseau privé fondé sur WireGuard, appelé tailnet, et attribue des adresses privées stables à ses nœuds. Il fournit au client un chemin sécurisé vers le VPS, avec des adresses 100.x ; il ne crée pas automatiquement de service fonctionnel sur la machine de destination. Pour SSH, le VPS doit toujours exécuter sshd à l’écoute sur le port 22.

Client ssh de WSL2
  -> connectivité Tailscale de l’hôte Windows
  -> adresse Tailscale 100.x du VPS
  -> sshd d’Ubuntu
  -> authentification par clé publique avec authorized_keys

Dans cette installation, Windows est le nœud du tailnet et WSL2 utilise sa connectivité VPN par la pile réseau Windows. Si WSL2 atteint déjà l’adresse Tailscale du VPS, il n’est pas nécessaire d’installer un second nœud Tailscale dans WSL2. Le comportement peut varier selon le mode réseau WSL et le VPN ; vérifiez donc le routage réel et la connexion SSH.

Ce n’est pas Tailscale SSH

Les noms se ressemblent, mais les deux solutions fonctionnent différemment :

Solution	Réseau	Service SSH et authentification
OpenSSH sur Tailscale	Tailscale fournit le chemin réseau privé	Le sshd d’Ubuntu traite SSH et utilise toujours les clés publiques utilisateur
Tailscale SSH	Tailscale fournit le réseau et prend en charge les connexions au port 22 arrivant par le tailnet	Tailscale gère les politiques d’authentification et d’autorisation

Cette série utilise la première solution ; ne lancez donc pas :

tailscale set --ssh

Installer Tailscale sur le VPS et rejoindre le tailnet

Vérifiez d’abord s’il est déjà installé :

[REMOTE: VPS]

command -v tailscale || true
systemctl status tailscaled --no-pager || true

La méthode officielle d’installation rapide sous Linux est :

[REMOTE: VPS]

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Dans un environnement plus strict, lisez le script ou configurez manuellement le dépôt officiel pour la distribution. tailscale up peut afficher une URL d’autorisation à ouvrir dans le navigateur. Affichez uniquement cette URL et laissez la personne qui administre le serveur se connecter et autoriser le nœud ; n’intégrez jamais de clé d’authentification au script.

Vérifier l’état du nœud

[REMOTE: VPS]

tailscale status
tailscale ip -4
systemctl is-enabled tailscaled
systemctl is-active tailscaled

Un nœud inscrit ou affiché « online » dans la console d’administration confirme son enregistrement, pas l’accessibilité du service depuis le client. Cela ne remplace pas un test de bout en bout depuis le client réellement utilisé.

Vérifier depuis WSL2

[LOCAL: WSL2]

ping -c 3 "$TAILSCALE_IPV4"

ssh \
  -i "$HOME/.ssh/id_ed25519" \
  -o IdentitiesOnly=yes \
  -o PreferredAuthentications=publickey \
  -o PasswordAuthentication=no \
  "$VPS_USER@$TAILSCALE_IPV4"

ping aide à vérifier le chemin réseau de base, mais seule une connexion SSH réussie valide l’accès d’administration à distance. Dans la session établie, examinez la sortie de cette commande :

[REMOTE: session reached through Tailscale]

printf '%s\n' "$SSH_CONNECTION"

La sortie indique normalement l’IP Tailscale du client, son port éphémère, l’IP Tailscale du VPS et le port 22. Ces valeurs permettent de confirmer que la connexion a emprunté le chemin prévu.

Échecs courants

• Le nœud Windows est en ligne, mais les connexions depuis WSL2 expirent toujours : vérifier le mode réseau WSL, le VPN et le pare-feu Windows, ainsi que la route vers 100.x ; ne pas fermer immédiatement le port 22 public.
• Le ping fonctionne, mais la connexion SSH expire : vérifier sshd sur le VPS, les règles d’interface UFW et les ports en écoute.
• SSH demande de confirmer une nouvelle clé d’hôte : comparer l’empreinte de la clé publique d’hôte du VPS par un accès déjà fiable.
• La console indique que le nœud est en ligne, mais la connexion échoue : cet état ne valide pas l’accès au service ; testez une connexion réelle depuis WSL2.

Conservez l’accès SSH public jusqu’à ce qu’une nouvelle session OpenSSH sur Tailscale fonctionne de manière fiable ; ce n’est qu’ensuite que vous pouvez restreindre l’accès SSH public.

Mes lectures