So baust du einen WireGuard-Test mit zwei Peers, der einen Pfad beweist

Ein WireGuard-Test, der eine Standardroute, ein LAN-Präfix, DNS und eine Firewall-Ausnahme trägt, kann dir nicht sagen, welcher Teil davon kaputt ist. Reduziere ihn auf zwei Peers, ein Adresspaar und einen erlaubten Dienst, und der Fehler hat keinen Ort mehr, an dem er sich verstecken kann. Die langweilige Basis ist die Diagnose. Baue sie zuerst; sie dauert fünfzehn Minuten und spart dir den Nachmittag, den du sonst mit Raten verbringen würdest.

Was die Basis beweist, ist enger, als die meisten erwarten. Sie beweist, dass zwei Identitäten übereinstimmen, dass UDP den lauschenden Port erreicht und dass ein erlaubtes Ziel eine Anfrage trägt. Weiterleitung, NAT, LAN-Routen und DNS sind getrennte Funktionen, die danach ergänzt werden, eine nach der anderen.

Schlüssel, Adressen und der eine Endpunkt

Erzeuge auf jedem System ein Schlüsselpaar und übertrage nur die öffentlichen Hälften zwischen ihnen. wg genkey | tee privatekey | wg pubkey > publickey ist der dokumentierte Einzeiler, und er lässt den privaten Schlüssel in einer Datei, die du anschließend schützen kannst. Wähle Tunneladressen aus einem Bereich, der in keiner anderen deiner Konfigurationen vorkommt, etwa 10.99.0.1/24 und 10.99.0.2/24. Notiere, welche Adresse zu welcher Maschine gehört, denn jede spätere Prüfung hängt von dieser Zuordnung ab.

Private Schlüssel reisen nie. Braucht ein Test einen, der auf die andere Seite kopiert wird, ist der Test bereits schiefgegangen. Wenn beide Systeme hinter NAT sitzen, braucht mindestens eines einen erreichbaren UDP-Port, während das andere einen Endpoint trägt, der darauf zeigt, und die öffentliche Adresse und der Port gehören in deine Notizen statt in deine Annahmen über 51820.

Eine Portweiterleitung, die einen anderen externen Port abbildet, funktioniert gut, solange der Endpoint dazu passt. Abweichungen hier erzeugen Stille statt Fehler, deshalb lohnt es sich, sie auf dem Papier zu prüfen, bevor du auf der Leitung debuggst.

Die Felder, die zu wg gehören, und die, die es nicht tun

Der Kernfeldsatz ist klein: PrivateKey und ListenPort unter Interface, PublicKey, AllowedIPs und Endpoint unter Peer. Address und DNS gehören zu wg-quick und nicht zu wg selbst, und dieser Unterschied beißt in dem Moment, in dem dieselbe Konfiguration in ein anderes Werkzeug wandert.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs trägt zwei Aufgaben gleichzeitig. Es wählt aus, welche Ziele in den Tunnel gehen, und es autorisiert den Peer, diese Quelladressen bei der Ankunft zu verwenden. Deshalb muss der Spiegel-Eintrag auf der anderen Seite deine Tunneladresse exakt benennen; ein /32 für den falschen Peer liest sich wie ein Routingproblem und verhält sich wie ein Autorisationsproblem. Der WireGuard-Schnellstart zeigt dieselbe Zwei-Peer-Form mit der kanonischen Formulierung, wenn du die Feldnamen vergleichen willst.

Den Handshake lesen statt das Symbol

Bringe die Schnittstelle über das hoch, was sie besitzt, und lies dann Zustand statt einer Statusleuchte. wg show druckt den letzten Handshake je Peer samt Byte-Zählern, und ein Handshake innerhalb der letzten Minuten bedeutet, dass Schlüssel, Endpunkt und UDP-Pfad alle funktionieren. Ein Zähler, der nur in eine Richtung steigt, ist seine eigene Antwort, und er ist nicht derselbe Fehler wie ein Handshake, der nie stattfindet.

Die beiden Fehler verlangen unterschiedliche Untersuchungen. Gar kein Handshake deutet auf eine Schlüsselabweichung, einen falschen Endpoint, blockiertes UDP oder eine Firewall, die den Handshake selbst verwirft. Ein Handshake, der gelingt, während Daten nirgendwohin gehen, deutet auf AllowedIPs, einen Dienst, der nicht auf der Tunneladresse lauscht, oder eine Host-Firewall, die den Port für das LAN, aber nicht für die Tunnelschnittstelle annimmt. Das sind verschiedene Hälften des Systems, und die Basis trennt sie, bevor du anfängst, Regeln zu ändern.

Einen erlaubten Dienst beweisen, dann die Gegenrichtung

Schicke eine Anfrage an die Tunneladresse des anderen Peers auf einem Dienst, der antworten soll, und wähle etwas Besseres als ping. Eine fehlende ICMP-Antwort kann Host-Filterung sein statt ein Tunnelfehler, also beweist ein stilles ping keine Richtung. Eine TCP-Verbindung zu einem Port, von dem du weißt, dass er offen ist, oder eine Anfrage, die Daten zurückgibt, liefert dir eine Antwort, die du deuten kannst.

Führe die Gegenrichtung als eigenen Test mit eigenem Ergebnis aus, weil die beiden Richtungen getrennte Firewall- und AllowedIPs-Einträge haben und unabhängig fehlschlagen können. Wenn der Handshake funktioniert und die Anfrage nicht, sitzt das Problem im Datenpfad statt im Tunnel: AllowedIPs, der lauschende Dienst oder eine Host-Firewall. Behebe das, bevor du Weiterleitung, NAT oder DNS ergänzt, sonst verbringst du den Nachmittag damit, eine Funktion zu debuggen, die nie schuld war.

Die Basis als Referenz erhalten

Speichere die funktionierende Topologie und die Profilquelle an einem Ort, von dem du wiederherstellen kannst, und halte sie aus jedem Verzeichnis heraus, das zu einem öffentlichen Dienst synchronisiert. Ergänze dann eine Funktion nach der anderen und wiederhole nach jeder die ursprüngliche Anfrage: Weiterleitung, NAT, eine LAN-Route und erst dann DNS. Jede Ergänzung, die den Test bricht, ist nun erkennbar, weil sich sonst nichts bewegt hat.

Eine Basis, die nur ein Symbol grün macht, hat dir nichts darüber gesagt, welche Ergänzung den nächsten Fehler verursacht hat. Halte den einen erlaubten Pfad als Referenz am Laufen, und jede spätere Änderung wird daran gemessen.