WireGuard verstehen: Cryptokey Routing und AllowedIPs

Wie WireGuard funktioniert – in einer Idee

WireGuard bindet jedes Paket an einen öffentlichen Schlüssel. Dieser Mechanismus heißt Cryptokey Routing und bildet das gesamte Design: Die Zeile AllowedIPs neben einem Peer ist die Routingtabelle für Pakete, die Ihren Rechner verlassen, und die Zugriffskontrollliste für Pakete, die von diesem Peer eintreffen. Eine Einstellung, zwei Aufgaben. Lesen Sie AllowedIPs auf diese Weise, und jede WireGuard-Konfigurationsdatei wird verständlich.

Es gibt keine Sitzungstabelle, die nach IP-Adresse indiziert ist, und keine Benutzerdatenbank. Ein Peer besteht aus einem öffentlichen Schlüssel und der Menge der Adressen, die dieser Schlüssel verwenden darf. Der Handshake und die Timer sorgen dafür, dass diese Zuordnung auch bei Änderungen im darunterliegenden Netzwerk erhalten bleibt. Wenn Sie zuerst einen funktionierenden Tunnel einrichten möchten, erstellen Sie ihn mit einem selbst gehosteten WireGuard-VPN auf Ihrem eigenen VPS und kehren Sie anschließend hierher zurück, wenn Sie eine Konfigurationszeile überrascht.

AllowedIPs ist eine Routingtabelle und eine Zugriffsliste

Betrachten Sie zuerst die ausgehende Richtung. Ihr Kernel routet ein Paket wie gewohnt über die Hauptroutingtabelle zum Gerät wg0. WireGuard vergleicht dann die Zieladresse dieses Pakets mit einer Tabelle, die die erlaubten Präfixe aller Peers enthält. Dabei wird zuerst das längste passende Präfix verwendet. Ein Treffer bestimmt einen Peer. Dieser verweist auf einen öffentlichen Schlüssel, der wiederum einen Sitzungsschlüssel und einen UDP-Endpunkt bestimmt. Das Paket wird für diesen Peer verschlüsselt und an ihn gesendet.

Wenn das AllowedIPs keines Peers das Ziel abdeckt, wird nichts gesendet. Es gibt dann keinen Schlüssel, mit dem das Paket verschlüsselt werden kann.

ping: sendmsg: Required key not available

Diese Fehlermeldung hat nur eine Ursache: Die Adresse, die Sie erreichen wollten, ist bei keinem Peer eingetragen. Die andere Fehlermeldung ping: sendmsg: Destination address required bedeutet, dass zwar ein Peer gefunden wurde, WireGuard aber keinen Endpunkt für ihn besitzt, weil weder einer konfiguriert wurde noch bereits einer ermittelt werden konnte.

Nun zur eingehenden Richtung. Ein UDP-Paket trifft am Listen-Port ein. WireGuard ermittelt anhand des Receiver-Index im Header die Sitzung, prüft den Zähler gegen ein gleitendes Replay-Fenster und entschlüsselt und authentifiziert anschließend die Nutzdaten. Erst danach liest WireGuard das innere Paket. Dessen Quelladresse muss innerhalb des AllowedIPs des sendenden Peers liegen. Andernfalls wird das Paket verworfen. Bei aktiviertem dynamischem Debugging gibt der Kernel den Grund in einer Zeile wie dieser aus:

wg0: Packet has unallowed src IP (10.8.0.9) from peer 2 (203.0.113.10:51820)

Deshalb erhält ein Peer auf der Serverseite ein /32. Ein Peer mit der Konfiguration AllowedIPs = 10.8.0.2/32 darf Pakete von 10.8.0.2 und von keiner anderen Adresse senden. Tragen Sie stattdessen dort 0.0.0.0/0 ein, darf dieser einzelne Client Pakete mit jeder Quelladresse innerhalb Ihres Tunnels einschleusen, auch mit der eines anderen Clients.

