Eine WireGuard-Konfiguration Zeile für Zeile lesen, von Interface bis Peer

Die meisten kaputten WireGuard-Konfigurationen haben keinen falschen Wert; sie setzen den richtigen Wert auf die falsche Seite. Ein privater Schlüssel gehört zu dieser Maschine, ein Peer trägt den öffentlichen Schlüssel der anderen Maschine, und eine Adresse steht im Interface-Block, obwohl sie beschreibt, wo der Tunnel lebt. Lesen Sie die Datei als zwei Richtungen, die sich treffen, und prüfen Sie dann, was das Hilfsskript obenauf ergänzt hat. Das Protokoll selbst hat weniger Felder als die Datei, und die zusätzlichen lohnt es, getrennt zu kennen.

Interface-Schlüssel beschreiben diese Maschine

Der Interface-Block enthält die eigene Identität dieses Endpunkts. PrivateKey ist diese Identität und verlässt nie den Host; der passende öffentliche Schlüssel wird daraus abgeleitet, und genau den listen andere Peers auf. ListenPort ist der Ort, an dem diese Seite Handshakes empfängt, daher brauchen zwei Clients hinter einer Adresse verschiedene Ports.

Address ist die Tunneladresse, auf der dieser Host antwortet, mit einer Präfixlänge geschrieben, weil sie auch die Quelle ist, die er verwenden wird. Ein falsches Präfix hier ändert, welche Ziele der Host als direkt verbunden betrachtet, und das erzeugt Fehler, die wie Routing und nicht wie Konfiguration aussehen.

Alles andere in einem [Interface] Block mit einem echten Client fügt normalerweise wg-quick hinzu: DNS, MTU, Table, und die Hook-Zeilen. Sie sind keine Protokollfelder, und eine blanke wg Einrichtung ignoriert sie vollständig.

Jeder Peer-Eintrag beschreibt eine andere Seite

Ein [Peer] Block ist die Gegenseite. PublicKey ist der abgeleitete Schlüssel dieser Seite, niemals ihr privater Schlüssel, und PresharedKey ist ein optionales zusätzliches Geheimnis, das beide Seiten identisch halten müssen. Endpoint ist das Ziel des Sendens, und PersistentKeepalive bittet diesen Host, nach dem Intervall ein Paket zu senden, wenn sonst nichts ausgeht.

Zwei Fehler erklären hier den größten Teil der Verwirrung. Den eigenen privaten Schlüssel in einen Peer-Block zu kopieren, lässt beide Enden eine Identität teilen, und der Handshake scheitert auf eine Weise, die sich schlecht protokollieren lässt. Endpoint bei einem Client wegzulassen, ist meist Absicht, weil der Server die Adresse aus dem eingehenden Handshake lernt; es bei einem Server wegzulassen, der initiieren muss, ist es nicht. Denken Sie auch daran, dass keepalive eine NAT-Zuordnung offen hält und weder den Durchsatz verbessert noch die Latenz senkt, also bringen dreißig Sekunden zusätzlicher Pakete nichts, wenn der Verkehr bereits fließt.

AllowedIPs ist Routing, keine Erlaubnisliste

AllowedIPs ist WireGuards Kryptoschlüssel-Routing. Ausgehend entscheidet es anhand des Ziels, welcher Peer ein Paket erhält. Eingehend entscheidet es anhand der Quelle, ob ein von diesem Peer kommendes Paket akzeptiert wird. Dasselbe Feld erledigt beides, deshalb ist es keine Zugriffskontrollliste und keine Liste erlaubter Websites.

Ein enges AllowedIPs auf dem Server für einen Client bedeutet, dass der Server nur Pakete annimmt, die diese Quellen behaupten, und nur diese Ziele an diesen Client sendet. Erweitern Sie eine Seite, ohne die andere zu erweitern, und Sie erhalten einen Tunnel, der hochkommt und nichts durchlässt.

Was wg-quick rings um das Protokoll ergänzt

wg-quick liest dieselbe Datei und führt die Netzwerkschritte aus, die das Protokoll dem Betriebssystem überlässt. Es weist die Interface-Adresse zu, fügt aus AllowedIPs abgeleitete Routen hinzu, schreibt die Resolver-Einstellungen und führt die Hook-Befehle der Reihe nach aus.

Diese Schicht erklärt die klassische Asymmetrie. Eine Datei mit 0.0.0.0/0 und einer DNS Zeile gibt einem Client eine Standardroute und einen Resolver, und sie tut überhaupt nichts für die Weiterleitungs- oder NAT-Regeln des Servers. Die gehören zur Konfiguration des Servers selbst, und keine Clientdatei kann sie liefern.

Halten Sie einen Eigentümer für die Datei. Sie von Hand zu bearbeiten, während SaveConfig aktiviert ist, bedeutet, dass Ihre Änderung verschwindet, wenn das Interface das nächste Mal heruntergeht, und das Interface wird Ihnen nicht sagen, dass es passiert ist.

Prüfen Sie den angewendeten Zustand, nicht die Datei

Die Datei ist eine Absicht. Der angewendete Zustand ist das, was der Kernel hält, und sie laufen auseinander, sobald ein Helfer, ein Drop-in oder ein Hook nach der Aktivierung etwas bearbeitet hat.

Lesen Sie den Live-Zustand und die Adressierung zusammen und vergleichen Sie dann beides mit dem, was Sie geschrieben haben:

sudo wg show
ip -4 addr show dev wg0
ip -4 route show dev wg0
grep -v "^#" /etc/wireguard/wg0.conf

Ist die Peer-Liste leer, wurde das Interface angelegt, ohne dass seine Konfiguration angewendet wurde. Existieren Adressen und Routen, bleiben die Zähler aber bei null, wurde die Datei geladen und der Handshake scheitert, was ein Schlüssel- oder Endpunktproblem ist und kein Problem der Abschnittsreihenfolge. Vergleichen Sie die beiden Ansichten vor dem Bearbeiten, denn die Lücke dazwischen ist meist der eigentliche Fehler.