HomelabNerds

HOME LAB · SELFHOSTING · NETZWERK

Schlagwort: WireGuard

OPNsense WireGuard Remote-Zugriff: sauberes Routing ohne Regelchaos
Schwierigkeit: Mittel · Dauer: 35–65 Min · Ziel: OPNsense WireGuard Remote-Zugriff: sauberes Routing ohne Regelchaos

Kurzproblem und Zielbild
In vielen Homelabs funktioniert die Erstinstallation, aber der Dauerbetrieb wird schnell unübersichtlich. Dieses Tutorial zeigt einen reproduzierbaren Ablauf für OPNsense WireGuard Remote-Zugriff mit Fokus auf Stabilität, klare Checks und einfache Fehlerbehebung.
Ziel ist ein Setup, das nicht nur heute läuft, sondern auch nach Updates und Änderungen beherrschbar bleibt.

Voraussetzungen
- Aktuelles Debian/Ubuntu oder kompatible Appliance
- Administrative Rechte und Wartungsfenster
- Backup- oder Snapshot-Möglichkeit vor Änderungen
Schnellstart (funktionierende Basis)
```
# Basisprüfung
hostnamectl
ip a
# Dienste prüfen
systemctl --failed
# Logs kurz prüfen
journalctl -p 3 -xb --no-pager | tail -n 30
```
Was macht das? Du prüfst erst den Grundzustand und vermeidest, dass Altfehler in neue Änderungen hineinwirken.

Schritt-für-Schritt Umsetzung

1) Ausgangszustand dokumentieren
```
date -Iseconds
uname -a
# versions/relevante configs sichern
```
Erklärung: Mit einer kurzen Bestandsaufnahme lassen sich spätere Fehler schneller eingrenzen.

2) Kernkonfiguration sauber setzen
```
# hier die zentrale OPNsense WireGuard Remote-Zugriff-Konfiguration umsetzen
# Konfigdatei bearbeiten, nur notwendige Werte ändern
```
Erklärung: Ändere nur das Nötigste und halte die Konfiguration nachvollziehbar.

3) Dienst kontrolliert neu laden
```
sudo systemctl daemon-reload
sudo systemctl restart 
sudo systemctl status  --no-pager
```
4) Betriebsgrenzen testen
```
# Healthcheck/Endpoint prüfen
# Logs und Fehlerraten beobachten
```
Validierung / Checks
```
systemctl status  --no-pager
journalctl -u  -n 150 --no-pager
# funktionaler End-to-End Check
```
Troubleshooting
Konfiguration wird nicht übernommen
Ursache: Tippfehler oder veralteter Service-Reload.
```
sudo  --check
sudo systemctl daemon-reload
sudo systemctl restart 
```
Dienst läuft, Funktion aber fehlerhaft
Ursache: Abhängigkeit, DNS oder Routing nicht konsistent.
```
dig example.org
ip route
journalctl -u  -n 200 --no-pager
```
Fazit
Mit einem klaren Ablauf für OPNsense WireGuard Remote-Zugriff reduzierst du Ausfälle und erhöhst die Wartbarkeit deutlich. Der wichtigste Hebel ist die Kombination aus kleiner Änderung, sofortigem Check und dokumentiertem Ergebnis.
Nächster Schritt: den Ablauf als monatliche Betriebsroutine einplanen und regelmäßig gegen echte Störfälle testen.

Quellen
16.02.2026
WireGuard Site-to-Site im Homelab: stabile Basis mit systemd und Checks
Schwierigkeit: Mittel · Dauer: 35–55 Min · Ziel: Zwei Netze per WireGuard stabil verbinden und den Betrieb mit systemd absichern.

Kurzproblem und Zielbild
Site-to-Site-Setups sind oft instabil durch fehlende Keepalive-/Routing-Checks. Ziel: stabiler Tunnel mit definierten AllowedIPs, sauberem Autostart und reproduzierbarer Prüfung.

Voraussetzungen
- Zwei Linux-Systeme mit WireGuard
- Öffentlich erreichbarer Endpoint auf mindestens einer Seite
- Firewall-Freigabe UDP 51820
Schnellstart (funktionierende Basis)
```
sudo systemctl enable wg-quick@wg0.service
sudo systemctl start wg-quick@wg0.service
sudo wg show
```
Schritt-für-Schritt Umsetzung

1) Schlüssel erstellen
```
umask 077
wg genkey | tee privatekey | wg pubkey > publickey
```
2) Minimal-Konfig setzen
```
[Interface]
Address = 10.10.10.1/24
PrivateKey = <PRIVATE_KEY>
ListenPort = 51820

[Peer]
PublicKey = <PEER_PUBLIC_KEY>
AllowedIPs = 10.10.10.0/24, 192.168.50.0/24
Endpoint = vpn.example.tld:51820
PersistentKeepalive = 25
```
3) Start + Persistenz
```
sudo systemctl daemon-reload
sudo systemctl enable wg-quick@wg0.service
sudo systemctl restart wg-quick@wg0.service
```
4) Routing/Erreichbarkeit prüfen
```
ip route
ping -c 3 10.10.10.2
wg show
```
Validierung / Checks
```
systemctl status wg-quick@wg0 --no-pager
wg show
journalctl -u wg-quick@wg0 -n 120 --no-pager
```
Troubleshooting
Kein Handshake
```
sudo ss -lunp | grep 51820
sudo wg show
```
Handshake da, aber keine Route
```
ip route
# AllowedIPs/Forwarding prüfen
```
Fazit
Mit klarer Minimal-Konfig + systemd + festen Checks wird Site-to-Site-WireGuard im Homelab deutlich stabiler. Nächster Schritt: Monitoring auf Handshake-Alter und Paketzähler.

