hostapd und OpenVPN auf einem Pi: Wem gehört die Standardroute?

hostapd und ein OpenVPN-Client können sich einen Pi teilen, wenn die Bridge ihre eigene Standardroute behält und der Tunnel einen Pfad zu seinem Server behält. Befehle und Rückabwicklung.

Telefone verbinden sich mit dem Access Point, erhalten eine Adresse und erreichen dann gar nichts mehr, sobald der Tunnel hochkommt. hostapd ist in diesem Zustand meist gesund, und OpenVPN ebenfalls; was bricht, ist die Standardroute, die entweder nie auf der Bridge existierte oder vom Tunnel ersetzt wurde, ohne einen Pfad zum VPN-Server selbst zu hinterlassen. Dieses Runbook setzt die Route dorthin zurück, wo sie hingehört, und belegt das Ergebnis von einem Client statt vom Pi. Jeder Schritt ist umkehrbar, und nichts hier ändert die Konfiguration des Tunnels, bis Sie wissen, welchen Verkehr Sie darin haben wollen.

Bestandsaufnahme der Schnittstellen, bevor Sie etwas ändern

Das vertraute Layout legt das Funkgerät und den kabelgebundenen Port in br0, startet hostapd gegen die Bridge und verteilt Leases aus dnsmasq, während ein OpenVPN-Client tun0 anlegt. Dann sehen drei getrennte Anforderungen wie eine aus: Access-Point-Clients brauchen den Pi als ihr Gateway, der Pi braucht eine Route ins Internet, um seinen Server zu erreichen, und die Bridge braucht eine Gateway-Adresse, die diese Clients nutzen können.

Lesen Sie den aktuellen Zustand, bevor Sie ihn ändern, denn diese vier Befehle trennen ein Schnittstellenproblem von einem Routingproblem.

ip -br addr
ip route show
ip link show master br0
bridge link show

Wenn br0 eine Adresse trägt, aber keine Standardroute hat, erreichen Clients den Pi und nichts dahinter. Wenn die Standardroute auf tun0 zeigt, während der Tunnel unten ist, hat der Pi überhaupt keinen funktionierenden Pfad, und das Clientsymptom sieht genau gleich aus. Beide Fälle sehen vom Telefon identisch aus, weshalb die Routentabelle direkt gelesen werden muss.

Geben Sie der Bridge eine Standardroute, die ihr gehört

Raspberry Pi OS lässt die Bridge häufig ohne Standardroute, wenn die Bridge erst entstand, nachdem die Schnittstellendatei geschrieben wurde. Der Block gehört in /etc/dhcpcd.conf und sollte den vorgelagerten Router nennen statt den Pi.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

In diesem Beispiel ist 192.168.50.1 der vorhandene Router und 192.168.50.2 die Bridge-Adresse des Pi im selben Subnetz, ersetzen Sie also durch Ihren eigenen Plan, statt die Zahlen zu kopieren. Die Bridge-Mitglieder dürfen ebenfalls keine Router anfordern, sonst hat der Pi konkurrierende Standardrouten, deren Gewinner von Metrik und Zeitpunkt abhängt statt von der Absicht.

Nach systemctl restart dhcpcd sollte ip route show default br0 einmal auflisten und kein Duplikat vom kabelgebundenen Port. Bestätigen Sie die Abfrage statt der Tabelle, denn ein veralteter Eintrag kann neben einem gewinnenden sitzen: ip -4 route get 203.0.113.10 muss br0 nennen. Diese Adresse stammt aus dem Dokumentationsbereich TEST-NET-3, kann also nicht mit einem echten Server kollidieren, während Sie dies lesen.

Hindern Sie den Tunnel daran, den Pfad zu seinem eigenen Server zu kapern

