OpenVPN-Client für das ganze LAN auf OpenWrt: eine funktionierende Reihenfolge

Schnittstellen-Eigentümerschaft, Zonenpolitik, Masquerading und Tabellen pro SSID sind vier getrennte Aufgaben. In dieser Reihenfolge erledigt, hört ein routerweiter Tunnel auf, gegen Sie zu arbeiten.

Vier unabhängige Aufgaben bringen das gesamte LAN eines Routers hinter einen Tunnel. Das Tunnelgerät braucht einen Eigentümer, eine Firewall-Zone, ein Übersetzungsziel zum Uplink hin und, falls einige Clients außerhalb des VPN bleiben müssen, Routing nach Quelladresse. Ein Tunnel, der sich verbindet, während nichts durchgeht, hat meist eine dieser vier Sachen nicht. In Abhängigkeitsreihenfolge zu arbeiten heißt: Ein Fehler am Ende gehört zu dem Schritt, den Sie gerade geändert haben. Jeder Schritt unten endet mit etwas, das Sie beobachten können, und das bewahrt den nächsten davor, eine Vermutung zu sein.

Entscheiden Sie, was den Tunnel teilt

Der Router, der WLAN und DHCP verteilt, kann den Client selbst ausführen. Damit steht jedes angeschlossene Gerät hinter dem Tunnel, ohne Einrichtung pro Gerät, und das ist die Anordnung, die die meisten kleinen Standorte wollen. Es ist zugleich die mit der größten Reichweite, wenn der Tunnel ausfällt, weil alle Geräte gleichzeitig ihren Weg verlieren. Nichts im LAN behält einen funktionierenden Weg nach draußen.

Ein zweiter Router hinter dem ersten, der den Client mit eigenem Subnetz betreibt, begrenzt den Tunnel auf seine eigenen Geräte. Er lässt sich leichter entfernen und leichter dem erklären, der ihn erbt. Der Preis ist Erreichbarkeit zwischen beiden Seiten ohne Route oder Portweiterleitung.

Wie auch immer, machen Sie die LAN-Subnetze unterschiedlich. Gleiche Bereiche lassen eine Seite direkt angeschlossen erscheinen, und das entstehende schwarze Loch liest sich stundenlang wie ein VPN-Fehler.

Geben Sie dem Tunnel einen Eigentümer

Deklarieren Sie den Tunnel als Netzwerkschnittstelle mit Namen, Gerät und ohne eigenes Protokoll. Das Netzwerksystem erstellt und verwaltet dann das Gerät, und alles Nachgelagerte bezieht sich auf die Schnittstelle per Namen statt per Gerät. Das befähigt die Zone, ihn zu finden.

Legen Sie dasselbe Gerät nicht an zwei Stellen an. Ein handgebauter Tunnel neben einer deklarierten Schnittstelle erzeugt ein Gerät, das existiert, aber in keiner Zone ist, oder eines, das beim Neuladen verschwindet. Beides sieht wie ein Client-Fehler aus, und keines erzeugt einen Fehler, der die echte Ursache nennt. Wählen Sie den deklarativen Weg und löschen Sie den manuellen.

Halten Sie den Namen in Netzwerk-, Firewall- und VPN-Konfiguration identisch. Die Zone listet Netzwerke nach Namen, ein Tippfehler lässt den Tunnel also außerhalb jeder Zone, während die Schnittstelle selbst gesund aussieht. Eine gesunde Schnittstelle ohne Politik ist der am schwersten zu erkennende Zustand.

In eine Zone legen, dann dorthin weiterleiten

Eine Firewall-Zone ist der Ort, an dem Politik lebt: input, output, forward und masquerade. Ein Tunnel in keiner Zone wird von Vorgaben regiert, die Sie nicht gewählt haben, und das ist selten, was ein Router-Client braucht. Die Blöcke unten deklarieren die Schnittstelle, legen sie in eine Zone und erlauben LAN-Verkehr in diese Zone.

config interface 'vpn'
    option device 'tun0'
    option proto 'none'

config zone
    option name 'vpn'
    list network 'vpn'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'

config forwarding
    option src 'lan'
    option dest 'vpn'

Auf Releases älter als 21.02 wird dieselbe Schnittstellenzeile als option ifname geschrieben, prüfen Sie also, welche Form die installierte Firmware verarbeitet, bevor Sie einfügen. Der Weiterleitungsblock ist die Erlaubnis, die LAN-Verkehr den Tunnel überhaupt nutzen lässt. Ohne ihn ist das Gerät oben, der Client verbunden, und kein LAN-Host erreicht den Tunnel. Das ist die häufigste Meldung verbunden, aber kein Internet bei Router-Clients.