Quellen
16.02.2026
WireGuard Autostart mit systemd auf Debian/Ubuntu
Schwierigkeit: Leicht · Dauer: 10–20 Min · Ziel: WireGuard unter Linux via systemd zuverlässig beim Boot starten und sauber prüfen.

Kurzproblem und Zielbild

Viele WireGuard-Setups funktionieren nach manueller Aktivierung, starten aber nach einem Reboot nicht automatisch. Das führt zu Ausfällen bei Remote-Zugriffen oder Routing-Setups im Homelab.

Ziel in diesem Tutorial: Deine bestehende wg0.conf wird als systemd-Service eingebunden, automatisch gestartet und mit klaren Checks verifiziert.

Voraussetzungen
- Linux-Host (Debian/Ubuntu) mit installierten Paketen wireguard und wireguard-tools
- Funktionierende Konfiguration unter /etc/wireguard/wg0.conf
- Sudo-Rechte und Zugriff auf System-Logs
Schnellstart (funktionierende Basis)
```
sudo systemctl enable wg-quick@wg0.service
sudo systemctl daemon-reload
sudo systemctl start wg-quick@wg0.service
sudo systemctl status wg-quick@wg0.service --no-pager
```
Was macht das? Der Dienst wird im Autostart registriert, geladen und sofort gestartet. Danach siehst du direkt, ob wg0 sauber hochkommt.

Schritt-für-Schritt Umsetzung

1) Konfigurationsdatei prüfen
```
sudo ls -l /etc/wireguard/wg0.conf
sudo grep -E '^(\[Interface\]|Address|PrivateKey|ListenPort|\[Peer\]|PublicKey|AllowedIPs|Endpoint|PersistentKeepalive)' /etc/wireguard/wg0.conf
```
Erklärung: Stelle sicher, dass die Datei existiert und zentrale Felder gesetzt sind. Falsche Pfade oder Tippfehler sind die häufigste Ursache für Startprobleme.

2) Service im Autostart aktivieren
```
sudo systemctl enable wg-quick@wg0.service
sudo systemctl daemon-reload
```
Erklärung: enable erstellt die Boot-Verknüpfung. Mit daemon-reload stellst du sicher, dass systemd den aktuellen Stand nutzt.

3) Service starten und Zustand prüfen
```
sudo systemctl start wg-quick@wg0.service
sudo systemctl status wg-quick@wg0.service --no-pager
sudo wg show
ip a show wg0
```
Erklärung: Du prüfst sowohl Service-Status als auch Interface-/Peer-Status. So erkennst du, ob der Tunnel nur „läuft“ oder wirklich aktiv kommuniziert.

4) Reboot-Test (entscheidend)
```
sudo reboot
# nach dem Login
systemctl is-enabled wg-quick@wg0.service
systemctl status wg-quick@wg0.service --no-pager
wg show
```
Erklärung: Erst der Reboot-Test bestätigt den echten Autostart und vermeidet böse Überraschungen bei ungeplanten Neustarts.

Validierung / Checks
```
# 1) Service ist enabled
systemctl is-enabled wg-quick@wg0.service

# 2) Service läuft ohne Fehler
systemctl status wg-quick@wg0.service --no-pager

# 3) WireGuard Interface + Handshake
wg show

# 4) Letzte Logs
journalctl -u wg-quick@wg0 -n 120 --no-pager
```
Troubleshooting

Fehlerbild 1: „Unit wg-quick@wg0.service not found“

Ursache: Paket fehlt oder Service-Name passt nicht zur Config-Datei.
```
sudo apt update
sudo apt install -y wireguard wireguard-tools
ls /etc/wireguard/
# wenn Datei z. B. wg-homelab.conf heißt:
sudo systemctl enable wg-quick@wg-homelab.service
```
Fehlerbild 2: Service startet, aber kein Handshake

Ursache: Endpoint/Firewall/Port oder Routing passt nicht.
```
sudo wg show
sudo ss -lunpt | grep 51820
sudo journalctl -u wg-quick@wg0 -n 200 --no-pager
# ggf. UFW/iptables prüfen
```
Fazit

Mit wg-quick@wg0 im systemd-Autostart wird WireGuard im Homelab deutlich zuverlässiger betrieben – besonders bei Router-/Gateway-Szenarien oder Remote-Administration.

Nächster Schritt: ergänze ein kleines Monitoring (z. B. periodischer Check via Cron/Health-Script), damit Ausfälle früh erkannt werden.

Quellen
16.02.2026