LXC est un système d'isolation qui permet d'exécuter plusieurs environnements Linux sur une seule plate-forme. Ce système utilise en fait un seul noyau mais permet de créer de multiples conteneurs Linux possédant chacun ses propres processus et interfaces réseau. LXC est similaire à OpenVZ mais a l'avantage d'être officiellement intégré au noyau.
Contrairement aux machines virtuelles (VirtualBox, VMware, KVM) ou à la paravirtualisation (Xen), LXC :
- n'est pas dépendant de l'architecture (x86, ARM, MIPS, ...)
- est plus léger en consommation mémoire puisque l'espace mémoire est partagé entre tous les conteneurs (il n'est pas nécessaire de définir la quantité de mémoire à allouer à chaque conteneur)
- peut encore être plus léger en consommation mémoire et stockage. En effet, il est possible de créer des conteneurs ayant accès aux répertoires /lib, /bin, /usr et /sbin du système hôte (via des montages utilisant les options bind,ro). Ainsi, il est possible de lancer un service dans un conteneur sans aucun impact sur l'utilisation mémoire.
Ces derniers points montrent qu'il est tout à fait envisageable d'intégrer LXC sur un système embarqué.
La suite de cet article évoque les différentes possibilités de configuration réseau de LXC. Pour des détails sur l'installation et la création de LXC, je vous invite à rechercher les nombreux articles que l'on peut trouver sur la toile (cf. section références).
Configuration réseau des LXC
Pour rappel, un conteneur LXC se crée généralement avec une commande comme :
lxc-create -n <name> -t debian -f </path/to/virtualization/config>
Le fichier de configuration donné avec l'option -f contient notamment la configuration réseau, représentée par les lignes suivantes :
lxc.network.type = <type> lxc.network.flags = up lxc.network.link = <interface> lxc.network.hwaddr = <MAC address> lxc.network.ipv4 = <IPv4 address> lxc.network.ipv6 = <IPv6 address>
Voici une aperçu des différents types de configuration (champ lxc.network.type) :
- empty : aucune interface réseau (hormis le loopback) dans le conteneur LXC
- phys : utilisation de l'interface physique de l'hôte précisé dans lxc.network.link
- veth : utilisation d'un bridge spécifié par lxc.network.link. Ce mode veth permet de créer deux interfaces : l'une est ajouté au bridge de l'hôte, l'autre est utilisée par le conteneur LXC. Chaque donnée émise sur une interface est reçu par l'autre.
- vlan : utilisation d'un VLAN sur une interface de l'hôte. Le numéro du VLAN est spécifié avec lxc.network.vlan.id.
- macvlan : utilisation de l'interface de l'hôte pour accéder au monde extérieur. Les échanges entre LXCs et entre un LXC et l'hôte ne sont pas possibles par défaut. Ceci permet de déléguer la gestion de la sécurité (pare-feu) à un switch particulier qui pourra retransférer des trames à destination d'un autre LXC ou de l'hôte.
- macvlan en mode bridge : afin que les LXC puissent communiquer entre eux, il est possible de configurer le macvlan en mode bridge. Pour cela, il suffit d'ajouter l'option lxc.network.macvlan.mode = bridge dans le fichier de configuration. Ceci ne permettra toujours pas une communication des LXC avec la machine hôte. Pour cela, il faudra créer une interface macvlan sur l'hôte. Pour plus d'informations sur la marche à suivre, lisez cette article.
Conclusion
La configuration la plus souvent recherchée est certainement celle en mode bridge. Notez que vous pouvez utiliser le mode veth ou macvlan (en mode bridge). Même si le mode macvlan peux permettre une configuration plus dynamique et sans nécessité de configurer une interface bridge, le mode veth semble plus intuitif et permettra l'utilisation d'outils avancés auxquels nous sommes habitués (tcpdump, ebtables ...).
Hello,
Merci pour ces explications.
Quelle est la meilleur solution dans le cas ou l'on veut pratiquer du firewalling sur la machine hôte ?