Überlappende Präfixe werden anhand ihrer Spezifität aufgelöst, da die Suche das längste passende Präfix verwendet. Identische Präfixe bei zwei Peers verhalten sich anders: Der Eintrag wird dem Peer zugewiesen, der zuletzt konfiguriert wurde. Der erste Peer empfängt diesen Datenverkehr dann nicht mehr, ohne dass irgendwo eine Fehlermeldung ausgegeben wird. wg show wg0 allowed-ips gibt die Tabelle aus, die tatsächlich im Kernel vorhanden ist. Diese ist maßgeblich, wenn der Zustand auf der Festplatte und der laufende Zustand voneinander abweichen.

Eine Konfigurationsdatei mit Blick auf Cryptokey Routing lesen

Die Serverseite:

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <server private key>

[Peer]
PublicKey = <laptop public key>
AllowedIPs = 10.8.0.2/32

Die Clientseite:

[Interface]
Address = 10.8.0.2/32
PrivateKey = <laptop private key>

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Dasselbe Schlüsselwort hat auf den beiden Seiten eine entgegengesetzte Bedeutung. Auf dem Client bedeutet es: „Jedes Ziel an diesen Peer senden“. Auf dem Server bedeutet es: „Von diesem Peer nur diese eine Adresse akzeptieren“. Die Asymmetrie liegt in den Werten, nicht in einer bestimmten Rolle.

Die Hälfte dieser Schlüssel gehört überhaupt nicht zum Protokoll. Address, DNS, MTU, PostUp und SaveConfig gehören zu wg-quick, dem Shell-Skript, das das Interface aktiviert. Der Kernel sieht diese Werte nie. wg-quick strip wg0 gibt die reduzierte Konfiguration aus, die das Tool wg tatsächlich lädt. Das ist der schnellste Weg, diese Trennung zu erkennen.

Was der Handshake tatsächlich macht

Der Handshake von WireGuard verwendet Noise_IKpsk2 aus dem Noise Protocol Framework. Der Teil IK ist für die Systemadministration entscheidend: Der statische öffentliche Schlüssel des Responder ist dem Initiator bereits bekannt, weil er in Ihrem [Peer]-Block als PublicKey eingetragen ist. Der Initiator sendet seinen eigenen statischen öffentlichen Schlüssel verschlüsselt in der ersten Nachricht. Daher gibt es keinen Zertifikatsaustausch und keinen gegenseitigen Identitätsaustausch. Ein passiver Beobachter kann nicht erkennen, welcher Schlüssel die Verbindung aufbaut, sofern er nicht über den privaten Schlüssel des Responder verfügt.

Der Preis dafür ist ein Round Trip. Die Initiierungsnachricht ist 148 Bytes groß, die Antwort 92 Bytes. Danach werden sofort Daten übertragen. Jede Seite erzeugt für jeden Handshake ein neues flüchtiges Curve25519-Schlüsselpaar. Die Sitzungsschlüssel werden aus einer Kette von Diffie-Hellman-Ergebnissen abgeleitet, in die die statischen und flüchtigen Schlüssel einfließen. Die privaten flüchtigen Schlüssel werden anschließend verworfen. Das bietet Forward Secrecy: Selbst wenn jemand Ihren Datenverkehr heute aufzeichnet und im nächsten Jahr den privaten Schlüssel des Servers stiehlt, kann er die aufgezeichneten Daten nicht lesen.

Eine Handshake-Initiierung enthält einen TAI64N-Zeitstempel. Jeder Peer merkt sich den größten Zeitstempel, den er vom anderen Peer gesehen hat. Dadurch werden wiederholte Initiierungen abgewiesen. Datenpakete enthalten einen 64-Bit-Zähler, der als Nonce verwendet wird. Der Empfänger verwaltet ein gleitendes Fenster bereits empfangener Zählerwerte. Dadurch werden Wiederholungen und starke Umordnungen ohne einen TCP-ähnlichen Verbindungsstatus verarbeitet.