Masquerade auf der VPN-Zone faltet jede LAN-Adresse in die Tunneladresse des Routers, bevor das Paket hinausgeht. Das beseitigt die Notwendigkeit einer Rückroute zu Ihrem Subnetz auf der Gegenseite.

Wenn die Gegenseite Ihr LAN bereits routet, hält das Abschalten von Masquerade Quelladressen sichtbar und macht Protokolle pro Client aussagekräftig. Wählen Sie eines und schreiben Sie auf, welches, weil die beiden Optionen später unterschiedliche Support-Fragen erzeugen. Das Entfernen der Standard-Weiterleitung von LAN nach WAN ist eine eigene Entscheidung mit eigener Folge. Nehmen Sie sie weg, und der eigene Internetzugang des Routers geht mit.

Benennen Sie den echten Uplink in NAT

Auf Firmware, wo die Übersetzungsregel von Hand geschrieben ist, ist die ausgehende Schnittstelle das Feld, das schiefgeht. Eine Regel mit vlan2 tut nichts, wenn die Sitzung auf ppp0 endet. Eine Regel ganz ohne Schnittstelle kann Verkehr übersetzen, der privat hätte bleiben sollen. Keiner der Fehler meldet sich selbst, weil der Tunnel weiterläuft.

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Ersetzen Sie ppp0 in dieser Regel durch die Schnittstelle aus ip route oder der Liste laufender Schnittstellen, und beobachten Sie dann den Zähler, während ein LAN-Host eine Seite lädt. Auf einem Router mit einem Anbieter genügt normalerweise eine Masquerade-Regel für den Uplink. Eine zweite Regel für die Tunnelschnittstelle ersetzt die erste nicht.

Dann fügen Sie die Client-Optionen hinzu, die entscheiden, was in den Tunnel gelangt. Eine redirect-gateway-Direktive schickt den Internetverkehr des Clients durchs VPN, und ohne sie trägt der Tunnel nur die Routen, die der Server schiebt. Prüfen Sie die resultierende Routentabelle, bevor Sie DNS anfassen.

Teilen Sie das WLAN mit einer zweiten Tabelle

Eine Routentabelle kann nicht zwei Vorgaben halten. Eine zweite SSID, die den Tunnel umgehen muss, braucht daher ihr eigenes Subnetz und ihre eigene Tabelle. Geben Sie der getunnelten SSID ihren eigenen Bereich und routen Sie dann nur diesen Bereich per Regel, die die Tabelle auswählt, in den Tunnel.

Policy-Routing-Pakete auf OpenWrt drücken genau diese Kombination aus. Von Hand geht es auch, mit einer Quellregel und einer Tabelle, deren Vorgabe auf das Tunnelgerät zeigt.

Prüfen Sie die Teilung aus beiden Netzen. Ein Client an der getunnelten SSID sollte die Ausgangsadresse des VPN zeigen, ein Client an der gewöhnlichen SSID die des Anbieters. Sehen beide gleich aus, trifft die Regel die falsche Quelle oder die Tabelle wird nie befragt. Testen Sie auch nach einem Reconnect, weil eine Regel, die am Schnittstellennamen hängt, bricht, wenn das Gerät neu nummeriert wird.

Verdächtigen Sie die Uhr und das Geräteflag

Das Flag persist-tun lässt das Tunnelgerät über Neustarts hinweg an Ort und Stelle. Das passt zu einem Server und verwirrt einen Client, dessen Zustand von Grund auf neu aufgebaut werden sollte. Entfernen Sie es, während Sie einen Router-Client diagnostizieren, weil ein Gerät, das eine gescheiterte Aushandlung überlebt, verbirgt, welcher Schritt wirklich brach. Setzen Sie es zurück, sobald der Client zuverlässig verbindet, und nicht vorher.

Die Uhr ist der andere stille Fehler. Ein Router ohne batteriegestützte Uhr startet bei der Epoche, was bedeutet, dass Zertifikatsprüfungen scheitern, bis NTP aufholt. Vergleichen Sie die Log-Zeitstempel mit der echten Zeit, bevor Sie ein Zertifikat anfassen, weil ein Client, der eine Minute nach dem Boot verbindet, meist auf die Zeitsynchronisation wartet.

Ähnliche Artikel