So bekommt ein Test-LAN einen eigenen WireGuard-Ausgang

Drei Entwürfe lösen dasselbe Laborproblem: Ein kleines LAN muss über einen WireGuard-Peer hinausgehen, während das Gateway selbst seinen gewohnten Uplink behält. Die verlockende Abkürzung ist, die Standardroute des Routers in den Tunnel zu verschieben, doch das bricht den eigenen Verwaltungsweg der Kiste und alles andere, was sie weiterleitet. Die interessante Option ist Policy-Routing, begrenzt auf eine Schnittstelle und ein Präfix. Wählen Sie zwischen ihnen, indem Sie drei Fragen über die Maschine beantworten, die Sie tatsächlich haben.

Entscheiden Sie, wo der Ausgang lebt

Erste Frage: leitet dieser Host auch für etwas anderes weiter? Ein dediziertes Labor-Gateway kann mit einer Weiterleitungsrichtlinie leben, die standardmäßig verwirft. Ein Router mit Produktionsaufgaben kann das nicht, und ein konkurrierendes Regelset über eine verwaltete Firewall zu legen, ist genau die Art, wie Ausfälle eingeplant werden. Zweitens: Können Sie zwei Policy-Objekte und ihre Reihenfolge über Neustarts hinweg besitzen? Drittens: Autorisiert der Peer, den Sie haben, Ihre Tunnel-Quelladresse und bietet er Internet-Egress? Ein Peer, der nur ein privates Netz freigibt, ist ein anderes Produkt, und keine lokale Routing-Änderung behebt das. Wenn eine Antwort nein lautet, legen Sie den Ausgang stattdessen in einen Namespace oder eine Wegwerf-VM.

Ein Namespace oder eine VM kostet Speicher und gibt Ihnen einen sauberen Explosionsradius. Policy-Routing kostet zwei Regeln und lässt Ihnen eine Kiste zum Debuggen.

Wählen Sie den Ausgang, der Ihre Quelle autorisiert

Die meisten Fehler in diesem Labor passieren, bevor auch nur eine einzige Firewall-Regel existiert. Der Betreiber des Ausgangs muss die Quelladresse akzeptieren, die Ihre Pakete nach der Übersetzung tragen, und das ist in diesem Entwurf die Tunneladresse statt des LAN-Präfixes. Deshalb gehört Maskierung von Anfang an in den Entwurf und nicht als späte Ergänzung.

Bestätigen Sie drei Dinge beim Betreiber: Der Peer autorisiert Ihre Tunneladresse, er leitet IPv4 weiter, statt bei sich selbst zu terminieren, und er wendet Egress-NAT an. Ohne das erste kommen Ihre Pakete an und verschwinden. Ohne das dritte gehen sie mit einer privaten Quelle hinaus und sterben auf dem nächsten Hop. Prüfen Sie dann, dass wg-quick keine eigene Standardroute installiert, was Table = off verhindert; diese Einstellung unterdrückt die Routenerstellung, nicht die AllowedIPs-Prüfungen des Peers oder dessen DNS-Behandlung.

Zwei Policy-Objekte übernehmen die Lenkung

Lenkung braucht eine Tabelle und eine Regel. Die Tabelle hält zwei Routen: das LAN-Präfix aus der LAN-Schnittstelle hinaus und eine Standardroute aus dem Tunnel hinaus. Die Regel schickt Verkehr, der auf der LAN-Schnittstelle ankommt und dieses Präfix trägt, in die Tabelle. Verwenden Sie den iif-Selektor zusammen mit dem Quelltreffer, denn die eigenen WireGuard-Pakete des Gateways entstehen lokal und treffen nie auf eine eingehende Schnittstelle.

Der Wächter kommt vor dem Lookup, nicht danach. Diese Reihenfolge ist die gesamte Sicherheitseigenschaft des Entwurfs.

Der Wächter ist eine zweite Regel auf demselben Selektor, deren Urteil unreachable lautet. Geben Sie ihr eine höhere numerische Priorität, damit der Lookup weiterhin gewinnt, solange der Tunnel steht. Wenn die Tunnelroute verschwindet, liefert der Lookup nichts, und der Wächter stoppt die Suche, statt sie auf die WAN-Standardroute in der Haupttabelle durchfallen zu lassen.

ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0

Schließen Sie die Rückfall-Lücke, bevor Sie sie öffnen

Installieren Sie zuerst den Wächter und danach den Lookup. Andersherum bleibt ein Fenster von Sekunden, in dem der Verkehr eines Testclients den Uplink erreichen kann.

Der Filter vervollständigt das Bild. Im forward-Hook akzeptieren Sie die Richtung vom LAN zum Tunnel für das Testpräfix und die etablierte Rückrichtung und verwerfen dann alles andere; das NAT für dieses Präfix auf die Tunnelschnittstelle gehört nach postrouting. Gerade policy drop auf der Forward-Kette zu lassen macht aus einer fehlenden Route Stille statt eines Lecks. Reverse-Path-Filterung braucht den lockeren Modus auf der Tunnelschnittstelle, weil eine öffentliche Quelle, die entkapselt ankommt, ihre beste Rückroute auf der WAN-Seite hat. Linux nimmt den höheren der Werte all und pro Schnittstelle, also ist das Setzen der Tunnelschnittstelle nicht dasselbe wie eine Abschwächung der Prüfung überall.

Beweisen Sie es mit dem Fehlerfall

Stellen Sie dem Kernel eine präzise Frage, indem Sie die Quelladresse des Clients und die Schnittstelle nennen, auf der er ankommt. Ein Lookup ohne beides beantwortet eine andere Frage und sieht in beiden Fällen korrekt aus. Schauen Sie dann auf die Firewall-Zähler, den Übertragungszustand des Peers und den Dienst des Clients selbst.

Testen Sie das Entfernen richtig. Stoppen Sie den Tunnel, während Regel und Filter an Ort und Stelle bleiben: Der Client sollte stocken und der eigene Verkehr des Gateways weiterlaufen. Stoppen Sie dann den Peer, ohne die lokale Schnittstelle anzufassen, denn das ist der Fall, der Entwürfe erwischt, die sich allein auf die vorhandene Route verlassen. Starten Sie schließlich neu und prüfen Sie die Regelreihenfolge erneut, denn ein Teardown-Hook, der den Wächter entfernt, gibt den gesamten Entwurf an die Haupttabelle zurück. Notieren Sie Tabellennummer, Prioritäten und Schnittstellennamen auf dem Änderungsticket, denn die nächste Person, die eine Regel hinzufügt, ist die, die das hier kaputt macht.