WireGuard erklärt: Cryptokey Routing mit AllowedIPs

Wie WireGuard funktioniert – eine zentrale Idee

WireGuard ordnet jedes Paket einem öffentlichen Schlüssel zu. Dieser Mechanismus heißt Cryptokey Routing und bildet das gesamte Design ab: Die AllowedIPs-Zeile neben einem Peer ist die Routing-Tabelle 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, wird jede WireGuard-Konfigurationsdatei verständlich.

Es gibt keine Sitzungstabelle, die nach IP-Adressen 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 bestehen bleibt. Wenn Sie zunächst einen funktionierenden Tunnel benötigen, richten Sie ein selbst gehostetes WireGuard-VPN auf Ihrem eigenen VPS ein. Kehren Sie anschließend hierher zurück, wenn Sie eine Konfigurationszeile überrascht.

AllowedIPs ist Routing-Tabelle und Zugriffsliste

Betrachten Sie zunächst die ausgehende Richtung. Ihr Kernel leitet ein Paket wie üblich über die Haupt-Routing-Tabelle an das Gerät wg0 weiter. WireGuard vergleicht dann die Zieladresse dieses Pakets mit einer Tabelle, die die zulässigen Präfixe aller Peers enthält. Dabei wird das längste Präfix zuerst berücksichtigt. Ein Treffer benennt einen Peer. Dieser Peer 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 dorthin gesendet.

Wenn kein AllowedIPs-Eintrag eines 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

Dieser Fehler hat genau eine Ursache: Die Adresse, die Sie erreichen wollten, ist bei keinem Peer eingetragen. Der andere Fehler ping: sendmsg: Destination address required bedeutet, dass ein Peer zwar gefunden wurde, WireGuard aber keinen Endpunkt für ihn kennt, weil keiner konfiguriert wurde und bisher auch keiner gelernt 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. Die Quelladresse dieses inneren Pakets muss innerhalb des AllowedIPs des sendenden Peers liegen. Andernfalls wird das Paket verworfen. Wenn das dynamische Debugging aktiviert ist, gibt der Kernel den Grund aus, beispielsweise in dieser Zeile:

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 konfiguriertem 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 einspeisen, auch mit der eines anderen Clients.

Überlappende Präfixe werden anhand ihrer Spezifität aufgelöst, da die Suche nach dem längsten passenden Präfix erfolgt. Identische Präfixe bei zwei Peers verhalten sich anders: Der Eintrag wird dem Peer zugeordnet, der zuletzt konfiguriert wurde. Der erste Peer empfängt diesen Datenverkehr dann nicht mehr, ohne dass irgendwo ein Fehler 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 unter Berücksichtigung des Cryptokey-Routings 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: „Sende jedes Ziel an diesen Peer.“ Auf dem Server bedeutet es: „Akzeptiere von diesem Peer nur diese eine Adresse.“ 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 Schlüssel nie. wg-quick strip wg0 gibt die reduzierte Konfiguration aus, die das Tool wg tatsächlich lädt. Damit lässt sich diese Trennung am schnellsten überprüfen.

Was der Handshake tatsächlich bewirkt

Der Handshake von WireGuard verwendet Noise_IKpsk2 aus dem Noise Protocol Framework. Der relevante Teil für die Systemadministration ist IK: Der statische öffentliche Schlüssel des Responders ist dem Initiator bereits bekannt, weil er in Ihrem Block [Peer] als PublicKey eingetragen ist. Der Initiator sendet seinen eigenen statischen öffentlichen Schlüssel verschlüsselt in der ersten Nachricht. Es gibt daher keinen Zertifikatsaustausch und keinen zusätzlichen Austausch zur Identitätsprüfung. Ein passiver Beobachter kann nicht feststellen, welcher Schlüssel eine Verbindung aufbaut, sofern er nicht über den privaten Schlüssel des Responders 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 ephemeres Curve25519-Schlüsselpaar. Die Sitzungsschlüssel werden aus einer Kette von Diffie-Hellman-Ergebnissen abgeleitet, in die die statischen und ephemeren Schlüssel einfließen. Die privaten ephemeren Schlüssel werden anschließend verworfen. Das gewährleistet Forward Secrecy: Wenn jemand Ihren Datenverkehr heute aufzeichnet und im nächsten Jahr den privaten Schlüssel des Servers stiehlt, kann er die aufgezeichneten Daten trotzdem 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 wird eine wiederholte Initiierung abgewiesen. Datenpakete enthalten einen 64-Bit-Zähler, der als Nonce verwendet wird. Der Empfänger führt ein gleitendes Fenster der zuletzt gesehenen Zählerwerte. Wiederholungen und starke Umordnungen werden dadurch ohne einen TCP-ähnlichen Verbindungsstatus verarbeitet.

