Comment fonctionne le réseau des conteneurs sur Mac
macOS ne peut pas exécuter directement des conteneurs Linux : chaque application de conteneurs sur Mac les exécute donc côté Linux et relaie le trafic entre celui-ci et le Mac. Trois chemins comptent :
- Entrant : un port publié sur le Mac redirige vers un conteneur.
- Sortant : un conteneur ouvre une connexion vers Internet, le réseau de votre entreprise ou un service sur le Mac.
- Noms : un conteneur résout un nom d'hôte.
Lorsque ces chemins contournent le réseau propre au Mac, les routes VPN ne s'appliquent pas, les noms d'hôtes internes ne sont pas résolus et un pare-feu ne peut pas voir quelle application communique. Oxcart est conçu pour éviter cela.
Sortant : votre VPN, votre DNS et votre pare-feu s'appliquent toujours
Oxcart redirige le TCP sortant des conteneurs et des étapes de construction, en IPv4 et IPv6, vers le Mac, qui ouvre la connexion avec ses propres sockets. La table de routage du Mac décide du chemin, y compris les routes installées par votre client VPN. Oxcart ne modifie aucune route du Mac, aucun réglage VPN ni aucune préférence de pare-feu.
La résolution d'adresses (A et AAAA) utilise le résolveur système de macOS, y compris /etc/hosts et la sélection du résolveur configurée par votre VPN. Les noms d'hôtes de l'entreprise sont donc résolus dans les conteneurs comme dans votre navigateur. Les noms des conteneurs restent limités à leurs réseaux Docker, et le DNS fonctionne en UDP et TCP.
Little Snitch, LuLu et agents de protection des postes
Un filtre réseau retient souvent la première connexion d'un nouveau programme pendant environ deux secondes, le temps de vous demander votre accord. Oxcart n'attend pas : les connexions empruntent un chemin de secours jusqu'à validation de la liaison principale ; une connexion lente ou en échec bascule automatiquement sur ce chemin. Trois échecs consécutifs désactivent la liaison pendant 30 secondes avant un nouvel essai. Autorisez Oxcart une fois dans votre filtre, puis ses règles s'appliqueront.
Entrant : les ports publiés
Publiez les ports avec la syntaxe Docker habituelle :
# Mac loopback only (recommended for development)
docker run -d -p 127.0.0.1:8080:80 nginx
# Ephemeral host port, UDP
docker run -d -p 127.0.0.1::9000/udp my-udp-service
# IPv4 and IPv6 listeners on the Mac
docker run -d -p "[::]:8080:80" nginxUne liaison sans adresse écoute sur toutes les adresses IPv4 du Mac, ce qui la rend accessible aux autres machines de votre réseau, sauf si le pare-feu macOS les bloque. TCP et UDP peuvent utiliser le même numéro de port hôte. Les points d'écoute publiés sont libérés lorsque le conteneur s'arrête.
Les ports publiés répondent aussi sur le localhost du moteur : un registre exécuté dans un conteneur fonctionne donc comme destination d'envoi :
docker run -d -p 127.0.0.1:5000:5000 --name registry registry:2
docker tag my-app localhost:5000/my-app
docker push localhost:5000/my-appLa vue Ports : pourquoi un port ne répond pas
La vue Ports d'Oxcart affiche tous les points d'écoute de votre Mac et tous les ports de conteneurs, regroupés par dépôt, worktree et branche, pour distinguer deux copies de travail du même projet. Chaque liaison est ready, pending ou error, avec le motif :
- l'adresse est déjà utilisée sur le Mac ;
- le serveur dans le conteneur écoute uniquement sur
127.0.0.1; - rien n'écoute encore sur ce port.
Les ports accessibles aux autres machines sont signalés. Votre agent de programmation voit les mêmes informations via l'outil MCP ports d'Oxcart ; voir Docker pour les agents de programmation IA.
Atteindre le Mac depuis un conteneur
host.docker.internal est résolu dans les conteneurs et les étapes de construction, et atteint en TCP les services liés à l'adresse 127.0.0.1 du Mac. Dirigez un conteneur vers une base de données ou un serveur de développement exécuté nativement sur le Mac :
docker run --rm curlimages/curl http://host.docker.internal:3000/healthConsidérez cela comme une ouverture volontaire : tout conteneur que vous exécutez peut ainsi atteindre les services sur la boucle locale de votre Mac. Ne laissez donc pas de services d'administration sans authentification sur 127.0.0.1 lorsque vous exécutez des conteneurs auxquels vous ne faites pas confiance.
La liaison chiffrée entre le Mac et le moteur
Le trafic entre le Mac et le côté Linux traverse un réseau virtuel que macOS partage avec d'autres logiciels de virtualisation sur le même Mac. Oxcart transporte le TCP publié et sortant sur cette liaison dans TLS 1.3 (TLS_AES_128_GCM_SHA256), avec épinglage sur un certificat créé à chaque démarrage du moteur et un jeton Bearer de 256 bits par démarrage. Un jeton invalide ferme la connexion, et le côté Linux ferme les connexions qui ne proviennent pas de l'adresse du Mac avant même le début de TLS.
La menace visée : d'autres logiciels sur ce réseau partagé qui usurpent des adresses pour lire ou injecter du trafic, ou ouvrir de nouvelles connexions vers vos conteneurs. Un pare-feu dans le système invité empêche aussi ces logiciels d'atteindre les ports de conteneurs non publiés et le résolveur interne. Le chiffrement a un coût sur cette liaison, et nous l'avons choisi. L'API Docker elle-même ne passe jamais par le réseau : c'est un socket Unix privé, et sans ports publiés, Oxcart ne maintient aucun socket TCP ou UDP sur le Mac.
Limites actuelles
- Le mode réseau hôte (
--network host) et le réseau IPv6 des conteneurs ne sont pas implémentés ; les conteneurs ont des adresses IPv4. host.docker.internaltransporte le TCP ; l'UDP vers la passerelle de l'hôte n'est pas implémenté.- Le TCP et l'UDP publiés ne conservent pas l'adresse du client : le conteneur voit le côté Linux comme correspondant.
- Les enregistrements DNS qui ne sont pas des adresses (comme SRV et TXT) utilisent les résolveurs DHCP du réseau plutôt que le DNS scindé de macOS.
Dépannage
| Symptôme | Cause probable | Solution |
|---|---|---|
Connexion refusée sur localhost:PORT | Le serveur écoute sur 127.0.0.1 dans le conteneur | Écouter sur 0.0.0.0 ; la vue Ports identifie ce cas |
| « port is already allocated » | Un autre processus ou conteneur occupe le port hôte | Choisir un autre port hôte ; la vue Ports montre qui l'occupe |
| Un nom d'hôte interne n'est pas résolu dans un conteneur | Le nom n'existe que dans le DNS de votre VPN | Connecter le VPN sur le Mac ; la résolution d'adresses suit le résolveur du Mac |
| Un conteneur n'atteint pas un serveur de développement sur le Mac | Utilisation de localhost dans le conteneur | Utiliser host.docker.internal |
| Le premier téléchargement se bloque quelques secondes | Un filtre réseau demande votre accord pour une nouvelle connexion | Autoriser Oxcart une fois ; les connexions utilisent le chemin de secours en attendant |
| Vos collègues peuvent accéder à votre port de développement | Publication sans adresse | Publier sur 127.0.0.1 |
Questions
Les conteneurs Docker sur Mac utilisent-ils mon VPN ?
Dans Oxcart, oui. Les connexions sortantes des conteneurs sont ouvertes par le Mac lui-même : les routes du Mac, le VPN, le DNS scindé pour la résolution d'adresses et le pare-feu par application s'y appliquent. Oxcart ne modifie aucune route du Mac, aucun réglage VPN ni aucune préférence de pare-feu.
Comment atteindre un service de mon Mac depuis un conteneur ?
Utilisez host.docker.internal. Dans Oxcart, il atteint en TCP les services liés à l'adresse 127.0.0.1 du Mac, depuis les conteneurs et les étapes de construction. --add-host mac:host-gateway donne un autre nom à la même adresse.
Pourquoi mon conteneur tourne-t-il alors que son port reste inaccessible ?
Le plus souvent, le serveur dans le conteneur écoute sur 127.0.0.1, que les ports publiés ne peuvent pas atteindre ; faites-le écouter sur 0.0.0.0. Les autres causes sont un port hôte déjà utilisé ou l'absence de service à l'écoute. La vue Ports d'Oxcart indique le cas concerné.
Oxcart fonctionne-t-il avec Little Snitch et LuLu ?
Oui. Lorsqu'un filtre réseau retient la première connexion d'Oxcart en attendant votre accord, les connexions empruntent un chemin de secours jusqu'à validation de la liaison : rien ne tombe en panne ni n'attend votre réponse. Une connexion lente ou en échec bascule automatiquement sur le chemin de secours.
Le trafic des conteneurs est-il chiffré sur mon Mac ?
Le TCP publié et sortant entre le Mac et le moteur d'Oxcart passe dans TLS 1.3, avec épinglage sur un certificat créé à chaque démarrage du moteur et un jeton de 256 bits par démarrage. Cela protège cette liaison des autres logiciels de virtualisation sur le réseau partagé de votre Mac. Le trafic vers Internet est protégé par ce que l'application elle-même utilise, par exemple HTTPS.
Mes ports publiés sont-ils visibles par les autres machines de mon réseau ?
Un port publié sans adresse écoute sur toutes les adresses IPv4 du Mac : les autres machines peuvent donc l'atteindre, sauf si le pare-feu macOS les bloque. Publiez sur 127.0.0.1 pour le limiter à votre Mac. Oxcart signale les ports accessibles aux autres machines.
Oxcart prend-il en charge le réseau hôte ou IPv6 pour les conteneurs ?
Non. Le mode réseau hôte et le réseau IPv6 des conteneurs ne sont pas implémentés. Les conteneurs ont des adresses IPv4 ; les ports peuvent néanmoins être publiés sur IPv6 avec "[::]:8080:80".
Sources et méthode
Le comportement réseau décrit ici a été testé sur Oxcart le 10 octobre 2026, notamment le TCP sortant, le DNS, les ports publiés, l'accès à l'hôte et TLS sur la liaison entre le Mac et les conteneurs.