Forum Linux.debian/ubuntu Debian 10 Buster : Problème iptables/nftables avec Docker

Posté par  . Licence CC By‑SA.
Étiquettes :
3
6
août
2019

Bonjour,

Je viens de migrer sous Debian Buster une machine de dev et un serveur Kimsufi.
Du côté de ma machine locale pas de souci, mais côté Kimsufi je rencontre un problème certainement lié à la migration iptables/nftables. Lorsque je lance une stack de containers avec docker-compose j'obtiens l'erreur suivante :

ERROR: Failed to program FILTER chain: iptables failed: iptables --wait -I FORWARD -o br-1f984716e934 -j DOCKER: iptables v1.8.2 (nf_tables):  RULE_INSERT failed (Invalid argument): rule in chain FORWARD
             (exit status 4)

J'ai checké mes versions de docker et docker-compose sont identiques sur les deux machines :

Docker version 19.03.1, build 74b1e89
docker-compose version 1.24.1, build 4667896b

Sur les deux machines iptables pointe bien vers nftables :

$ aptitude search nftables | grep ^i
i A libnftables0 - Netfilter nftables high level userspace API library
i A nftables - Program to control packet filtering rules by Netfilter project

$ update-alternatives --config iptables
Il existe 2 choix pour l'alternative iptables (qui fournit /usr/sbin/iptables).

  Sélection   Chemin                     Priorité  État
------------------------------------------------------------
* 0            /usr/sbin/iptables-nft      20        mode automatique
  1            /usr/sbin/iptables-legacy   10        mode manuel
  2            /usr/sbin/iptables-nft      20        mode manuel

Je précise que j'ai vidé, pour tester, mes anciennes règles iptables sur le serveur et que celui-ci a été rebooté (suite à la migration). J'ai par ailleurs re-installé docker après la migration mais rien n'y fait.

Je ne sais pas si cela peut jouer mais sur le serveur Kimsufi j'utilise un noyau ovh :

$ uname -mr
4.9.185-xxxx-std-ipv6-64 x86_64

sur ma machine locale c'est le noyau par défaut de Debian Buster :

4.19.0-5-amd64 x86_64

Je n'ai pas trouvé de ressources qui pourraient m'aiguiller sur le net, auriez-vous une piste ?

  • # Logs noyau ?

    Posté par  (site web personnel) . Évalué à 1.

    Déjà vu des blagues similaires sur une machine où on essayait de configurer un VPN. Au final, iptables (c'était il y a quelques années déjà) renvoyait des erreurs similaires sur la gestion des routes et du forwarding, mais le problème fondamental était que lancer ces commandes nécessitait de charger des modules noyau. Or cette machine avait un nouveau noyau, n'avait pas encore redémarré dessus, et le chargement de modules échouait.

    Bref, je suggère de vérifier dmesg et assimilés. Quant au noyau OVH, je ne suis pas sûr de comprendre pourquoi il faut se fader ce genre de choses…

    Debian Consultant @ DEBAMAX

    • [^] # Re: Logs noyau ?

      Posté par  . Évalué à 1.

      Merci pour le retour.

      Le serveur Kimsufi avait été rebooté plusieurs fois entre temps, ce qui n'exclut pas l'absence d'un/plusieurs modules noyau sur le kernel ovh.

      Sur le dmesg du serveur Kimsufi, il y a cela que je ne retrouve pas en local :

      Aug  6 18:21:15 XXXXXX dockerd[560]: time="2019-08-06T18:21:15+02:00" level=warning msg="Running modprobe nf_nat failed with message: `modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.9.185-xxxx-std-ipv6-64/modules.dep.bin'\nmodprobe: WARNING: Module nf_nat not found in directory /lib/modules/4.9.185-xxxx-std-ipv6-64`, error: exit status 1"
Aug  6 18:21:15 XXXXXX dockerd[560]: time="2019-08-06T18:21:15+02:00" level=warning msg="Running modprobe xt_conntrack failed with message: `modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.9.185-xxxx-std-ipv6-64/modules.dep.bin'\nmodprobe: WARNING: Module xt_conntrack not found in directory /lib/modules/4.9.185-xxxx-std-ipv6-64`, error: exit status 1"

      Toutefois je ne maîtrise pas assez Netfilter et ce que Docker fait avec Netfilter pour être certain que cela soit le souci.

      Par ailleurs, sur le serveur, j'ai désactivé Nftables au démarrage, je l'ai stoppé, vidé toutes les règles (nftables flush rules), basculé en iptables-legacy.
      Puis, après un reboot dans le doute, mes stacks dockers se lancent correctement.

      Mais si je reviens en nftables, c'est mort ! (j'ai testé avec toutes les règles vidées sauf celles montées par dockerd).

      Suis un peu perdu….

      • [^] # Re: Logs noyau ?

        Posté par  (site web personnel) . Évalué à 1.

        Ça ressemble beaucoup à ce que j'évoquais… Il semblerait qu'il n'y ait pas de nf_nat.ko et xt_conntrack.ko chargeable pour ton noyau, du coup paf ?

        Debian Consultant @ DEBAMAX

  • # Même cas ici

    Posté par  . Évalué à 1.

    Je suis dans le même cas que vous avec un upgrade vers Buster, J'ai redémarré les containers des milliers de fois. Jusqu'à effacer les networks docker externe et interne et au moment de recréer un network interne à une stack j'ai eu ce joli message d'IPTable. Auparavant même les perfs docker s'écroulaient dans le temps.

    Je regrette un peu d'avoir upgradé le serveur de prod vers Buster.

    • [^] # Re: Même cas ici

      Posté par  . Évalué à 1.

      Bonjour,

      si je me souviens bien, le noyau OVH de base n'utilise pas les modules.

      Mais vous avez la possibilité d'installer un noyau "standard" qui lui les gère.

      C'est ce que j'avais fait pour installer docker sur mon serveur kimsufi.

      Eric

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.