Zur Sammlung der Programme zur Verwaltung des Computers, bietet systemd auch das Modul systemd-networkd an, das sich um die Konfiguration von Netzwerkzugängen kümmert. In Kombination mit wpa-supplicant lässt sich so einfach der Zugriff zu WLANs organisieren.

Für systemd-networkd befinden sich die Konfigurationsdateien in dem Verzeichnis /etc/systemd/network/. Dort kann man mehrere Dateien anlegen (der erste Treffer zählt) und über den Abschnitt [Match] bestimmen, wann der Inhalt der Datei gilt. Im einfachsten Fall aktiviert man für alle Netzwerkschnittstellen DHCP, aber kann auch noch zusätzliche Einstellungen festlegen; siehe systemd.network(5).

% cat /etc/systemd/network/20-dhcp.network
[Match]
Type=wlan ether

[Network]
DHCP=yes

Mit systemd-networkd kann man unter Debian ifupdown und NetworkManager ersetzen.

% apt purge resolvconf network-manager ifupdown
% systemctl enable --now systemd-networkd

WLAN-Verwaltung mit wpa-supplicant

Für die Verwaltung von WLAN-Zugängen, insbesondere für Netzwerke mit Verschlüsselung, hat sich wpa-supplicant etabliert. Aber nicht nur WLANs, sondern auch kabelgebundene Netzwerke mit IEEE 802.1X können von wpa-supplicant betreut werden.

Damit sich wpa-supplicant um einen bestimmten Anschluss kümmert, benötigt es eine Konfigurationsdatei /etc/wpa_supplicant/wpa_supplicant-.conf und über systemd muss ein entsprechender Dienst wpa_supplicant@ gestartet werden.

% cat /etc/wpa_supplicant/wpa_supplicant-wlp59s0.conf
ctrl_interface=/var/run/wpa_supplicant

eapol_version=1
ap_scan=1
fast_reauth=1

# Offenes WLAN (keine Verschlüsselung)
network={
        ssid="www.freifunk-jena.de"
        key_mgmt=NONE
        priority=5
}

# Verschlüsseltes WLAN mit (PSK)
# Eintrag erstellt mit (wpa_passphrase private 12345678)
network={
        ssid="private"
        psk=5bf4bef0551a4aa78e46a765da91836427fadd24e986cde757a68c7bd17044c9
}

% sudo systemctl enable --now wpa_supplicant@wlp59s0

Caching der DNS-Abfragen

Neben dem Modul systemd-networkd zur Konfiguration der Netzwerkzugänge bietet systemd auch noch das Modul systemd-resolved für DNS-Anfragen, um Antworten zum Beispiel zwischenzuspeichern; damit lässt sich dnsmasq ersetzen.

% sudo apt remove dnsmasq-base
% sudo systemctl enable --now systemd-resolved

DNSSec erzwingen

Mit systemd-resolved kann man die Prüfung der DNSSec‐Signaturen erzwingen. Hierfür ist jedoch ein DNS‐Server notwendig, der DNSSec unterstützt; Liste von OpenNic. In /etc/systemd/resolved.conf kann man dies festlegen:

[Resolve]
# https://duckduckgo.com/?q=free+dns+server&t=ffsb&ia=answer&iax=answer
DNS=208.67.222.222 37.235.1.174 209.244.0.4 2620:0:ccd::2 2001:910:800::12 2001:67c:28a4::
DNSSEC=yes

Daraufhin sollte diese Abfrage des Resolver-Tests fehlschlagen:

% host sigfail.verteiltesysteme.net
Host sigfail.verteiltesysteme.net not found: 2(SERVFAIL)
% resolvectl query sigfail.verteiltesysteme.net
sigfail.verteiltesysteme.net: resolve call failed: DNSSEC validation failed: invalid

Siehe: Archlinux-Wiki

Kabelgebundene Netzwerke bevorzugen

Um manchmal die höhere Bandbreite einer Kabelverbindung gegenüber der WLAN-Verbindung nutzen zu können, verwende ich den Ethernet-Anschluss zum Router. In solchen Fällen gibt es dann zwei Standardwege in die weite Welt:

% ip route
default via 192.168.178.1 dev enx9cebe81fc proto dhcp src 192.168.178.20 metric 512
default via 192.168.178.1 dev wlp59s0 proto dhcp src 192.168.178.22 metric 1024
192.168.178.0/24 dev wlp59s0 proto kernel scope link src 192.168.178.22
192.168.178.0/24 dev enx9cebe81fc proto kernel scope link src 192.168.178.20
192.168.178.1 dev enx9cebe81fc proto dhcp scope link src 192.168.178.20 metric 512
192.168.178.1 dev wlp59s0 proto dhcp scope link src 192.168.178.22 metric 1024

Über die Metrik eines Eintrags in der Routing-Tabelle kann man steuern, welche Verbindung bevorzugt verwendet wird, wenn es mehrere Möglichkeiten gibt. Eine kleine Zahl steht dabei für eine höhere Priorität. Um dem die Ethernet-Verbindung der WLAN-Verbindung vorzuziehen, weiße ich diese Einträgen mithilfe von systemd-networkd eine RouteMetric=512 zu. Hierfür habe ich eine Konfigurationsdatei /etc/systemd/network/10-prefer-wired.network, die für Netzwerkgeräte, deren Name mit en beginnt, eingerichtet:

[Match]
Name=en*

[Network]
DHCP=yes

[DHCP]
RouteMetric=512

Punkt-zu-Punkt-Verbindungen (bei OVH)

Bei einer virtuellen Maschine des Anbieters OVH bin ich auf eine interessante Interpretation der Netzwerkkonfiguration bzw. ‑anbindung gestoßen: »Der (Default‑)Gateway wird als direkte Gegenstelle (Peer) betrachtet, so als seien beide Systeme mit einem Kabel verbunden.« In der Praxis ist dies ja auch der Fall, denn Bus-Verkabelungen gibt es in der Regel nicht mehr. Deshalb können die virtuelle Maschine und der Gateway auch IP-Adressen aus völlig unterschiedlichen Netzwerksegmenten haben, was mich anfangs sehr verwirrt hat.

Diese Peer-Konfiguration wird vom Kernel und auch von Systemd-Networkd unterstützt:

[Match]
Name=en*

[Network]
DNS=213.186.33.99
Gateway=x.x.x.254
Gateway=2001:41d0:1:4ff:ff:ff:ff:ff

[Address]
Address=x.x.x.x/32
Peer=x.x.x.254/32

[Address]
Address=2001:41d0:1:46e::/128
Peer=2001:41D0:1:4ff:ff:ff:ff:ff/128