Tailscale est-il sécurisé ? Modèle de confiance

Tailscale est-il sécurisé ? Réponse courte

Tailscale est-il sécurisé ? Pour le point qui inquiète le plus souvent, oui : le serveur de coordination qui gère votre tailnet ne détient jamais les clés privées utilisées pour chiffrer votre trafic. Il ne peut donc pas lire les données que vos appareils s’échangent. La page de sécurité de Tailscale l’indique clairement : « Les clés privées ne quittent jamais l’appareil. Tout le trafic est chiffré de bout en bout, en permanence. » La question utile est différente. Un serveur de coordination compromis ou soumis à une décision de justice n’a pas besoin de lire vos paquets. Il détermine quelles clés publiques vos appareils approuvent. Il pourrait donc inscrire un appareil que vous n’avez jamais autorisé.

C’est le modèle de confiance en une phrase : le chiffrement protège les données et le plan de contrôle détermine les membres. Chaque section ci-dessous présente une partie à laquelle vous devez faire confiance, précise ce qu’elle peut réellement faire et indique le contrôle qui en limite les capacités. Si le produit vous est encore inconnu, commencez par ce qu’est Tailscale et le fonctionnement de son réseau maillé.

Le plan de contrôle et le plan de données sont distincts

Tailscale est un VPN maillé (réseau privé virtuel) basé sur WireGuard, le même protocole que vous configureriez manuellement sur un VPS WireGuard auto-hébergé. Chaque appareil génère localement sa propre paire de clés WireGuard. L’article comment cela fonctionne de Tailscale décrit le serveur de coordination comme « une boîte de dépôt partagée pour les clés publiques » et précise que « la clé privée ne quitte jamais, au grand jamais, son nœud ».

Le plan de données correspond au trafic chiffré entre vos appareils. Il circule directement d’un appareil à l’autre chaque fois que le réseau le permet. Le plan de contrôle regroupe tout le reste : les appareils qui appartiennent au tailnet, la clé publique associée à chaque appareil, la stratégie d’accès, les paramètres DNS et la liste des relais. Tailscale fournit le plan de contrôle sous la forme d’un service hébergé. Vous exécutez le plan de données sur vos propres machines.

En séparant ces deux plans, vous pouvez répondre à toutes les questions de sécurité abordées ici. Le chiffrement est une propriété du plan de données. L’appartenance au réseau est une décision du plan de contrôle. Aucun chiffrement ne permet à lui seul de déterminer qui est autorisé à être un pair.

Que pourrait faire un serveur de coordination compromis ?

Il ne pourrait pas déchiffrer votre trafic. Les clés qui assurent le chiffrement sont générées sur vos appareils et ne sont jamais téléversées. Il n’y a donc aucune clé à saisir ou à divulguer pour ouvrir le tunnel. Cela vaut également pour le trafic relayé, traité plus loin.

Il pourrait inscrire un nœud. Lorsque Tailscale a annoncé tailnet lock, l’entreprise a décrit le risque en ces termes : un serveur malveillant pourrait « utiliser un nœud ajouté secrètement pour envoyer ou recevoir du trafic vers vos nœuds existants », et à ce stade « le chiffrement du trafic n’aurait plus d’importance, car le pair lui-même serait malveillant ». Votre appareil fait confiance à un pair parce que le control plane lui a indiqué que cette clé appartient au tailnet.

Il pourrait modifier les ressources que vos appareils sont autorisés à atteindre. La politique d’accès est stockée dans le control plane, puis distribuée aux nœuds. Le livre blanc sur tailnet lock de Tailscale indique que tailnet lock « n’empêche pas un control plane compromis de rompre la connectivité dans votre réseau, par exemple en ne distribuant pas les clés de nouveaux nœuds ou en distribuant une politique de contrôle d’accès qui refuse l’accès à tous les nœuds ».

Il voit dans tous les cas les métadonnées des connexions. Les journaux de flux réseau de Tailscale enregistrent les événements d’ouverture et de fermeture de chaque connexion entre machines. La documentation précise que ces journaux « ne contiennent strictement aucune information sur les opérations effectuées par les clients ni sur le contenu du trafic réseau ». Le control plane peut donc savoir quels appareils ont communiqué entre eux et à quel moment. Il ne sait pas ce qu’ils se sont dit.

