Nur einen lokalen Webdienst am VPN vorbei nach Port routen

Ein Host-Dienst muss das Internet über den physischen Uplink beantworten, während alles andere auf der Maschine den Tunnel weiter nutzt. Drei Bedingungen entscheiden, ob policybasiertes Routing diese Last tragen kann, und jede ist billig zu prüfen, bevor Sie eine Regel schreiben. Der Dienst muss auf diesem Host enden und nicht hinter einem DNAT oder einem weitergeleiteten Port, die eigenen Regeln des VPN müssen die Ausnahme erlauben, und Sie müssen die Antwort abgleichen statt die Anfrage. Scheitert eine der drei, laden die Befehle unten sauber und tun trotzdem nichts Nützliches.

Prüfen Sie die drei Bedingungen, bevor Sie eine Regel schreiben

Ein Container, der einen Port per DNAT veröffentlicht, oder ein Server hinter einer Portweiterleitung erzeugt Pakete, die nicht auf diesem Host entstehen. Diese Pakete werden weitergeleitet, also eine Regel, die auf hostlokalem Input ansetzt, sieht sie nie und der Verkehr nimmt weiter die Standardroute. Bestätigen Sie, wo der Dienst tatsächlich läuft, bevor Sie fortfahren, denn das ist die Bedingung, bei der Menschen am häufigsten danebenliegen.

Die zweite Bedingung ist Politik und nicht Mechanik. Jede Route, die den Tunnel umgeht, ist eine Ausnahme vom Zweck des Tunnels, und auf einem verwalteten Host gehört diese Entscheidung demjenigen, der die Politik besitzt, nicht der Person, die ein Timeout debuggt.

Gleichen Sie die Antwort ab, nicht den Zielport des Clients

Die Antwort eines Servers, der auf TCP 443 lauscht, verlässt den Host mit Quellport 443. Ein Browser auf demselben Host, der sich mit einer entfernten HTTPS-Seite verbindet, sendet einen kurzlebigen Quellport und Zielport 443. Beides ist Port-443-Verkehr, und nur eines davon sollte die WAN-Tabelle nehmen, weshalb ein Abgleich auf den Zielport die falsche Hälfte erwischen würde.

Die Antwortrichtung ist das, was Sie unterscheiden können. Gleichen Sie den Quellport ab, beschränken Sie die Regel auf lokal erzeugte Pakete, und die Regel deckt die eigenen Antworten des Dienstes ab, ohne die Anfragen des Browsers zu berühren.

Bauen Sie eine vollständige Rücktabelle, bevor die Regel darauf zeigt

Eine leere Tabelle bedeutet keine Route, was wie ein kaputter Dienst aussieht und nicht wie eine kaputte Politik. Füllen Sie sie zuerst, mit einer Tabellennummer und Priorität, die nichts anderes auf dem Host beansprucht:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

Lesen Sie die Nummern vom laufenden Host ab, statt sie zu kopieren. ip -4 rule show sagt Ihnen, welche Prioritäten belegt sind, und eine Regel auf eine bereits vorhandene Priorität zu legen ändert stillschweigend die Reihenfolge zweier Regeln, die einzeln betrachtet in Ordnung aussehen.

Zwei Selektoren leisten hier die eigentliche Arbeit. iif lo ist die Art, wie der Kernel Pakete meldet, die der Host selbst erzeugt hat, sodass die Regel nicht versehentlich weitergeleiteten Verkehr von außen erfasst. ipproto tcp sport 443 engt das auf ein Transportprotokoll und einen Port ein, was so eng ist, wie die Anforderung es zulässt. Lassen Sie den Protokollselektor weg, und die Regel erfasst auch UDP 443, einen anderen Dienst mit anderem Verhalten.

Halten Sie private Antworten im Tunnel

Wenn derselbe Listener auch Clients auf der privaten Seite beantwortet, versucht eine WAN-Standardroute, die alles abfängt, in Tabelle 100, diese Antworten über den Uplink zurückzuschicken. Fügen Sie die privaten Präfixe hinzu, die der WAN-Standardroute nicht folgen dürfen, oder lassen Sie sie auf die nächste Politikregel durchfallen:

ip -4 route add table 100 throw 10.90.0.0/24

Eine Throw-Route beendet die Suche in dieser Tabelle und gibt das Paket an die Regelliste zurück, sodass die folgende VPN-Politik ihre Chance bekommt. Sie selbst leitet nichts in den Tunnel, und wenn keine spätere Regel eine passende Route hat, scheitert das Paket trotzdem; prüfen Sie die nächste Politik, statt anzunehmen, der Throw sei eine Lösung.

Reverse-Path-Filterung und Firewall-Regeln des Hosts gelten weiterhin für die ankommende Anfrage. Sehen Sie sich deren tatsächliche Urteile an, bevor Sie die Prüfung lockern, denn eine Routing-Ausnahme führt nicht dazu, dass rp_filter einen Rückweg akzeptiert, den es für unmöglich hält.

Testen Sie TCP, dann QUIC, dann einen Neustart

Öffnen Sie eine Verbindung von einem autorisierten externen Client und eine von der privaten Seite und prüfen Sie dann den Antwort-Lookup mit den tatsächlichen Adressen und Ports. Wenn die externe Antwort Tabelle 100 nimmt und die private nicht, tut die Politik, was Sie verlangt haben.

HTTP/3 wird über UDP ausgeliefert und von einer TCP-Regel nicht erfasst, ein QUIC-Listener braucht also seinen eigenen Selektor, sonst nutzt er weiter den Tunnel, während HTTPS funktioniert. Legen Sie die Regeln, auf die Sie sich festlegen, bei der Komponente ab, die das Interface besitzt, und bestätigen Sie sie nach einem Reconnect oder einer DHCP-Erneuerung. Wenn ein konkurrierender Manager nach einem Neustart eine Laufzeitroute entfernt, ist das ein Eigentumsproblem, das an der Quelle zu lösen ist, kein Grund, größere NAT-Regeln darüberzulegen.