So konfigurieren Sie ein WireGuard Point-to-Site-VPN unter Debian 12

Beispielszenario: Maya nutzt einen Debian 12 VPS als persönlichen VPN-Zugangspunkt, wenn sie in einem Café arbeitet. Ihr Laptop soll den VPS über einen verschlüsselten WireGuard-Tunnel erreichen und seinen IPv4-Internetverkehr über diesen Server leiten. Dieses Beispiel ist kein Bericht über einen Live-Test; die unten angezeigten öffentlichen IPs, Schlüssel und Terminalausgaben sind Platzhalter oder beispielhafte Darstellungen.

Diese Konfiguration ist ein Point-to-Site-VPN: Ein Client verbindet sich mit einem Server. Sie nutzt die in Debian enthaltenen WireGuard-Tools, einen einzelnen Peer, IPv4-Weiterleitung und IPv4-NAT. Vorausgesetzt wird, dass der VPS über eine öffentliche oder per Portweiterleitung freigegebene IPv4-Adresse verfügt, mit sudo verwaltet werden kann und über UDP-Port 51820 erreichbar ist. Die Anleitung konfiguriert weder geroutetes IPv6 noch ein privates Netzwerk hinter dem VPS.

Planen Sie zuerst die Adressen und den Zugang.

Das Beispiel verwendet 10.8.0.0/24ein VPN, das sowohl 10.8.0.1auf dem Server als auch 10.8.0.2auf dem ersten Client von Maya eingerichtet ist. Verwenden Sie ein Subnetz, das sich nicht mit dem WLAN, dem Büronetzwerk oder den Cloud-Netzwerken des Clients überschneidet. Eine Kollision kann dazu führen, dass der Datenverkehr über die falsche Route geleitet wird, selbst wenn der Handshake erfolgreich war.

WireGuard verwendet Public-Key-Authentifizierung. Der Server benötigt den öffentlichen Schlüssel des Clients und der Client den öffentlichen Schlüssel des Servers; jeder private Schlüssel verbleibt auf dem Gerät, dem er gehört. Die WireGuard-Dokumentation von Debian beschreibt die Paket- und Peer-Konfiguration, während die WireGuard-Schnellstartanleitung die Schlüsselgenerierung und das Keepalive-Verhalten erläutert. Siehe die Debian-WireGuard-Dokumentation und die WireGuard-Schnellstartanleitung .

Konfigurieren Sie den Debian 12-Server

1. Installieren Sie die Werkzeuge

Aktualisieren Sie den Paketindex und installieren Sie WireGuard sowie nftables, wodurch die Beispielregel für IPv4-Masquerading bereitgestellt wird. Führen Sie diese Befehle auf dem VPS aus:

sudo apt update
sudo apt install wireguard nftables

Debian packt WireGuard über das wireguardMetapaket und die zugehörigen Tools. Falls der Server bereits einen Firewall-Manager wie UFW, firewalld oder vom Provider verwaltete Regeln verwendet, ermitteln Sie dessen aktiven Regelsatz, bevor Sie weitere Änderungen vornehmen. Ersetzen Sie keine bestehende Firewall-Konfiguration durch dieses Beispiel.

2. Suchen Sie die öffentliche Schnittstelle und aktivieren Sie die Weiterleitung.

Fragen Sie die Routing-Tabelle, welche Schnittstelle Debian verwendet, um eine externe IPv4-Adresse zu erreichen:

ip route get 1.1.1.1

Im Beispiel wird die Route verwendet eth0. Ihr VPS kann einen anderen Namen wie z ens3. B. oder anzeigen enp1s0; verwenden Sie den Namen aus Ihrer eigenen Ausgabe später in der NAT-Regel. Notieren Sie sich außerdem die öffentliche IPv4-Adresse oder den DNS-Namen des Servers. Befindet sich der Server hinter einem Router, leiten Sie UDP-Port 51820 von diesem Router an den Debian-Host weiter.

Für einen vollständigen Tunnel ist IPv4-Weiterleitung erforderlich. Aktivieren Sie diese jetzt, damit sie auch nach Neustarts erhalten bleibt:

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

