Docker & Shorewall

J'utilise Shorewall sur mon serveur comme un simple pare - feu autonome et je voudrais également utiliser Docker .

En utilisant un conteneur Docker et son docker de redirection de port, il installe ses propres règles / chaînes iptables qui seront supprimées si shorewall est redémarré. Le conteneur deviendra donc inaccessible .

Quelqu'un a-t-il réussi à enregistrer / restaurer les règles du docker lors d'un redémarrage du mur de quai ou quelqu'un a-t-il une autre solution?

Voir également:

• Liste de diffusion Shorewall avec une question similaire
• GitHub Issue # 2801 @ dotcloud / docker

Les modifications de configuration suivantes doivent garantir le flux de trafic entre Docker et l'hôte Shorewall. Testé sur Shorewall 4.5.21.9 mais devrait s'appliquer aux versions les plus récentes:

/etc/shorewall/shorewall.conf

Assurez-vous que le transfert IP est activé (la plupart des éléments de configuration sont Oui / Non, mais celui-ci est "On"):

IP_FORWARDING=On

/ etc / shorewall / masq

Activez le masquage (NAT) pour votre réseau Docker privé (si vous utilisez un réseau différent, c'est-à-dire que vous lancez Docker avec --bip=#.#.#.#/#, puis modifiez en conséquence). Passez eth0à n'importe quelle interface sur la machine hôte avec une connectivité externe:

#INTERFACE:DEST         SOURCE
eth0                    172.17.0.0/16

/ etc / shorewall / interfaces

Ajoutez une entrée d'interface pour que Shorewall sache à quelle interface la dockzone se rapporte:

#ZONE           INTERFACE               OPTIONS
dock            docker0

/ etc / shorewall / zones

Créez une nouvelle zone; note, dockerest trop long et provoquera une erreur "nom de zone non valide".

#ZONE   INTERFACE
dock    ipv4

/ etc / shorewall / policy

Vous voulez probablement autoriser les conteneurs Docker à parler à la machine hôte et à Internet, c'est donc un bon point de départ:

#SOURCE         DEST            POLICY
# ...(other policies)...
dock            all             ACCEPT
# ...(other policies, catch-all)...

Vous pouvez également avoir besoin d'une ACCEPTstratégie similaire pour le trafic de fwà dock, si vous ne l'avez pas déjà ouvert avec fwà all.

Vous pouvez affinez ceci plus loin dans les politiques ou les règles des fichiers au besoin. Par exemple, ce qui précède ne permet pas explicitement au trafic extérieur d'atteindre vos conteneurs Docker; vérifiez vos autres zones / politiques / règles pour cela.

Depuis que Docker a introduit sa fonction d'isolation de réseau, les autres solutions mentionnées ici ne sont plus suffisantes si vous souhaitez utiliser des réseaux personnalisés. Shorewall 5.0.6 introduit la prise en charge de Docker, y compris les réseaux Docker. Cette:

• Permet de démarrer / arrêter / redémarrer shorewall et docker dans n'importe quel ordre
• Évite la nécessité de maintenir un script d'extension

Je viens de le découvrir sur ma boîte. Assurez-vous que /etc/shorewall.conf a:

IP_FORWARDING=Yes

Docker s'appuie sur le transfert, et j'ai espacé que «marionnette» le définit sur «Non» sur tous mes serveurs.

Mise à jour: Vous devez probablement également masquer le trafic provenant du docker de votre interface WAN.

Modifiez /etc/shorewall/masqet vous aurez besoin d'une ligne similaire à:

br0 172.17.0.0/12

Dans ce cas, mon interface WAN est en fait br0 (un pont), mais la vôtre sera probablement quelque chose comme eth0. (Utilisez ifconfigpour voir vos interfaces et leurs adresses IP). Sur ma machine, Docker utilise 172.17.0.0/24 qui est une plage d'adresses privées RFC1918. Cela peut différer sur d'autres systèmes, mais vous pouvez voir la plage en utilisant ifconfigà nouveau pour rechercher l'interface docker0.

Vous pouvez vous assurer que l'ensemble de règles Docker survit à un redémarrage du mur de quai en créant des scripts d'extension qui enregistrent la DOCKERchaîne avant le redémarrage, puis la restaurent à nouveau par la suite. Je viens de publier un article avec un exemple de la façon de procéder , même si je suis sûr que c'est loin d'être la seule méthode possible.

Le service docker peut être redémarré sans impact sur les conteneurs en cours d'exécution et peut être exécuté après un redémarrage de Shorewall pour recharger les règles spécifiques du docker. Il y aura évidemment un court laps de temps où la mise en réseau avec les conteneurs est interrompue.

C'est vrai au moins sur mes quelques installations d'Archlinux.

L'action d'actualisation ne supprime pas l'iptable, donc si vous souhaitez simplement actualiser des règles ou des politiques, vous pouvez simplement exécuter l'actualisation au lieu de redémarrer:

sudo shorewall refresh

De toute évidence, le problème persiste si vous devez vraiment redémarrer Shorewall. Ensuite, vous devez redémarrer docker et recharger vos conteneurs.

Une option possible consiste à exécuter Docker avec l'option --net = host, pour permettre au réseau hôte d'accès aux applications conteneurisées sans transfert IP et NAT.