Un conteneur VPN peut être connecté à un réseau distant alors que l’hôte ZimaOS reste totalement inconscient de cette route. C’était le problème décrit dans ce fil source de septembre 2025. Le conteneur Tailscale de l’utilisateur avait bien rejoint le tailnet, mais ZimaOS lui-même — et donc l’application Fichiers ainsi que le processus de montage SMB depuis l’hôte — ne pouvait pas accéder au serveur CasaOS distant via l’espace de noms réseau du conteneur.
L’utilisateur a résolu le problème pratique de sauvegarde en modifiant l’architecture plutôt qu’en forçant le conteneur Tailscale à devenir un VPN de l’hôte. Il a rejoint le serveur CasaOS distant au réseau ZeroTier associé à ZimaOS et a indiqué que l’accès SMB fonctionnait alors correctement.
La topologie d’origine comportait deux serveurs distants
La configuration source était la suivante :
- un ZimaBlade exécutant ZimaOS comme machine source ;
- un serveur distant exécutant CasaOS comme cible de sauvegarde SMB ;
- Tailscale assurant la connexion entre les deux sites.
Lorsque les deux machines exécutaient auparavant CasaOS, l’utilisateur avait installé Tailscale directement sur les hôtes et monté normalement le partage SMB distant.
Le conteneur Tailscale a rejoint le tailnet, mais pas ZimaOS
Sur ZimaOS, l’utilisateur exécutait Tailscale dans Docker. Cela fournissait une connectivité au conteneur Tailscale lui-même, mais n’ajoutait pas automatiquement les routes ou adresses Tailscale à l’espace de noms réseau de l’hôte ZimaOS.
L’application Fichiers ne pouvait donc pas simplement parcourir un serveur SMB accessible uniquement depuis l’intérieur du conteneur Tailscale.
Il s’agit d’une limite liée à l’espace de noms réseau, et non d’un problème de mot de passe SMB
Un conteneur Docker possède normalement ses propres interfaces, routes et règles de pare-feu. Même si le conteneur peut envoyer des requêtes ping vers une adresse distante du tailnet, les applications de l’hôte n’héritent pas de ces routes, sauf si le VPN a été délibérément intégré au réseau de l’hôte, au routage ou à une architecture de proxy.
Modifier les identifiants SMB ne résoudrait pas l’absence de cette route.
L’utilisateur a basculé le serveur CasaOS distant sur ZeroTier
Après quelques recherches supplémentaires, l’auteur du sujet d’origine a installé ZeroTier sur le serveur CasaOS distant et l’a rejoint au réseau virtuel utilisé par ZimaOS. Il a ensuite indiqué que le serveur distant pouvait accéder au partage SMB et que la solution fonctionnait bien.
La commande d’installation exacte publiée sur le forum provenait d’un membre de la communauté. L’architecture réutilisable est plus importante que la reproduction de ce script d’installation en une seule ligne.
L’accès distant actuel à ZimaOS repose sur un réseau virtuel basé sur ZeroTier
La documentation actuelle d’IceWhale décrit l’identifiant réseau de connexion ou d’accès distant de ZimaOS comme une identité de réseau ZeroTier. ZimaClient utilise ce réseau virtuel pour assurer une connectivité distante chiffrée.
La solution de l’utilisateur apparaît donc moins comme un simple contournement qu’elle ne pourrait le sembler : au lieu d’essayer d’exporter une route Docker Tailscale vers l’hôte, le NAS distant rejoint le réseau virtuel que ZimaOS utilise déjà au niveau de l’hôte.
IceWhale documente désormais le même modèle avec d’autres plateformes NAS
La documentation actuelle de ZimaOS consacrée à la synchronisation avec QNAP demande aux utilisateurs d’obtenir l’identifiant réseau ZimaOS, d’installer ZeroTier côté QNAP, puis de rejoindre cet identifiant avant de créer une tâche de synchronisation entre réseaux.
Utilisez le modèle actuel de réseau ZeroTier inter-NAS comme référence architecturale prise en charge.
Une option Tailscale au niveau de l’hôte constitue une solution différente
Des projets communautaires plus récents ont intégré Tailscale à ZimaOS sous la forme d’un systemd-sysext natif, spécifiquement pour fournir à l’hôte une véritable interface TUN et permettre le routage au niveau de l’hôte. Cela peut résoudre la limitation liée à l’espace de noms d’origine, mais il s’agit d’un logiciel communautaire et non d’une fonctionnalité Tailscale officielle de ZimaOS.
Si l’objectif se limite à effectuer des sauvegardes SMB distantes, joindre le serveur distant au réseau virtuel existant de ZimaOS peut être plus simple que d’installer une nouvelle extension VPN au niveau de l’hôte.
L’accessibilité au niveau de l’hôte doit être établie avant que Fichiers puisse monter le partage SMB
Quel que soit le réseau superposé choisi, l’hôte ZimaOS doit pouvoir acheminer le trafic vers l’adresse du serveur SMB distant. Ce n’est qu’ensuite que le nom du partage SMB, le nom d’utilisateur, le mot de passe et les autorisations deviennent les prochains éléments à vérifier.
Traitez la destination SMB distante comme faisant partie du périmètre de sécurité de la sauvegarde
Un partage de sauvegarde accessible via un réseau superposé doit tout de même exiger une authentification et ne doit exposer que les dossiers nécessaires au processus de sauvegarde. Évitez de rendre l’intégralité du serveur distant accessible en écriture simplement parce que le trafic est chiffré.
FAQ sur le SMB distant via des réseaux superposés
Pourquoi le conteneur Tailscale pouvait-il atteindre le serveur distant alors que Fichiers de ZimaOS ne le pouvait pas ?
Le conteneur disposait de son propre espace de noms réseau et de ses propres routes ; l’hôte ZimaOS n’en héritait pas automatiquement.
Qu’a utilisé l’auteur du sujet d’origine à la place ?
Il a rejoint le serveur CasaOS distant au réseau ZeroTier utilisé par ZimaOS et a indiqué que cela fonctionnait bien.
ZimaOS utilise-t-il actuellement ZeroTier pour les connexions réseau distantes ?
La documentation actuelle d’IceWhale décrit l’identifiant réseau de connexion distante et les processus inter-NAS en s’appuyant sur un réseau virtuel basé sur ZeroTier.
