systemd-networkd (Français)

État de la traduction: Cet article est la version francophone de Systemd-networkd. Date de la dernière traduction: 2022-01-08. Vous pouvez aider à synchroniser la traduction s'il y a eu des changements dans la version anglaise.

systemd-networkd est un daemon système qui gère les configurations réseau. Il détecte et configure les périphériques réseau à mesure qu'ils apparaissent ; il peut également créer des périphériques réseau virtuels. Ce service peut être particulièrement utile pour mettre en place des configurations réseau complexes pour un conteneur géré par systemd-nspawn ou pour des machines virtuelles. Il fonctionne également très bien sur des connexions simples.

Utilisation de base

Le paquet systemd fait partie de l'installation par défaut d'Arch et contient tous les fichiers nécessaires au fonctionnement d'un réseau filaire. Les adaptateurs sans fil, traités plus loin dans cet article, peuvent être configurés par des services, tels que wpa_supplicant ou iwd.

Services requis et configuration

Pour utiliser systemd-networkd, démarrez et activez systemd-networkd.service.

Note: Vous devez vous assurer qu'aucun autre service souhaitant configurer le réseau n'est en cours d'exécution ; en effet, plusieurs services réseau entreront en conflit. Trouvez la liste des services en cours d'exécution avec systemctl --type=service et ensuite stoppez-les.

La configuration de systemd-resolved, qui est un service de résolution de noms de réseau pour les applications locales, est facultative, compte tenu des points suivants :