Der letzte Befehl sollte eine Meldung ausgeben net.ipv4.ip_forward = 1. Diese Einstellung ermöglicht die Paketweiterleitung; sie öffnet jedoch nicht automatisch die Firewall und stellt kein NAT bereit.

3. Erstellen Sie das Serverschlüssel- und das Clientschlüsselpaar.

Erstellen Sie den Serverschlüssel auf dem Debian-Host mit restriktiven Dateiberechtigungen:

sudo install -d -m 700 /etc/wireguard
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/server.key; wg pubkey < /etc/wireguard/server.key > /etc/wireguard/server.pub'

Generieren Sie das Client-Schlüsselpaar nach Möglichkeit auf dem Client-Gerät. Auf einem Linux-Client mit wireguard-toolsinstalliertem:

umask 077
wg genkey | tee client.key | wg pubkey > client.pub

Erstellen Sie für ein Smartphone einen neuen Tunnel in der offiziellen WireGuard-App und lassen Sie die Profilschlüssel generieren. Kopieren Sie nur den öffentlichen Schlüssel des Clients auf den Server. Bewahren Sie client.keydiesen Schlüssel geheim auf; fügen Sie ihn niemals in die Serverkonfiguration ein oder senden Sie ihn im Chat. Die wichtigsten Befehle und Schnittstellenfelder sind im Debian Bookworm- wg(8)Handbuch dokumentiert.

4. Erstellen Sie die Serverschnittstelle und fügen Sie den Peer hinzu.

Erstellen Sie /etc/wireguard/wg0.confdie Datei mit folgender Struktur. Ersetzen Sie jeden Platzhalter in Großbuchstaben durch den entsprechenden echten Schlüssel. Lesen Sie den privaten Serverschlüssel lokal ein sudo cat /etc/wireguard/server.key; fügen Sie den öffentlichen Schlüssel des Clients im Abschnitt „Peer“ ein.

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.8.0.2/32

Schützen Sie die Datei, da sie einen privaten Schlüssel enthält:

sudo chown root:root /etc/wireguard/wg0.conf
sudo chmod 600 /etc/wireguard/wg0.conf

AllowedIPs = 10.8.0.2/32Weist diesem Peer eine VPN-Adresse zu und verhindert, dass ein anderer Peer diese beansprucht. Jedes weitere Gerät erhält ein eigenes Schlüsselpaar und eine eindeutige Adresse, z. B. 10.8.0.3/32. Verwenden Sie kein Clientprofil für mehrere Geräte, wenn Sie separate Widerrufs- oder Identitätsverwaltung benötigen.

5. IPv4-NAT hinzufügen und den WireGuard-Port zulassen

Für den beispielhaften vollständigen IPv4-Tunnel müssen ausgehende Pakete 10.8.0.0/24über die öffentliche Schnittstelle mit Quell-NAT gesendet werden. Fügen Sie eine entsprechende Regel zur bestehenden nftables-Konfiguration des Servers oder zum Firewall-Manager hinzu. Die folgende eigenständige nftables-Tabelle veranschaulicht die Regel; ersetzen Sie sie eth0durch die in Schritt 2 ermittelte Schnittstelle:

table ip wg_nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    ip saddr 10.8.0.0/24 oifname "eth0" masquerade
  }
}

Wenn Sie Debian verwenden nftables.service, integrieren Sie die Tabelle in die Konfiguration, die der Dienst beim Systemstart lädt, und überprüfen Sie die gesamte Datei, sudo nft -c -f /etc/nftables.confbevor Sie sie neu laden. Prüfen Sie, ob Ihre aktuelle Konfiguration bestehende Regeln löscht oder ersetzt, bevor Sie sie anwenden. NAT allein kann eine Weiterleitungsrichtlinie, die Datenverkehr verwirft, nicht außer Kraft setzen: Erlauben Sie die Weiterleitung von wg0der WAN-Schnittstelle und den Rückverkehr in Ihrer aktiven Firewall. Das Debian- nft(8)Handbuch dokumentiert das Laden von nftables-Regeln und NAT-Anweisungen.