Sitzungsschlüssel bleiben nicht lange gültig. Die Timer sind fest im Code hinterlegt und können nicht konfiguriert werden.

[
  {
    "label": "REKEY_TIMEOUT",
    "seconds": 5,
    "notes": "resend a handshake initiation that got no answer"
  },
  {
    "label": "KEEPALIVE_TIMEOUT",
    "seconds": 10,
    "notes": "send a keepalive after receiving data and sending none back"
  },
  {
    "label": "REKEY_ATTEMPT_TIME",
    "seconds": 90,
    "notes": "give up on the handshake and report the peer as down"
  },
  {
    "label": "REKEY_AFTER_TIME",
    "seconds": 120,
    "notes": "sender begins a fresh handshake for a new session key"
  },
  {
    "label": "REJECT_AFTER_TIME",
    "seconds": 180,
    "notes": "the old session key is refused and traffic stops"
  }
]

Dies sind Konstanten aus der Protokollspezifikation und keine Messwerte. Die 5 Konstanten steuern den gesamten Lebenszyklus der Sitzung. Nach 120 Sekunden aktiver Nutzung beginnt der Sender einen neuen Handshake. Nach 180 Sekunden wird der alte Schlüssel endgültig abgelehnt. Der Datenverkehr wird daher angehalten, bis ein neuer Handshake abgeschlossen ist. Wenn eine Initiierung keine Antwort erhält, wird sie alle 5 Sekunden erneut gesendet und nach 90 Sekunden aufgegeben. Deshalb gibt wg show latest handshake als relatives Alter aus und deshalb bleibt dieses Alter bei einem ausgelasteten, funktionierenden Tunnel niedrig. Wenn das Alter steigt, während Sie aktiv Daten senden, schlagen die Handshakes fehl. Das bedeutet nicht, dass der Tunnel inaktiv ist.

Warum ein Peer keine Client- oder Serverrolle hat

Beide Seiten führen denselben Code mit demselben Konfigurationsformat aus. Es gibt keinen Servermodus. Die wahrgenommene Asymmetrie entsteht durch Endpoint, und Endpoint ist optional.

Ein Peer mit konfiguriertem Endpunkt kann einen Handshake starten. Ein Peer ohne Endpunkt wartet und übernimmt die Adresse und den Port der anderen Seite aus dem ersten Paket, das erfolgreich authentifiziert wird. Dieser gelernte Endpunkt wird gespeichert und bei jedem gültigen Paket von einer neuen Adresse aktualisiert. So funktioniert Roaming: Wechselt ein Laptop von WLAN zu einem Mobilfunknetz, bleibt derselbe Tunnel bestehen, weil eine Sitzung anhand von Schlüssel und Index und nicht anhand der IP-Adresse identifiziert wird. Es wird keine Verbindung erneut hergestellt, weil zuvor keine Verbindung im Sinne von TCP bestand.

Aus demselben Mechanismus ergibt sich ein wichtiger Punkt: Der Peer mit der öffentlichen Adresse speichert immer die zuletzt bekannte öffentliche IP-Adresse der anderen Seite, und wg show gibt sie aus.

Feste Primitiven, keine Aushandlung

WireGuard verfügt über keine Ciphersuite-Liste. Für authentifizierte Verschlüsselung wird ChaCha20-Poly1305 verwendet, für die Schlüsselaushandlung Curve25519, für Hashing BLAKE2s und für die Schlüsselableitung HKDF. Jede Bereitstellung verwendet diese Primitiven. Daher gibt es keine Aushandlungsphase, die verarbeitet werden muss, und keinen Downgrade-Pfad zu einer schwächeren Option. Dieser Kompromiss ist real: Wird eine dieser Primitiven gebrochen, ist eine neue Version des gesamten Protokolls und eine Aktualisierung an beiden Enden erforderlich, keine Konfigurationsänderung. Diese eine Entscheidung entfernt den größten Teil des Codes und der Fehlerfälle, die ein TLS-basierter Tunnel mit sich bringt. Darauf läuft der Vergleich in WireGuard im Vergleich zu OpenVPN im Wesentlichen hinaus.

