OpenWrt-VPN-Zone, Weiterleitung und Maskierung: Was brauchen Sie?
Zonen-Eingang, Weiterleitung und Maskierung beantworten verschiedene Fragen. Entscheiden Sie, was Ihr VPN-Verkehr braucht, bevor Sie die WAN-Zone öffnen.
Drei Änderungen werden vermischt, sobald ein VPN auf OpenWrt trifft: einen Port öffnen, Weiterleitung erlauben und Maskierung einschalten. Sie beantworten verschiedene Fragen, und meist ist nur eine davon die tatsächliche Anforderung. Wer jede Steuerung nach der Verkehrsrolle liest, die sie regelt, macht aus einer Vermutung eine Entscheidung und erfährt außerdem, welches Symptom bei einer falschen Änderung zu erwarten ist. Beginnen Sie mit der Rolle, die versagt hat, nicht mit dem Kontrollkästchen, an das Sie sich erinnern.
Benennen Sie die Verkehrsrolle, bevor Sie eine Steuerung anfassen
Der Zonen-Eingang entscheidet, was den Router selbst erreichen darf. Der Zonen-Ausgang umfasst Verkehr, den der Router selbst erzeugt, die Zonen-Weiterleitung ist der Standard für Verkehr, der eine Zone durchquert, und die Maskierung entscheidet, ob die Quelladresse auf dem Weg nach draußen umgeschrieben wird. Das sind vier verschiedene Fragen, und eine Zonenrichtlinie beantwortet alle auf einmal mit demselben Wert, weshalb eine Änderung für die ganze Zone ein grobes Werkzeug ist. Eine benannte Regel kann eine davon beantworten, ohne die übrigen anzutasten.
Die nützliche Karte ist nach Verkehrsrolle geordnet, denn genau das lässt sich beobachten, wenn etwas fehlschlägt. Jede Rolle unten hat eine Steuerung, die sie entscheidet, und ein Symptom, das auf sie zeigt:
| Traffic role | Control that decides it | Where it lives in the config | Symptom when it is wrong |
|---|---|---|---|
| A client reaching a listener on the router | Input policy of the zone that carries the connection, or a rule for the port | option input in the zone stanza, or a named rule | The handshake never completes and the tunnel log says nothing |
| A tunnel client reaching the router itself | Input policy of the tunnel zone | option input in the VPN zone | A ping to the gateway fails |
| A tunnel client reaching another LAN host | Forwarding from the tunnel zone to the LAN zone | config forwarding plus the zone assignment | The gateway answers and the file share times out |
| The router's own traffic leaving the WAN | Output policy, and translation if the far side needs it | option output and option masq | The tunnel never establishes, or replies vanish |
Ein Dienst auf dem Router braucht eine schmale Eingangsregel
Ein OpenVPN-Server auf dem Router empfängt Verkehr, der an den Router adressiert ist, deshalb hängt seine äußere Verbindung von der Eingangsrichtlinie der Zone ab, die ihn trägt. Erlauben Sie das konfigurierte Transportprotokoll und den Port und lassen Sie alles andere in dieser Zone verwerfen. Eine einzelne Portregel ist eine viel kleinere Änderung als eine Freigabe für die ganze Zone, und sie ist diejenige, die Sie auch in einem Jahr noch erklären können.
Zwei Dinge machen diese Regel sicher genug zum Behalten: Sie nennt den Port, den der Dienst tatsächlich nutzt, und sie steht neben der Zonendefinition, damit die nächste Person sieht, warum es sie gibt. Die Zeilen unten sind die Form, wobei der Port für das steht, was auf dem Server konfiguriert ist. Ändern Sie diesen Port an beiden Stellen, wenn der Dienst umzieht, denn eine Regel, die auf dem alten bleibt, ist bis zur Prüfung unsichtbar.
config zone
option name 'wan'
option input 'REJECT'
option forward 'REJECT'
option output 'ACCEPT'
option masq '1'
config rule
option name 'allow-openvpn'
option src 'wan'
option proto 'udp'
option dest_port '1194'
option target 'ACCEPT'Prüfen Sie vor dem Neuladen, denn ein Syntaxfehler in einer Firewall-Datei kann den Router ohne funktionierendes Regelset zurücklassen. In einer Version mit fw4 ist die Prüfung ein eigener Befehl, und sie schlägt laut fehl, statt einen kaputten Block stillschweigend zu übernehmen. Laden Sie erst neu, nachdem die Prüfung bestanden ist, und bewahren Sie die vorherige Datei dort auf, wo Sie sie zurücklegen können.
fw4 check
service firewall reloadEine Client-Anfrage durchläuft die Weiterleitung, nicht den Eingang
Nach der Anmeldung erzeugt die Anfrage eines Tunnelclients nach einem LAN-Dienst einen weitergeleiteten Fluss, deshalb ist die Steuerung, die das entscheidet, die Weiterleitungsbeziehung zwischen der Tunnelzone und der LAN-Zone. Weisen Sie die Tunnelschnittstelle der vorgesehenen Zone zu und erklären Sie dann die Richtung, die Quellen und den Dienst. Die Zonenzuweisung ist das, was der Weiterleitungsregel Bedeutung gibt, und beides ergibt nur zusammen gelesen Sinn. Eine Weiterleitungsbeziehung, die die Tunnelzone als Quelle und die LAN-Zone als Ziel nennt, liest sich als eine bewusste Entscheidung, während zwei Freigaben für die ganze Zone sich wie ein Unfall lesen.
Der Router selbst wird weiterhin über den Eingangspfad erreicht, deshalb sagt ein Ping zum Gateway nichts über die Dateifreigabe dahinter. Diese beiden Fehler leben in verschiedenen Blöcken und werden mit verschiedenen Änderungen behoben. Schreiben Sie beide Pfade getrennt auf, bevor Sie einen davon ändern.
Maskierung ist eine Routingentscheidung, keine Berechtigung
Maskierung schreibt die Quelladresse ausgewählten ausgehenden Verkehrs um. Sie kann ein Ausgangsdesign retten, bei dem die Gegenseite keine Rückroute hat, und sie verbirgt außerdem einzelne Clientadressen vor jedem Dienst, der Adressen protokolliert oder danach autorisiert. Sie abzuschalten ist eine Routingentscheidung über den Rückweg, kein Sicherheitsschalter, der ein eingehendes Loch schließt. Ein Tunnel, der mit eingeschalteter Übersetzung funktioniert und in dem Moment scheitert, in dem sie abgeschaltet wird, hat meist eine fehlende Rückroute, keine fehlende Firewallregel.
Eine geroutete Alternative braucht statt der Übersetzung eine Rückroute auf der Gegenseite. Keine der beiden Möglichkeiten liefert die Firewall-Berechtigung oder das Anwendungskonto, weshalb das Abschalten der Maskierung fast nie einen Tunnelclient repariert, der nichts erreichen kann. Behandeln Sie auch die IPv4- und die IPv6-Richtlinie getrennt, denn eine Übersetzungseinstellung beschreibt nicht beide Familien.
Beweisen Sie die Entscheidung mit einer erlaubten und einer abgelehnten Anfrage
Senden Sie eine Anfrage, die erlaubt werden soll, und eine, die abgelehnt werden soll, und bestimmen Sie dann die Steuerung, die jede Entscheidung getroffen hat. Eine Seite, die zufällig lädt, ist kein Beweis; der Beweis ist die Regel, die gepasst hat, in der Kette, in der sie gepasst hat. Die Ablehnung zählt so viel wie der Erfolg, denn sie zeigt, dass die Richtlinie etwas tut, statt dass alles erlaubt ist.
Zwei Befehle liefern Ihnen diesen Beweis in einer aktuellen Version. Der Zähler an der passenden Regel bewegt sich, wenn die Anfrage angenommen wird, und das Protokoll zeigt den Verwerf, wenn Sie die Protokollierung für die Regel eingeschaltet haben:
nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'Behalten Sie einen Verwaltungsweg, den Sie noch nutzen können, bevor Sie eine Firewall-Richtlinie ändern, und folgen Sie dem Prüf- und Rückabwicklungsprozess des Konfigurationsverantwortlichen. Eine Änderung, die Sie vom Router aussperrt, ist kein Testergebnis, sondern ein zweiter Vorfall. Notieren Sie die Zone und die Verkehrsrolle neben jeder Beobachtung, damit das Ergebnispaar die Richtlinie erklärt, statt ein glückliches Laden einer Seite zu beschreiben.