Un seul élément de cette liste concerne le chiffrement. Les autres concernent les membres du tailnet et le contenu de la politique. C’est pourquoi les contrôles auxquels vous devez prêter attention sont ceux qui régissent l’inscription des nœuds.

Votre fournisseur d’identité est la racine de confiance de votre tailnet

Tailscale ne gère aucune base de mots de passe qui lui soit propre. Sa documentation indique clairement qu’il n’existe pas de mots de passe Tailscale et que l’authentification est déléguée à un fournisseur d’identité (IdP) : Apple, Google, GitHub, Microsoft, Okta, OneLogin ou un fournisseur OpenID Connect personnalisé.

Considérez cela comme une question de sécurité, car c’en est une. Toute personne capable de se connecter à votre compte Google ou Microsoft peut se connecter à votre tailnet. Votre authentification multifacteur (MFA) dépend des règles appliquées par l’IdP. Votre procédure de départ d’un utilisateur dépend de ce que fait l’IdP lorsqu’une personne quitte l’organisation. Un compte IdP hameçonné donne accès au tailnet, et l’attaquant n’a jamais besoin d’attaquer WireGuard : il ajoute un appareil et bénéficie des autorisations accordées à cet utilisateur par votre policy.

Deux contrôles séparent un compte d’identité volé d’un appareil fonctionnel dans votre tailnet : l’approbation des appareils et l’expiration des clés. Tailnet lock constitue un troisième contrôle ; il cible le control plane plutôt que le compte.

Approbation des appareils : rien ne se connecte sans validation humaine

La documentation de Tailscale décrit l’approbation des appareils comme une fonctionnalité qui « permet aux administrateurs du réseau Tailscale d’examiner et d’approuver les nouveaux appareils avant qu’ils puissent rejoindre votre réseau Tailscale ». Un Owner, un Admin ou un IT admin peut approuver un appareil. Un nouvel appareil affiche le badge « Needs approval » dans la page Machines jusqu’à ce qu’une personne intervienne.

Activez cette fonctionnalité et le scénario du compte compromis change. L’attaquant se connecte, l’appareil s’enregistre, puis reste bloqué et ne peut rien atteindre. Dans votre console d’administration, un badge vous indique qu’une machine que vous ne reconnaissez pas demande à rejoindre le réseau. L’automatisation continue de fonctionner, car une auth key peut être marquée comme préapprouvée lors de sa génération, et les appareils peuvent être approuvés via l’API.

Les auth keys constituent l’autre moyen d’accès. Traitez-les donc comme des identifiants. La documentation de Tailscale est claire sur les clés à risque : « Soyez très prudent avec les clés réutilisables ! Elles peuvent être très dangereuses si elles sont volées. Il est préférable de les conserver dans un produit de coffre-fort de clés spécialement conçu à cet effet. » En août 2026, la plage d’expiration documentée des clés est de 1 à 90 jours. Si aucune expiration n’est indiquée, la valeur par défaut est la durée maximale de 90 jours. Préférez les clés à usage unique, marquez-les comme éphémères pour les machines temporaires, et conservez toute clé réutilisable chiffrée avec Ansible Vault ou dans un secrets manager plutôt que dans un shell script.

Expiration des clés : le délai qui limite toutes les autres erreurs

Les clés des nœuds expirent. Un appareil volé ou oublié devient ainsi un problème temporaire. La documentation de Tailscale indique que « par défaut, les nouveaux domaines sont configurés avec une période d’expiration de 180 jours » et que « si la réauthentification n’a pas lieu, les clés expirent et les connexions vers et depuis le point de terminaison concerné cessent de fonctionner ». Vous pouvez réauthentifier vous-même un appareil :

tailscale up --force-reauth

La documentation avertit que cela « peut interrompre la connexion au tailnet et ne doit donc pas être effectué à distance via SSH ou RDP sans autre moyen de se connecter si la connexion est perdue ». Exécutez cette commande avec un accès à la console ouvert, ou depuis un second chemin d’accès à la machine, car vous êtes sur le point d’interrompre le réseau que vous utilisez.

