VPN-Gateway auf dem Raspberry Pi: eine Netzwerkkarte oder ein eigener Client-Port

Sie haben einen Pi, ein funktionierendes ausgehendes VPN-Profil und zwei Geräte, die darüber ins Internet gelangen sollen. Die Frage, die den ganzen Aufbau entscheidet, ist nicht, welcher Anleitung man folgt, sondern wie viel Abschottung Sie brauchen. Ein einziger Port lässt den Pi neben diesen Geräten im LAN des Routers stehen und als zusätzliches Gateway wirken; ein zweiter Port lässt Sie sie in ein Segment setzen, in dem der Pi der einzige Weg nach draußen ist. Alles danach — DHCP, Umfang der Firewall, DNS, der Ausfallfall — folgt daraus.

Worin sich die beiden Layouts tatsächlich unterscheiden

Beide Entwürfe routen. Der Unterschied ist, wer sonst noch am Kabel hängt und was passiert, wenn Ihre Politik falsch ist.

Abschottung ist die eigentliche Achse. Layout A ist beratend: ein Gerät, das das per DHCP zugewiesene Gateway ignoriert und den Router wählt, funktioniert weiterhin, unverschlüsselt. Layout B wird durch die Topologie erzwungen, weil es keinen anderen nächsten Hop zu wählen gibt.

Layout A: der Pi als zusätzliches Gateway im bestehenden LAN

Nehmen Sie an, der ISP-Router ist 192.168.50.1, der Pi ist 192.168.50.2, und die ausgewählten Clients zeigen auf den Pi. Entscheidend ist, dass zwei verschiedene Paketströme ein Kabel teilen. Das innere Paket des Clients kommt am Pi an und muss durch den Tunnel hinaus; das eigene verschlüsselte Paket des Pi zum VPN-Peer muss über dasselbe Kabel zum Router hinaus. Sie laufen in entgegengesetzten Richtungen über dieselbe Schnittstelle und brauchen unterschiedliche Behandlung.

Geben Sie dem Pi seine Adresse über den installierten Netzwerkmanager, nicht über ein altes Interface-Datei-Rezept, das mit ihm um das Gerät streitet. Stellen Sie dann die Clients ein: ein statisches Gateway auf einem Gerät oder eine DHCP-Reservierung, die 192.168.50.2 als Router ausgibt. Ändern Sie nicht den gesamten DHCP-Bereich des Routers wegen zweier Geräte, und nehmen Sie nicht an, dass ein Client die Option beachtet — prüfen Sie es.

Die Schwäche ist strukturell und nicht behebbar. Jeder Client in diesem Segment kann auf 192.168.50.1 zeigen und im Klartext hinausgehen, und ein Gerät mit zweiter Schnittstelle oder Mobilfunk verlässt Ihren Durchsetzungspfad vollständig. Wenn dieser Satz für das betreffende Gerät nicht akzeptabel ist, haben Sie Ihre Antwort schon: Nehmen Sie Layout B.

Layout B: ein eigener Port schließt die Geräte ein

Hier behält der Pi 192.168.50.2 am Uplink mit Gateway 192.168.50.1 und nimmt 10.20.0.1/24 auf einer zweiten Schnittstelle für die angeschlossenen Geräte. Der Pi ist nun ein Router mit zwei Netzen, und das angeschlossene Segment hat genau einen Ausgang.

Prüfen Sie den Bereich gegen alles andere, bevor Sie sich festlegen: das eigene Subnetz des Tunnels, andere Standort-zu-Standort-Präfixe und alles, was über das VPN erreichbar ist. Ein 10.20.0.0/24, das mit einem entfernten LAN kollidiert, erzeugt jenes halb funktionierende Ergebnis, dessen Diagnose einen Abend kostet. Ist der zweite Port ein USB-Adapter, bestätigen Sie, dass er unterstützt wird, und legen Sie seinen Namen im Netzwerkmanager fest, damit eine Neuordnung nach dem Neustart Ihre LAN-Adresse nicht verschiebt.

Betreiben Sie den DHCP-Listener nur auf dieser Schnittstelle. Ein Server, der am Uplink antwortet, konkurriert mit dem ISP-Router und gibt die Adressen Ihres Segments an den Rest des Hauses aus. Binden Sie ihn an die LAN-Schnittstelle, beschränken Sie ihn auf den erklärten Bereich und halten Sie die eigene Adresse des Pi aus dem Pool.

Weiterleitung, Übersetzung und die Regel zum Schließen bei Ausfall