Il est important de comprendre comment resolv.conf et systemd-resolved interagissent pour configurer correctement le DNS qui sera utilisé, quelques explications sont fournies dans systemd-resolved.
systemd-resolved est nécessaire si les entrées DNS sont spécifiées dans les fichiers .network.
systemd-resolved est également nécessaire si vous souhaitez obtenir des adresses DNS à partir de serveurs DHCP ou d'annonces de routeurs IPv6.
(en définissant (DHCP= et/ou IPv6AcceptRA= dans la section [Network], et UseDNS=yes (the default) in the corresponding section(s) [DHCPv4], [DHCPv6], [IPv6AcceptRA], see systemd.network(5)).
Notez que systemd-resolved peut également être utilisé sans systemd-networkd.

systemd-networkd-wait-online

Activer systemd-networkd.service permet également d'activer systemd-networkd-wait-online.service, qui est un service système à action unique qui attend que le réseau soit configuré. Ce dernier a WantedBy=network-online.target, il ne sera donc démarré que lorsque network-online.target lui-même est activé ou tiré par une autre unité. Consultez également Systemd (Français)#Exécution des services après le démarrage du réseau.

Par défaut, systemd-networkd-wait-online.service attend que tous les liens dont il a connaissance et qui sont gérés par systemd-networkd soient entièrement configurés ou défaillants, et qu'au moins un lien soit en ligne.

Si votre système possède plusieurs interfaces réseau, mais que certaines ne sont pas censées être connectées en permanence (par exemple, si vous avez une carte Ethernet à double port, mais qu'un seul câble est branché), le démarrage de systemd-networkd-wait-online.service échouera après le délai par défaut de 2 minutes. Cela peut entraîner un retard indésirable dans le processus de démarrage. Pour modifier le comportement et attendre que "n'importe quelle" interface soit en ligne plutôt que "toutes" les interfaces, éditez le service et ajoutez le paramètre --any à la ligne ExecStart :

/etc/systemd/system/systemd-networkd-wait-online.service.d/wait-for-only-one-interface.conf

[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --any

D'autres comportements, tels que les interfaces spécifiques à attendre ou l'état opérationnel, peuvent également être configurés. Consultez systemd-networkd-wait-online(8) pour connaître les paramètres disponibles.

Exemples de configuration

Toutes les configurations de cette section sont stockées sous le nom foo.network dans /etc/systemd/network/. Pour une liste complète des options et l'ordre de traitement, consultez #Fichiers de configuration et systemd.network(5).

systemd/udev attribue automatiquement des noms d'interface réseau prévisibles et stables pour toutes les interfaces locales Ethernet, WLAN et WWAN. Utilisez networkctl list pour répertorier les périphériques du système.

Après avoir apporté des modifications à un fichier de configuration, redémarrez systemd-networkd.service.

Note:

Les options spécifiées dans les fichiers de configuration sont sensibles à la casse.
Dans les exemples ci-dessous, enp1s0 est l'adaptateur filaire et wlp2s0 est l'adaptateur sans fil. Ces noms peuvent être différents sur différents systèmes. Consultez Network configuration (Français)#Interfaces pour vérifier les noms de vos adaptateurs.
Il est également possible d'utiliser un caractère générique, par exemple Nom=fr* ou Nom=wl*.
Les périphériques peuvent également être mis en correspondance par leur type. Par exemple, Type=ether pour Ethernet, Type=wlan pour Wi-Fi et Type=wwan pour WWAN. Notez que Type=ether correspondra également aux interfaces Ethernet virtuelles (veth*), ce qui peut être indésirable.
Si vous souhaitez désactiver IPv6, consultez IPv6#systemd-networkd.

Adaptateur filaire utilisant DHCP

/etc/systemd/network/20-wired.network

[Match]
Name=enp1s0

[Network]
DHCP=yes

Adaptateur filaire utilisant une IP statique

/etc/systemd/network/20-wired.network

[Match]
Name=enp1s0

[Network]
Address=10.1.10.9/24
Gateway=10.1.10.1
DNS=10.1.10.1

Address= peut être utilisé plusieurs fois pour configurer plusieurs adresses IPv4 ou IPv6. Consultez #Fichiers network ou systemd.network(5) pour plus d'options.

Adaptateur sans fil

Afin de se connecter à un réseau sans fil avec systemd-networkd, un adaptateur sans fil configuré avec une autre application telle que wpa_supplicant ou iwd est nécessaire.

/etc/systemd/network/25-wireless.network

[Match]
Name=wlp2s0

[Network]
DHCP=yes
IgnoreCarrierLoss=3s

Si l'adaptateur sans fil a une adresse IP statique, la configuration est la même (sauf pour le nom de l'interface) que pour un adaptateur filaire.

Astuce: IgnoreCarrierLoss=3s garantit que systemd-networkd ne reconfigurera pas l'interface (par exemple, libérer et réacquérir un bail DHCP) pendant une courte période (3 secondes dans cet exemple) pendant que l'interface sans fil se déplace vers un autre point d'accès dans le même réseau sans fil (SSID), ce qui se traduit par un temps d'arrêt plus court lors de l'itinérance.

Pour s'authentifier sur le réseau sans fil, utilisez par exemple wpa_supplicant ou iwd.

Adaptateurs avec et sans fil sur la même machine

Cette configuration activera une IP DHCP pour une connexion filaire et sans fil en utilisant la directive metric pour permettre au noyau de décider à la volée laquelle utiliser. De cette façon, aucune interruption de connexion n'est observée lorsque la connexion filaire est débranchée.

La métrique de route du noyau (la même que celle configurée avec ip) décide de la route à utiliser pour les paquets sortants, dans les cas où plusieurs correspondent. C'est le cas lorsque les périphériques filaires et sans fil du système ont tous deux des connexions actives. Pour les départager, le noyau utilise la métrique. Si l'une des connexions est interrompue, l'autre l'emporte automatiquement sans qu'il n'y ait de vide où rien ne soit configuré (les transferts en cours peuvent encore ne pas gérer cela de manière agréable, mais cela se situe à une couche OSI différente).

Note: L'option Metric concerne les routes statiques tandis que l'option RouteMetric concerne les configurations n'utilisant pas de routes statiques. Consultez systemd.network(5) pour plus de détails.

/etc/systemd/network/20-wired.network

[Match]
Name=enp1s0

[Network]
DHCP=yes

[DHCPv4]
RouteMetric=10

/etc/systemd/network/25-wireless.network

[Match]
Name=wlp2s0

[Network]
DHCP=yes

[DHCPv4]
RouteMetric=20

Si vous utilisez IPv6, vous devrez définir séparément la métrique pour les routes IPv6 également, comme par exemple :

/etc/systemd/network/20-wired.network

...

[IPv6AcceptRA]
RouteMetric=10

/etc/systemd/network/25-wireless.network

...

[IPv6AcceptRA]
RouteMetric=20

Renommer une interface

Au lieu de modifier les règles d'udev, un fichier .link peut être utilisé pour renommer une interface. Un exemple utile est de définir un nom d'interface prévisible pour un adaptateur USB vers Ethernet en se basant sur son adresse MAC, car ces adaptateurs reçoivent généralement des noms différents en fonction du port USB sur lequel ils sont branchés.

/etc/systemd/network/10-ethusb0.link

[Match]
MACAddress=12:34:56:78:90:ab

[Link]
Description=USB to Ethernet Adapter
Name=ethusb0

Note: Tout .link fourni par l'utilisateur doit avoir un nom de fichier lexicalement antérieur à celui de la configuration par défaut 99-default.link pour être pris en compte. Par exemple, il faut nommer le fichier 10-ethusb0.link et non ethusb0.link.

Fichiers de configuration

Les fichiers de configuration sont situés dans /usr/lib/systemd/network/, le répertoire réseau d'exécution volatile /run/systemd/network/ et le répertoire réseau d'administration locale /etc/systemd/network/. Les fichiers se trouvant dans /etc/systemd/network/ ont la plus haute priorité.

Il existe trois types de fichiers de configuration. Ils utilisent tous un format similaire à celui de fichiers d'unités de systemd.

Les fichiers .network. Ils vont appliquer une configuration réseau pour un périphérique correspondant.
Les fichiers .netdev. Ils vont créer un périphérique réseau virtuel pour un environnement correspondant.
Les fichiers .link. Lorsqu'un périphérique réseau apparaît, udev cherchera le premier fichier .link correspondant.

Ils suivent tous les mêmes règles :

Si toutes les conditions de la section [Match] sont remplies, le profil sera activé.
Une section [Match] vide signifie que le profil s'appliquera dans tous les cas (peut être comparé au caractère générique *).
tous les fichiers de configuration sont triés collectivement et traités dans l'ordre lexical, quel que soit le répertoire dans lequel ils se trouvent
les fichiers ayant un nom identique se remplacent les uns les autres

Astuce:

Les fichiers dans /etc/systemd/network/ remplacent le fichier correspondant fourni par le système dans /usr/lib/systemd/network/. Vous pouvez également créer un lien symbolique vers /dev/null pour "masquer" un fichier système.
systemd accepte les valeurs 1, true, yes, on pour un booléen vrai, et les valeurs 0, false, no, off pour un booléen faux. Consultez systemd.syntax(7).

Fichiers network

Ces fichiers sont destinés à définir les variables de configuration du réseau, notamment pour les serveurs et les conteneurs.

Les fichiers .network ont les sections suivantes : [Match], [Link], [Network], [Address], [Route], et [DHCPv4]. Vous trouverez ci-dessous les clés communément configurées pour chaque section. Consultez systemd.network(5) pour plus d'informations et d'exemples.

[Match]

Paramètre	Description	Valeurs acceptées
`Nom=`	Correspond aux noms de périphériques, par exemple `en*`. En préfixant avec `!`, la liste peut être inversée.	noms de périphériques séparés par des espaces blancs, avec des globales, la négation logique (`!`)
`MACAddress=`	Correspondance des adresses MAC, par exemple `MACAddress=01:23:45:67:89:ab 00-11-22-33-44-55 AABB.CCDD.EEFF`	Les adresses MAC sont séparées par des espaces dans un format hexadécimal délimité par deux points, un trait d'union ou un point.
`Host=`	Correspond au nom d'hôte ou à l'ID de la machine de l'hôte.	La chaîne de noms d'hôtes avec des expressions globales, machine-id(5)
`Virtualisation=`	Vérifie si le système est exécuté dans un environnement virtualisé. `Virtualization=false` correspondra uniquement à votre machine hôte, tandis que `Virtualization=true` correspondra à tout conteneur ou VM. Il est possible de vérifier un type ou une implémentation de virtualisation spécifique, ou un espace de noms d'utilisateur (avec `private-users`).	Les paramètres suivants peuvent être utilisés : booléen, négation logique (`!`), type (`vm`, `container`), implémentation (consultez systemd-detect-virt(1)), `private-users`.

[Link]

Paramètre	Description	Valeurs acceptées	Valeur par défaut
`MACAddress=`	Attribue une adresse matérielle au périphérique. Utile pour MAC address spoofing.	Les adresses MAC hexadécimales délimitées par deux points, un trait d'union ou un point.
`MTUBytes=`	Unité de transmission maximale en octets à définir pour le périphérique. Notez que si IPv6 est activé sur l'interface, et que le MTU est choisi en dessous de 1280 (le MTU minimum pour IPv6), il sera automatiquement augmenté à cette valeur. La définition d'une valeur MTU plus grande (par exemple, lors de l'utilisation de jumbo frames) peut accélérer de manière significative vos transferts sur le réseau	integer (les suffixes habituels K, M, G, sont pris en charge et sont compris dans la base de 1024)
`Multicast=`	permet l'utilisation de multicast	booléen	? non documenté ?

[Network]

Paramètre	Description	Valeurs acceptées	Valeur par défaut
`DHCP=`	Contrôle la prise en charge des clients DHCPv4 et/ou DHCPv6.	boolean, `ipv4`, `ipv6`	`false`
`DHCPServer=`	Si cette option est activée, un serveur DHCPv4 sera lancé.	boolean	`false`
`MulticastDNS=`	Active la prise en charge du multicast DNS. Lorsqu'il a pour valeur `resolve`, seule la résolution est activée, mais pas l'enregistrement et l'annonce des hôtes ou des services.	booléen, `resolve`	`false`
`DNSSEC=`	Contrôle la prise en charge de la validation DNSSEC du DNS sur le lien. Lorsqu'il est défini sur `allow-downgrade`, la compatibilité avec les réseaux non compatibles DNSSEC est améliorée, en désactivant automatiquement le DNSSEC dans ce cas.	booléen, `allow-downgrade`	`false`
`DNS=`	Configurer des adresses DNS statiques. Peut être spécifié plus d'une fois.	inet_pton(3)
`Domains=`	Une liste de domaines qui doivent être résolus en utilisant les serveurs DNS de ce lien. plus d'informations	Nom de domaine, éventuellement préfixé d'un tilde (`~`)
`IPForward=`	Si elle est activée, les paquets entrants sur n'importe quelle interface réseau seront transférés vers n'importe quelle autre interface en fonction de la table de routage. Consultez Internet sharing#Enable packet forwarding pour plus de détails.	boolean, `ipv4`, `ipv6`	`false`
`IPMasquerade=`	Si elle est activée, les paquets transférés depuis l'interface réseau apparaîtront comme provenant de l'hôte local. Selon la valeur, implique `IPForward=ipv4`, `IPForward=ipv6` ou `IPForward=yes`	`ipv4`, `ipv6`, `both`, `no`	`no`
`IPv6PrivacyExtensions=`	Configure l'utilisation d'adresses temporaires sans état qui changent avec le temps (consultez RFC 4941). Lorsque `prefer-public`, active les extensions de confidentialité, mais préfère les adresses publiques aux adresses temporaires. Lorsque `kernel`, le paramètre par défaut du noyau est laissé en place.	boolean, `prefer-public`, `kernel`	`false`

[Adress]

Paramètre	Description	Valeurs acceptées	Valeur par défaut
`Adresse=`	Spécifiez cette clé plusieurs fois pour configurer plusieurs adresses. Obligatoire sauf si DHCP est utilisé. Si l'adresse spécifiée est `0.0.0.0` (pour IPv4) ou `::`} (pour IPv6), une nouvelle plage d'adresses de la taille demandée est automatiquement allouée à partir d'un pool de plages inutilisées à l'échelle du système.	adresse IPv4 ou IPv6 statique et sa longueur de préfixe (consultez inet_pton(3))

[Route]

Gateway= cette option est obligatoire sauf si DHCP est utilisé.
Destination= le préfixe de destination de la route, éventuellement suivi d'une barre oblique et de la longueur du préfixe.

Si Destination n'est pas présent dans la section [Route], cette section est traitée comme une route par défaut.

Astuce: Vous pouvez placer les clés Address= et Gateway= dans la section [Network] comme raccourci si la section [Address] ne contient qu'une clé Address et la section [Route] ne contient qu'une clé Gateway.

[DHCPv4]

Paramètre	Description	Valeurs acceptées	Valeur par défaut
`UseDNS=`	contrôle si les serveurs DNS annoncés par le serveur DHCP sont utilisés	booléen	`true`
`Anonymize=`	Lorsque cette option est vraie, les options envoyées au serveur DHCP suivent la RFC:7844. (Profils d'anonymat pour les clients DHCP) pour minimiser la divulgation d'informations d'identification	booléen	`false`
`UseDomains=`	contrôle si le nom de domaine reçu du serveur DHCP sera utilisé comme domaine de recherche DNS. S'il a pour valeur `route`, le nom de domaine reçu du serveur DHCP sera utilisé pour le routage des requêtes DNS uniquement, mais pas pour la recherche. Cette option peut parfois corriger la résolution de noms locaux lors de l'utilisation de systemd-resolved.	booléen, `route`	`false`

[DHCPServer]

Voici un exemple de configuration de serveur DHCP qui fonctionne bien avec hostapd pour créer un hotspot sans fil. IPMasquerade ajoute les règles de pare-feu pour NAT et implique IPForward=ipv4 pour activer packet forwarding.

The factual accuracy of this article or section is disputed.

Reason: IPMasquerade=true n'ajoute pas les règles pour la table filter, elles doivent être ajoutées manuellement. Consultez Systemd-nspawn#Use a virtual Ethernet link. (Discuss in Talk:Systemd-networkd)

/etc/systemd/network/wlan0.network

[Match]
Name=wlan0

[Network]
Address=10.1.1.1/24
DHCPServer=true
IPMasquerade=true

[DHCPServer]
PoolOffset=100
PoolSize=20
EmitDNS=yes
DNS=9.9.9.9

Fichiers netdev

Ces fichiers permettent de créer des périphériques réseau virtuels. Ils comportent deux sections : [Match] et [NetDev]. Vous trouverez ci-dessous les clés communément configurées pour chaque section. Consultez systemd.netdev(5) pour plus d'informations et d'exemples.

Section [Match]

Host= le nom d'hôte
Virtualization= vérifie si le système fonctionne dans un environnement virtualisé.

Section [NetDev]

Les clés les plus courantes sont :

Name= le nom de l'interface. obligatoire
Kind= par exemple bridge, bond, vlan, veth, sit, etc. obligatoire

Fichiers link

Ces fichiers sont une alternative aux règles udev personnalisées et seront appliqués par udev lorsque le périphérique apparaîtra. Ils ont deux sections : [Match] et [Link]. Vous trouverez ci-dessous les clés communément configurées pour chaque section. Consultez systemd.link(5) pour plus d'informations et d'exemples.

Astuce: Utiliser udevadm test-builtin net_setup_link /sys/path/to/network/device en tant qu'utilisateur root pour diagnostiquer les problèmes avec les fichiers .link.

Section [Match]

MACAddress= l'adresse MAC
Host= le nom de l'hôte
Virtualisation= le nom de l'hôte
Type= le type de périphérique, par exemple vlan

Section [Link]

MACAddressPolicy= adresses persistantes ou aléatoires, ou
MACAddress= une adresse spécifique
NamePolicy= liste des politiques par lesquelles le nom de l'interface doit être défini, par exemple, noyau, garder

Note: le /usr/lib/systemd/network/99-default.link du système est généralement suffisant pour la plupart des cas de base.

Utilisation avec les conteneurs

systemd-networkd peut fournir une configuration entièrement automatique du réseau pour les conteneurs systemd-nspawn lorsqu'il est utilisé sur le système hôte ainsi qu'à l'intérieur du conteneur. Consultez systemd-nspawn#Networking pour une présentation complète.

Pour les exemples ci-dessous ,

nous limiterons la sortie de la commande ip a aux interfaces concernées.
Nous supposons que l'hôte est le système d'exploitation principal sur lequel vous démarrez et que le conteneur est votre machine virtuelle invitée.
tous les noms d'interfaces et les adresses IP ne sont que des exemples.

Pont réseau avec DHCP

Interface pont

Tout d'abord, créez une interface virtuelle bridge. Nous demandons à systemd de créer un périphérique nommé br0 qui fonctionne comme un pont Ethernet.

/etc/systemd/network/mybridge.netdev

[NetDev]
Name=br0
Kind=bridge

Astuce: systemd-networkd attribue au pont une adresse MAC générée à partir du nom de l'interface et de l'ID de la machine. Cela peut provoquer des problèmes de connexion, par exemple en cas de routage basé sur le filtrage MAC. Pour contourner ces problèmes, vous pouvez attribuer une adresse MAC à votre passerelle, probablement la même que celle de votre périphérique physique, en ajoutant la ligne MACAddress=xx:xx:xx:xx:xx:xx dans la section NetDev ci-dessus.

Redémarrez systemd-networkd.service pour que systemd crée le pont.

Pour consulter le pont nouvellement créé sur l'hôte et sur le conteneur, tapez :

$ ip a

3 : br0 : <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default 
    link/ether ae:bd:35:ea:0c:c9 brd ff:ff:ff:ff:ff:ff:ff

Notez que l'interface br0 est listée mais est toujours DOWN à ce stade.

Lier Ethernet au pont

L'étape suivante consiste à ajouter une interface réseau au pont nouvellement créé. Dans l'exemple ci-dessous, nous ajoutons toute interface qui correspond au nom en* au pont br0.

/etc/systemd/network/bind.network

[Match]
Name=en*

[Network]
Bridge=br0

L'interface Ethernet ne doit pas avoir de DHCP ou d'adresse IP associée car le pont a besoin d'une interface à laquelle se lier sans IP : modifiez le /etc/systemd/network/MyEth.network correspondant en conséquence pour supprimer l'adressage.

Réseau du pont

Maintenant que le pont a été créé et qu'il a été lié à une interface réseau existante, la configuration IP de l'interface du pont doit être spécifiée. Ceci est défini dans un troisième fichier .network, l'exemple ci-dessous utilise DHCP.

/etc/systemd/network/mybridge.network

[Match]
Name=br0

[Network]
DHCP=ipv4

Configurer le conteneur

Utilisez l'option --network-bridge=br0 lors du démarrage du conteneur. Consultez Systemd-nspawn#Use a network bridge pour plus de détails.

Résultat

sur l'hôte

$ ip a

3 : br0 : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff:ff
    inet 192.168.1.87/24 brd 192.168.1.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::16da:e9ff:feb5:7a88/64 scope link 
       valid_lft forever preferred_lft forever
6 : vb-MyContainer : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether d2:7c:97:97:37:25 brd ff:ff:ff:ff:ff:ff:ff
    inet6 fe80::d07c:97ff:fe97:3725/64 scope link 
       valid_lft forever preferred_lft forever

sur le conteneur

$ ip a

2 : host0 : <BROADCAST,MULTICAST,ALLMULTI,AUTOMEDIA,NOTRAILERS,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 5e:96:85:83:a8:5d brd ff:ff:ff:ff:ff:ff:ff
    inet 192.168.1.73/24 brd 192.168.1.255 scope global host0
       valid_lft forever preferred_lft forever
    inet6 fe80::5c96:85ff:fe83:a85d/64 scope lien 
       valid_lft forever preferred_lft forever

Avertissement

Nous avons maintenant une adresse IP pour br0 sur l'hôte et une pour host0 dans le conteneur.
deux nouvelles interfaces sont apparues : vb-MyContainer dans l'hôte et host0 dans le conteneur. Ceci est le résultat de l'option --network-bridge=br0 comme expliqué dans Systemd-nspawn#Use a network bridge pour plus de détails.
l'adresse DHCP sur host0 provient du fichier /usr/lib/systemd/network/80-container-host0.network du système.
sur l'hôte

$ brctl show

bridge name	bridge id		STP enabled	interfaces
br0		8000.14dae9b57a88	no		enp7s0
							vb-MyContainer

la sortie de la commande ci-dessus confirme que nous avons un pont avec deux interfaces liées à.

sur l'hôte

$ ip route

default via 192.168.1.254 dev br0 
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.87

sur le conteneur

$ ip route

default via 192.168.1.254 dev host0 
192.168.1.0/24 dev host0 proto kernel scope link src 192.168.1.73

Les résultats de la commande ci-dessus confirment que nous avons activé les interfaces {ic|br0}} et {ic|host0}} avec une adresse IP et une passerelle 192.168.1.254. L'adresse de la passerelle a été automatiquement récupérée par systemd-networkd.

Pont réseau avec adresses IP statiques

Définir une adresse IP statique pour chaque appareil peut être utile dans le cas de services web déployés (par exemple FTP, http, SSH). Chaque périphérique conservera la même adresse MAC lors des redémarrages si le fichier /usr/lib/systemd/network/99-default.link de votre système possède l'option MACAddressPolicy=persistent (par défaut). Ainsi, vous pourrez facilement router n'importe quel service sur votre passerelle vers le périphérique souhaité.

La configuration suivante doit être effectuée pour cette installation :

sur l'hôte

La configuration est très similaire à celle de la section #Pont réseau avec DHCP. Tout d'abord, une interface de pont virtuelle doit être créée et l'interface physique principale doit lui être liée. Cette tâche peut être accomplie avec les deux fichiers suivants, dont le contenu est identique à celui de la section DHCP.

/etc/systemd/network/MyBridge.netdev
/etc/systemd/network/MyEth.network

Ensuite, vous devez configurer l'IP et le DNS de l'interface de pont virtuel nouvellement créée. Par exemple :

/etc/systemd/network/MyBridge.network

[Match]
Name=br0

[Network]
DNS=192.168.1.254
Address=192.168.1.87/24
Gateway=192.168.1.254

sur le conteneur

Pour obtenir la configuration d'une adresse IP statique sur le conteneur, nous devons remplacer le fichier /usr/lib/systemd/network/80-container-host0.network du système, qui fournit une configuration DHCP pour l'interface réseau host0 du conteneur. Pour ce faire, il suffit de placer la configuration dans /etc/systemd/network/80-container-host0.network. Par exemple :

/etc/systemd/network/80-container-host0.network

[Match]
Name=host0

[Network]
DNS=192.168.1.254
Address=192.168.1.94/24
Gateway=192.168.1.254

Assurez-vous que systemd-networkd.service est activé dans le conteneur.

Trucs et astuces

Interface et intégration au bureau

systemd-networkd ne dispose pas d'une interface de gestion interactive appropriée, que ce soit via le shell de ligne de commande ou graphique.

Néanmoins, certains outils sont disponibles pour afficher l'état actuel du réseau, recevoir des notifications ou interagir avec la configuration sans fil :

networkctl (via CLI) offre un vidage simple des états de l'interface réseau.
Lorsque networkd est configuré avec wpa_supplicant, wpa_cli et wpa_gui offrent la possibilité d'associer et de configurer les interfaces WLAN dynamiquement.
networkd-notify-git^AUR peut générer des notifications simples en réponse aux changements d'état de l'interface réseau (tels que la connexion/déconnexion et la réassociation).
Le daemon networkd-dispatcher^AUR permet d'exécuter des scripts en réponse aux changements d'état de l'interface réseau, de manière similaire à NetworkManager-dispatcher.
Comme pour le résolveur DNS systemd-resolved, les informations sur les serveurs DNS actuels peuvent être visualisées avec resolvectl status.

Configuration d'une IP statique ou DHCP basée sur le SSID (emplacement)

Il arrive souvent que le réseau sans fil de votre domicile utilise le DHCP et que le réseau sans fil de votre bureau utilise une IP statique. Cette configuration mixte peut être configurée comme suit :

Note: Le numéro dans le nom du fichier décide de l'ordre dans lequel les fichiers sont traités. Vous pouvez [Match] en fonction du SSID, du BSSID ou des deux.

/etc/systemd/network/24-wireless-office.network

# special configuration for office WiFi network
[Match]
Name=wlp2s0
SSID=office_ap_name
#BSSID=aa:bb:cc:dd:ee:ff

[Network]
Address=10.1.10.9/24
Gateway=10.1.10.1
DNS=10.1.10.1
#DNS=8.8.8.8

/etc/systemd/network/25-wireless-dhcp.network

# use DHCP for any other WiFi network
[Match]
Name=wlp2s0

[Network]
DHCP=ipv4

Collage d'une interface filaire et sans fil

Consulter également Liaison sans fil.

Le bonding permet le partage de la connexion à travers plusieurs interfaces, donc si par exemple l'interface filaire est débranchée, le sans-fil reste connecté et la connectivité du réseau reste en place de manière transparente.

Créez une interface de liaison. Dans ce cas, le mode est active-backup, ce qui signifie que les paquets sont acheminés par une interface secondaire si l'interface primaire tombe en panne.

/etc/systemd/network/30-bond0.netdev

[NetDev]
Name=bond0
Kind=bond

[Bond]
Mode=active-backup
PrimaryReselectPolicy=always
MIIMonitorSec=1s

Définissez l'interface filaire comme primaire :

/etc/systemd/network/30-ethernet-bond0.network

[Match]
Name=enp0s25

[Network]
Bond=bond0
PrimarySlave=true

Définissez le réseau sans fil comme secondaire :

/etc/systemd/network/30-wifi-bond0.network

[Match]
Name=wlan0

[Network]
Bond=bond0

Configurez l'interface de liaison comme vous le feriez pour une interface normale :

/etc/systemd/network/30-bond0.network

[Match]
Name=bond0

[Network]
DHCP=ipv4

Maintenant, si le réseau filaire est débranché, la connexion devrait rester via le sans fil :

$ networkctl

IDX LINK    TYPE     OPERATIONAL      SETUP     
  1 lo      loopback carrier          unmanaged 
  2 enp0s25 ether    no-carrier       configured
  3 bond0   bond     degraded-carrier configured
  5 wlan0   wlan     enslaved         configured

4 links listed.

Accélérer le démarrage lent de TCP

Sur une liaison à bande passante élevée avec une latence modérée (généralement une connexion Internet domestique supérieure à 10 Mbit/s), les paramètres par défaut de l'algorithme de démarrage lent TCP sont quelque peu conservateurs. Ce problème se manifeste par des téléchargements qui démarrent lentement et qui mettent plusieurs secondes à s'accélérer avant d'atteindre la pleine largeur de bande de la connexion. Il est particulièrement visible lors d'une mise à jour de pacman, où chaque paquet téléchargé démarre lentement et se termine souvent avant d'avoir atteint la vitesse maximale de la connexion.

Ces paramètres peuvent être ajustés pour que les connexions TCP démarrent avec des tailles de fenêtre plus grandes que les valeurs par défaut, évitant ainsi le temps qu'il faut pour qu'elles augmentent automatiquement à chaque nouvelle connexion TCP [1]. Bien que cela diminue généralement les performances sur les connexions lentes (ou si les valeurs sont trop élevées) en raison de la nécessité de retransmettre un plus grand nombre de paquets perdus, elles peuvent augmenter considérablement les performances sur les connexions avec une bande passante suffisante.

Il est important d'effectuer une analyse comparative avant et après la modification de ces valeurs pour s'assurer que la vitesse du réseau est améliorée et non réduite. Si vous ne consultez pas les téléchargements qui commencent lentement et s'accélèrent progressivement, il n'est pas nécessaire de modifier ces valeurs car elles sont déjà optimales pour la vitesse de votre connexion. Lors de l'évaluation comparative, veillez à effectuer des tests sur un serveur distant à haute et à basse vitesse pour vous assurer que vous n'accélérez pas l'accès aux machines rapides au détriment de l'accès aux serveurs lents.

Pour ajuster ces valeurs, modifiez le fichier .network de la connexion :

/etc/systemd/network/eth0.network

[Match]
Name=eth0

#[Network]
#Gateway=...  <-- Remove this if you have it, and put it in the Gateway= line below

[Route]
# This will apply to the gateway supplied via DHCP.  If you manually specify
# your gateway, put it here instead.
Gateway=_dhcp4

# The defaults for these values is 10.  They are a multiple of the MSS (1460 bytes).
InitialCongestionWindow=10
InitialAdvertisedReceiveWindow=10

Les valeurs par défaut de 10 fonctionnent bien pour les connexions plus lentes que 10 Mbit/s. Pour une connexion de 100 Mbit/s, une valeur de 30 fonctionne bien. La page de manuel systemd.network(5) § [ROUTE] SECTION OPTIONS indique qu'une valeur de 100 est considérée comme excessive.

Si le paramètre sysctl net.ipv4.tcp_slow_start_after_idle est activé, la connexion reviendra à ces paramètres initiaux après un certain temps d'inactivité (souvent très court). Si ce paramètre est désactivé, la connexion maintiendra une fenêtre plus élevée si une fenêtre plus grande a été négociée pendant le transfert de paquets. Quel que soit le paramètre, chaque nouvelle connexion TCP commencera avec les paramètres Initial* définis ci-dessus.

Le paramètre sysctl net.ipv4.tcp_congestion_control n'est pas directement lié à ces valeurs, car il contrôle la façon dont les fenêtres d'encombrement et de réception sont ajustées lorsqu'une liaison TCP est active, et particulièrement lorsque le chemin entre les deux hôtes est encombré et que le débit doit être réduit. Les valeurs Initial* ci-dessus définissent simplement les valeurs de fenêtre par défaut sélectionnées pour chaque nouvelle connexion, avant qu'un algorithme de congestion prenne le relais et les ajuste si nécessaire. Définir des valeurs initiales plus élevées raccourcit simplement une partie de la négociation pendant que l'algorithme de congestion tente de trouver les valeurs optimales (ou, à l'inverse, définir des valeurs initiales erronées ajoute un temps de négociation supplémentaire pendant que l'algorithme de congestion s'efforce de les corriger, ralentissant chaque connexion TCP nouvellement établie pendant quelques secondes supplémentaires).

Voir aussi

systemd-networkd(8)
Messages de Tom Gundersen sur le blog de Core OS
Comment configurer systemd-networkd avec wpa_supplicant (Instruction de WonderWoofy sur les forums Arch)