C’est sur les serveurs que ce contrôle est souvent désactivé. Une machine qui doit se réauthentifier tous les 180 jours quittera le tailnet à 3 h du matin, sans personne pour le constater. Les administrateurs désactivent donc l’expiration des clés sur cette machine. Ils suppriment ainsi le délai qui finirait par invalider une clé volée. Pour un serveur, un appareil associé à un tag est une meilleure solution : le tag appartient à la machine et non à une personne. La machine reste donc fonctionnelle lorsque cette personne quitte l’entreprise. Quelle que soit votre décision, tenez une liste des machines pour lesquelles l’expiration est désactivée : leurs clés restent valides jusqu’à la suppression de l’appareil.

Tailnet lock : retirer le serveur de coordination de la chaîne de confiance

Tailnet lock s’attaque directement au problème de l’enrôlement. La documentation de Tailnet lock de Tailscale explique le mécanisme : « Lorsqu’un nouveau nœud rejoint le tailnet, sa clé publique de nœud doit recevoir une signature d’une clé Tailnet Lock. Le serveur de coordination distribue la clé publique signée du nœud aux nœuds pairs. » Vos appareils existants vérifient cette signature avant d’accepter un pair. Une clé de nœud que le control plane aurait créée seul est donc refusée.

tailscale lock status
tailscale lock sign nodekey:1abddef1 tlpub:abcdef12

tailscale lock init active la fonctionnalité, et vous désignez vos nœuds signataires à ce moment-là. Tailscale exige au moins 2 nœuds signataires lors de l’initialisation et en autorise au maximum 20 dans un tailnet. Ensuite, chaque nouvel appareil doit recevoir une signature de l’un d’eux. Cela représente un coût opérationnel réel : ajouter un téléphone signifie exécuter une commande sur un ordinateur portable.

Les limites sont documentées et comptent davantage que la description de la fonctionnalité :

• Si vous perdez le secret de désactivation, il n’existe aucune récupération possible. La documentation indique : « Si vous perdez vos secrets de désactivation et que vous n’en avez pas fourni un au support Tailscale, le tailnet ne peut pas être récupéré. »
• La clé de signature se trouve sur un appareil que vous possédez. Elle hérite donc du niveau de sécurité de cet appareil. La documentation est explicite : « Si l’appareil est compromis, la clé peut être récupérée. »
• Vous ne pouvez pas utiliser les 2 contrôles simultanément. Tailscale indique que Tailnet lock et l’approbation des appareils sont mutuellement exclusifs. Activer l’un revient donc à renoncer à l’autre.
• Il s’agit d’un modèle de confiance au premier usage (TOFU). La configuration initiale passe toujours par le control plane, et l’ancre de confiance ne se déplace dans votre propre réseau qu’après cette première étape.

Tailnet lock protège l’appartenance au tailnet. Il ne protège pas la disponibilité, et le livre blanc le précise.

Une connexion relayée expose-t-elle mon trafic ?

Non. Lorsque deux appareils ne peuvent pas communiquer directement, le trafic passe par un serveur DERP (Designated Encrypted Relay for Packets). La documentation de Tailscale l’affirme clairement : « Comme les clés privées Tailscale ne quittent jamais l’appareil local qui les a générées, un serveur DERP ne peut pas déchiffrer votre trafic. Un serveur DERP retransmet sans les inspecter les données déjà chiffrées d’un appareil à un autre. »

Un relais réduit toutefois le débit et observe les métadonnées : deux points d’extrémité chiffrés, ainsi que le moment et le volume des données échangées. Vérifiez le type de connexion utilisé :

tailscale status
tailscale netcheck

tailscale status indique pour chaque peer s’il est en connexion directe, affiché comme direct 203.0.113.10:41641, ou relayé, affiché comme relay suivi du nom du relay, avec les compteurs d’octets à la suite. Lorsqu’un peer reste sur un relay, cela signifie que les deux extrémités n’ont pas pu établir de chemin direct, généralement parce que l’UDP est bloqué quelque part ou parce que les deux côtés se trouvent derrière un NAT strict (network address translation). tailscale netcheck indique si l’UDP fonctionne depuis cette machine, comment le NAT mappe les ports et quelle est la latence vers les relais les plus proches. Ces informations permettent de déterminer laquelle de ces deux causes est en jeu. Si un peer est déjà en connexion directe mais que le débit reste décevant, le relay n’est pas en cause : un MTU de chemin incohérent est généralement à l’origine d’un WireGuard lent.

Un nœud de sortie déplace votre trafic sortant, mais ne le supprime pas

