Für eine WireGuard-Verbindung mit systemd-networkd und systemd-resolved.
Alle Konfigurationsdateien gehören in /etc/systemd/network/.
Interface #
Das WireGuard-Interface anlegen (muss mit einer Zahl beginnen, z.B. 10-wg0.netdev) (Dokumentation)
1[NetDev]
2Name=wg0
3Kind=wireguard
4Description=WireGuard-Tunnel für Casa Due Pur
5MTUBytes=1320
6
7[WireGuard]
8PrivateKey=...
9# Für alle Netze aus AllowedIPs soll automatisch eine Route erzeugt werden, in einer separaten Routing-Tabelle:
10RouteTable=123
11# Die verschlüsselten WireGuard-Pakete werden markiert:
12FirewallMark=123
13# Beides erlaubt spezielles Routing, konfiguriert in der *.network-Datei
14
15[WireGuardPeer]
16PublicKey=<Public Key>
17PresharedKey=...
18AllowedIPs=0.0.0.0/0,::1
19Endpoint = vpn.casa-due-pur.de:51194
20PersistentKeepalive=16
PrivateKey= und PresharedKey= entsprechend ausfüllen, den Rest sicherheitshalber nochmal abgleichen. Die Datei sollte für unprivilegierte Nutzer nicht lesbar sein, d.h. chown root:systemd-network ..., chmod 640 ....
Netzwerk #
Nun das passende Netzwerk zum Interface anlegen (z.B. wg0.network) (Dokumentation)
1[Match]
2Name=wg0
3
4[Network]
5Address=...
6Address=...
7
8# Nur Domains mit dieser Endung über diesen DNS auflösen:
9Domains=~casa-due-pur.de
10DNS=2a01:4f8:fff0:22:ca9:16ff:fe6e:cc14
11DNS=159.69.238.89
12DNSDefaultRoute=false
13
14[Link]
15RequiredForOnline=no
16# Optional: nicht automatisch beim Systemstart verbinden
17ActivationPolicy=manual
18
19# Die verschlüsselten WireGuard-Pakete sind mit 123 markiert und dürfen nicht über diese Verbindung geleitet werden.
20# Die WireGuard-spezifischen Routen sind in einer Tabelle mit id 123.
21# Diese Policy wendet die spezifischen Routen ausschliesslich auf unmarkierte Pakete an.
22[RoutingPolicyRule]
23FirewallMark=123
24Table=123
25InvertRule=true
26Family=both
Adressen (ipv4 und ipv6) eintragen. Der Tunnel kann mit networkctl up wg0 bzw networkctl down wg0 nach Bedarf verbunden und getrennt werden.
Sobald der Tunnel verbunden ist, lässt sich die Routing-Tabelle mit ip route show table 123 anzeigen. Die RoutingPolicy sollte in ip rule auftauchen.
DNS #
Wir haben jetzt zwei DNS-Server im System. Falls bei beiden Domains= gesetzt ist, muss der vorhandene Server explizite als default markiert werden (z.B. in eth0.network):
1[Network]
2DNSDefaultRoute=true
Firewall #
Es wird kein Routing konfiguriert, daher sind normalerweise keine Änderungen an iptables notwendig.
Am Beispiel einer Firewall mit striktem whitelisting sind mindestens folgende Verbindungen zu erlauben:
- WireGuard-Traffic zum Endpoint
iptables -A OUTPUT -m owner ! --uid-owner 0-99999 -p udp -d 159.69.238.84 --dport 51194 -j ACCEPT(Wireguard-Pakete kommen aus dem Kernel und sind keinem Benutzer zugeordnet) - Ausgehender traffic auf wg0:
iptables -A OUTPUT -o wg0 -j ACCEPT, ggf. mit-m owner --uid-owner ...auf einen Nutzer beschränkt. - DNS-Traffic über den Tunnel:
iptables -A OUTPUT -m owner --uid-owner systemd-resolve -d 159.69.238.89 -o wg0 j ACCEPT - Eingehende pings und andere ICMP-Pakete auf wg0:
iptables -A INPUT -i wg0 -p icmp -j ACCEPT - Optional anderer eingehender Traffic auf wg0, z.B. ssh:
iptables -A INPUT -i wg0 -p tcp --dport 22 -j ACCEPT(kann nicht nach Nutzer gefiltert werden)
Die Firewall muss verbindungsorientiert sein, üblicherweise mit einer der folgenden Methoden:
- Zugehörige Pakete werden direkt akzeptiert, z.B. mit
iptables -A INPUT/OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT(Tutorial) - Verbindungen werden markiert (statt
-j ACCEPTnutzt man-j CONNMARK --set-mark ...) und markierte Verbindungen werden erlaubt (iptables -A INPUT/OUTPUT -m connmark --mark ... -j ACCEPT). Diese Variante ist umständlicher, erlaubt aber Traffic Shaping oder separate Statistiken pro verwendeter Markierung.
Für ipv6 sind äquivalente Regeln einzurichten.
Per E-Mail antworten