Sitzungsschlüssel bleiben nicht lange gültig. Die Timer sind fest im Programm 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 dieser Konstanten steuern den gesamten Lebenszyklus der Sitzung. Nach 120 Sekunden Nutzung beginnt der Sender einen neuen Handshake. Nach 180 Sekunden wird der alte Schlüssel vollständig abgewiesen. Der Datenverkehr stoppt daher, bis ein neuer Handshake abgeschlossen ist. Eine Initiierung ohne Antwort wird alle 5 Sekunden erneut gesendet und nach 90 Sekunden aufgegeben. Deshalb gibt wg show latest handshake als relatives Alter aus. Deshalb bleibt dieses Alter bei einem ausgelasteten, fehlerfreien Tunnel niedrig. Wenn das Alter wächst, 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 identischen Code aus und verwenden dasselbe Konfigurationsformat. Es gibt keinen Servermodus. Die wahrgenommene Asymmetrie entsteht durch Endpoint, und Endpoint ist optional.

Ein Peer mit konfiguriertem Endpoint kann einen Handshake starten. Ein Peer ohne Endpoint wartet und übernimmt die Adresse und den Port der anderen Seite aus dem ersten Paket, das erfolgreich authentifiziert wird. Dieser ermittelte Endpoint wird gespeichert und bei jedem gültigen Paket von einer neuen Adresse aktualisiert. So funktioniert Roaming: Ein Laptop kann vom WLAN in ein Mobilfunknetz wechseln und denselben Tunnel behalten, weil eine Sitzung anhand von Schlüssel und Index statt anhand der IP-Adresse identifiziert wird. Es wird nichts erneut verbunden, weil im TCP-Sinn nie eine Verbindung bestand.

Derselbe Mechanismus führt zu einem wichtigen Detail: Der Peer mit der öffentlichen Adresse kennt immer die zuletzt bekannte öffentliche IP-Adresse der anderen Seite, und wg show gibt sie aus.

Feste Primitive, keine Aushandlung

Bei WireGuard gibt es keine Ciphersuite-Liste. ChaCha20-Poly1305 für authentifizierte Verschlüsselung, Curve25519 für die Schlüsselvereinbarung, BLAKE2s für Hashing und HKDF für die Schlüsselableitung. Jede Bereitstellung verwendet diese Primitive. Daher gibt es keine Aushandlungsphase, die verarbeitet werden muss, und keinen Downgrade-Pfad zu einer schwächeren Option. Dieser Kompromiss ist real: Wenn eines dieser Primitive gebrochen wird, besteht die Lösung in einer neuen Version des gesamten Protokolls und einer Aktualisierung an beiden Enden, nicht in einer Konfigurationsänderung. Diese einzelne Entscheidung entfernt den Groß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 berechnet wird. Der verwendete Schlüssel wird aus dem statischen öffentlichen Schlüssel des Responders abgeleitet. Ein Absender, der diesen öffentlichen Schlüssel nicht kennt, kann kein gültiges 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, der keine Antwort erhält.

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

nmap meldet open|filtered. Das ist dieselbe Antwort, die nmap für einen Port ausgibt, dessen Pakete eine Firewall stillschweigend verwirft. Der Port verhält sich gleich, unabhängig davon, ob WireGuard auf Verbindungen wartet. Das gilt zumindest für Absender, die nicht bereits über Ihren öffentlichen Schlüssel verfügen.

Ein zweites Feld, mac2, schützt vor Überlastung durch Denial-of-Service-Angriffe. Wenn der Empfänger ausgelastet ist, antwortet er auf eine gültige Initiation mit einer an die Quelladresse des Absenders gebundenen 64-Byte-Cookie-Antwort. Aufwendige Berechnungen mit öffentlichen Schlüsseln führt er erst aus, wenn der Absender dieses Cookie zurücksendet. Dadurch wird die Echtheit der Quelladresse geprüft, bevor dafür CPU-Zeit aufgewendet wird. Dieser Mechanismus wird nur unter Last aktiviert.