Ein OpenVPN-Client, der redirect-gateway akzeptiert, übernimmt die Standardroute und richtet sie in den Tunnel. Das ist richtig, wenn jeder Access-Point-Client das VPN nutzen soll, und falsch, wenn nur einige Ziele es sollen. So oder so darf die eigene Verbindung des Pi zum Server nicht innerhalb des Tunnels verlaufen, den er noch aufbaut. OpenVPN fügt eine Hostroute zum Gegenüber über das ursprüngliche Gateway hinzu, wenn es die Standardroute umleitet, und genau dieses Verhalten hält den Transport am Leben; fehlt diese Route, bricht der Tunnel zusammen, sobald er steht.

Ein kurzer Vergleich dieses Transportpfads vor und nach dem Verbinden ist die zehn Sekunden wert. ip -4 route get 203.0.113.10 sollte in beiden Zuständen das Underlay-Gerät nennen, wobei sich nur die Metrik verschiebt. Wenn es nach dem Hochkommen des Tunnels tun0 nennt, wurde die Hostroute nie installiert, und die nächste Wiederverbindung schlägt fehl.

Wenn nur ausgewählte Präfixe den Tunnel kreuzen sollen, verwenden Sie route-nopull und fügen Sie die gewünschten Routen von Hand hinzu, oder schieben Sie einen engeren Satz vom Server. Die Bridge behält in diesem Entwurf die Standardroute, und DNS wird die nächste Entscheidung: Eine Weiterleitung von dnsmasq an einen Heim-Resolver ergibt nur für die Namen Sinn, die dort tatsächlich leben.

Entscheiden Sie die Geschichte von Weiterleitung und NAT

Ein voller Tunnel braucht aktivierte Weiterleitung auf dem Pi und ein Gateway auf der Gegenseite, das das Access-Point-Subnetz routen will. Prüfen Sie die Weiterleitung vor allem anderen, denn eine Null macht jede Routenänderung irrelevant.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

Die NAT-Regel ist die Abkürzung, die funktioniert, wenn der Server das Access-Point-Präfix nicht akzeptiert, zum Preis, dass jeder Client in den Protokollen der Gegenseite als Tunneladresse des Pi erscheint. Das Präfix ohne NAT zu routen hält Adressen sichtbar und hängt von einer Rückroute für 192.168.50.0/24 auf der Heimseite ab.

Schreiben Sie die Wahl neben die Firewall-Regeln, denn eine NAT-Regel, die im Entwurf unsichtbar ist, wird sechs Monate später unerklärlich. Behalten Sie IPv6 in derselben Entscheidung; ein funktionierender IPv4-Pfad neben einem kaputten IPv6-Pfad liest sich im Browser weiterhin als halb kaputt.

Prüfen Sie von einem Client aus und rollen Sie dann sauber zurück

Testen Sie in dieser Reihenfolge von einem Telefon oder Laptop am Access Point: ein Lease von dnsmasq, ein Ping an die Bridge-Adresse, dann ein Ziel auf der Gegenseite des Tunnels. Jeder Schritt isoliert eine Schicht, statt einen einzigen nutzlosen Fehler zu erzeugen.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

Bestätigen Sie dann, dass der Pi noch seinen eigenen Weg nach draußen hat: ip route get 203.0.113.10 sollte das Underlay-Gerät nennen, und ping -c 3 -I br0 203.0.113.10 sollte antworten, wenn der Server ICMP erlaubt. Wenn die ersten beiden Client-Schritte bestehen und der dritte scheitert, sitzt der Fehler in Weiterleitung oder NAT. Wenn der zweite Schritt scheitert, sind Bridge oder DHCP noch unvollständig.

Rückabwicklung ist eine Dateibearbeitung und zwei Befehle: Entfernen Sie den Block, starten Sie dhcpcd neu und ersetzen Sie die Standardroute ausdrücklich mit ip route replace default via 192.168.50.1 dev br0. Tun Sie das, bevor das Wartungsfenster schließt, statt danach, denn ein Pi, der seine Standardroute verloren hat, ist aus dem Netz nicht erreichbar, das Sie zur Reparatur nutzen würden.

Ähnliche Artikel