OpenWrt-Policy-Routing: die Kette, die lokales DNS abfängt

Clients im LAN lösen über den Tunnel auf, die eigenen Abfragen des Routers tun das stillschweigend nicht. Paketaktualisierungen, Zeitsynchronisierung und dynamisches DNS verlassen den normalen Uplink, während jede weitergeleitete Abfrage das VPN nimmt, und nichts in der Oberfläche deutet darauf hin, dass zwei verschiedene Wege existieren. Die Erklärung ist kein Fehler in der Policy, sondern die Frage, welcher Hook das Paket sieht. Zwei Flüsse, eine Resolveradresse, und nur einer davon durchquert den Router. Sie auseinanderzuhalten ist die ganze Lösung.

Zwei Flüsse, eine Resolveradresse

Der erste Fluss ist der, den man sich vorstellt. Ein Client fragt den Resolver des Routers, der Resolver leitet upstream weiter, und dieses weitergeleitete Paket passiert den Router auf dem Weg nach draußen. Dieses Paket ist für alles sichtbar, was weitergeleiteten Verkehr beobachtet.

Der zweite Fluss kommt von nirgendwo an. Der Router erzeugt ihn, also gibt es kein eingehendes Paket und keinen Weiterleitungsschritt, der passen könnte.

Beide können dieselbe Resolveradresse anvisieren, und genau deshalb ist der Unterschied leicht zu übersehen. Gleiches Ziel, anderer Ursprung, andere Kette. Sobald man den Ursprung sieht, folgt der Rest der Diagnose.

Weitergeleitete und lokal erzeugte Pakete kommen unterschiedlich herein

Weitergeleiteter Verkehr wird bewertet, wenn er von einer anderen Schnittstelle ankommt. Policy-Routing-Pakete legen das als prerouting-Kette offen, und eine dort platzierte Regel sieht jedes Paket, das den Router durchquert. Deshalb verhalten sich Client-Abfragen genau wie die Policy beschreibt, und deshalb ignoriert der Router sie. Die Regel ist nicht falsch, sie hängt nur an einem Hook, den der Router nie erreicht. Verschiebt man sie, beginnt derselbe Treffer zu wirken.

Lokal erzeugter Verkehr wird von einem Prozess auf dem Router erzeugt und tritt stattdessen in den Ausgangspfad ein. Er wird durch die eigene Entscheidung des Routers geroutet und trifft nur dann auf die Policy, wenn die Policy diese Kette abdeckt. Es gibt keine eingehende Schnittstelle zum Abgleichen und keine Weiterleitungsentscheidung zu beobachten.

Das ist eine Eigenschaft des Ortes, an dem Pakete entstehen, und nicht eines bestimmten Pakets. Eine für eine Kette geschriebene Regel hat schlicht keine Meinung über die andere. Kein Maß an Regel-Feintuning ändert das.

Wähle die Output-Kette, dann verenge den Treffer

Die Lösung besteht darin, dieselbe Absicht auch an die Output-Kette zu hängen, oder die Regel dorthin zu verschieben, wenn die eigenen Abfragen des Routers das sind, was zählt. In einem OpenWrt-Setup, das auf einem Policy-Routing-Paket aufbaut, bedeutet das, in der Ketteneinstellung der Regel output statt prerouting zu wählen. Behalte beide Regeln, wenn beide Populationen abgedeckt sein müssen.

Verenge dann, was die Regel trifft. Ziel-Resolveradressen auf dem Port, den der Resolver tatsächlich nutzt, sind eine viel kleinere Entscheidung, als alles in den Tunnel zu schicken, was der Router erzeugt.

Halte die beiden Regeln explizit, statt eine zu schreiben, die beide Ketten abdeckt. Getrennte Regeln sind leichter zu lesen, und sie erlauben dir, den Pfad des Routers abzuschalten, ohne den Client-Verkehr zu stören, während du debugst. Sie machen auch die Zähler einzeln aussagekräftig.

Halte den eigenen Transport des Tunnels aus der Regel heraus

Die äußere Verbindung des Tunnels wird ebenfalls vom Router erzeugt. Eine Regel, die allen lokal erzeugten Verkehr in den Tunnel schickt, wird den Tunnel durch sich selbst routen, und er wird überhaupt nicht hochkommen.

Der Verwaltungszugriff ist das zweite Opfer. Administrative Sitzungen, die vom Router ausgehen, oder Antworten darauf können von einer zu breiten lokalen Regel in den Tunnel gezogen und aus dem LAN unerreichbar werden.

Nimm den Endpunkt des Tunnels vom Treffer aus und halte die Regel auf die Resolveradressen begrenzt. Das genügt für die DNS-Anforderung und ist klein genug, um darüber nachzudenken.

Teste beide Populationen, nicht eine

Beobachte, wie der Router seine eigene Abfrage stellt, und notiere, welche Schnittstelle sie getragen hat. Wiederhole die Abfrage von einem LAN-Host und notiere den Weg, den diese genommen hat. Zähler an den Policy-Regeln machen beide Antworten sichtbar, ohne zu raten.

Behandle die Ergebnisse als zwei Befunde. Ein Client, der über den Tunnel auflöst, sagt nichts über den Router, und ein Router, der korrekt auflöst, sagt nichts über einen Client an einem anderen Listener. Schreibe sie als getrennte Zeilen in den Änderungsnachweis.

Prüfe auch den Port: eine Regel, die Zielport 53 trifft, verfehlt einen Resolver, der über DNS over TLS auf 853 oder einen HTTPS-Endpunkt erreicht wird. Triff den Transport, den der konfigurierte Upstream wirklich nutzt, und das Leck schließt sich aus dem richtigen Grund.