Warum der Port auf einen Scanner nicht antwortet

Jede Handshake-Nachricht enthält ein Feld namens mac1. Dabei handelt es sich um einen MAC (Message Authentication Code), der über die Nachricht mit einem aus dem statischen öffentlichen Schlüssel des Responders abgeleiteten Schlüssel berechnet wird. Ein Sender, der diesen öffentlichen Schlüssel nicht kennt, kann keinen gültigen mac1 erzeugen. Der Empfänger verwirft ein solches Paket daher vollständig ohne Antwort. Es gibt keine Fehlermeldung, keinen Reset und keine ICMP-Nachricht.

Das sichtbare Ergebnis ist ein UDP-Scan, bei dem keine Antwort eingeht.

sudo nmap -sU -p 51820 vpn.example.com

nmap meldet open|filtered. Das ist dieselbe Antwort wie bei einem Port, dessen Pakete eine Firewall ohne Rückmeldung verwirft. Der Port verhält sich für einen Absender, der Ihren öffentlichen Schlüssel nicht bereits besitzt, gleich, unabhängig davon, ob WireGuard lauscht oder nicht.

Ein zweites Feld, mac2, schützt vor DoS-Belastung. Wenn der Empfänger stark ausgelastet ist, beantwortet er eine gültige Initiation mit einer an die Quelladresse des Senders gebundenen 64-Byte-Cookie-Antwort. Aufwendige Public-Key-Berechnungen führt er erst aus, wenn der Sender dieses Cookie zurücksendet. Dadurch wird bestätigt, dass die Quelladresse tatsächlich erreichbar ist, bevor CPU-Zeit dafür aufgewendet wird. Diese Funktion wird nur unter Last aktiviert.

Warum 0.0.0.0/0 einen Peer zu Ihrer Standardroute macht

Da AllowedIPs die Routing-Tabelle ist, beansprucht AllowedIPs = 0.0.0.0/0, ::/0 jedes Ziel für diesen Peer. Das ist die vollständige Full-Tunnel-Konfiguration.

Die Routing-Konfiguration, die dies ermöglicht, ist interessanter als die Zeile selbst. Eine einfache Standardroute über wg0 würde eine Schleife erzeugen, weil das verschlüsselte UDP-Paket mit Ihrem Datenverkehr ebenfalls das System verlassen muss und dabei seine eigene Standardroute verwenden würde. wg-quick verhindert dies durch Policy Routing. Die eigenen ausgehenden Pakete von WireGuard werden mit einem fwmark markiert. Die Standardroute des Tunnels wird in eine separate Routing-Tabelle eingetragen. Zusätzlich werden Regeln angelegt, sodass nur nicht markierter Datenverkehr diese Route verwendet. Führen Sie ip rule show aus. Das Ergebnis sieht so aus:

32764:	from all lookup main suppress_prefixlength 0
32765:	not from all fwmark 0xca6c lookup 51820
32766:	from all lookup main

0xca6c entspricht 51820 in Hexadezimaldarstellung. 51820 ist außerdem die Tabellennummer. Die Regel suppress_prefixlength 0 sorgt dafür, dass die Haupttabelle ihre eigene Standardroute überspringt. Dadurch haben spezifische Routen wie Ihr lokales Subnetz weiterhin Vorrang, während der übrige Datenverkehr an die Tunnel-Tabelle weitergeleitet wird. Ein Split-Tunnel benötigt dies nicht. Eine spezifischere Liste wie AllowedIPs = 10.8.0.0/24, 10.20.0.0/16 wird als gewöhnliche Route in die Haupttabelle eingetragen.