Warum 0.0.0.0/0 einen Peer zur Standardroute macht

Da AllowedIPs die Routingtabelle ist, beansprucht AllowedIPs = 0.0.0.0/0, ::/0 jedes Ziel für diesen Peer. Das ist die gesamte Einstellung für einen Full Tunnel.

Die Routing-Konfiguration, durch die das funktioniert, ist interessanter als die Zeile selbst. Eine einfache Standardroute über wg0 würde eine Schleife erzeugen, weil das verschlüsselte UDP-Paket, das Ihren Datenverkehr überträgt, die Maschine ebenfalls verlassen muss und dabei auf die eigene Standardroute treffen würde. wg-quick verhindert das mit Policy Routing. Es markiert die eigenen ausgehenden Pakete von WireGuard mit einem fwmark, legt die Standardroute des Tunnels in eine separate Routingtabelle und fügt Regeln hinzu, sodass nur nicht markierter Datenverkehr diese Route verwendet. Führen Sie ip rule show aus, um das Ergebnis zu sehen:

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

0xca6c ist 51820 in Hexadezimaldarstellung, und 51820 ist auch die Nummer der Routingtabelle. 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 aller übrige Datenverkehr an die Tunneltabelle weitergeleitet wird. Ein Split Tunnel benötigt das alles nicht: Eine engere Liste wie AllowedIPs = 10.8.0.0/24, 10.20.0.0/16 wird zu normalen Routen in der Haupttabelle.

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

Wof PersistentKeepalive tatsächlich verwendet wird

WireGuard sendet nichts, wenn kein Datenverkehr stattfindet. Es gibt keinen Heartbeat, keine Sitzungsaktualisierung und nichts auf der Leitung. Diese Stille schont den Akku und hilft beim oben beschriebenen Scanner-Fall. Sie verhindert jedoch eine bestimmte Konfiguration.

Ein Peer hinter NAT (Network Address Translation) oder hinter einer Stateful Firewall ist von außen nur erreichbar, solange in diesem Gerät ein Mapping existiert. Dieses Mapping wurde durch ein ausgehendes Paket angelegt. Übliche UDP-Mappings haben eine Lebensdauer von etwa 30 Sekunden. Läuft das Mapping ab, verwirft die Netzwerkkomponente Pakete von der öffentlichen Seite. Der Tunnel wirkt dann inaktiv, 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 Lebensdauer, sodass das Mapping geöffnet bleibt.

Setzen Sie die Einstellung auf dem Peer hinter NAT. Ein Server mit öffentlicher Adresse und geöffnetem UDP-Port benötigt sie nicht. Dort erzeugt sie lediglich zusätzlichen Datenverkehr. Verwechseln Sie sie nicht mit dem automatischen Keepalive. Dieses wird 10 Sekunden ausgelöst, nachdem ein Peer Daten empfangen hat und selbst nichts zurückzusenden hat. Es ist immer aktiviert und kann nicht konfiguriert werden.

Das Routing Ihres LANs durch den Tunnel ist keine WireGuard-Funktion

Angenommen, Peer B befindet sich in einem Heimnetz 192.168.50.0/24, und Peer A soll dieses Netz 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. Außerdem akzeptiert A von B Pakete mit diesen Quelladressen. Ohne diesen Eintrag kennt das Cryptokey-Routing keinen Schlüssel für das Ziel und erlaubt die Quelladresse nicht.

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 Forwarding-Kette der Firewall auf B muss den Datenverkehr zulassen. 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ückkommen.

Die Aufgabe von WireGuard endet, sobald das entschlüsselte Paket an den Kernel übergeben wird. Alles danach ist gewöhnliches Linux-Routing und -Filtern. Deshalb zeigt sich dieser Fehler in den Zählern von nft list ruleset oder in ip -s link show wg0, nicht in wg show. Wenn Sie Peers lieber über eine Weboberfläche verwalten möchten, erzeugt wg-easy in Docker ausführen die Peer-Einträge für Sie. Die Forwarding-Regeln müssen jedoch weiterhin auf dem Host konfiguriert werden.

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 gelangen. Daher stammt der Durchsatz. Das erklärt auch, warum das Modul mit etwa viertausend Codezeilen klein genug bleibt, um geprüft und im März 2020 in den Mainline-Linux-Kernel 5.6 aufgenommen zu werden. Ubuntu 24.04 und Debian 13 liefern es mit, daher fehlt nur das Paket wireguard-tools.