Un nœud de sortie achemine tout le trafic Internet public d’un appareil via un autre appareil du tailnet, en utilisant les routes par défaut 0.0.0.0/0 et ::/0. Sous Linux, la machine qui fournit ce service l’annonce, puis chaque client choisit de l’utiliser :

sudo tailscale set --advertise-exit-node
sudo tailscale set --exit-node=100.101.102.103
sudo tailscale set --exit-node=100.101.102.103 --exit-node-allow-lan-access=true
sudo tailscale set --exit-node=

Un nœud de sortie doit être approuvé par un Owner, un Admin ou un Network admin dans la console d’administration. Votre policy doit également accorder autogroup:internet avant qu’un client puisse l’utiliser. Ces deux étapes sont intentionnelles : une machine non approuvée ne peut pas devenir discrètement la sortie de l’ensemble de votre tailnet. La même validation s’applique aux routes de sous-réseau. Une machine qui annonce une plage privée reste inactive jusqu’à ce qu’un administrateur l’accepte. C’est le premier obstacle pour annoncer un réseau privé à votre tailnet depuis un VPS.

Examinons maintenant la question de la confiance. Le trafic est chiffré entre votre ordinateur portable et le nœud de sortie. Il quitte ensuite cette machine sous la forme d’un trafic Internet ordinaire, avec l’adresse IP de cette machine. L’opérateur du nœud de sortie voit donc vos destinations, tout comme l’hébergeur de cette machine et son réseau en amont. Vous avez déplacé le point d’observation, vous ne l’avez pas supprimé. C’est un compromis acceptable lorsque vous contrôlez l’extrémité distante, ce qui justifie l’exécution de votre propre nœud de sortie sur un VPS, mais pas lorsque ce n’est pas le cas.

La stratégie par défaut est un réseau plat

Un tailnet est livré avec une configuration permissive. La documentation du contrôle d’accès de Tailscale indique que le fichier de stratégie par défaut « autorise les communications entre tous les appareils du tailnet ». Chaque appareil peut atteindre tous les autres appareils sur tous les ports. Il s’agit d’un réseau plat. Vous l’avez déplacé dans le tunnel, ce qui protège contre les connexions externes, mais ne change rien si un ordinateur portable est infecté.

Renforcez la configuration dans le fichier de stratégie du tailnet. Celui-ci accepte les listes de contrôle d’accès (ACL) ou les grants, plus récents. Les deux utilisent un dialecte JSON qui autorise les commentaires :

{
  "acls": [
    {"action": "accept", "src": ["group:eng"], "dst": ["tag:prod:22"]},
    {"action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:internet:*"]}
  ]
}

Cette stratégie permet à un groupe d’accéder au service SSH des serveurs de production, autorise les membres à utiliser un exit node et refuse tout le reste par omission. Tailscale indique quelles cibles de règles sont disponibles selon le forfait. Vérifiez donc ce point avant de concevoir votre configuration autour des tags ou des autogroups, et consultez ce que le forfait gratuit inclut réellement. Pour un appareil qui ne doit jamais accepter de connexions entrantes, comme un téléphone personnel, tailscale set --shields-up les bloque côté client.

Ce que change l’auto-hébergement du control plane avec Headscale

Headscale est « une implémentation open source et auto-hébergée du serveur de contrôle Tailscale ». Son README définit honnêtement son périmètre : « Il couvre un périmètre limité, un seul réseau Tailscale (tailnet), adapté à un usage personnel ou à une petite organisation open source. » Sa liste de fonctionnalités comprend les ACL et les grants, les subnet routers, les exit nodes, un serveur DERP intégré, Tailscale SSH et Taildrop. Si ce périmètre limité pose problème, NetBird est l’autre mesh qui fournit un control plane auto-hébergeable, et exécuter le serveur NetBird sur votre propre VPS déplace cette même décision d’enrôlement vers du matériel que vous contrôlez.

Ce qui change, c’est l’identité de la partie qui pourrait enrôler un nœud compromis. Avec Headscale, le répertoire des clés et la policy résident sur votre serveur. Aucun tiers ne détient la liste des clés publiques de vos appareils. Aucun tiers ne peut être contraint d’en transmettre une ou d’en signer une.

