Un client VPN peut accéder au tableau de bord du NAS tout en ne pouvant pas atteindre les sous-réseaux Docker, car l’accessibilité de l’hôte ne crée pas automatiquement de routes de transfert vers les réseaux de conteneurs.
Sur un serveur domestique ZimaSpace, la page de gestion du NAS peut écouter sur l’adresse de l’hôte, tandis que les applications auto-hébergées résident derrière des ponts Docker tels que 172.18.0.0/16. Le VPN peut se terminer correctement sur l’hôte, tout en ne disposant d’aucune route annoncée, règle de transfert, route de retour ou plan d’adressage sans chevauchement pour ces réseaux de pont.
Vérifiez que le VPN ne connaît que la route vers l’hôte
Comparez la table de routage du client VPN pour l’adresse de l’hôte NAS et le sous-réseau Docker réel.
Un article ciblé sur le routage de sous-réseaux VPN, les routeurs de sous-réseaux étendent l’accès au-delà d’un seul hôte, aide à isoler cette piste, car il traite le même problème précis au lieu de simplement définir le protocole sous-jacent.
Si seul l’hôte ou le sous-réseau LAN est annoncé, ne vous attendez pas à ce qu’un pont Docker privé devienne automatiquement accessible.
Recherchez un chevauchement entre les sous-réseaux Docker et VPN
Comparez le pool d’adresses du client VPN, les réseaux locaux domestiques et chaque plage de pont Docker.
Une étude de cas concrète sur le routage, un sous-réseau Docker peut chevaucher le VPN, aide à isoler cette piste, car elle traite le même problème précis au lieu de simplement définir le protocole sous-jacent.
Déplacez les pools d’adresses Docker à l’écart des plages domestiques et VPN, puis recréez uniquement le réseau concerné.
Recherchez une route Docker inattendue sur l’hôte
Vérifiez quelle interface Linux choisit pour le client VPN et les destinations du sous-réseau de conteneurs.
Un article ciblé sur les réseaux homelab, Docker peut installer une route qui masque un autre sous-réseau, aide à isoler cette piste, car il traite le même problème précis au lieu de simplement définir le protocole sous-jacent.
Une route qui envoie les réponses VPN vers le mauvais pont crée un trafic asymétrique, même si le tableau de bord continue de fonctionner.
Considérez la planification des adresses Docker et VPN comme un seul système
N’attribuez pas les plages Docker indépendamment des plages VPN, VLAN et LAN.
Un guide ciblé sur les réseaux Docker, les conflits d’adresses entre Docker et VPN sont un problème de routage, aide à isoler cette piste, car il traite le même problème précis au lieu de simplement définir le protocole sous-jacent.
Réservez une plage privée documentée pour les ponts de conteneurs et maintenez-la en dehors de tout pool VPN destiné aux utilisateurs distants.
Vérifiez le transfert IP et le NAT sur l’hôte VPN
Un hôte peut accepter les paquets qui lui sont destinés tout en refusant de les transférer vers une autre interface ou un autre pont.
Un guide ciblé de dépannage du routage VPN, les clients VPN ont besoin du transfert et du NAT pour router le trafic plus loin, aide à isoler cette piste, car il traite le même problème précis au lieu de simplement définir le protocole sous-jacent.
Capturez les paquets sur les interfaces VPN et de pont Docker. Si le trafic arrive sur l’une et ne repart jamais par l’autre, corrigez la règle de transfert ou la politique du pare-feu.
Vérifiez le routage WireGuard propre à chaque conteneur
Certaines architectures de serveurs domestiques font passer certains conteneurs par un espace de noms WireGuard, ce qui modifie leur chemin de retour vers les clients distants.
Un article ciblé sur le routage des conteneurs homelab, le routage des conteneurs peut utiliser un chemin WireGuard distinct, aide à isoler cette piste, car il traite le même problème précis au lieu de simplement définir le protocole sous-jacent.
Testez séparément un conteneur utilisant un pont ordinaire et un conteneur routé par VPN afin de ne pas confondre le routage par politique avec une défaillance générale de Docker.
Retestez le chemin exact vers le serveur domestique
Après avoir modifié une variable, répétez le même workflow NAS ou auto-hébergé depuis le même client, au lieu de passer à un autre test susceptible d’emprunter un chemin différent.
Le guide ZimaSpace associé sur le chemin réseau adjacent du serveur domestique aide à maintenir la vérification finale dans le même environnement auto-hébergé.
La correction n’est terminée que lorsque le symptôme d’origine reste résolu après une reconnexion, un redémarrage du service et un second transfert ou une seconde requête contrôlée.
Questions fréquentes
Pourquoi puis-je accéder au tableau de bord du NAS, mais pas à un sous-réseau de conteneurs ?
Le tableau de bord se termine sur l’hôte. Les ponts Docker nécessitent une gestion distincte du routage, du transfert et du chemin de retour.
Dois-je annoncer les sous-réseaux des ponts Docker sur mon VPN ?
Uniquement lorsque les clients distants ont réellement besoin d’un accès direct aux ponts. Les ports publiés par un proxy sont souvent plus simples et plus sûrs.
Le chevauchement des plages Docker et VPN peut-il ne perturber que certaines applications ?
Oui. La sélection des routes par Linux peut envoyer les réponses destinées à une plage vers le mauvais pont, tandis que les autres services de l’hôte restent accessibles.
Assistance et conseils
Plus à lire

Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...

Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...

Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...

