systemd-networkd (Français)
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
.
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/ouIPv6AcceptRA=
dans la section[Network]
, etUseDNS=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
.
- Les options spécifiées dans les fichiers de configuration sont sensibles à la casse.
- Dans les exemples ci-dessous,
enp1s0
est l'adaptateur filaire etwlp2s0
est l'adaptateur sans fil. Ces noms peuvent être différents sur différents systèmes. Consultez Network configuration#Network 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*
ouNom=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 etType=wwan
pour WWAN. Notez queType=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.
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).
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
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
- 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 valeurs0
,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 | Valeur par défaut |
---|---|---|---|
Name= |
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) | |
Virtualization= |
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. systemd.network(5) § [NETWORK] SECTION OPTIONS | 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 |
---|---|---|---|
Address= |
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.
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.
/etc/systemd/network/wlan0.network
[Match] Name=wlan0 [Network] Address=10.1.1.1/24 DHCPServer=true IPMasquerade=ipv4 [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ôteVirtualization=
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. obligatoireKind=
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.
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 MACHost=
le nom de l'hôteVirtualization=
vérifie si le système fonctionne dans un environnement virtualiséType=
le type de périphérique, par exemple vlan
Section [Link]
MACAddressPolicy=
adresses persistantes ou aléatoires, ouMACAddress=
une adresse spécifiqueNamePolicy=
liste des politiques par lesquelles le nom de l'interface doit être défini, par exemple, noyau, garder
/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 avec un fichier d'unité netdev. 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
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éé. Son fichier de configuration doit être chargé avant ceux des interfaces liées, donc son fichier de configuration doit être alphanumériquement antérieur à ceux-ci. Dans l'exemple ci-dessous, nous ajoutons toute interface qui correspond au nom en* au pont br0.
/etc/systemd/network/10_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 pourhost0
dans le conteneur. - deux nouvelles interfaces sont apparues :
vb-MyContainer
dans l'hôte ethost0
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-gitAUR 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-dispatcherAUR 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 :
/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)