Ce qui ne change pas, c’est le data plane. Vous utilisez le même WireGuard, avec le même chiffrement de bout en bout et le même relais de secours lorsqu’un chemin direct est impossible. Vous récupérez également les tâches que Tailscale prenait en charge : surveillance de la disponibilité, application des correctifs, sauvegardes et sécurité physique de la machine. Si cette machine est un VPS loué, ce dernier point repose sur l’engagement d’un tiers et non sur votre contrôle, car l’hyperviseur peut lire la mémoire de votre guest et, par conséquent, le répertoire contenant les clés, sauf si le matériel prend en charge une mémoire chiffrée dont vous pouvez attester l’intégrité. Un hôte Headscale compromis donne à un attaquant exactement les mêmes possibilités qu’un serveur de coordination compromis : inscrire un nœud et distribuer la stratégie. Tailnet lock ne figure pas dans la liste des fonctionnalités de Headscale. Le contrôle compensatoire correspondant à ce risque précis n’est donc pas disponible. Le coût pousse certains tailnets dans la même direction, car Tailscale facture par utilisateur et non par appareil et le calcul change dès qu’une petite équipe dépasse le forfait gratuit. Si la question de la propriété est celle qui décide pour vous, l’auto-hébergement du control plane avec Headscale décrit la procédure de configuration.

Ce que Tailscale protège contre

• Les ports en écoute publics. Un service lié à une adresse du tailnet n’est pas accessible depuis Internet. Les scanners qui testent tous les VPS sur le port 22 ne le voient donc jamais. L’exception est activée volontairement, car Funnel publie délibérément un service du tailnet sur Internet. Il est donc utile de savoir où s’arrête serve et où commence funnel avant d’exécuter l’une ou l’autre commande. Conservez tout de même le pare-feu de l’hôte : un port Docker publié ajoute ses propres règles et contourne ufw sur l’interface publique.
• Les tentatives de deviner les mots de passe des accès exposés. Il n’y a rien à attaquer lorsque le port ne répond qu’à l’intérieur du tunnel. C’est une meilleure protection que la limitation du débit sur un port ouvert. Toutefois, fail2ban sur Ubuntu 24.04 reste utile pour tout service qui doit rester public.
• Les réseaux non fiables sur le chemin. Le trafic entre vos machines est chiffré de bout en bout, qu’il passe par le réseau d’un café ou par le LAN partagé d’un fournisseur. Il reste chiffré lorsqu’il est relayé.
• La distribution manuelle des clés. Chaque pair ajouté manuellement dans une configuration WireGuard peut entraîner la réutilisation d’une adresse ou l’insertion de la mauvaise clé. Le maillage gère ces informations pour vous. C’est l’essentiel de la différence pratique dans WireGuard contre Tailscale.

Ce que Tailscale ne protège pas

• Un endpoint compromis. Le tailnet fait confiance aux appareils. Un malware présent sur un portable approuvé obtient le tunnel, les adresses du tailnet et les accès accordés à cet utilisateur par votre policy. C’est la principale faille, et aucun VPN ne peut la supprimer.
• Un administrateur malveillant ou négligent. Toute personne pouvant modifier le fichier de policy peut s’accorder l’accès à n’importe quelle ressource. Toute personne prenant le contrôle du compte d’identité d’un Owner peut faire de même. Examinez les modifications de policy comme vous examinez du code.
• L’analyse du trafic. Votre FAI (fournisseur d’accès à Internet) voit des paquets UDP chiffrés circuler vers un endpoint, ainsi que leur fréquence et leur volume. Les flow logs de Tailscale indiquent quels pairs ont communiqué et à quel moment. Aucun des deux ne voit le contenu, mais l’existence de la connexion n’est pas masquée. Consultez donc les différences entre Tor et un VPN avant de choisir un outil pour cette tâche.
• Un appareil que vous avez déjà perdu. L’expiration de la key constitue une protection de dernier recours lente, avec une valeur par défaut de 180 jours. La suppression de l’appareil dans la console d’administration est la méthode rapide. Repérez donc ce bouton avant d’en avoir besoin.

Vérifiez votre propre tailnet