Vier Dinge werden oft als eines beschrieben und sind es nicht. Weiterleitung einzuschalten (net.ipv4.ip_forward=1) sagt dem Kernel nur, dass er Pakete zwischen Schnittstellen bewegen darf; es erlaubt für sich genommen nichts und garantiert keinen Weg. Den Ausgang zu wählen ist eine Routingentscheidung. Das Paket zu erlauben ist eine Politikentscheidung in der forward-Kette. Seine Quelle umzuschreiben ist eine postrouting-Entscheidung. Ein Aufbau, der nur das Erste tut, ergibt einen Pi, der Clientverkehr fröhlich über den Uplink weiterleitet.

Beschränken Sie die Erlaubnis auf die gemeinten Quellen und auf die Schnittstelle, die der Verkehr nutzen soll, und schließen Sie den Rückweg und die eigenen nötigen Ziele des Pi ein. Übersetzen Sie dann am Tunnelausgang, wenn der Anbieter Ihr LAN-Präfix nicht zu Ihnen zurückroutet. nftables-Handbuch behandelt Weiterleitung, lokale Ausgabe und Quellübersetzung als getrennte Vorgänge, was hier das richtige Denkmodell ist.

Der häufige Fehler ist eine breite masquerade-Regel auf der physischen Schnittstelle. Dann erreicht der Verkehr das Internet über den ISP-Weg, während er von der Clientseite her genau wie ein funktionierendes VPN aussieht. Das beweist nichts. Halten Sie die Übersetzung an den erklärten Ausgang gebunden und halten Sie Ihre Regeln in der Firewall, die der Host ohnehin nutzt, statt ein konkurrierendes Regelset hinzuzufügen, das eine gemeinsame postrouting-Kette leert.

Behandeln Sie dann das Fehlen des Tunnels. Ein Clientprofil, das eine breite Standardroute installiert, bedeutet auch, dass bei einem Tunnelabbruch die gewöhnliche Standardroute zurückkommen kann und der Clientverkehr still zum Uplink zurückkehrt. Wo ein Rückfall in Klartext nicht akzeptabel ist, muss die forward-Politik Verkehr vom Client zum Uplink ausdrücklich verweigern, und zwar in dem Zustand, in dem die VPN-Route weg ist. Schreiben Sie das als reject-Regel, nicht als Annahme. Der eigene verschlüsselte Transport des Pi zum VPN-Peer ist ein getrennter local-output-Strom und muss erlaubt bleiben, sonst kann der Tunnel nie zurückkommen.

DNS und IPv6 brauchen ihre eigene Antwort

Wenn Clients den Pi als Resolver nutzen, treffen sie auf einen lokalen Listener, und der Pi startet eine neue Abfrage. Diese vorgelagerte Abfrage folgt der eigenen Route des Pi, nicht der forward-Regel, die Sie für Clients geschrieben haben, also ist ein Clientpfad nur durch den Tunnel plus ein Resolver, der direkt ausgeht, ein Leck ohne jede Fehlermeldung. Entscheiden Sie bewusst: ein über den Tunnel erreichter Resolver oder ein lokaler, den Sie als direkt akzeptieren, und lassen Sie die eigene Ausgangspolitik des Pi zu dieser Entscheidung passen.

IPv6 ist wieder ein eigener Fall. Eine forward-Regel für IPv4 beschränkt nichts bezüglich IPv6, und Router-Ankündigungen am Uplink können dem Pi und über ihn dem angeschlossenen Segment eine zweite Standardroute geben, die Ihre Politik umgeht. Geben Sie IPv6 entweder nach demselben Prinzip einen eigenen geschützten Weg, oder beschränken Sie es im Clientsegment ausdrücklich und sagen Sie es.

Testen Sie die Grenze, bevor Sie ihr trauen

Akzeptieren Sie den Entwurf erst nach vier getrennten Prüfungen, denn der verführerische Einzeltest — einen Browser auf einem Client öffnen — besteht in mehreren kaputten Zuständen.

Bestätigen Sie, dass ein echter Client über den Tunnel ins Internet gelangt, und bestätigen Sie dann, dass derselbe Client bei ausgefallenem Tunnel das Internet nicht erreicht. Bestätigen Sie, dass die DNS-Auflösung funktioniert und die Abfrage dort hinausgeht, wo Sie es wollten. Bestätigen Sie, dass der eigene Transport des Pi nach einem Tunnelneustart noch funktioniert und die Erholung keinen Neustart der Maschine erfordert. Prüfen Sie schließlich ein Gerät, das Sie nicht ausgewählt haben: unter Layout A soll es normal weiterarbeiten, und unter Layout B soll es in diesem Segment gar nicht existieren.

• Zwei Ports und eine Verweigerungsregel erzwingen; ein Port und eine DHCP-Option beraten.
• Übersetzung an der falschen Schnittstelle sieht wie Erfolg aus und ist keiner.
• Der eigene Verkehr des Pi, DNS und IPv6 brauchen jeweils eine Entscheidung, keine Schlussfolgerung.