WireGuard-Peer nicht erreichbar, während ein anderer funktioniert: Checkliste

Ein WireGuard-Peer überträgt Verkehr, ein zweiter führt den Handshake aus, erreicht aber nie etwas hinter dem Tunnel. Der funktionierende Peer sagt Ihnen, dass Schnittstelle, UDP-Port und Serverschlüssel wahrscheinlich in Ordnung sind. Über die AllowedIPs des zweiten Peers, seine innere Quelladresse und die Weiterleitungsregeln dazwischen sagt er nichts. Arbeiten Sie die Liste der Reihe nach ab und brechen Sie beim ersten Schritt ab, dessen Bedingung nicht erfüllt ist.

Schritt 1: Notieren Sie den Pfad, den das Paket nehmen soll

Zwei Clients an demselben Hub erreichen sich nicht automatisch. In einem Hub-and-Spoke-Design empfängt der Server das Paket auf wg0 und muss es wieder aus wg0 zum anderen Peer weiterleiten, was IP-Weiterleitung und eine Weiterleitungsregel erfordert. In einem direkten Peer-to-Peer-Design braucht jede Seite den Endpunkt der anderen und deren Tunneladresse innerhalb der AllowedIPs. Entscheiden Sie, welches Design Sie debuggen, bevor Sie irgendeine Konfiguration lesen.

Der erwartete Pfad sagt Ihnen auch, wo Sie suchen müssen. Soll das Paket den Hub passieren, ist der fehlerhafte Hop entweder die AllowedIPs des Senders, die Weiterleitung am Hub oder die AllowedIPs des Empfängers. Soll es direkt gehen, ist der Hub irrelevant, und es zählen die Endpunktfelder auf beiden Peers.

Schritt 2: Vergleichen Sie die AllowedIPs auf beiden Seiten, nicht nur auf einer

WireGuard nutzt AllowedIPs zugleich als Routing-Tabelle und als Zugriffsliste. Beim Senden wird die Zieladresse in den AllowedIPs des Peers nachgeschlagen, um den Tunnel zu wählen; beim Empfangen muss die innere Quelladresse innerhalb der AllowedIPs des sendenden Peers liegen, sonst wird das Paket verworfen. Ein fehlender Bereich auf einer der beiden Seiten erzeugt dasselbe Symptom: Der Transport funktioniert, die Nutzlast verschwindet.

Lesen Sie den Live-Zustand statt der Datei, denn ein Reload kann stillschweigend fehlgeschlagen sein: sudo wg show wg0 allowed-ips. Auf dem Server muss der Eintrag des fehlerhaften Peers seine Tunneladresse enthalten, zum Beispiel 10.90.0.3/32. Auf dem Client muss der Eintrag des Server-Peers das Ziel enthalten, das Sie testen, ob das nun die Tunneladresse des Hubs oder das entfernte Subnetz ist. Überlappende Bereiche machen die Suche mehrdeutig und können einen Peer auswählen, den Sie nicht gemeint haben, halten Sie sie deshalb getrennt.

Schritt 3: Prüfen Sie die innere Quelladresse

Ein Client, der 10.90.0.3 über wg0 routet, aber Pakete von seiner Wi-Fi-Adresse aus sendet, wird vom Empfänger abgelehnt, weil die Quelle nicht zu den AllowedIPs des Peers passt. Prüfen Sie mit ip route get 10.90.0.3 from 10.90.0.2, was der Kernel tatsächlich auswählt, und bestätigen Sie mit ip -brief addr show wg0 die Adresse, die der Tunnelschnittstelle zugewiesen ist.

Auf dem empfangenden Linux-Host ist die Reverse-Path-Filterung ein zweites Tor. Ein strikter rp_filter auf der Schnittstelle, die die Rückroute besitzt, kann Tunnelverkehr verwerfen, dessen Rückweg nicht zur Schnittstelle passt, auf der er ankam. Prüfen Sie den effektiven Wert, bevor Sie ihn abschalten; in vielen Topologien ist die richtige Korrektur eine Route und kein gelockerter Filter.

Schritt 4: Prüfen Sie die Weiterleitung am Hub und den Rückweg

Muss der Hub zwischen Peers weiterleiten, braucht der Kernel net.ipv4.ip_forward=1, und die Firewall muss den weitergeleiteten Fluss annehmen: eingehend auf wg0, ausgehend auf wg0, von der Tunneladresse des Senders zu der des Empfängers. Ein häufiger Fehler ist eine Eingangsregel, die UDP 51820 akzeptiert, aber keine Weiterleitungsregel], sodass der Handshake gelingt und die Nutzlast stirbt. Listen Sie die wirksamen Regeln mit sudo nft list ruleset oder dem Äquivalent für Ihren Firewall-Manager auf.

Prüfen Sie dann die Antwort. Der Zielhost muss eine Route zurück zum Sender haben, entweder über den Hub oder über sein eigenes Gateway. NATet der Hub zusätzlich das Tunnel-Subnetz, bestätigen Sie, dass die Übersetzung für den weitergeleiteten Fluss gilt und dass die Antwort den Hub erreicht, bevor der Zustand abläuft. Ein einseitiger Fehler, der wie ein Schlüsselproblem aussieht, ist oft nur diese Rückroute.

Trennen Sie schließlich Handshake und Daten. Ein Peer, der den Handshake abschließt, aber bei großen Übertragungen stockt, hat meist ein MTU- oder MSS-Problem auf genau diesem Pfad und kein AllowedIPs-Problem. Testen Sie zuerst mit einem kleinen Ping, dann mit einem in voller Größe, und vergleichen Sie die beiden Peers.

Schritt 5: Ändern Sie eine Sache und lassen Sie den funktionierenden Peer unangetastet

Nehmen Sie eine einzige Änderung am fehlerhaften Pfad vor und testen Sie beide Peers erneut. Die AllowedIPs jedes Peers durch 0.0.0.0/0 zu ersetzen, ist der schnellste Weg, den bereits funktionierenden Peer zu zerstören, denn es ändert die Routingentscheidung für den gesamten Verkehr auf dieser Schnittstelle. Bearbeiten Sie den einen Eintrag, laden Sie neu und lesen Sie den Live-Zustand zurück.

Notieren Sie, welcher Pfad erfolgreich war, welcher fehlschlug und die genaue Befehlsausgabe für jeden. Dieser Vergleich ist mehr wert als ein allgemeiner Bericht, dass das VPN kaputt sei, und es ist das Erste, wonach die nächste Person fragen wird.