
Accès distant sécurisé à son NAS avec Tailscale
Le problème
Une vingtaine de services tournent sur le NAS — Jellyfin, Immich, Home Assistant, dashboards de monitoring — tous accessibles localement. Dès qu'on s'éloigne du réseau, plus rien.
La solution classique consiste à ouvrir des ports sur la box, configurer du port forwarding, mettre en place un DNS dynamique et espérer qu'aucun bot ne trouve les services exposés.
VPN classique vs Tailscale
Un VPN auto-hébergé classique (OpenVPN, WireGuard natif) demande d'ouvrir au moins un port UDP sur le routeur, de configurer du port forwarding, de gérer un DNS dynamique si l'IP change, de maintenir serveur, certificats et clés, et de configurer manuellement chaque client.
Tailscale est un VPN mesh basé sur WireGuard qui crée des tunnels point-à-point entre appareils : zéro serveur central à maintenir et zéro port ouvert sur le routeur. Les connexions passent par du NAT traversal (STUN/DERP), qui trouve le chemin le plus direct entre deux appareils, même derrière du double NAT. Quand c'est impossible, le trafic transite par des relais DERP, mais reste chiffré de bout en bout.
Installation via Ansible
# group_vars/nas.yml (extrait Tailscale)
tailscale_auth_key: 'tskey-auth-xxxxx' # clé d'authentification (vault)
tailscale_subnet_router: true
tailscale_advertised_routes: '192.168.1.0/24'
tailscale_exit_node: true
tailscale_accept_dns: true
Ce que le rôle exécute concrètement :
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up \
--authkey=tskey-auth-xxxxx \
--advertise-routes=192.168.1.0/24 \
--advertise-exit-node \
--accept-dns
Subnet router : exposer tout le LAN
C'est la feature la plus puissante. Avec le subnet routing, le NAS devient une passerelle qui expose tout le réseau local (192.168.1.0/24) aux appareils Tailscale.
Depuis un téléphone en 4G avec Tailscale actif, on accède à tous les services du NAS par leur IP locale (192.168.1.50:8096 pour Jellyfin), aux autres appareils du LAN (imprimante réseau, caméras IP, hub domotique) et aux interfaces d'administration (box internet, switches managés). Les apps se comportent exactement comme sur le réseau local.
Deux prérequis. D'abord l'IP forwarding sur le NAS :
# /etc/sysctl.d/99-tailscale.conf
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
Ensuite l'approbation des routes dans la console Tailscale (ou via tailscale set avec les ACLs). Sans elle, les routes advertised ne remontent pas.
Exit node : navigation sécurisée
Activé sur un client, l'exit node fait passer tout le trafic internet de l'appareil via le NAS, qui devient le proxy de sortie. Utile sur les réseaux WiFi publics : au lieu de faire confiance au réseau local, tout est chiffré dans le tunnel WireGuard jusqu'au NAS puis sort par la connexion maison.
Côté client, c'est un simple toggle dans l'app Tailscale, activable à la demande selon le réseau.
Cas d'usage réels
- Jellyfin en déplacement : regarder ses films et séries partout, sans exposer le port 8096
- Immich depuis le téléphone : backup auto des photos et consultation hors de la maison
- SSH d'urgence : connexion au NAS depuis un portable pour dépanner rapidement
- Dashboards internes : Homepage, Uptime Kuma, Scrutiny sans les rendre publics
- WiFi public sécurisé : exit node activé à l'hôtel pour naviguer via la connexion maison
MagicDNS : des noms au lieu des IPs
Tailscale intègre un DNS interne, MagicDNS, qui résout automatiquement les noms des machines du tailnet :
ssh nasadmin@nas.tail1234.ts.net
Couplé au subnet routing, on garde l'accès par IP locale pour les services Docker, et le hostname Tailscale pour SSH.
Vérifier l'état
$ tailscale status
100.64.1.1 nas francois@ linux active; direct 192.168.1.50:41641
100.64.1.2 laptop francois@ linux active; direct 82.66.x.x:38412
100.64.1.3 pixel8 francois@ android active; relay "par"
100.64.1.4 macbook-pro francois@ macOS idle; offline
On voit immédiatement quels appareils sont connectés, en direct ou via relay, et leur état. Ici le téléphone passe par un relay DERP à Paris — pas de connexion directe possible, mais trafic chiffré de bout en bout.
Intégration avec le pare-feu
Point important : Tailscale utilise sa propre interface (tailscale0) et n'est pas affecté par les règles UFW. Le trafic arrive déjà déchiffré sur tailscale0 puis accède aux services localement — c'est pourquoi les services restreints au LAN restent accessibles via Tailscale.
Aucune règle de pare-feu à modifier, contrairement à un VPN classique où il faut souvent ajouter des règles pour le sous-réseau VPN.
Tailscale vs WireGuard auto-hébergé
| WireGuard natif | Tailscale | |
|---|---|---|
| Port ouvert sur le routeur | Oui (UDP) | Non |
| DNS dynamique | Nécessaire | Intégré (MagicDNS) |
| Gestion des clés | Manuelle | Automatique |
| NAT traversal | Non | Oui |
| Subnet routing | Config manuelle | Toggle dans l'admin |
| Multi-utilisateurs + ACLs | Complexe | Intégré |
| Dépendance externe | Aucune | Tailscale (SaaS) |
Le tradeoff est la dépendance au service Tailscale pour la coordination — pas pour le trafic, qui reste point-à-point.
Côté performances, WireGuard est réputé pour son overhead minimal : en connexion directe, aucune différence perceptible entre un accès local et un accès Tailscale. Seul le passage par un relay DERP ajoute de la latence, et c'est rare.
Résumé
Plus de ports ouverts, plus de DNS dynamique, plus de VPN complexe à maintenir : on installe l'app sur un appareil, on se connecte, et tout le réseau local est accessible comme à la maison. C'est la solution à recommander à quiconque auto-héberge et veut y accéder de loin sans compromettre la sécurité.
Articles similaires