<metaname="description"content="systemd-nspawn peut être utilisé pour exécuter une commande ou un système d’exploitation dans un espace de noms léger. Il est plus puissant que chroot car il...">
<divclass="col-main cell cell--auto"><!-- start custom main top snippet --><divid="results-container"class="search-result js-search-result"></div><!-- end custom main top snippet -->
</details><p><em>systemd-nspawn peut être utilisé pour exécuter une commande ou un système d’exploitation dans un espace de noms léger. Il est plus puissant que chroot car il virtualise entièrement la hiérarchie du système de fichiers, ainsi que l’arborescence des processus, les différents sous-systèmes IPC et le nom de l’hôte et du domaine.</em></p>
<p><ahref="https://wiki.archlinux.org/title/Systemd-nspawn">systemd-nspawn</a> ressemble à la commande chroot, mais c’est un chroot sur les stéroïdes.</p>
<p>systemd-nspawn limite l’accès à diverses interfaces du noyau dans le conteneur à la lecture seule, comme /sys, /proc/sys ou /sys/fs/selinux. Les interfaces réseau et l’horloge système ne peuvent pas être modifiées depuis le conteneur. Les nœuds de périphériques ne peuvent pas être créés. Le système hôte ne peut pas être redémarré et les modules du noyau ne peuvent pas être chargés à partir du conteneur.</p>
<p><em>systemd-nspawn est un outil plus simple à configurer que LXC ou Libvirt.</em></p>
<li><ahref="https://blog.karmacomputing.co.uk/using-systemd-nspawn-containers-with-publicly-routable-ips-ipv6-and-ipv4-via-bridged-mode-for-high-density-testing-whilst-balancing-tenant-isolation/">Using systemd-nspawn containers with publicly routable ips (IPv6 and IPv4) via bridged mode for high density testing whilst balancing tenant isolation</a></li>
<p>Ensuite, créez un répertoire pour contenir le conteneur. Dans cet exemple, nous utiliserons <codeclass="language-plaintext highlighter-rouge">~/MonConteneur</code></p>
<p>Ensuite, nous utilisons <codeclass="language-plaintext highlighter-rouge">pacstrap</code> pour installer un système Arch de base dans le conteneur.<br/>
Au minimum, nous devons installer le paquet de base.</p>
<divclass="language-shell highlighter-rouge"><divclass="highlight"><preclass="highlight"><code><spanclass="c"># pacstrap -K -c ~/MonConteneur base [paquets/groupes supplémentaires]</span>
</code></pre></div></div>
<p>Astuce : Le paquet base ne dépend pas du paquet linux kernel et est prêt pour le conteneur.</p>
<p>Une fois l’installation terminée, chrootez dans le conteneur et définissez un mot de passe root :</p>
<p>L’option <codeclass="language-plaintext highlighter-rouge">-b</code> permet de démarrer le conteneur (c’est-à-dire d’exécuter systemd en tant que PID=1), au lieu d’exécuter simplement un shell, et <codeclass="language-plaintext highlighter-rouge">-D</code> spécifie le répertoire qui devient le répertoire racine du conteneur.</p>
<p>Après le démarrage du conteneur, connectez-vous en tant que “root” avec votre mot de passe.</p>
<pclass="info">Note : Si la connexion échoue avec “Login incorrect”, le problème vient probablement de la liste blanche du périphérique TTY securetty. Voir #Root login fails.</p>
<p>Le conteneur peut être mis hors tension en exécutant <codeclass="language-plaintext highlighter-rouge">poweroff</code> depuis le conteneur. Depuis l’hôte, les conteneurs peuvent être contrôlés par l’outil <codeclass="language-plaintext highlighter-rouge">machinectl</code>.</p>
<pclass="info">Remarque : pour mettre fin à la session à partir du conteneur, maintenez les touches <codeclass="language-plaintext highlighter-rouge">Ctrl ALTGR</code> enfoncées et appuyez rapidement sur <codeclass="language-plaintext highlighter-rouge">]</code> à trois reprises.</p>
<p><em>Créer un environnement Debian ou Ubuntu</em></p>
<p>Installez <strong>debootstrap</strong>, ainsi que <strong>debian-archive-keyring</strong> ou <strong>ubuntu-keyring</strong>, ou les deux, en fonction de la distribution choisie.</p>
<pclass="info">Note : <em>systemd-nspawn</em> nécessite que le système d’exploitation dans le conteneur utilise <em>systemd init</em> (qu’il tourne en tant que PID 1) et que <em>systemd-nspawn</em> soit installé dans le conteneur. Ces exigences peuvent être satisfaites en s’assurant que le paquetage <em>systemd-container</em> est installé sur le système du conteneur. Le paquetage <em>systemd-container</em> dépend de dbus, qui n’est pas installé par défaut.<br/>
<strong>Assurez-vous que le paquetage <em>dbus</em> ou <em>dbus-broker</em> est installé sur le système de conteneurs.</strong></p>
<p>À partir de là, il est assez facile de configurer les environnements Debian ou Ubuntu :</p>
<divclass="language-shell highlighter-rouge"><divclass="highlight"><preclass="highlight"><code><spanclass="c"># cd /var/lib/machines</span>
<p>Pour <strong>Debian</strong>, les noms de code valides sont soit les noms de roulement comme “stable” et “testing”, soit les noms de version comme “bullseye” et “sid”.</p>
<p>Pour <strong>Ubuntu</strong>, le nom de code “xenial” ou “zesty” doit être utilisé. Une liste complète des noms de code se trouve dans /usr/share/debootstrap/scripts et la table officielle des noms de code et des numéros de version se trouve dans <ahref="https://wiki.ubuntu.com/DevelopmentCodeNames#Release_Naming_Scheme">DevelopmentCodeNames</a>.</p>
<p>Dans le cas d’une image Debian, le “repository-url” peut être https://deb.debian.org/debian/.<br/>
Pour une image Ubuntu, le “repository-url” peut être http://archive.ubuntu.com/ubuntu/. Le “repository-url” ne doit pas contenir de barre oblique à la fin.</p>
<p>Le container bullseyes est créé</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>I: Base system installed successfully.
</code></pre></div></div>
<p>Tout comme Arch, Debian et Ubuntu ne vous laisseront pas vous connecter sans mot de passe. Pour définir le mot de passe root, exécutez systemd-nspawn sans l’option <codeclass="language-plaintext highlighter-rouge">-b</code> :</p>
<h3id="options-par-défaut">Options par défaut</h3>
<p>Les conteneurs situés dans <codeclass="language-plaintext highlighter-rouge">/var/lib/machines/</code> peuvent être contrôlés par la commande <codeclass="language-plaintext highlighter-rouge">machinectl</code>, qui contrôle en interne les instances de l’unité de <codeclass="language-plaintext highlighter-rouge">service systemd-nspawn@</code><br/>
Les sous-répertoires de <codeclass="language-plaintext highlighter-rouge">/var/lib/machines/</code> correspondent aux noms des conteneurs, c’est-à-dire <codeclass="language-plaintext highlighter-rouge">/var/lib/machines/nom du conteneur/</code></p>
<pclass="info">Note : Si le conteneur ne peut pas être déplacé dans /var/lib/machines/ pour une raison quelconque, il peut être lié par un lien symbolique. Voir <ahref="https://man.archlinux.org/man/machinectl.1#FILES_AND_DIRECTORIES">machinectl § FILES AND DIRECTORIES</a> pour plus de détails.</p>
<p>Il est important de comprendre que les conteneurs démarrés via <codeclass="language-plaintext highlighter-rouge">machinectl</code> ou <codeclass="language-plaintext highlighter-rouge">systemd-nspawn@.service</code> utilisent des options par défaut différentes de celles des conteneurs démarrés manuellement par la commande <codeclass="language-plaintext highlighter-rouge">systemd-nspawn</code><br/>
Les options supplémentaires utilisées par le service sont les suivantes :</p>
<ul>
<li><codeclass="language-plaintext highlighter-rouge">-b/--boot</code> - Les conteneurs gérés recherchent automatiquement un programme d’initialisation et l’invoquent en tant que PID 1.</li>
<li><codeclass="language-plaintext highlighter-rouge">--network-veth</code> qui implique <codeclass="language-plaintext highlighter-rouge">--private-network</code> - Les conteneurs gérés obtiennent une interface réseau virtuelle et sont déconnectés du réseau hôte.</li>
<li><codeclass="language-plaintext highlighter-rouge">-U</code> - Les conteneurs gérés utilisent la fonctionnalité user_namespaces(7) par défaut si elle est supportée par le noyau.</li>
<p>Le comportement peut être modifié dans les fichiers de configuration par conteneur, voir le paragraohe <strong>Configuration</strong> pour plus de détails.</p>
<h3id="machinectl">machinectl</h3>
<pclass="info">Note : L’outil <codeclass="language-plaintext highlighter-rouge">machinectl</code> nécessite que <em>systemd</em> et <em>dbus</em> soient installés dans le conteneur.</p>
<p>Les conteneurs peuvent être gérés par la sous-commande <codeclass="language-plaintext highlighter-rouge">machinectl nom-du-conteneur</code><br/>
<pclass="warning">Remarque : machinectl exige que le nom du conteneur soit composé uniquement de lettres ASCII, de chiffres et de traits d’union afin qu’il s’agisse d’un nom d’hôte valide. Par exemple, si le nom du conteneur contient un trait de soulignement, il ne sera tout simplement pas reconnu et l’exécution de machinectl start nom_du_conteneur entraînera l’erreur Nom_du_conteneur invalide.</p>
<p>De même, il existe des sous-commandes telles que <codeclass="language-plaintext highlighter-rouge">poweroff</code>, <codeclass="language-plaintext highlighter-rouge">reboot</code>, <codeclass="language-plaintext highlighter-rouge">status</code> et <codeclass="language-plaintext highlighter-rouge">show</code>. Voir <ahref="https://man.archlinux.org/man/machinectl.1#Machine_Commands">machinectl § Commandes machine</a> pour des explications détaillées.</p>
<p><strong>Astuce</strong> : Les opérations de mise hors tension et de redémarrage peuvent être effectuées depuis le conteneur à l’aide des commandes <codeclass="language-plaintext highlighter-rouge">poweroff</code> et <codeclass="language-plaintext highlighter-rouge">reboot</code>.</p>
<p>D’autres commandes courantes sont :</p>
<ul>
<li><codeclass="language-plaintext highlighter-rouge">machinectl lis</code>t - affiche la liste des conteneurs en cours d’exécution</li>
<li><codeclass="language-plaintext highlighter-rouge">machinectl login nom-du-conteneur</code> - ouvre une session de connexion interactive dans un conteneur</li>
<li><codeclass="language-plaintext highlighter-rouge">machinectl shell [username@]container-name</code> - ouvre une session interactive dans un conteneur (cela invoque immédiatement un processus utilisateur sans passer par le processus de connexion dans le conteneur)</li>
<li><codeclass="language-plaintext highlighter-rouge">machinectl enable container-name</code> et <codeclass="language-plaintext highlighter-rouge">machinectl disable container-name</code> - active ou désactive le lancement d’un conteneur au démarrage, voir <ahref="https://wiki.archlinux.org/title/Systemd-nspawn#Enable_container_to_start_at_boot">#Enable container to start at boot</a> pour plus de détails</li>
</ul>
<p><strong>machinectl</strong> possède également des sous-commandes pour gérer les images des conteneurs (ou des machines virtuelles) et les transferts d’images. Voir <ahref="https://man.archlinux.org/man/machinectl.1#Image_Commands">machinectl §Image Commands</a> et <ahref="https://man.archlinux.org/man/machinectl.1#Image_Transfer_Commands">machinectl §Image Transfer Commands</a> pour plus de détails. A partir du 2023Q1, les 3 premiers exemples de machinectl(1) § EXEMPLES démontrent les commandes de transfert d’images. <ahref="https://man.archlinux.org/man/machinectl.1#FILES_AND_DIRECTORIES">machinectl(1) § FILES AND DIRECTORIES</a> discute de l’endroit où trouver des images appropriées.</p>
<p>Une grande partie de la chaîne d’outils de base de systemd a été mise à jour pour fonctionner avec les conteneurs. Les outils qui le font fournissent généralement une option <codeclass="language-plaintext highlighter-rouge">-M</code>, <codeclass="language-plaintext highlighter-rouge">--machine=</code> qui prend un nom de conteneur comme argument.</p>
<p>Exemples :</p>
<p>Voir les journaux d’une machine particulière :</p>
<p>Les fichiers <codeclass="language-plaintext highlighter-rouge">.nspawn</code> peuvent être utilisés pour spécifier des paramètres par conteneur et non des paramètres globaux. Voir <ahref="https://man.archlinux.org/man/systemd.nspawn.5">systemd.nspawn(5)</a> pour plus de détails.</p>
<p>Remarque : les fichiers <codeclass="language-plaintext highlighter-rouge">.nspawn</code> peuvent être retirés de la base de données :</p>
<ul>
<li>Les fichiers .nspawn peuvent être supprimés de manière inattendue de /etc/systemd/nspawn/ lorsque vous exécutez <codeclass="language-plaintext highlighter-rouge">machinectl remove</code><ahref="https://github.com/systemd/systemd/issues/15900">[5]</a></li>
<li>L’interaction des options réseau spécifiées dans le fichier <codeclass="language-plaintext highlighter-rouge">.nspawn</code> et sur la ligne de commande ne fonctionne pas correctement lorsqu’il y a <codeclass="language-plaintext highlighter-rouge">--settings=override</code> (qui est spécifié dans le fichier <codeclass="language-plaintext highlighter-rouge">systemd-nspawn@.service</code>). Comme solution de contournement, vous devez inclure l’option <codeclass="language-plaintext highlighter-rouge">VirtualEthernet=on</code>, même si le service spécifie <codeclass="language-plaintext highlighter-rouge">--network-veth</code>.</li>
</ul>
<h3id="lancement-au-démarrage">Lancement au démarrage</h3>
<p>Lorsque vous utilisez fréquemment un conteneur, il se peut que vous souhaitiez le lancer au démarrage.</p>
<p>Assurez-vous d’abord que l’option <codeclass="language-plaintext highlighter-rouge">machines.target</code> est activée.</p>
<p>Les conteneurs détectables par <codeclass="language-plaintext highlighter-rouge">machinectl</code> peuvent être activés ou désactivés :</p>
<li>Cela a pour effet d’activer l’unité systemd <codeclass="language-plaintext highlighter-rouge">systemd-nspawn@container-name.service</code>.</li>
<li>Comme mentionné dans <ahref="https://wiki.archlinux.org/title/Systemd-nspawn#Default_systemd-nspawn_options">#Options systemd-nspawn par défaut</a>, les conteneurs démarrés par machinectl obtiennent une interface Ethernet virtuelle. Pour désactiver le réseau privé, voir <ahref="https://wiki.archlinux.org/title/Systemd-nspawn#Use_host_networking">#Utiliser le réseau de l’hôte</a>.</li>
</ul>
<h3id="contrôle-des-ressources">Contrôle des ressources</h3>
<p>Vous pouvez profiter des groupes de contrôle pour implémenter des limites et une gestion des ressources de vos conteneurs avec <codeclass="language-plaintext highlighter-rouge">systemctl set-property</code>, voir <ahref="https://man.archlinux.org/man/systemd.resource-control.5">systemd.resource-control(5)</a>.<br/>
Par exemple, vous pouvez vouloir limiter la quantité de mémoire ou l’utilisation du processeur. Pour limiter la consommation de mémoire de votre conteneur à 2 GiB :</p>
<p>Cela créera des fichiers permanents dans <codeclass="language-plaintext highlighter-rouge">/etc/systemd/system.control/systemd-nspawn@container-name.service.d/</code></p>
<p>D’après la documentation, <codeclass="language-plaintext highlighter-rouge">MemoryHigh</code> est la méthode préférée pour contrôler la consommation de mémoire, mais elle ne sera pas limitée de manière stricte comme c’est le cas avec <codeclass="language-plaintext highlighter-rouge">MemoryMax</code>. Vous pouvez utiliser les deux options en laissant <codeclass="language-plaintext highlighter-rouge">MemoryMax</code> comme dernière ligne de défense. Prenez également en considération le fait que vous ne limiterez pas le nombre de CPU que le conteneur peut voir, mais vous obtiendrez des résultats similaires en limitant le temps que le conteneur obtiendra au maximum, par rapport au temps total du CPU.</p>
<blockquote>
<p>Astuce : Si vous voulez que ces changements ne soient que temporaires, vous pouvez passer l’option <codeclass="language-plaintext highlighter-rouge">--runtime</code><br/>
Vous pouvez vérifier les résultats avec <codeclass="language-plaintext highlighter-rouge">systemd-cgtop</code></p>
</blockquote>
<h3id="mise-en-réseau">Mise en réseau</h3>
<p>Les conteneurs <em>systemd-nspawn</em> peuvent utiliser le réseau hôte ou le réseau privé :</p>
<ul>
<li>Dans le mode réseau hôte, le conteneur a un accès complet au réseau hôte. Cela signifie que le conteneur pourra accéder à tous les services réseau de l’hôte et que les paquets provenant du conteneur apparaîtront au réseau extérieur comme provenant de l’hôte (c’est-à-dire qu’ils partageront la même adresse IP).</li>
<li>En mode réseau privé, le conteneur est déconnecté du réseau de l’hôte. Toutes les interfaces réseau sont alors indisponibles pour le conteneur, à l’exception du périphérique de bouclage et des interfaces explicitement attribuées au conteneur. <br/>
Il existe plusieurs façons de configurer des interfaces réseau pour le conteneur :
* Une interface existante peut être affectée au conteneur (par exemple, si vous avez plusieurs périphériques Ethernet).
* Une interface réseau virtuelle associée à une interface existante (c’est-à-dire une interface VLAN) peut être créée et attribuée au conteneur.
* Un lien Ethernet virtuel entre l’hôte et le conteneur peut être créé.<br/>
Dans ce dernier cas, le réseau du conteneur est totalement isolé (du réseau extérieur et des autres conteneurs) et il appartient à l’administrateur de configurer le réseau entre l’hôte et les conteneurs. Cela implique généralement la création d’un pont réseau pour connecter plusieurs interfaces (physiques ou virtuelles) ou la mise en place d’une traduction d’adresses réseau entre plusieurs interfaces.</li>
</ul>
<p>Le mode de<u> mise en réseau de l'hôte</u> convient aux conteneurs d’application qui n’exécutent aucun logiciel de mise en réseau susceptible de configurer l’interface attribuée au conteneur. Le mode réseau hôte est le mode par défaut lorsque vous exécutez systemd-nspawn à partir de l’interpréteur de commandes.</p>
<p>En revanche, le <u>mode réseau privé</u> convient aux conteneurs système qui doivent être isolés du système hôte. La création de liens Ethernet virtuels est un outil très flexible qui permet de créer des réseaux virtuels complexes. C’est le mode par défaut pour les conteneurs démarrés par machinectl ou systemd-nspawn@.service.</p>
<p>Les sous-sections suivantes décrivent des scénarios courants. Voir <ahref="https://man.archlinux.org/man/systemd-nspawn.1#Networking_Options">systemd-nspawn(1) § Options de mise en réseau</a> pour plus de détails sur les options disponibles de <em>systemd-nspawn</em>.</p>
<h4id="utiliser-la-mise-en-réseau-de-lhôte">Utiliser la mise en réseau de l’hôte</h4>
<p>Pour désactiver la mise en réseau privée et la création d’un lien Ethernet virtuel utilisé par les conteneurs démarrés avec machinectl, ajoutez un fichier .nspawn avec l’option suivante :</p>
<p>Cette option remplacera l’option <codeclass="language-plaintext highlighter-rouge">-n/--network-veth</code> utilisée dans <codeclass="language-plaintext highlighter-rouge">systemd-nspawn@.service</code> et les conteneurs nouvellement démarrés utiliseront le mode réseau de l’hôte.</p>
<h4id="utiliser-un-lien-ethernet-virtuel">Utiliser un lien Ethernet virtuel</h4>
<p>Si un conteneur est démarré avec l’option <codeclass="language-plaintext highlighter-rouge">-n/--network-veth</code>, <em>systemd-nspawn</em> créera un lien Ethernet virtuel entre l’hôte et le conteneur.<br/>
Le côté hôte du lien sera disponible en tant qu’interface réseau nommée <codeclass="language-plaintext highlighter-rouge">ve-container-name</code><br/>
Le côté conteneur du lien sera nommé <codeclass="language-plaintext highlighter-rouge">host0</code>. Notez que cette option implique <codeclass="language-plaintext highlighter-rouge">--private-network</code></p>
<p>Remarque :</p>
<ul>
<li>Si le nom du conteneur est trop long, le nom de l’interface sera raccourci (par exemple, <codeclass="language-plaintext highlighter-rouge">ve-long-conKQGh</code> au lieu de <codeclass="language-plaintext highlighter-rouge">ve-long-nom-du-conteneur</code>) afin de respecter la <ahref="https://stackoverflow.com/a/29398765">limite de 15 caractères</a>. Le nom complet sera défini comme la propriété <codeclass="language-plaintext highlighter-rouge">altname</code> de l’interface (voir <ahref="https://man.archlinux.org/man/ip-link.8">ip-link(8)</a>) et pourra toujours être utilisé pour référencer l’interface.</li>
<li>Lors de l’examen des interfaces avec <codeclass="language-plaintext highlighter-rouge">ip link</code>, les noms d’interface seront affichés avec un suffixe, comme <codeclass="language-plaintext highlighter-rouge">ve-container-name@if2</code> et <codeclass="language-plaintext highlighter-rouge">host0@if9</code>. Le <codeclass="language-plaintext highlighter-rouge">@ifN</code> ne fait pas partie du nom de l’interface, mais <codeclass="language-plaintext highlighter-rouge">ip link</code> ajoute cette information pour indiquer à quel “emplacement” le câble Ethernet virtuel se connecte à l’autre extrémité.<br/>
Par exemple, une interface Ethernet virtuelle hôte présentée comme <codeclass="language-plaintext highlighter-rouge">ve-foo@if2</code> est connectée au conteneur foo, et à l’intérieur du conteneur à la deuxième interface réseau - celle présentée avec l’index 2 lors de l’exécution d’ip link à l’intérieur du conteneur. De même, l’interface nommée <codeclass="language-plaintext highlighter-rouge">host0@if9</code> dans le conteneur est connectée à la 9ème interface réseau de l’hôte.</li>
</ul>
<p>Lorsque vous démarrez le conteneur, une adresse IP doit être attribuée aux deux interfaces (sur l’hôte et dans le conteneur). Si vous utilisez <ahref="https://wiki.archlinux.org/title/Systemd-networkd">systemd-networkd</a> sur l’hôte ainsi que dans le conteneur, ceci est fait out-of-the-box :</p>
<ul>
<li>le fichier <codeclass="language-plaintext highlighter-rouge">/usr/lib/systemd/network/80-container-ve.network</code> sur l’hôte correspond à l’interface <codeclass="language-plaintext highlighter-rouge">ve-container-name</code> et démarre un serveur DHCP, qui attribue des adresses IP à l’interface de l’hôte ainsi qu’au conteneur,</li>
<li>le fichier <codeclass="language-plaintext highlighter-rouge">/usr/lib/systemd/network/80-container-host0.network</code> du conteneur correspond à l’interface <codeclass="language-plaintext highlighter-rouge">host0</code> et démarre un client DHCP qui reçoit une adresse IP de l’hôte.</li>
</ul>
<p>Si vous n’utilisez pas <em>systemd-networkd</em>, vous pouvez configurer des adresses IP statiques ou démarrer un serveur DHCP sur l’interface hôte et un client DHCP dans le conteneur. Voir <ahref="https://wiki.archlinux.org/title/Network_configuration">Configuration du réseau</a> pour plus de détails.</p>
<p>Pour permettre au conteneur d’accéder au réseau extérieur, vous pouvez configurer NAT comme décrit dans <ahref="https://wiki.archlinux.org/title/Internet_sharing#Enable_NAT">Partage Internet#Activer NAT</a>. Si vous utilisez <em>systemd-networkd</em>, cela est fait (partiellement) automatiquement via l’option <codeclass="language-plaintext highlighter-rouge">IPMasquerade=both</code> dans /usr/lib/systemd/network/80-container-ve.network. Cependant, cette option n’émet qu’une règle <ahref="https://wiki.archlinux.org/title/Iptables">iptables</a> (ou <ahref="https://wiki.archlinux.org/title/Nftables">nftables</a>) telle que</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>-t nat -A POSTROUTING -s 192.168.163.192/28 -j MASQUERADE
</code></pre></div></div>
<p>La table de filtrage doit être configurée manuellement comme indiqué dans <ahref="https://wiki.archlinux.org/title/Internet_sharing#Enable_NAT">Partage Internet#Activer NAT</a>.<br/>
Vous pouvez utiliser un joker pour faire correspondre toutes les interfaces commençant par ve- :</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>iptables -A FORWARD -i ve-+ -o internet0 -j ACCEPT
</code></pre></div></div>
<pclass="info">Note : <em>systemd-networkd</em> et <em>systemd-nspawn</em> peuvent s’interfacer avec <ahref="https://wiki.archlinux.org/title/Iptables">iptables</a> (en utilisant la librairie <ahref="https://tldp.org/HOWTO/Querying-libiptc-HOWTO/whatis.html">libiptc</a>) ainsi qu’avec <ahref="https://wiki.archlinux.org/title/Nftables">nftables</a><ahref="https://github.com/systemd/systemd/issues/13307">[7]</a><ahref="https://github.com/systemd/systemd/blob/9ca34cf5a4a20d48f829b2a36824255aac29078c/NEWS#L295-L304">[8]</a>. Dans les deux cas, la NAT IPv4 et IPv6 est prise en charge.</p>
<p>De plus, vous devez ouvrir le port UDP 67 sur les interfaces <codeclass="language-plaintext highlighter-rouge">ve-+</code> pour les connexions entrantes vers le serveur DHCP (géré par <em>systemd-networkd</em>) :</p>
<h4id="utiliser-un-pont-réseau">Utiliser un pont réseau</h4>
<p>Si vous avez configuré un pont réseau sur le système hôte, vous pouvez créer un lien Ethernet virtuel pour le conteneur et ajouter son côté hôte au pont réseau.<br/>
Cette opération s’effectue à l’aide de l’option <codeclass="language-plaintext highlighter-rouge">--network-bridge=nom du pont</code><br/>
Notez que l’option <codeclass="language-plaintext highlighter-rouge">--network-bridge</code> implique <codeclass="language-plaintext highlighter-rouge">--network-veth</code>, c’est-à-dire que le lien Ethernet virtuel est créé automatiquement.<br/>
Cependant, le côté hôte du lien utilisera le préfixe <codeclass="language-plaintext highlighter-rouge">vb-</code> au lieu de <codeclass="language-plaintext highlighter-rouge">ve-</code>, de sorte que les options <em>systemd-networkd</em> de démarrage du serveur DHCP et de masquage d’IP ne seront pas appliquées.</p>
<p>La gestion du pont est laissée à l’administrateur. Par exemple, le pont peut connecter des interfaces virtuelles avec une interface physique, ou il peut connecter seulement des interfaces virtuelles de plusieurs conteneurs. Voir <ahref="https://wiki.archlinux.org/title/Systemd-networkd#Network_bridge_with_DHCP">systemd-networkd#Network bridge with DHCP</a> et <ahref="https://wiki.archlinux.org/title/Systemd-networkd#Network_bridge_with_static_IP_addresses">systemd-networkd#Network bridge with static IP addresses</a> pour des exemples de configurations utilisant <em>systemd-networkd</em>.</p>
<p>Il existe également une option <codeclass="language-plaintext highlighter-rouge">--network-zone=zone-name</code> qui est similaire à <codeclass="language-plaintext highlighter-rouge">--network-bridge</code> mais le pont réseau est géré automatiquement par <em>systemd-nspawn</em> et <em>systemd-networkd</em><br/>
L’interface de pont nommée <codeclass="language-plaintext highlighter-rouge">vz-zone-name</code> est automatiquement créée lorsque le premier conteneur configuré avec l’option <codeclass="language-plaintext highlighter-rouge">--network-zone=zone-name</code> est démarré, et est automatiquement supprimée lorsque le dernier conteneur configuré avec l’option <codeclass="language-plaintext highlighter-rouge">--network-zone=zone-name</code> se termine.<br/>
Cette option permet donc de placer facilement plusieurs conteneurs apparentés sur un réseau virtuel commun.<br/>
Notez que les interfaces <codeclass="language-plaintext highlighter-rouge">vz-*</code> sont gérées par <em>systemd-networkd</em> de la même manière que les interfaces <codeclass="language-plaintext highlighter-rouge">ve-*</code> en utilisant les options du fichier <codeclass="language-plaintext highlighter-rouge">/usr/lib/systemd/network/80-container-vz.network</code></p>
<h4id="utiliser-une-interface-macvlan-ou-ipvlan">Utiliser une interface “macvlan” ou “ipvlan</h4>
<p>Au lieu de créer un lien Ethernet virtuel (dont le côté hôte peut ou non être ajouté à un pont), vous pouvez créer une interface virtuelle sur une interface physique existante (c’est-à-dire une interface <ahref="https://wiki.archlinux.org/title/VLAN">VLAN</a>) et l’ajouter au conteneur.<br/>
L’interface virtuelle sera pontée avec l’interface hôte sous-jacente et le conteneur sera donc exposé au réseau extérieur, ce qui lui permet d’obtenir une adresse IP distincte via DHCP à partir du même réseau local que celui auquel l’hôte est connecté.</p>
<li><codeclass="language-plaintext highlighter-rouge">--network-macvlan=interface</code> - l’interface virtuelle aura une adresse MAC différente de l’interface physique sous-jacente et sera nommée <codeclass="language-plaintext highlighter-rouge">mv-interface</code></li>
<li><codeclass="language-plaintext highlighter-rouge">--network-ipvlan=interface</code> - l’interface virtuelle aura la même adresse MAC que l’interface physique sous-jacente et sera nommée <codeclass="language-plaintext highlighter-rouge">iv-interface</code></li>
</ul>
<p>Les deux options impliquent <codeclass="language-plaintext highlighter-rouge">--private-network</code></p>
<h4id="utiliser-une-interface-existante">Utiliser une interface existante</h4>
<p>Si le système hôte possède plusieurs interfaces réseau physiques, vous pouvez utiliser l’option <codeclass="language-plaintext highlighter-rouge">--network-interface=interface</code> pour affecter une interface au conteneur (et la rendre indisponible pour l’hôte pendant le démarrage du conteneur).<br/>
Notez que <codeclass="language-plaintext highlighter-rouge">--network-interface</code> implique <codeclass="language-plaintext highlighter-rouge">--private-network</code></p>
<pclass="warning">Note : Le passage d’interfaces réseau sans fil aux conteneurs systemd-nspawn n’est actuellement pas supporté <ahref="https://github.com/systemd/systemd/issues/7873">[9]</a></p>
<h3id="mappage-des-ports">Mappage des ports</h3>
<p>Lorsque le réseau privé est activé, les ports individuels de l’hôte peuvent être mappés aux ports du conteneur en utilisant l’option <codeclass="language-plaintext highlighter-rouge">-p/--port</code> ou en utilisant le paramètre <ahref="URL">Port</a> dans un fichier <em>.nspawn</em>. Cela se fait en émettant des règles <ahref="https://wiki.archlinux.org/title/Iptables">iptables</a> dans la table nat, mais la chaîne <codeclass="language-plaintext highlighter-rouge">FORWARD</code> dans la table de filtrage doit être configurée manuellement comme indiqué dans <ahref="https://wiki.archlinux.org/title/Systemd-nspawn#Use_a_virtual_Ethernet_link">#Use a virtual Ethernet link (Utiliser un lien Ethernet virtuel)</a>.</p>
<p>Par exemple, pour mapper un port TCP 8000 sur l’hôte au port TCP 80 dans le conteneur :</p>
<pclass="warning">Remarque : systemd-nspawn exclut explicitement l’interface <codeclass="language-plaintext highlighter-rouge">loopback</code> lors du mappage des ports. Ainsi, dans l’exemple ci-dessus, localhost:8000 se connecte à l’hôte et non au conteneur. Seules les connexions vers d’autres interfaces sont soumises au mappage des ports. Voir <ahref="https://github.com/systemd/systemd/issues/6106">[10]</a> pour plus de détails.</p>
<h3id="résolution-nom-domaine">Résolution nom domaine</h3>
<p>La résolution des noms de domaine dans le conteneur peut être configurée de la même manière que sur le système hôte. En outre, systemd-nspawn fournit des options pour gérer le fichier /etc/resolv.conf à l’intérieur du conteneur :</p>
<ul>
<li><codeclass="language-plaintext highlighter-rouge">--resolv-conf</code> peut être utilisé en ligne de commande</li>
<li><codeclass="language-plaintext highlighter-rouge">ResolvConf=</code> peut être utilisé dans les fichiers <em>.nspawn</em></li>
</ul>
<p>Ces options correspondantes ont de nombreuses valeurs possibles qui sont décrites dans <ahref="https://man.archlinux.org/man/systemd-nspawn.1#Integration_Options">systemd-nspawn(1) § Options d’intégration</a>.<br/>
La valeur par défaut est <codeclass="language-plaintext highlighter-rouge">auto</code>, ce qui signifie que :</p>
<ul>
<li>Si <codeclass="language-plaintext highlighter-rouge">--private-network</code> est activé, le fichier <codeclass="language-plaintext highlighter-rouge">/etc/resolv.conf</code> est laissé tel quel dans le conteneur.</li>
<li>Sinon, si <ahref="https://wiki.archlinux.org/title/Systemd-resolved">systemd-resolved</a> est en cours d’exécution sur l’hôte, son fichier stub <codeclass="language-plaintext highlighter-rouge">resolv.conf</code> est copié ou monté dans le conteneur.</li>
<li>Sinon, le fichier<codeclass="language-plaintext highlighter-rouge"> /etc/resolv.conf</code> est copié ou monté de l’hôte vers le conteneur.</li>
</ul>
<p>Dans les deux derniers cas, le fichier est copié si la racine du conteneur est accessible en écriture, et monté par liaison s’il est en lecture seule.</p>
<p>Dans le second cas où <ahref="https://wiki.archlinux.org/title/Systemd-resolved">systemd-resolved</a> s’exécute sur l’hôte, <em>systemd-nspawn</em> s’attend à ce qu’il s’exécute également dans le conteneur, afin que ce dernier puisse utiliser le fichier de liens symboliques <codeclass="language-plaintext highlighter-rouge">/etc/resolv.conf</code> de l’hôte. Si ce n’est pas le cas, la valeur par défaut <codeclass="language-plaintext highlighter-rouge">auto</code> ne fonctionne plus et vous devez remplacer le lien symbolique en utilisant l’une des options <codeclass="language-plaintext highlighter-rouge">replace-*</code></p>