Ein Full-Tunnel behebt die Namensauflösung nicht automatisch. Der Resolver, den Ihr Client normalerweise vom lokalen Netzwerk übernommen hat, bleibt in der Regel aktiv, und seine Route ist spezifischer. Das ist eine separate Aufgabe, die unter DNS-Leaks außerhalb eines WireGuard-Tunnels behandelt wird.

Wofür PersistentKeepalive tatsächlich gedacht ist

WireGuard sendet nichts, wenn kein Datenverkehr stattfindet. Es gibt keinen Heartbeat, keine Sitzungsaktualisierung und überhaupt keine Datenübertragung. Diese Ruhe schont den Akku und unterstützt den oben beschriebenen Scanner-Fall. Eine bestimmte Konfiguration funktioniert dadurch jedoch nicht.

Ein Peer hinter NAT (Network Address Translation) oder einer Stateful Firewall ist von außen nur erreichbar, solange in diesem Gerät ein Mapping besteht. Dieses Mapping wurde durch ein ausgehendes Paket erstellt. Übliche UDP-Mappings haben eine Gültigkeit von etwa 30 Sekunden. Läuft das Mapping ab, verwirft das zwischengeschaltete Gerät Pakete von der öffentlichen Seite. Der Tunnel wirkt dann unterbrochen, bis der Peer hinter NAT etwas sendet. PersistentKeepalive = 25 sendet alle 25 Sekunden ein leeres, authentifiziertes Paket. Dieser Abstand liegt unter der kürzesten üblichen Gültigkeitsdauer, sodass das Mapping geöffnet bleibt.

Setzen Sie die Option auf dem Peer hinter NAT. Ein Server mit einer öffentlichen Adresse und einem offenen UDP-Port benötigt sie nicht. Wenn Sie sie dort setzen, wird lediglich zusätzlicher Datenverkehr erzeugt. Verwechseln Sie die Option nicht mit dem automatischen Keepalive. Dieses wird 10 Sekunden nach dem Empfang von Daten durch einen Peer gesendet, wenn der Peer selbst nichts zurückzusenden hat. Es ist immer aktiviert und kann nicht konfiguriert werden.

Das Routing Ihres LANs über den Tunnel ist keine WireGuard-Funktion

Angenommen, Peer B befindet sich in einem Heimnetzwerk 192.168.50.0/24 und Peer A soll dieses erreichen. Dafür müssen zwei getrennte Systeme korrekt konfiguriert sein. Nur eines davon ist WireGuard.

Der Teil von WireGuard: Fügen Sie 192.168.50.0/24 zu AllowedIPs von B auf A hinzu. Dadurch routet A das Präfix zu B und akzeptiert von B Pakete mit diesen Quelladressen. Ohne diesen Eintrag kennt das Cryptokey-Routing weder einen Schlüssel für das Ziel noch eine Berechtigung für die Quelle.

Der Teil des Kernels: Auf B muss net.ipv4.ip_forward auf 1 gesetzt sein. Andernfalls verwirft der Kernel jedes entschlüsselte Paket, das nicht an B selbst adressiert ist. Die Forward-Kette der Firewall auf B muss den Datenverkehr erlauben. Die Hosts im LAN benötigen eine Route zurück zu 10.8.0.0/24. Alternativ muss B Source NAT anwenden, damit die Antworten über B zurückgesendet werden.

WireGuards Aufgabe endet, sobald das entschlüsselte Paket an den Kernel übergeben wurde. Alles danach ist gewöhnliches Linux-Routing und -Filtern. Deshalb tritt dieser Fehler in den Zählern von nft list ruleset oder in ip -s link show wg0 auf und nicht in wg show. Wenn Sie Peers lieber über eine Weboberfläche verwalten möchten, wg-easy in Docker ausführen die Peer-Einträge für Sie. Die Weiterleitungsregeln gehören jedoch weiterhin zum Host. Diese Aufteilung bleibt auch bestehen, wenn eine Koordinierungsschicht das Präfix für Sie verteilt: ein privates Netzwerk von einem VPS mit einem Tailscale-Subnetzrouter bekannt geben ersetzt die manuelle Bearbeitung von AllowedIPs auf jedem Peer. Das Weiterleitungs-sysctl und die Firewall-Regeln auf dem Router selbst müssen Sie jedoch weiterhin konfigurieren.