Sowohl in der Firewall des VPS-Anbieters als auch in der Firewall des Hosts muss eingehender UDP-Verkehr über Port 51820 zugelassen werden. TCP-Port 51820 darf für diesen WireGuard-Tunnel nicht geöffnet werden. Die SSH-Zugriffsregel muss während der Änderung der Firewall-Richtlinien beibehalten werden. Im Falle einer Unterbrechung der Verbindung durch einen Firewall-Neustart sollte die Provider-Konsole oder ein anderer Wiederherstellungspfad verwendet werden.

Client konfigurieren und verbinden

6. Erstellen Sie das Kundenprofil.

Erstellen Sie einen neuen Tunnel in der WireGuard-Client-App oder speichern Sie eine Konfiguration wie diese auf einem Linux-Client. Ersetzen Sie den privaten Schlüssel, den öffentlichen Serverschlüssel und den Endpunkt durch Ihre tatsächlichen Werte. Die unten angegebene Adresse TEST-NET ist nur ein Beispiel und kann keinen echten Server erreichen.

[Interface]
Address = 10.8.0.2/32
PrivateKey = CLIENT_PRIVATE_KEY
DNS = 1.1.1.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

AllowedIPs = 0.0.0.0/0IPv4-Ziele werden über den Tunnel geleitet, daher ist dies die Option für einen vollständigen IPv4-Tunnel. Für einen schmalen Split-Tunnel, der nur die WireGuard-Serveradresse erreicht, verwenden Sie 10.8.0.0/24stattdessen [alternativer Pfad einfügen]. Um ein LAN hinter dem Server zu erreichen, fügen Sie das tatsächliche Subnetz dieses LANs in die Client-Konfiguration ein AllowedIPs, fügen Sie eine Rückroute oder ein geeignetes NAT hinzu und lassen Sie den Datenverkehr durch die Server-Firewall passieren. Diese Schritte hängen vom LAN-Router ab und werden in diesem Beispiel nicht behandelt.

PersistentKeepalive = 25Dies kann dazu beitragen, dass ein Client hinter einem NAT-Router nach längeren Inaktivitätsphasen erreichbar bleibt. Es ist optional; laut WireGuard-Dokumentation benötigen die meisten Benutzer es nicht, geben aber 25 Sekunden als allgemein sinnvolles Intervall an, in dem eine NAT-Zuordnung offen bleiben muss. Das DNSFeld wird von einigen Clients und Clients, die auf WireGuard basieren, unterstützt wg-quick; falls Ihre Anwendung es ignoriert, konfigurieren Sie die DNS-Einstellungen über die entsprechenden Einstellungen Ihrer Anwendung.

7. Starten Sie den Tunnel und überprüfen Sie den Handshake.

Unter Debian wird die Benutzeroberfläche beim Systemstart mit folgendem Befehl aktiviert:

sudo systemctl enable --now wg-quick@wg0
sudo wg show

Importieren oder aktivieren Sie das Clientprofil, sobald UDP-Port 51820 erreichbar ist. wg showÜberprüfen Sie in der Konfiguration, ob der erwartete Peer angezeigt wird und ob die Konfiguration latest handshakeaktualisiert wird, nachdem der Client Datenverkehr gesendet hat. Das wg-quick(8)Handbuch für Debian Bookworm beschreibt den von der systemd-Unit verwendeten Interface-Setup-Assistenten.

Ein fehlender Handshake deutet zunächst auf Erreichbarkeitsprobleme oder Schlüsselkonflikte hin: Überprüfen Sie die Endpunktadresse und den Port, die UDP-Firewallregeln, den Server-Schlüssel im Clientprofil, den Client-Schlüssel wg0.confund die Systemzeit. Ein Handshake ohne funktionierenden Datenverkehr deutet in der Regel auf Weiterleitung, NAT, Routenüberschneidungen oder eine Firewall-Weiterleitungsregel hin.