Dass es sich um ein normales Interface handelt, hat praktische Konsequenzen. tcpdump -ni wg0 zeigt die Klartextpakete im inneren Tunnel, 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 gestört ist. netfilter und Traffic-Shaping behandeln wg0 wie jedes andere Interface. Wenn das Kernelmodul nicht verfügbar ist, etwa 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 deutlich, weil jedes Paket die Kernelgrenze zweimal überquert.

Wovor WireGuard Sie nicht schützt

Das Bedrohungsmodell ist bewusst eng gefasst. Ein so unauffälliges Protokoll lädt zu falschen Erwartungen ein. Formulieren Sie es klar.

• WireGuard bleibt als verwendetes Protokoll erkennbar. Handshake-Nachrichten haben feste Größen, das erste Byte gibt den Nachrichtentyp an und der Transport verwendet UDP. Eine Deep-Packet-Inspection erkennt WireGuard problemlos, und ein Netzwerk, das VPNs nicht zulässt, kann den Datenverkehr blockieren. Obfuscation wurde bewusst nicht integriert.
• WireGuard verbirgt weder das Datenvolumen noch den zeitlichen Ablauf. Nutzdaten werden nur bis zu einer Grenze von 16 Byte aufgefüllt. Ein Beobachter sieht daher weiterhin, wann Sie Daten senden und ungefähr wie viele.
• WireGuard 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 fest in der Konfiguration eingetragen ist, ergibt sich daraus ein stabiler Bezeichner, der einem Benutzer zwischen Netzwerken folgt. Auf dem eigenen VPS ist das unproblematisch. Deshalb ergänzen kommerzielle Dienste das Protokoll um eine zusätzliche Schicht.
• WireGuard authentifiziert einen Schlüssel, keine Person. Wer die Datei mit dem privaten Schlüssel besitzt, ist der Peer. Setzen Sie für /etc/wireguard den Modus 700 und für die Schlüsseldateien den Modus 600.
• Es gibt weder eine Sperrliste noch ein Ablaufdatum. 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. Genau das ist der Zweck: WireGuard authentifiziert und verschlüsselt, während Identitätsverwaltung und Adresszuweisung einer darüber aufgebauten Lösung überlassen bleiben. Eine Koordinierungsschicht wie in WireGuard im Vergleich zu Tailscale beschrieben schließt genau diese Lücke. Sie verwendet dabei dieselbe Data Plane, die Sie gerade kennengelernt haben.

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 in AllowedIPs eine Liste von Präfixen. Für ausgehende Pakete wählt WireGuard den Peer anhand des Abgleichs der Zieladresse mit der Liste jedes Peers aus. Dabei wird zuerst das längste Präfix berücksichtigt, sodass die Liste als Routing-Tabelle fungiert. Für eingehende Pakete muss die innere Quelladresse nach der Entschlüsselung und Authentifizierung innerhalb derselben Peer-Liste liegen. Andernfalls wird das Paket verworfen. Die Liste fungiert daher 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 die Option auf der Seite hinter NAT (Network Address Translation) oder hinter einer zustandsbehafteten Firewall. Das ist normalerweise der Client. WireGuard sendet im Leerlauf keine Daten. 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 Option nicht.

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

Weil sich die Zieladresse in keinem AllowedIPs eines Peers befindet. Das Cryptokey-Routing hat daher keinen Schlüssel gefunden, mit dem das Paket verschlüsselt werden kann, und der Kernel hat das Senden verweigert. 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 bezeichnet ein anderes Problem: Ein Peer wurde gefunden, aber WireGuard kennt keinen Endpoint für ihn. Es wurde kein Endpoint konfiguriert, und 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 groß. Das erste Byte jeder Nachricht gibt ihren Typ an. Außerdem verwendet WireGuard UDP. Daher kann eine Deep-Packet-Inspection das Protokoll problemlos erkennen. Netzwerke, die UDP blockieren oder Protokolle anhand von Fingerprints erkennen, können WireGuard blockieren. Um den Tunnel zu verbergen, müssen Sie ihn in etwas anderes kapseln. Dafür benötigen Sie ein separates Tool und keine WireGuard-Einstellung.