1. Exécutez tailscale status sur un appareil et consultez la liste des pairs. Une machine que vous ne pouvez pas identifier correspond exactement à la situation que l’approbation des appareils est censée empêcher.
2. Exécutez tailscale lock status pour vérifier si le verrouillage du tailnet est activé, puis déterminez si la signature de chaque nouvel appareil justifie son coût pour votre tailnet.
3. Ouvrez la console d’administration et notez chaque machine pour laquelle l’expiration de la clé est désactivée, ainsi que chaque clé d’authentification réutilisable qui existe encore. Dans les deux cas, il s’agit d’identifiants sans délai d’expiration.
4. Lisez votre fichier de stratégie. S’il s’agit toujours de la configuration par défaut, chaque appareil peut atteindre tous les autres appareils sur tous les ports, et un ordinateur portable infecté peut tous les atteindre.

Tailscale doit sa réputation au plan de données, où la conception ne laisse à l’opérateur aucun moyen de lire votre trafic. Retenez cette promesse telle que le fournisseur la documente, puis auditez les éléments qui relèvent de votre configuration : les comptes d’identité, le paramètre d’approbation, la liste des expirations et le fichier de stratégie. La page consacrée à la sécurité de Tailscale mentionne une certification SOC 2 Type II et des travaux de sécurité continus avec Latacora. Cela renseigne sur leur processus, et non sur votre configuration.

FAQ

Tailscale peut-il lire mon trafic ?

Non. Le trafic est chiffré avec des clés WireGuard générées sur vos appareils. La page de sécurité de Tailscale précise que « les clés privées ne quittent jamais l’appareil. Tout le trafic est toujours chiffré de bout en bout. » Cela s’applique aussi aux connexions qui passent par un relais DERP, car le relais « transmet aveuglément le trafic déjà chiffré d’un appareil à un autre » et ne détient aucune clé permettant de le déchiffrer. L’infrastructure de Tailscale voit uniquement des métadonnées : les appareils qui existent, ainsi que les appareils qui se sont connectés entre eux et à quel moment.

Que pourrait réellement faire un serveur de coordination Tailscale compromis ?

Il pourrait inscrire un nœud. L’annonce officielle de Tailscale sur le tailnet lock décrit le risque lié à l’ajout secret d’un nœud qui pourrait « envoyer ou recevoir du trafic vers vos nœuds existants ». Le chiffrement ne suffirait pas, « car le pair lui-même serait malveillant ». Un plan de contrôle compromis pourrait aussi distribuer une policy qui modifierait les ressources accessibles depuis vos appareils. Le livre blanc sur le tailnet lock précise également qu’il pourrait interrompre la connectivité en ne distribuant pas les nouvelles clés de nœud. En revanche, il ne pourrait pas déchiffrer le trafic entre vos appareils existants, car il n’a jamais détenu leurs clés privées.

Un exit node masque-t-il ma navigation à mon FAI ?

Il masque les destinations au réseau auquel vous êtes connecté, y compris le FAI de votre domicile ou du café. Tout le trafic quitte votre appareil sous forme chiffrée, à destination de l’exit node. Cela ne vous rend pas anonyme. L’exit node voit ces destinations, tout comme son hébergeur et le réseau en amont. Les sites que vous consultez voient l’adresse IP de l’exit node. Vous choisissez donc un autre observateur : choisissez-en un auquel vous faites réellement confiance.

Headscale est-il plus sécurisé que le serveur de coordination de Tailscale ?

Il s’agit d’un choix de confiance différent, pas nécessairement d’une solution plus sûre. Avec Headscale, vous contrôlez l’annuaire des clés et la policy. Aucun tiers ne peut donc être contraint d’inscrire un appareil dans votre tailnet. En contrepartie, vous devez administrer ce serveur : appliquer les correctifs, assurer sa disponibilité, effectuer les sauvegardes et protéger l’hôte lui-même. Un hôte Headscale compromis donnerait à un attaquant le même pouvoir d’inscription qu’un serveur de coordination compromis. De plus, le tailnet lock ne figure pas dans la liste des fonctionnalités de Headscale. Protégez donc cet hôte en conséquence.

Ai-je toujours besoin d’un pare-feu sur un VPS qui se trouve dans mon tailnet ?

Oui. L’interface réseau publique existe toujours. Tout service lié à 0.0.0.0 reste donc accessible depuis Internet, que Tailscale soit exécuté ou non. Liez les services à l’adresse du tailnet, conservez une policy de refus par défaut sur l’interface publique et vérifiez les ports publiés de vos conteneurs. Docker ajoute ses propres règles et peut exposer un port que vous pensiez fermé.