8. Überprüfen Sie den Datenverkehr und verstehen Sie das IPv6-Limit.

Nachdem der Client verbunden ist, testen Sie zuerst die Tunneladresse des Servers und anschließend die öffentliche IPv4-Adresse, die von einem externen IPv4-Adressprüfdienst angezeigt wird:

ping -c 3 10.8.0.1
curl -4 https://ifconfig.me

Der Ping sollte den Server erreichen, sofern ICMP zugelassen ist. Die externe IPv4-Prüfung sollte die öffentliche Ausgangsadresse des VPS für diese vollständige Tunnelkonfiguration anzeigen. Falls sich die öffentliche Adresse nicht ändert, überprüfen Sie AllowedIPsdie Weiterleitung, den Namen der NAT-Schnittstelle und die Weiterleitungsrichtlinie der Firewall.

Dieses Beispiel ist rein IPv4-basiert. AllowedIPs = 0.0.0.0/0IPv6 wird nicht geroutet, daher kann ein Client mit IPv6-Konnektivität weiterhin IPv6-Datenverkehr außerhalb des Tunnels senden. Beschreiben Sie diese Konfiguration nicht als vollständigen Dual-Stack-Datenschutztunnel. Um IPv6 über WireGuard zu übertragen, müssen Sie IPv6-Adressen für den Tunnel zuweisen und routen, die IPv6-Weiterleitung aktivieren, entsprechende Firewall- und Routing-Regeln konfigurieren und ::/0den Client erst dann hinzufügen, wenn dieser Pfad durchgängig funktioniert. Die Unterstützung durch den Provider variiert. Alternativ können Sie bewusst eine Split-Tunnel-Richtlinie wählen und das IPv6-Verhalten des Clients überprüfen.

Häufige Probleme und ein kurzer Schlusscheck

• Kein Handshake: Bestätigung eingehender UDP-Ports 51820 an den Firewalls von Provider und Host, der öffentlichen IP-Adresse oder des DNS-Servers des Endpunkts sowie der öffentlichen Schlüssel beider Seiten.
• Der Handshake funktioniert, aber die Webseiten werden nicht geladen: bestätigen Sie net.ipv4.ip_forward=1, dass die NAT-Regel die tatsächliche Ausgangsschnittstelle verwendet und die Firewall weitergeleiteten Datenverkehr zulässt.
• Nur einige Netzwerke sind nicht fehlerfrei: Prüfen Sie, ob 10.8.0.0/24es sich um ein lokales oder entferntes Netzwerk handelt. Nummerieren Sie den Tunnel gegebenenfalls neu und aktualisieren Sie dabei sowohl die Peers als auch die Firewall-Regel.
• Es funktioniert bis zum Neustart: Stellen Sie sicher, dass wg-quick@wg0es aktiviert ist und dass die Firewall- und sysctl-Einstellungen bei der normalen Systemkonfiguration beibehalten werden.
• IPv6 nutzt weiterhin die lokale Verbindung: Das ist bei diesem reinen IPv4-Beispiel zu erwarten. Konfigurieren und testen Sie eine IPv6-Tunnelroute, bevor Sie sich auf die vollständige Tunnel-Datenschutzgarantie verlassen.

Bevor Sie die Einrichtung als abgeschlossen betrachten, überprüfen Sie, ob der Serverdienst aktiv ist, wg showeinen kürzlich erfolgten Handshake meldet und die Übertragungszähler steigen, der Client erreichbar ist 10.8.0.1und eine IPv4-Ausgangsprüfung die öffentliche Adresse des Servers bestätigt. Starten Sie den Server erst neu, nachdem die Firewall- und Weiterleitungseinstellungen dauerhaft eingerichtet sind, und wiederholen Sie anschließend diese Prüfungen. Verwenden Sie für weitere Peers separate Schlüsselpaare und eindeutige Tunnel-IP-Adressen. Entfernen Sie anschließend ein Gerät, indem Sie dessen Peer-Eintrag löschen und die Schnittstelle neu laden.