Ce post est un mémo pour l’installation d’un hyperviseur LXD sur un serveur dédié fonctionnant sous Ubuntu Xenial, et utilisant bridge-utils et Shorewall pour la partie réseau.

Beaucoup de temps a passé depuis mon billet sur les conteneurs LXC mais au final les choses n’ont pas changé tant que ça, elles se sont surtout simplifiées.

Variables

export LXD_IPV4=votre_ip_v4_externe
export LXD_PORT=12345
export LXD_PASSWD=yourverysecuredpassword

Paquets système

Les divers outils :

sudo apt-get install \
  haveged \
  bridge-utils \
  thin-provisioning-tools \
  shorewall \
  shorewall6

Remarque : haveged sert à générer plus d’entropie, et est à installer sur le host, pour que l’effet soit disponible dans les conteneurs. Il n’affaiblit pas la sécurité de la cryptographie, au contraire (source)

On utilise la version backport pour la fonctionnalité network de LXD :

sudo apt-get install -t xenial-backports lxd

Configuration LXD

On initialise avec un backend de stockage directory mais c’est juste pour simplifier l’initialisation LXD, on changera ça tout de suite après. :

sudo lxd init --auto \
  --storage-backend dir \
  --network-address $LXD_IPV4 \
  --network-port $LXD_PORT\
  --trust-password $LXD_PASSWD

On affiche le fingerprint :

lxc info | grep certificate_fingerprint

On pré-configurera un groupe virtuel vglxd :

sudo vgcreate --verbose --vgmetadatacopies all vglxd /dev/sdaXXX

On définit un nouveau stockage de type LVM qui s’appuie dessus, et on le définit comme stockage dans le profil par défaut :

lxc storage create lvm lvm source=vglxd
lxc profile device remove default root
lxc profile device add default root disk path=/ pool=lvm

Scripts utilitaires

Récuperer les scripts de gestion. Ils servent à gérer les bridge (1 bridge = 1 vlan = 1 dmz) et les fichiers interfaces portant leur configuration IP :

git clone https://github.com/nipil/lxd-mgt-tools.git

Lire la documentation et ajouter la ligne nécessaire à /etc/network/interface

Topologie réseau

Mes hyperviseurs n’ont qu’un adresse IP externe (1 IPv4 + 1 IPv4) et tous les flux transiteront par l’hyperviseur. Celui-ci disposera donc de plusieurs interfaces IP, et un routage interne ainsi qu’un filtrage seront effectués entre celles-ci.

À l’aide des scripts ci-dessus, on créera 256 DMZ :

for DMZ in {0..255}
do
  ./dmz-create.sh $DMZ
done

Firewall

J’utilise un outil pour me simplifie la vie et avoir facilement une identicité entre IPv4 et IPv6 :

git clone https://github.com/nipil/shorewall-merged.git

Ce qui est commun sera dans commun, ce qui est spécifique à IPv4 sera dans ipv4 (pareil pour ipv6) et les noms associés aux IP sont partagés et distribués automatiquement entre IPv6 et IPv4.

Ça permet aussi de pousser la conf finalisée aux firewall distant, que ça soit en mode "full" (shorewall et shorewall6 installé sur le firewall) ou en mode "light" (compilé par shorewall et shorewall6 en local, puis poussé et exécuté sur le firewall via shorewall-light et shorewall6-light)

Et comme nos hyperviseurs sont banalisés, les fichiers seront répliqués au bon endroit sur chaque hyperviseur, ce qui permet d’assurer une identité de tous les paramétrages sur chaque hyperviseur !

Création des VM

Pour créer une VM on a besoin de choisir la DMZ, on affecte un numéro à la VM, et on lui donne un nom. Pour créer la VM "toto" n°24 dans la DMZ 10, on effectuera :

./container-create.sh 10 24 toto

Ce qui donnera le résultat suivant :

+------+---------+-------------------+-----------------------+------------+-----------+
| NAME |  STATE  |       IPV4        |         IPV6          |    TYPE    | SNAPSHOTS |
+------+---------+-------------------+-----------------------+------------+-----------+
| toto | RUNNING | 10.0.10.24 (eth0) | fd00:0:0:a::18 (eth0) | PERSISTENT | 0         |
+------+---------+-------------------+-----------------------+------------+-----------+

Les VM LXC pourront être déplacées d’hyperviseur LXD en hypérviseur LXD (facilement à froid) : elles conserveront tous leurs paramètres, et leur configuration réseau

C’est la raison pour laquelle on utilise la même configuration réseau et firewall sur tous les hyperviseurs, ce qui est possible car les accès aux conteneurs sont basés sur du nattage (cf première section)