13
VPN-Gateway für ein einzelnes Gerät im Heimnetz mit rPi
Hallo zusammen,
ist es möglich ein OVPN-Gateway auf rPI einzurichten das nur von einem Gerät im Heimnetz bzw. selektiv von Geräten benutzt werden kann?
zunächst die Rahmenbedingungen
- rPi4 mit bullseye ist vorhanden.
- Wir befinden uns in einem privaten Netzwerk 192.168.1.0 hinter einem DSL-Router
- der rPi ist mit eth0 ein IP-Client in diesem privaten Netz und hat auf eth0 die feste IP 192.168.1.100
- Der DSL-Router ist die 192.168.1.200
In diesem Netz gibt es 3 Clients mit festen IP-Adressen:
C1: 192.168.1.11
C2: 192.168.1.12
C3: 192.168.1.13
Das Gateway ist für alle Clients der DSL-Router 192.168.1.200
Vorhaben:
Die Verbindungen des Clients C2 nach aussen sollen über ein OpenVPN-Netz geschickt werden. Der rPi soll dabei als Router fungieren.
Auf dem rPi wird mittels OpenVPN ein Tunnel aufgebaut. OpenVPN fungiert auf dem rPi als OVPN-Client. Beim Verbindungsaufbau wird ein virtuelles Device tun1 angelegt. Die IP für tun1 kommt per DHCP vom OVPN-Server.
An dieser Stelle hänge ich nun.
- Was muss ich nun tun damit die Verbindungen des C2 in diesen Tunnel geroutet werden - aber auch nur die Verbindungen des C2?
- Es sollen nur die Verbindungen nach extern in diesen Tunnel geroutet werden.
- C2 soll weiterhin im privaten Netz unter 192.168.1.12 für andere erreichbar sein
- C2 soll weiterhin andere Clients im privaten Netz 192.168.1.0 direkt erreichen können.
- Die Verbindungen der anderen Clients und des rPI selbst sollen weiterhin über den DSL-Router in's Internet laufen.
Auf Seite des C2 war meine Überlegung dass ich diesem sage dass sein Gateway der rPi 192.168.1.100 sein soll. Auf Seite rPi 192.168.1.100 war mein Gedanke dass ich einen "Selektor" brauche der Verbindungen prüft von wem sie kommen, ob von C2 oder von etwas anderem. Wie könnte ich einen solchen Selektor realisieren?
Der Pi hat nur NIC (und das soll auch so bleiben). Eine physische Trennung mittels Ports funktioniert schonmal nicht.
Vielen Dank schonmal für eure Hilfe.
ist es möglich ein OVPN-Gateway auf rPI einzurichten das nur von einem Gerät im Heimnetz bzw. selektiv von Geräten benutzt werden kann?
zunächst die Rahmenbedingungen
- rPi4 mit bullseye ist vorhanden.
- Wir befinden uns in einem privaten Netzwerk 192.168.1.0 hinter einem DSL-Router
- der rPi ist mit eth0 ein IP-Client in diesem privaten Netz und hat auf eth0 die feste IP 192.168.1.100
- Der DSL-Router ist die 192.168.1.200
In diesem Netz gibt es 3 Clients mit festen IP-Adressen:
C1: 192.168.1.11
C2: 192.168.1.12
C3: 192.168.1.13
Das Gateway ist für alle Clients der DSL-Router 192.168.1.200
Vorhaben:
Die Verbindungen des Clients C2 nach aussen sollen über ein OpenVPN-Netz geschickt werden. Der rPi soll dabei als Router fungieren.
Auf dem rPi wird mittels OpenVPN ein Tunnel aufgebaut. OpenVPN fungiert auf dem rPi als OVPN-Client. Beim Verbindungsaufbau wird ein virtuelles Device tun1 angelegt. Die IP für tun1 kommt per DHCP vom OVPN-Server.
An dieser Stelle hänge ich nun.
- Was muss ich nun tun damit die Verbindungen des C2 in diesen Tunnel geroutet werden - aber auch nur die Verbindungen des C2?
- Es sollen nur die Verbindungen nach extern in diesen Tunnel geroutet werden.
- C2 soll weiterhin im privaten Netz unter 192.168.1.12 für andere erreichbar sein
- C2 soll weiterhin andere Clients im privaten Netz 192.168.1.0 direkt erreichen können.
- Die Verbindungen der anderen Clients und des rPI selbst sollen weiterhin über den DSL-Router in's Internet laufen.
Auf Seite des C2 war meine Überlegung dass ich diesem sage dass sein Gateway der rPi 192.168.1.100 sein soll. Auf Seite rPi 192.168.1.100 war mein Gedanke dass ich einen "Selektor" brauche der Verbindungen prüft von wem sie kommen, ob von C2 oder von etwas anderem. Wie könnte ich einen solchen Selektor realisieren?
Der Pi hat nur NIC (und das soll auch so bleiben). Eine physische Trennung mittels Ports funktioniert schonmal nicht.
Vielen Dank schonmal für eure Hilfe.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2638876046
Url: https://administrator.de/contentid/2638876046
Ausgedruckt am: 10.11.2024 um 01:11 Uhr
13 Kommentare
Neuester Kommentar
Moin,
dein „Selektor“ nennt sich Routing und ist in wenigen Minuten eingerichtet… Die VPN-Konfiguration musst du dann als Split-Tunneling betreiben und der Client bekommt den rPi als Gateway.
Fertig…
VG
P.S.: und alles was sich in deinem lokalen Subnetz abspielt geht sowieso nicht über das Gateway…
dein „Selektor“ nennt sich Routing und ist in wenigen Minuten eingerichtet… Die VPN-Konfiguration musst du dann als Split-Tunneling betreiben und der Client bekommt den rPi als Gateway.
Fertig…
VG
P.S.: und alles was sich in deinem lokalen Subnetz abspielt geht sowieso nicht über das Gateway…
Zitat von @BirdyB:
dein „Selektor“ nennt sich Routing und ist in wenigen Minuten eingerichtet… Die VPN-Konfiguration musst du dann als Split-Tunneling betreiben und der Client bekommt den rPi als Gateway.
dein „Selektor“ nennt sich Routing und ist in wenigen Minuten eingerichtet… Die VPN-Konfiguration musst du dann als Split-Tunneling betreiben und der Client bekommt den rPi als Gateway.
Könntest du mir das an einem Beispiel aufzeigen?
Ich steh auf dem Schlauch, ob ich auf dem Pi ein eth0.1 brauche, und weil ich beim route-Befehl nur Zielnetz und Gateway setze, nicht aber die Quelle
Nicht dass wir unterschiedliches meinen:
Die Selektion, was in den OVPN-Tunnel geschickt werden soll und was nicht, muss zwingend auf dem Pi erfolgen da eine Anpassung der Routen auf dem Client "C2" nicht möglich ist (weil Android, kein Root, SmartTV).
Sprich der Client C2 hat als Gateway eine IP des Pi eingetragen und schickt alles, wofür ein Gateway benötigt wird, also alles ausser 192.168.1.x, zu dieser IP des Pi
Der TO ist vermutlich wieder so ein Opfer dieser gruseligen öffentlicher VPN Provider wie NordVPN usw. und will mit C2 sehr wahrscheinlich Geofencing überwinden?!
Die Lösung ist kinderleicht. Es gibt zwei Optionen Varianten
Wenn du zusätzlich noch sicherstellen willst das nur C2 den RasPi benutzt stellst du das mit einer IP Accessliste über iptables oder die moderneren nftables ein. Fertisch...
Die Lösung ist kinderleicht. Es gibt zwei Optionen Varianten
- Das Default Gateway von C2 wird auch den Raspberry Pi VPN Server gesetzt
- Im Internet Router machst du ein Policy Routing was das Default Gateway von C2 auf den RasPi umsetzt.
Wenn du zusätzlich noch sicherstellen willst das nur C2 den RasPi benutzt stellst du das mit einer IP Accessliste über iptables oder die moderneren nftables ein. Fertisch...
Moin,
Du hängst den Raspberry ganz normal in dein 192.168.1.0/24-Netz. Der Raspberry bekommt dort auch (erstmal) als Gateway den DSL-Router 192.168.1.200 eingetragen. Dann legst du auf dem Raspberry deine VPN-Konfiguration an. Dort kannst du entweder redirect-gateway nutzen, dann wird jeder ausgehende Traffic vom RPi durch den Tunnel geschickt oder aber du kannst entsprechend die Routen setzen lassen, was über den Tunnel gehen soll. Das passiert direkt über die OpenVPN-Konfiguration.
Dann aktivierst du auf dem Pi noch das IP-Forwarding (sysctl -w net.ipv4.ip_forward=1) und dann bist du eigentlich schon fertig (wenn du mit dem Server auf der Gegenseite eine korrekte Site2Site-Konfiguration hast)
Wenn nicht, musst du den Traffic ggf. durch den VPN-Tunnel NATten.
Für das lokale Netz wird niemals das Gateway genutzt.
VG
Zitat von @blacksun:
Könntest du mir das an einem Beispiel aufzeigen?
Ich steh auf dem Schlauch, ob ich auf dem Pi ein eth0.1 brauche, und weil ich beim route-Befehl nur Zielnetz und Gateway setze, nicht aber die Quelle
Nein, du brauchst kein eth0.1 - Also:Könntest du mir das an einem Beispiel aufzeigen?
Ich steh auf dem Schlauch, ob ich auf dem Pi ein eth0.1 brauche, und weil ich beim route-Befehl nur Zielnetz und Gateway setze, nicht aber die Quelle
Du hängst den Raspberry ganz normal in dein 192.168.1.0/24-Netz. Der Raspberry bekommt dort auch (erstmal) als Gateway den DSL-Router 192.168.1.200 eingetragen. Dann legst du auf dem Raspberry deine VPN-Konfiguration an. Dort kannst du entweder redirect-gateway nutzen, dann wird jeder ausgehende Traffic vom RPi durch den Tunnel geschickt oder aber du kannst entsprechend die Routen setzen lassen, was über den Tunnel gehen soll. Das passiert direkt über die OpenVPN-Konfiguration.
Dann aktivierst du auf dem Pi noch das IP-Forwarding (sysctl -w net.ipv4.ip_forward=1) und dann bist du eigentlich schon fertig (wenn du mit dem Server auf der Gegenseite eine korrekte Site2Site-Konfiguration hast)
Wenn nicht, musst du den Traffic ggf. durch den VPN-Tunnel NATten.
Nicht dass wir unterschiedliches meinen:
Die Selektion, was in den OVPN-Tunnel geschickt werden soll und was nicht, muss zwingend auf dem Pi erfolgen da eine Anpassung der Routen auf dem Client "C2" nicht möglich ist (weil Android, kein Root, SmartTV).
Sprich der Client C2 hat als Gateway eine IP des Pi eingetragen und schickt alles, wofür ein Gateway benötigt wird, also alles ausser 192.168.1.x, zu dieser IP des Pi
Das ist schon richtig. Alles was den RPi als Gateway hat, geht dann über das VPN raus und alles was deinen DSL-Router als Gateway hat geht direkt raus.Die Selektion, was in den OVPN-Tunnel geschickt werden soll und was nicht, muss zwingend auf dem Pi erfolgen da eine Anpassung der Routen auf dem Client "C2" nicht möglich ist (weil Android, kein Root, SmartTV).
Sprich der Client C2 hat als Gateway eine IP des Pi eingetragen und schickt alles, wofür ein Gateway benötigt wird, also alles ausser 192.168.1.x, zu dieser IP des Pi
Für das lokale Netz wird niemals das Gateway genutzt.
VG
Versteht man den TO oben richtig geht es aber nicht um einen mobilen Client sondern einen aus seinem lokalen LAN der via VPN Server ins Internet geht. Vermutlich Aushebeln von Geofencing?!
Die Lösung ist kinderleicht. Es gibt zwei Optionen Varianten
- Das Default Gateway von C2 wird auch den Raspberry Pi VPN Server gesetzt
- Im Internet Router machst du ein Policy Routing was das Default Gateway von C2 auf den RasPi umsetzt.
Der Internet-Router ist ne FritzBox 7490. Damit scheidet Vorschlag 2 schonmal aus, oder?
Den Vorschlag 1 habe ich nicht verstanden. Die Pi ist doch nur ein OVPN-client. Warum VPN-Server?
Der Pi soll *bestimmten* Traffic in das OVPN routen, nämlich nur das von C2. Kommen Anfragen von anderen Clients oder der Traffic vom Pi selbst, der soll nicht durch das VPN geleitet werden.
Zitat von @BirdyB:
Nein, du brauchst kein eth0.1 - Also:
Du hängst den Raspberry ganz normal in dein 192.168.1.0/24-Netz...Dann legst du auf dem Raspberry deine VPN-Konfiguration an. Dort kannst du entweder redirect-gateway nutzen, dann wird jeder ausgehende Traffic vom RPi durch den Tunnel geschickt oder aber du kannst entsprechend die Routen setzen lassen, was über den Tunnel gehen soll. Das passiert direkt über die OpenVPN-Konfiguration.
Nein, du brauchst kein eth0.1 - Also:
Du hängst den Raspberry ganz normal in dein 192.168.1.0/24-Netz...Dann legst du auf dem Raspberry deine VPN-Konfiguration an. Dort kannst du entweder redirect-gateway nutzen, dann wird jeder ausgehende Traffic vom RPi durch den Tunnel geschickt oder aber du kannst entsprechend die Routen setzen lassen, was über den Tunnel gehen soll. Das passiert direkt über die OpenVPN-Konfiguration.
Richtig, redirect-gateway leitet alles durch den Tunnel. Genau das soll aber nicht sein. Es soll bestimmter Traffic in den Tunnel hinein. Bei den Routen wird aber nicht unterschieden wo die Anfrage her kommt, sondern nur wo sie hin geht. Anders formuliert, in einer Routingtabelle stehen nur Zieladressen, aber keine Quellen.
Das meinte ich mit "Selektor". Es soll geschaut werden wer die Anfrage gestellt hat, ob das der C2 war, oder jemand anderer.
Beispiel:
Auf dem C2 wird eine Anfrage zu google.de gestellt.
Zunächst findet eine Namensauflösung statt. Bei C2 ist als DNS-Server die 192.168.1.200 eingetragen. Diese wird also nicht in den Tunnel geschickt da lokales LAN. Der DNS-Server sagt C2 dass google.de die IP 8.8.9.9 hat
Also schickt C2 seinen Request nach 8.8.9.9 an sein Gateway, also den Pi 192.168.1.100. Dieser erkennt dass C2 den Request schickt und leitet die Anfrage an 8.8.9.9 durch den Tunnel.
Dann wird auf dem C1 eine Anfrage zu google.de gestellt. Die Namenauflösung läuft wie gerade.
Dann schickt C1 seinen Request für 8.8.9.9 an den Pi. Nun sollte der PI erkennen dass die Anfrage von C1 kam und es somit nicht durch den Tunnel schicken.
Ich weiß, man könnte diese Variante vermeiden indem man auf dem C1 nicht den Pi als Gateway einträgt.
Zum Schluss stellt der PI selbst eine Anfrage zu google.de Die Namensauflösung läuft wieder wie gehabt.
Dann sollte der "Selektor" erkennen dass die Anfrage nicht von C2 kommt und somit nicht in den Tunnel soll.
Der Pi sollte sich also quasi nicht selbst als Gateway in den Tunnel nehmen, sondern seine Anfragen zum DSL-Router als Gateway schicken.
Und jetzt ist die Frage wie man so einen Selektor realisiert der nach der Quelle des Requests unterscheidet.
Man könnte die Frage auch so formulieren:
Auf dem Pi sind 3 Requests die an 8.8.9.9 gehen sollen. Ein Request soll durch den Tunnel, die anderen beiden Requests aber nicht.
Nach was könnte der Selektor schauen um Unterscheidungen vorzunehmen? Nach MAC-Adresse, nach IP, nach Hostname?
Warum willst du denn allen Clients den Pi als Gateway geben? Das ist doch schon aus Performance-Sicht sinnlos…
Aber wenn du unbedingt möchtest, ist Policy-Based-Routing dein Freund.
Siehe z.B. hier: https://osric.com/chris/accidental-developer/2019/03/linux-policy-based- ...
VG
Aber wenn du unbedingt möchtest, ist Policy-Based-Routing dein Freund.
Siehe z.B. hier: https://osric.com/chris/accidental-developer/2019/03/linux-policy-based- ...
VG
Damit scheidet Vorschlag 2 schonmal aus, oder?
Ja, falsche Hardware. Kann die Kiste nicht.Die Pi ist doch nur ein OVPN-client. Warum VPN-Server?
Sorry, da hast du natürlich Recht. Server war falsch...Der OVPN Client ist quasi das Gateway ins VPN für C2. Siehe auch hier.
Dir bleibt mit der FritzBox dann nur C2 eine statische IP außerhalb des FB DHCP Pools zu vergeben und als Default Gateway dann den Pi einzutragen. DNS z.B. Quad 9 auf C2.
Warum willst du denn allen Clients den Pi als Gateway geben?
Will er doch gar nicht.Nur C2 damit er das Geofencing überwindet. Vermutlich irgendweien Setop Box etc. Der TO hat leider nicht gelesen was diese VPN Provider mit seinem Account so alles machen sonst würde er das lassen.
Zitat von @aqui:
Nur C2 damit er das Geofencing überwindet. Vermutlich irgendweien Setop Box etc. Der TO hat leider nicht gelesen was diese VPN Provider mit seinem Account so alles machen sonst würde er das lassen.
Dann wird auf dem C1 eine Anfrage zu google.de gestellt. Die Namenauflösung läuft wie gerade.
Dann schickt C1 seinen Request für 8.8.9.9 an den Pi. Nun sollte der PI erkennen dass die Anfrage von C1 kam und es somit nicht durch den Tunnel schicken.
Ich weiß, man könnte diese Variante vermeiden indem man auf dem C1 nicht den Pi als Gateway einträgt.
Warum willst du denn allen Clients den Pi als Gateway geben?
Will er doch gar nicht.Nur C2 damit er das Geofencing überwindet. Vermutlich irgendweien Setop Box etc. Der TO hat leider nicht gelesen was diese VPN Provider mit seinem Account so alles machen sonst würde er das lassen.
Dann schickt C1 seinen Request für 8.8.9.9 an den Pi. Nun sollte der PI erkennen dass die Anfrage von C1 kam und es somit nicht durch den Tunnel schicken.
Ich weiß, man könnte diese Variante vermeiden indem man auf dem C1 nicht den Pi als Gateway einträgt.
@aqui: Hat er doch so geschrieben... Sonst würde die Anfrage von C1 ja garnicht zum Pi gehen...
C1 bekommt ja DHCP mit Gateway und DNS von der FritzBox, geht also komplett über die FritzBox wie es der TO will.
C2 darf kein DHCP von der FritzBox bekommen denn der soll ja übers VPN. Also statische IP und statisches Default Gateway auf den RasPi und DNS von Quad 9 oder wem auch immer wenn es denn unbedingt US DNS Server sein müssen.
Färdsch... Problem des TO gelöst.
C2 darf kein DHCP von der FritzBox bekommen denn der soll ja übers VPN. Also statische IP und statisches Default Gateway auf den RasPi und DNS von Quad 9 oder wem auch immer wenn es denn unbedingt US DNS Server sein müssen.
Färdsch... Problem des TO gelöst.
Zitat von @aqui:
Wenn du zusätzlich noch sicherstellen willst das nur C2 den RasPi benutzt stellst du das mit einer IP Accessliste über iptables oder die moderneren nftables ein.
Wenn du zusätzlich noch sicherstellen willst das nur C2 den RasPi benutzt stellst du das mit einer IP Accessliste über iptables oder die moderneren nftables ein.
Genau da haben wir das Problem, = ich
Ich habe mich bisher überhaupt nicht iptables beschäftigt. Für mich war iptables immer nur ein reiner Filter, der nur filtern und blockieren kann. Dass iptables (oder nftables, das kann ich bisher noch nicht) auch für ein Forward oder NATing genutzt werden kann, das war mir nicht bewusst.
Bisher war ich noch nicht in der Verlegenheit irgendwas filtern zu müssen.
Bisher hat mir sysctl -w net.ipv4.ip_forward=1 auf allen Systemen gereicht. Sprich jedes Device darf alles und überall hin.
Zitat von @aqui:
sondern einen aus seinem lokalen LAN der via VPN Server ins Internet geht. Vermutlich Aushebeln von Geofencing?!
sondern einen aus seinem lokalen LAN der via VPN Server ins Internet geht. Vermutlich Aushebeln von Geofencing?!
Absolut richtig.
wieder absolut richtig.
Dir bleibt mit der FritzBox dann nur C2 eine statische IP außerhalb des FB DHCP Pools zu vergeben und als Default Gateway dann den Pi einzutragen. DNS z.B. Quad 9 auf C2.
Und genau soweit bin ich aktuell.
Aktuell würden die Requests von C2 zum Pi gehen da dieser als Gateway eingetragenn ist, und dann vom Pi zum DSL-Router ins Inet.
Jetzt geht es darum die Requets des C2 zu erkennen und in das VPN zu zwingen.
Dafür hat der PI ein tun-Device und fungiert als VPN-Client.
Nur C2 damit er das Geofencing überwindet. Vermutlich irgendweien Setop Box etc. Der TO hat leider nicht gelesen was diese VPN Provider mit seinem Account so alles machen sonst würde er das lassen.
Genau das ist der Anlass für meinen Post hier.
Wenn ich es mir einfach machen würde, dann würde ich einfach alles in den Tunnel schicken, also der Traffic aller Clients die den PI als Gateway eingetragen haben, inkl. des Traffic des PI selbst.
Da ich das nicht will, soll nur der absolut notwendige Traffic durch das VPN, also die Verbindungen des C2
Zitat von @aqui:
C1 bekommt ja DHCP mit Gateway und DNS von der FritzBox, geht also komplett über die FritzBox wie es der TO will.
C2 darf kein DHCP von der FritzBox bekommen denn der soll ja übers VPN. Also statische IP und statisches Default Gateway auf den RasPi und DNS von Quad 9 oder wem auch immer wenn es denn unbedingt US DNS Server sein müssen.
Färdsch... Problem des TO gelöst.
C1 bekommt ja DHCP mit Gateway und DNS von der FritzBox, geht also komplett über die FritzBox wie es der TO will.
C2 darf kein DHCP von der FritzBox bekommen denn der soll ja übers VPN. Also statische IP und statisches Default Gateway auf den RasPi und DNS von Quad 9 oder wem auch immer wenn es denn unbedingt US DNS Server sein müssen.
Färdsch... Problem des TO gelöst.
leider noch nicht ganz gelöst.
es mangelt wie beschrieben an den Kenntnissen zu iptables/nftables
Wie du ja geschrieben hast, wird iptables durch nftables ersetzt, sprich ich sollte dann gleich mit nftables einsteigen.
Habe das richtig herausgelesen dass ich 2 Regeln setzen muss, einmal eine Filter-Forward-Regel, und dann noch eine NAT-Regel für masquerade?
Ich würde den C2-Client anhand der IP4-Adresse herausfiltern, also über einen ip-Filter. (ipv6 ist bei mir komplett deaktiviert). Wäre ARP besser geeignet?
es mangelt wie beschrieben an den Kenntnissen zu iptables/nftables
Dem kann man ja mit etwas lesen abhelfen.. https://wiki.nftables.org/wiki-nftables/index.php/Main_Page
Wenn es das denn nun war bitte dann auch deinen Thread hier als erledigt schliessen!
