Ne désactivez pas IPv6 simplement parce que ss indique qu’un service CasaOS ou Docker écoute sur :::80. Sous Linux, un socket IPv6 générique peut également accepter IPv4 selon ses paramètres, et Docker publie normalement les ports en IPv4 lorsqu’aucune adresse hôte n’est spécifiée.
Le cas d’origine concernait CasaOS sur Debian 12 dans GCP, et non ZimaOS. Le bon diagnostic consiste à tester explicitement IPv4, à examiner la passerelle CasaOS et les liaisons de ports Docker, puis à vérifier le pare-feu cloud avant de modifier GRUB ou de désactiver IPv6 globalement.
Tester d’abord IPv4 directement
curl -4 -v http://127.0.0.1:80/
curl -4 -v http://SERVER_IPV4:80/
ss -ltnp | grep ':80'
Si IPv4 fonctionne localement mais échoue à distance, le problème vient probablement du pare-feu de l’hôte ou du cloud, ou du routage, plutôt que de la liaison CasaOS.
La publication des ports Docker inclut normalement IPv4
Le guide actuel de publication des ports Docker indique que les ports publiés sont normalement accessibles via les mappages d’adresses de l’hôte ; un comportement explicitement limité à IPv6 nécessite une configuration différente.
Vérifier CasaOS lui-même
systemctl status casaos
journalctl -u casaos --no-pager -n 100
ss -ltnp | grep -E ':80|casaos'
L’installateur actuel de CasaOS recense toujours les adresses des interfaces réseau IPv4 lorsqu’il affiche l’URL du tableau de bord ; une installation fonctionnelle n’est donc pas conçue pour nécessiter un accès limité à IPv6.
Vérifier le pare-feu GCP
Vérifiez que la machine virtuelle possède une adresse IPv4, une route et une règle d’entrée pour le port web CasaOS choisi. Un pare-feu cloud peut bloquer le port 80 même lorsque le service écoute correctement.
Ne désactivez pas IPv6 globalement comme première solution
D’anciens composants de CasaOS ont historiquement attendu que /proc/net/tcp6 existe, et la désactivation d’IPv6 a causé des problèmes de gestion des applications dans certaines versions. Supprimer IPv6 peut créer un second problème sans résoudre le premier.
Si vous avez besoin d’une liaison Docker limitée à IPv4
ports:
- "0.0.0.0:8080:80"
Utilisez une liaison IPv4 explicite uniquement lorsque vous contrôlez cette définition Compose et que vous comprenez les implications en matière d’exposition.
Vérifier le port web CasaOS
L’installateur peut choisir un autre port disponible si le port 80 est déjà occupé. Confirmez le port HTTP réellement utilisé par CasaOS avant de conclure que le service a échoué.
Le guide de mise en réseau Docker présente les mêmes principes fondamentaux de réseau.
Vérifier sysctl uniquement après avoir testé la connectivité réelle
Si vous soupçonnez toujours un comportement lié aux sockets double pile, examinez sysctl net.ipv6.bindv6only. La valeur 0 permet à de nombreux sockets IPv6 génériques d’accepter des connexions IPv4 mappées ; la valeur 1 les limite à IPv6. Ne modifiez pas ce paramètre à l’échelle du système sans comprendre quels services seront affectés.
Vérifier les adresses réellement publiées par Docker
docker ps --format 'table {{.Names}} {{.Ports}}'
docker inspect CONTAINER --format '{{json .NetworkSettings.Ports}}'
Cela indique si Docker a créé un mappage IPv4 tel que 0.0.0.0:PORT, un mappage IPv6 ou les deux. Cette méthode est plus fiable que de déduire le comportement à partir d’une seule ligne de liste des processus.
Garder à l’esprit que GCP possède deux couches de pare-feu
Un hôte Debian peut avoir ses propres règles nftables/iptables, tandis que GCP contrôle séparément les accès entrants du pare-feu VPC. Un service peut fonctionner correctement localement tout en restant inaccessible de l’extérieur parce que l’une ou l’autre couche bloque le port.
FAQ
:::80 signifie-t-il toujours « IPv6 uniquement » ?
Non. Vérifiez avec curl -4 avant de tirer cette conclusion.
Dois-je désactiver IPv6 dans GRUB ?
Pas comme première étape de dépannage. Cela peut interrompre des composants qui attendent des interfaces réseau IPv6 du noyau.
Pourquoi localhost fonctionne-t-il alors que l’IPv4 publique ne fonctionne pas ?
Vérifiez le pare-feu cloud, le groupe de sécurité, la route et le pare-feu de l’hôte.
S’agit-il d’un problème lié à ZimaOS ?
La discussion d’origine concerne CasaOS installé sur Debian 12, et non ZimaOS.