Warum WireGuard im Kernel läuft

wg0 ist ein Netzwerktreiber. Pakete erreichen ihn über den normalen Routing-Stack, werden im Softirq-Kontext verschlüsselt und verlassen das System über einen UDP-Socket, ohne jemals in den Userspace zu wechseln. Daraus ergibt sich der hohe Durchsatz. Deshalb umfasst das Modul auch nur rund viertausend Codezeilen. Es ist dadurch klein genug für Reviews und konnte im März 2020 in den Mainline-Kernel von Linux 5.6 aufgenommen werden. Ubuntu 24.04 und Debian 13 liefern es mit, sodass nur das Paket wireguard-tools fehlt.

Dass es sich um ein normales Interface handelt, hat praktische Folgen. tcpdump -ni wg0 zeigt die unverschlüsselten inneren Pakete, während tcpdump -ni eth0 udp port 51820 die verschlüsselten äußeren Pakete zeigt. Ein Vergleich der beiden zeigt sofort, in welcher Richtung die Verbindung fehlschlägt. netfilter und Traffic Shaping behandeln wg0 wie jedes andere Netzwerk-Interface. Wenn das Kernelmodul nicht verfügbar ist, beispielsweise bei einer Container-Virtualisierung mit gemeinsam genutztem Host-Kernel, implementiert wireguard-go dasselbe Protokoll im Userspace über ein TUN-Gerät. Das verringert den Durchsatz spürbar, weil jedes Paket die Kernel-Grenze zweimal passiert.

Wovor WireGuard Sie nicht schützt

Das Bedrohungsmodell ist absichtlich eng gefasst, und ein so unauffälliges Protokoll verleitet zu falschen Erwartungen. Formulieren Sie es klar.

• Es verbirgt nicht, dass Sie WireGuard verwenden. Handshake-Nachrichten haben feste Größen, das erste Byte gibt den Nachrichtentyp an, und der Transport erfolgt über UDP. Deep Packet Inspection erkennt dies problemlos, und ein Netzwerk, das VPNs nicht zulässt, kann den Datenverkehr blockieren. Obfuscation wurde bewusst nicht integriert.
• Es verbirgt weder das Datenvolumen noch den Zeitpunkt der Übertragung. Nutzdaten werden nur auf eine Grenze von 16 Byte aufgefüllt. Ein Beobachter sieht daher weiterhin, wann Sie Daten senden und ungefähr wie viel.
• Es speichert den zuletzt bekannten Endpoint. Der Peer mit der öffentlichen Adresse speichert die aktuelle öffentliche IP-Adresse der anderen Seite, und wg show zeigt sie an. Zusammen mit einer Tunneladresse, die in der Konfiguration festgelegt ist, ergibt sich daraus ein stabiler Bezeichner, der einem Benutzer zwischen Netzwerken folgt. Auf Ihrem eigenen VPS ist das unproblematisch. Genau deshalb ergänzen kommerzielle Dienste das Protokoll um eine weitere Ebene.
• Es authentifiziert einen Schlüssel, keine Person. Wer die Datei mit dem privaten Schlüssel besitzt, ist der Peer. Setzen Sie /etc/wireguard auf Modus 700 und die Schlüsseldateien auf 600.
• Es gibt weder eine Sperrliste noch einen Ablaufzeitpunkt. Der Zugriff endet, wenn Sie den Peer-Eintrag von jedem Server löschen, auf dem er vorhanden ist. Statische Schlüssel bleiben gültig, bis Sie sie entfernen.

