Vérifiez si ce qui suit peut vous aider.
Ceci est très probablement un conflit classique entre le moteur de réseau de Docker et le pare-feu de YunoHost (AFW) sur Debian 12.
La cause profonde est que YunoHost gère le pare-feu à l’aide de nftables (et précédemment iptables), et lorsqu’il recharge ou applique des règles, il vide souvent les chaînes iptables. Docker crée ses propres chaînes personnalisées (comme la chaîne DOCKER) pour gérer le routage des conteneurs. Lorsque YunoHost les vide, Docker essaie d’ajouter des règles à une chaîne qui n’existe plus, ce qui entraîne l’erreur : iptables: No chain/target/match by that name.
Parce que les règles de réseau sont cassées, votre conteneur evolution_api ne peut pas « voir » le conteneur redis, même s’ils se trouvent dans le même fichier compose. Cela conduit à l’inondation redis disconnected.
Voici la solution étape par étape pour corriger les deux problèmes.
1. Corriger la Configuration (Evolution API)
L’Evolution API attend une URI de connexion, et non des variables Host et Port séparées. Vous utilisez CACHE_REDIS_HOST, que l’API ignore probablement au profit de CACHE_REDIS_URI.
Mettez à jour la section environnement de votre docker-compose.yml : Supprimez CACHE_REDIS_HOST et CACHE_REDIS_PORT et remplacez-les par CACHE_REDIS_URI.
# Changez ceci :
- CACHE_REDIS_ENABLED=true
- CACHE_REDIS_HOST=redis
- CACHE_REDIS_PORT=6379
# En ceci :
- CACHE_REDIS_ENABLED=true
- CACHE_REDIS_URI=redis://redis:6379
(Remarque : Si vous utilisez un mot de passe pour Redis, le format est redis://:password@redis:6379).
2. Résoudre le conflit iptables / YunoHost
Pour corriger l’erreur Unable to enable ACCEPT OUTGOING rule et restaurer la connectivité entre les conteneurs, vous devez vous assurer que Docker recréé ses chaînes de réseau après que YunoHost a initialisé le pare-feu.
Le correctif immédiat (manuel)
Exécutez ces commandes dans l’ordre pour effacer le conflit et forcer Docker à reconstruire ses règles :
# 1. Rechargez d'abord le pare-feu YunoHost
yunohost firewall reload
# 2. Redémarrez le daemon Docker pour le forcer à réinjecter ses chaînes dans iptables
sudo systemctl restart docker
# 3. Relancez votre stack
docker compose up -d
Le correctif permanent (automatisation)
Comme YunoHost peut recharger le pare-feu lors des mises à jour ou via l’interface Web, les règles de Docker s’effondreront à nouveau. Pour éviter cela, vous pouvez créer un simple override systemd pour vous assurer que Docker redémarre chaque fois que le pare-feu change, ou plus simplement, ajouter un cron job/hook.
Cependant, la façon la plus stable sur YunoHost est de s’assurer que Docker est la dernière chose à démarrer. Si vous trouvez que cela se produit fréquemment après un redémarrage, exécutez :
sudo systemctl enable docker
Et si vous rechargez manuellement le pare-feu, suivez toujours avec sudo systemctl restart docker.
Réponses à vos questions spécifiques :
1. Le Redis natif de YunoHost ou la gestion d’iptables est-elle connue pour causer des conflits ?
Oui. La gestion du pare-feu de YunoHost est agressive. Elle ne « connaît » pas les chaînes iptables personnalisées de Docker. Lorsque YunoHost recharge ses règles, elle efface la chaîne DOCKER. C’est pourquoi vous voyez l’erreur « No chain/target/match »—Docker essaie de communiquer avec une chaîne que YunoHost vient de supprimer.
2. Comment puis-je m’assurer que le conteneur Docker contourne le pare-feu de YunoHost ?
La communication inter-conteneurs (Evolution API →→ Redis) se produit sur le Docker Bridge Network via la chaîne FORWARD. Le pare-feu de YunoHost gère principalement la chaîne INPUT (le trafic provenant du monde extérieur). Les conteneurs n’ont pas besoin de « contourner » le pare-feu ; ils ont juste besoin que les règles gérées par Docker existent. Redémarrer le daemon Docker après que le pare-feu soit actif est le seul moyen de restaurer ces règles.
3. Y a-t-il des règles de chaîne DOCKER-USER spécifiques que je devrais injecter ?
Non. La chaîne DOCKER-USER est pour vos règles personnalisées (par exemple, bloquer une adresse IP spécifique de frapper votre API). L’erreur que vous voyez n’est pas à propos d’une règle de sécurité manquante, mais d’une chaîne d’infrastructure manquante. Injecter des règles dans DOCKER-USER ne corrigera pas l’échec ACCEPT OUTGOING car cet échec se produit dans le processus de configuration de base de Docker.