Nichts davon macht WireGuard unsicher. Es macht das Protokoll kompakt, und genau das ist der Zweck: WireGuard authentifiziert und verschlüsselt, während Sie Identitätsverwaltung und Adressvergabe einer darüberliegenden Lösung überlassen. Eine Koordinierungsebene wie in WireGuard im Vergleich zu Tailscale schließt genau diese Lücke und verwendet dabei dieselbe Datenebene, die Sie gerade kennengelernt haben. Sobald eine solche Ebene eingerichtet ist, stellt sich als Nächstes die Frage, wer einen Dienst erreichen darf, den Sie innerhalb des Tunnels betreiben. Genau das legt die Wahl zwischen Tailscale serve und funnel für einen einzelnen Port fest.

FAQ

Was ist Cryptokey-Routing in WireGuard?

Cryptokey-Routing ist die Regel, die jedes Paket an einen öffentlichen Schlüssel bindet. Jeder Peer-Eintrag enthält eine Liste von Präfixen in AllowedIPs. Für ausgehende Pakete wählt WireGuard den Peer, indem es das Ziel des Pakets mit der Liste jedes Peers abgleicht. Dabei wird zuerst das längste Präfix verwendet, sodass die Liste als Routing-Tabelle dient. Bei eingehenden Paketen muss die innere Quelladresse nach der Entschlüsselung und Authentifizierung innerhalb derselben Peer-Liste liegen. Andernfalls wird das Paket verworfen. Die Liste dient damit zugleich als Zugriffskontrollliste. WireGuard benötigt keine separate Routing-Konfiguration und keine separate interne Firewall, weil diese eine Liste beide Aufgaben übernimmt.

Benötige ich PersistentKeepalive auf beiden Peers?

Nein. Setzen Sie es auf der Seite hinter NAT (Network Address Translation) oder hinter einer Stateful Firewall. Das ist normalerweise der Client. WireGuard sendet im Leerlauf nichts. Daher läuft das Mapping, über das die Gegenseite diesen Peer erreichen kann, häufig innerhalb einer Minute ab. Der Tunnel wirkt dann in eine Richtung nicht mehr verfügbar. PersistentKeepalive = 25 sendet alle 25 Sekunden ein leeres, authentifiziertes Paket und hält das Mapping offen. Ein Peer mit einer öffentlichen Adresse und einem offenen UDP-Port benötigt diese Einstellung nicht.

Warum meldet ping über den Tunnel „Required key not available“?

Die Zieladresse liegt in keinem AllowedIPs eines Peers. Daher hat das Cryptokey-Routing keinen Schlüssel gefunden, mit dem es das Paket verschlüsseln kann, und der Kernel verweigert das Senden. Führen Sie wg show wg0 allowed-ips aus und vergleichen Sie die Ausgabe mit der Adresse, die Sie anpingen. Der ähnliche Fehler Destination address required weist auf ein anderes Problem hin: Ein Peer wurde gefunden, aber WireGuard kennt keinen Endpoint für ihn. Es wurde entweder keiner konfiguriert, oder von diesem Peer ist noch kein authentifiziertes Paket eingegangen.

Kann eine Firewall WireGuard erkennen und blockieren?

Ja. WireGuard authentifiziert und verschlüsselt Ihren Datenverkehr und versucht nicht, sich zu tarnen. Handshake-Nachrichten sind 148 und 92 Bytes lang. Das erste Byte jeder Nachricht gibt ihren Typ an. Außerdem verwendet der Transport UDP. Daher lässt sich das Protokoll durch Deep Packet Inspection problemlos erkennen. Netzwerke, die UDP blockieren oder Protokolle anhand ihres Fingerabdrucks erkennen, unterbrechen WireGuard. Um den Tunnel zu verbergen, müssen Sie ihn in etwas anderes einbetten. Dafür ist ein separates Tool erforderlich, keine WireGuard-Einstellung.