Ziel ist, über einen eigenen OpenVPN-Server, der auf einem dedizierten Root-Server betrieben wird, Zugriff auf das lokale Netzwerk Zuhause (Heimnetz) zu erlangen. Es soll möglich sein, sich von überall mit dem VPN zu verbinden (z.B. über ein Smartphone) und dann auf das Heimnetzwerk zuzugreifen.
Als Gateway zwischen dem VPN und dem Heimnetz verwenden wir einen Raspberry Pi.
Im Folgenden wird davon ausgegangen, dass bereits ein OpenVPN Server eingerichtet ist und sich mehrere Clients mit diesem verbinden können. Die Einrichtung ist in einem anderen Artikel ausführlich beschrieben.
IP-Bereiche und Adressen
- 10.8.0.0/24 VPN
- 10.8.0.50 Raspberry Pi VPN-Gateway
- 192.168.1.0/24 Heimnetz
- 192.168.1.1 Router mit DNS-Server
- 192.168.1.50 Raspberry Pi VPN-Gateway
Das Client-Zertifikat ist bereits als pi-vpn-gw ausgestellt und die Client-Config liegt auf dem Raspberry Pi im Home-Verzeichnis als ~/pi-vpn-gw.ovpn vor.
Einrichtung auf dem Raspberry Pi
Zuerst installieren wir OpenVPN und kopieren die Client-Config, wobei wir die Dateiendung auf .conf ändern.
sudo apt-get install openvpn sudo cp ~/pi-vpn-gw.ovpn /etc/openvpn/pi-vpn-gw.conf
Anschließend aktivieren wir das IP-Forwarding und die NAT-Regeln.
sudo sysctl -w net/ipv4/ip_forward=1 sudo iptables -t nat -F POSTROUTING sudo iptables -t nat -A POSTROUTING -o eth0 -s 10.8.0.0/24 -j MASQUERADE
Damit dies in Zukunft automatisch bei einem Neustart des Raspberry Pi erledigt wird, fügen wir die folgenden Zeilen in der Datei /etc/rc.local vor der Zeile exit 0 hinzu:
# IP-Forward aktivieren echo 1 > /proc/sys/net/ipv4/ip_forward # Weiterleitung in das lokale Netz iptables -t nat -F POSTROUTING iptables -t nat -A POSTROUTING -o eth0 -s 10.8.0.0/24 -j MASQUERADE
Abschießend erstellen wir noch den Symlink für den SystemD-Service und starten diesen.
sudo ln -s /lib/systemd/system/openvpn@.service /etc/systemd/system/openvpn@pi-vpn-gw.service sudo systemctl start openvpn@pi-vpn-gw.service
Damit läuft der OpenVPN-Client nun permanent im Hintergrund und stellt die VPN-Verbindung wieder her falls diese abbrechen sollte.
Anpassung auf dem OpenVPN Server
Bei dem OpenVPN-Server fügen wir der Server-Config die folgenden Einträge hinzu, sofern noch nicht vorhanden:
# Verzeichnis für die Client-Configs client-config-dir ccd # Route zum Heimnetz auf dem Host-System des OpenVPN-Servers anlegen (optional) ;route 192.168.1.0 255.255.255.0 # Route zum Heimnetz allen Clients mitteilen push "route 192.168.1.0 255.255.255.0" # DNS-Server den Clients mitteilen push "dhcp-option DNS 192.168.1.1" push "dhcp-option DNS 1.1.1.1" push "dhcp-option DNS 1.0.0.1"
Die Route zum Heimnetz in Zeile 5 ist optional und sollte nur aktiviert werden, wenn man von dem Host-System des OpenVPN-Servers direkten Zugriff auf das Heimnetz benötigt, oder in der Config des OpenVPN-Servers die Anweisung client-to-client nicht enthalten ist.
Als 1. DNS-Server wird die IP des Routers im Heimnetz verwendet, wodurch es möglich wird über das VPN auch die Hostnamen der Geräte im Heimnetz zu verwenden. Als 2. und 3. DNS-Server nehmen wir die Cloudflare-DNS-Server, für den Fall dass der 1. DNS-Server mal nicht erreichbar ist.
Weiterhin legen wir eine clientspezifische Config für unseren Client unter /etc/openvpn/ccd/pi-vpn-gw auf dem Server an beziehungsweise ergänzen diese:
# Feste IP für den Client (Client-IP Subnet) ifconfig-push 10.8.0.50 255.255.255.0 # Internes Routing zum Heimnetz über diesen Client iroute 192.168.1.0 255.255.255.0
Abschließend noch ein Neustart des OpenVPN-Servers.
sudo systemctl restart openvpn
Fertig!
Nachdem sich unser Raspberry Pi VPN Gateway nun mit dem OpenVPN-Server verbunden hat, sollte es von jedem VPN-Client aus möglich sein jedes Gerät im Heimnetz zu erreichen.
Zum Testen kann man beispielsweise versuchen von einem Smartphone (mit ausgeschaltetem WLAN und aktivierten VPN) den Raspberry Pi (192.168.1.50) oder den Router im eigenen Heimnetz (192.168.1.1) zu erreichen.
15. Nov. 2017 um 17:38
Super! Genau danach hab ich gesucht … funktioniert einwandfrei!
18. Nov. 2017 um 16:56
Schöner Artikel, auch ich habe genau das gesucht. Ich bekomme es trotzdem nicht hin. Lokaler Client und vServer im Internet sehen sich (Ping 10.8.0.1 bzw. 10.8.0.122 geht durch), aber das Routing zu den internen Adressen 192.168.12.x funktioniert weder von einem anderen VPNClient (Smartphone) noch vom vServer.
18. Nov. 2017 um 17:21
Hast du die IP-Adressen vom Beispiel oben an dein Netzwerk angepasst, also überall 192.168.12.x anstatt 192.168.1.x verwendet?
Manche neueren Systeme bezeichnen die Ethernet Schnittstelle nicht als eth0 sondern als ensXY. In dem Fall muss dies natürlich auch entsprechend angepasst werden.
Wenn du die Möglichkeit hast, einen Linux-Client zu verwenden, dann wäre die Ausgabe von
route -ninteressant. Hier sollte das Ziel 192.168.12.0 über das Interface tun0 geroutet werden.Für das Routing vom Server zum Client muss in der Serverconfig der Eintrag
route 192.168.12.0 255.255.255.0(ohne ; am Anfang) enthalten sein. Dann sollte nach einem Neustart des OpenVPN-Servers beiroute -nwieder die Route zu 192.168.12.0 über tun0 zu sehen sein.18. Nov. 2017 um 19:37
Hallo Peter, der Hinweis mit der Routingtabelle war richtig, vielen Dank. Der Eintrag ist in der server.conf vorhanden, wird aber nicht automatisch angewendet. Trage ich ihn von Hand ein, funktioniert es (route add -net 192.168.12.0 netmask 255.255.255.0 dev tun0). Auch der Eintrag in rc.local bringt den Server nicht dazu den Eintrag zu erzeugen (wahrscheinlich weil tun0 zum Zeitpunkt der Anwendung noch nicht zur Verfügung steht?).
19. Nov. 2017 um 18:26
Seltsam… habe es eben nochmals getestet und beim Start des OpenVPN Servers (v2.3.10) wird die Route richtig erstellt.
Über die rc.local ist klar, dass es nicht funktioniert, da das Device tun0 beim Start noch nicht vorhanden ist.
Du kannst noch versuchen den folgenden Eintrag in der Datei
/etc/network/interfaceshinzuzufügen:19. Nov. 2017 um 19:11
Es ist mir ja schon peinlich, aber das wirkt auch nicht. tun0 ist gestartet, trotzdem wird die Route nicht eingetragen (von Hand nach wie vor schon). Aber mach Dir keine Mühe, Du hast mir auch so schon extrem geholfen, vielen Dank dafür!!!!!
Heute habe ich den ganzen Tag mit iptables gekämpft um die eingehenden Ports auf meinen Webserver durch den Tunnel umzuleiten. Jetzt funktioniert es, dank Deiner Hilfe.
Viele Grüße
Marc
21. Jan. 2018 um 15:04
Hi, habe dasselbe Problem… Wie hast du es mit den iptables gemacht?
9. Feb. 2019 um 21:21
Hallo
wenn ich alles richtig verstanden habe geht es um diese Konstellation?
Lokales Netz (192.168.0.0)
|
VPN-Client (openVPN lokal)
|
Router
|
DSL Provider (Provider innogy ohne öffentliche ipv4 und ohne ipv6)
|
Internet
|
VPN Server (openVPN)
|
Internet
|
VPN-Client (openVPN remote)
Es ist doch so gedacht, dass der remote VPN-Client auf das lokale Netz zugreifen können sollte, oder habe ich da einen Denkfehler?
Prinzipiell funktionieren bei mir die VPN Verbindungen, nur auf das lokale Netz kann ich weder vom remote VPN Client noch von VPN Server zugreifen.
Der VPN Server zeigt folgenden Status:
OpenVPN CLIENT LIST
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
homelan,öffentl-IP:48019,10210,6699,Sat Feb 9 20:06:26 2019
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.8.0.50,homelan,öffentl-IP:52763,Sat Feb 9 20:06:29 2019
192.168.1.0/24,homelan,öffentl-IP:52763,Sat Feb 9 20:05:35 2019
route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 IP-VPN_SERVER 0.0.0.0 UG 0 0 0 eth0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
IP-VPN_SERVER 0.0.0.0 255.255.252.0 U 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
Sieht für mich eigentlich korrekt aus, aber ich bin nicht der Routing Experte. Hat da jemand noch einen Tip?
12. Nov. 2019 um 15:09
Hi, ich habe nach dieser Anleitung erfolgreich Verbindungen eingerichtet.
Ich bin jetzt eher auf ein nachgelagertes Problem gestoßen.
Ich habe einen Server.
Ein Vpn Gateway Haus 1, ein Vpn Gateway Haus 2.
Für jedes Haus mehrere weitere Clients für die Mobilen Geräte.
Haus 1 hat 192.168.1.0/24 und Haus 2 hat 192.168.2.0/24 als ip Adressen.
Wie ist es jetzt zu lösen wenn Haus 3 dazu kommt und das auch 192.168.1.0/24 als ip Adressen hat.
Ich nehme an das in den routen für die Mobilen Clients dann irgendwo der Hinweis hin muss über welches Vpn Gateway in das Haus Netzwerk geroutet werden muss.
Der einfache weg Haus 3 einfach einen anderen Adresse Bereich zu geben geht nicht da der Router nicht von mir verwaltet wird.
12. Nov. 2019 um 15:58
Hallo Tim,
meines Wissens nach wird das ohne einen eigenen IP-Bereich für Haus 3 leider gar nicht gehen.
Das eigentliche Routing macht der Server. Die Clients bekommen nur mitgeteilt, welche Netzbereiche über den Server erreichbar sind und senden dann alle Pakete an den Server. Dieser routet dann die Pakete entsprechend weiter zum Ziel. Zwei Ziele mit gleichem IP-Bereich sind nicht möglich, da der Server dann natürlich nicht mehr unterscheiden kann wer wer ist.
Was man eventuell probieren könnte, sofern du darauf Einfluss hast, wäre den Netzbereich 192.168.1.0/24 beim Routing im VPN nochmals zu unterteilen, sodass dann beispielsweise zu Haus 1 der Bereich 192.168.1.0/25 (192.168.1.1 bis 192.168.1.126) und zu Haus 3 der Bereich 192.168.1.128/25 (192.168.1.129 bis 192.168.1.254) geroutet wird.
Dafür müssten dann aber die Geräte, die im jeweiligen Haus erreichbar sein sollen, eine IP in dem Bereich haben. Ein Routing zwischen den Client-Netzen von Haus 1 und 3 wäre damit dann aber nicht mehr möglich.
8. Jan. 2020 um 16:49
Hallo Herr Müller,
kann man anstelle des raspberry, einen permanent laufenden Windows Rechner nutzen?
Wenn ja, welche Schritte würden ich ändern.
Vielen Dank im Voraus
Wladi
8. Jan. 2020 um 18:13
Hallo,
das sollte denke ich auch möglich sein. Mit dem Routing und den dazu nötigen Einstellungen unter Windows kenne ich mich aber absolut nicht aus. Generell sind hier das IP Forwarding und das Maskieren der IP beim Forwarding nötig.
Die Configs für OpenVPN selbst sollten unter Windows die gleichen sein.
8. Jan. 2020 um 19:28
Ok ich werde es mal ausprobieren
Danke
20. Jan. 2020 um 16:53
Ich bin gerade am überlegen mir auch OpenVPN und einen Gateway einzurichten, um auf mein Heimnetzwerk zuzugreifen. Momentan habe ich eine VPN Verbindung zwischen zwei Fritzbox-Netzwerken über die Fritzbox interne VPN Funktion hergestellt (Büronetzwerk Heimnetzwerk). Leider ist liegt die Datanübertragungsrate bei weit unter 10 Mbit/s. Meine vom Internetprovider bereitgestellte Übertragungsrate beträgt jedoch 40 Mbit/s. Es ist also offenbar die VPN durch die Fritzbox der Flaschenhals. Nun wollte ich fragen, ob mir jemand sagen kann, wie die Datenübertragungsrate bei dem hier vorgestelltem System mit dem Raspi ist?
20. Jan. 2020 um 18:40
Habe es eben mal live bei mir getestet und bin auf rund 30 Mbit/s gekommen.
Wenn deine Fritzboxen beide an deinem normalen privaten Internetanschluss hängen, dann kann das auch das Problem sein. Bei den meisten Anschlüssen hast du nämlich eine deutlich geringere Upload- als Download-Rate.
20. Jan. 2020 um 18:57
Vielen Dank für die schnelle Antwort! Das hört sich schon mal vielversprechend an. Mein Anschluss hat eine 100 Mbit/s DL und 40 Mbit/s UL Rate. Ich sollte also auch bei min. 30 Mbit/s sein, wenn ich dein Setup nutze. Das Problem ist laut einigen Foren, die CPU Leistung der FritzBox bei der VPN Verschlüsselung der zu sendenden Daten.
Ich werde es demnächst mit deinem Setup und einem Raspberry Pi 4 oder evtl mit einem stärkeren Linux Rechner versuchen. Meine Resultate poste ich dann hier.
31. Jan. 2020 um 14:36
Ich finde die Anleitung sehr gut. Kurz zu meinem Setup:
Ich habe ein Raspi (3B), welches ich als OpenVPN Gateway nutzen möchte. Zudem ist das Raspi mit anderen Raspis-Zeros mittels Wlan über einen Router verbunden.
Auf Grundlage der Anleitung bekomme ich eine OpenVPN Verbindung mit dem OpenVPN Access Server hin, kann auch darauf zugreifen über einen anderen Client (bspw. Laptop von zu Hause).
Das Problem:
Sobald sich das Raspi mit dem OpenVPN Server verbindet, kann ich mich lokal nicht mehr aufdie Raspi-Zeroes (LAN-Netzwerk) zugreifen. Ich habe deine Anleitung mit den iptables befolgt, jedoch statt eth0 wlan0 eingesetzt und die IP meines OpenVPN Servers angepasst.
Ich denke jedoch, dass es nicht daran liegt, sondern irgendwie an den Einstellungen am Raspi oder evtl. am Router.
Vielen Dank für Deine Hilfe
31. Jan. 2020 um 17:51
Das klingt nach einer Überschneidung der IP-Bereiche. Dein lokales Netz muss einen anderes Subnet haben, als dein VPN-Netz. Also z.B. lokal 192.168.1.x und im VPN 192.168.2.x, jeweils mit einer Netmask von 255.255.255.0.
5. Jun. 2020 um 22:29
Hallo,
Sagen wir, ich habe zwei Clients (Haus und Büro).
Haus
Heimnetzwerk: 192.168.1.123
OpenVPN: 172.23.10.12
Büro
Heimnetzwerk: 192.168.1.123
OpenVPN: 172.23.10.13
Wenn sie nun gleichzeitig mit dem OpenVPN-Server verbunden sind und ich versuche mit meinem Laptop(172.23.10.20) aus dem Ausland auf Heimnetzwerk zuzugreifen, würde dies zu einem “Netzwerkausfall” führen, da der Server nicht entscheiden kann, zu welcher IP die Pakete geroutet werden müssen, habe ich Recht? Welche Art von Massnahmen kann ich dagegen ergreifen?
BG
6. Jun. 2020 um 12:51
Zu einem Ausfall würde es denke ich nicht kommen, da im Zweifelsfall die zweite Route beim Server einfach nicht angelegt werden kann, da schon eine mit dem selben Ziel existiert. Sollte sie doch angelegt werden, dann mit einer andern MTU, wobei dann die Route mit der niedrigsten MTU “gewinnt”.
Die einfachste Lösung wäre Haus und Büro in unterschiedliche Subnetze zu packen. Beispielsweise Haus 192.168.1.x und Büro 192.168.2.x.
Damit wäre dann ein eindeutiges Routing möglich.
6. Jun. 2020 um 16:49
Vielen Dank Herr Müller, das hat mir sicherlich geholfen.
17. Jul. 2020 um 7:43
GENAU das habe ich gesucht wie verrückt!
Vielen Dank für die Anleitung! So kann ich auch Meine Cams im LAN erreichen die kein VPN unterstützen 😉
3. Dez. 2020 um 18:09
Hallo,
vielleicht können Sie mir bei meinem openVPN Problem weiter helfen. So wie ich diesen Thread hier verstanden hab, ist es bei meiner Konstellation genau anders herum. Ich habe einen openVPN Server, auf den ich mit mehreren Clients drauf zugreifen möchte, ohne das jeder Client ein eigenen openVPN Client installieren muss. Dazu habe ich einen RaspberryPI im Netzwerk platziert und dort openVPN installiert. Ich bin soweit gekommen, dass der PI sich mit dem openVPN Server verbindet und auch ein Ping lokal vom Pi in das Zielnetzwerk funktioniert. Damit die Clients nun den Pi als Gateway benutzen, habe ich in meinem Router eine statische Route gesetzt, wo ich gesagt habe, dass das Zielnetzwerk via PI (als Gateway) zu erreichen ist. Leider funktioniert es nicht. Haben Sie vielleicht einen Tip?
4. Dez. 2020 um 17:55
Hi, das habe ich bei mir auch so laufen. Der Pi macht das Gateway zwischen lokalem Netz und VPN in beide Richtungen.
Damit das funktioniert ist zusätzlich zum oben im Beitrag beschriebenen Setup und der statischen Route über den Pi noch eine iptables-Regel zum Maskieren des Traffics vom lokalen Netz ins VPN notwendig:
`iptables -t nat -A POSTROUTING -o tun0 -s 192.168.1.0/24 -j MASQUERADE`
Natürlich mit dem entsprechenden Netzbereich des lokalen Netzes. 😉
5. Dez. 2020 um 23:45
Vielen Dank für Ihren Tip. Da ich schon einen laufenden Server habe und auch die Client-Verbindung lokal auf dem Raspberry Pi (Gateway) funktionierte, habe ich die folgenden Kommandos nur auf diesem abgesetzt:
sudo sysctl -w net/ipv4/ip_forward=1
sudo iptables -t nat -F POSTROUTING
sudo iptables -t nat -A POSTROUTING -o eth0 -s 10.8.0.4/24 -j MASQUERADE
sudo iptables -t nat -A POSTROUTING -o tun1 -s 192.168.11.0/24 -j MASQUERADE
Jetzt funktioniert der Ping aus dem 11er Netz auch über das VPN an Clients im anderen Netz. Ein weiterer Test mit einer FTP-Verbindung schlug jedoch fehl. Fehlt noch etwas? Muss ich noch Änderungen am VPN-Server vornehmen?
7. Dez. 2020 um 11:11
Wenn ein Ping funktioniert und sonst keine Firewall dabei irgendwas blockt, dann sollte es das an Setup gewesen sein.
Beim FTP wird hier nur passives FTP funktionieren.
Beim aktiven FTP ist eine direkte Verbindung (ohne NAT) zwischen Server und Client notwendig, da hier der Client einen Port öffnet, an den der Server dann die Daten überträgt. Hinter einem NAT, was in diesem Fall der Raspi macht, ist das nicht möglich, da der Server hier nur den Raspi sieht, aber nicht den Rechner dahinter.
Beim passiven FTP öffnet der Server einen zusätzlichen Port für die Datenübertragung, wodurch das auch mit NAT funktioniert.
15. Jan. 2021 um 8:19
Hi !
Ich musste am server in der config explizit die route vom heimnetz angeben (inkl. gateway)
route heimnetz netzmaske gateway (clientip)
dann lief es erst…
3. Apr. 2021 um 18:48
Vielen herzlichen Dank für die hervorragende Anleitung. Zum einen genau das was ich gesucht habe und zum anderen perfekt beschrieben!
Gemäß der Anleitung kann ich nur als aktiver vpn-Client auf das LAN hinter dem VPN-Gatewayclient zugreifen.
Kann ich als LAN-Client im LAN des VPN-Servers auch auf das LAN hinter dem VPN-Gatewayclient zugreifen, ohne dass ich mich zuvor als VPN-Client beim VPN-Server anmelden muss? Ich habe es schon mit statischen IPv4 Routen in meinem Router probiert, jedoch ohne Erfolg.
3. Apr. 2021 um 20:05
Ja das geht auch, erfordert aber etwas mehr Konfiguration:
Natürlich müssen alle Netzbereiche unterschiedliche IP-Bereiche haben. Ansonsten funktioniert das nicht.
Angenommen das lokale Netz hinter deinem Gateway-Client ist 192.168.1.0/24, das lokale Netz des Servers ist 172.20.1.0/24 und der Server hat die IP 172.20.1.10. Die Ethernetschnittstelle am Server heißt eth0 und die VPN-Schnittstelle tun0.
Auf dem Server muss das IP-Forwarding aktiviert sein.
In der Config des VPN-Servers musst du die Route zum Heimnetz wie oben beschrieben anlegen lassen mittels `route 192.168.1.0 255.255.255.0` in der Server-Config.
Zudem musst du am Server alle Pakete, die vom lokalen Netz des Servers kommen und in das Netz des Gateway-Clients sollen maskieren.
Die iptables Regel dazu sieht dann wie folgt aus:
`sudo iptables -t nat -A POSTROUTING -i eth0 -o tun0 -s 172.20.1.0/24 -d 192.168.1.0/24 -j MASQUERADE`
Zuletzt brauchen deine Clients im lokalen Netz des Servers noch eine statische Route zum Netzbereich hinter dem Gateway-Client über den VPN-Server:
`sudo ip route add 192.168.1.0/24 via 172.20.1.10`
Damit solltest du dann von einem Rechner im Netz des Servers die Rechner im Netz des Gateway-Clients erreichen können. 🙂
Bei einem Traceroute sollten die einzelnen Zwischenpunkte (VPN-Server und Gateway-Client) als Hop zu sehen sein.
Wenn deine Rechner im Netz des Servers ihre IP-Adressen per DHCP bekommen, dann kannst du im DHCP-Server auch die statischen Route hinterlegen (Code 121, classless-static-route).
3. Apr. 2021 um 20:50
Vielen Dank für die prompte Antwort.
Ich ziehe den Hut vor diesem Fachwissen!
Schöne Ostern.
3. Apr. 2021 um 21:31
Noch eine Rückmeldung:
– der Befehl iptables mit POSTFORWARDING passt anscheinend mit dem Interface-Argument -i eth0 nicht zusammen. Ich habe -i eth0 weggelassen und es so in rc.local auf dem Server eingetragen.
– die statische Route habe ich in meinem DSL-Router hinterlegt
=> PERFEKT!
Nochmals vielen herzlichen Dank!
4. Apr. 2021 um 10:37
Danke für die Rückmeldung. 🙂
Eine Sache ist mir noch eingefallen:
Wenn in beiden lokalen Netzen jeweils die Route zum anderen Netzbereich gesetzt ist, dann kannst du sogar komplett auf das Maskieren, also die `MASQUERADE` Regeln, am Server und am Gateway-Client verzichten, da dann in beide Richtungen ein eindeutiges Routing existiert.
Dies hat den Vorteil, dass du kein NAT mehr hast und somit überall in Serverlogs etc. die echten IP-Adressen der Clients siehst.
22. Jul. 2021 um 20:54
Hallo Peter
ich werde nicht schlau draus, hab es exakt so wie in der Anleitung ein gerichtet kann aber von einem Client aus nur den Server anpingen und nicht den Gateway. selbes Bild vom Gateway aus Server geht zu Dingen Client nicht. Ich weis einfach nicht mehr weiter.
Gruß Mike
8. Okt. 2022 um 19:34
lange musste ich im Internet suchen um eine Anleitung zu finden, wie ich auf meine Netzwerkgeräte hinter dem Pi zugreifen kann. Dies funktionierte nämlich mit diversen anderen Anleitungen überhaupt nicht. Dank dieser Anleitung hier habe ich es aber endlich hinbekommen. Musste es nur auf meine Netztwerk-Settings anpasssen und dann funktionierte es tatsächlich.
Vielen Dank dafür!! Hat mir sehr geholfen.
21. Feb. 2023 um 12:49
Nach genau so einer Anleitung habe ich gesucht! Allerdings habe ich das noch etwas abgeändert, ich pushe die Route an die jeweiligen User die berechtigt sein sollen auf ein bestimmtes Netz zu zugreifen über die ccd config und nicht generell über die server.conf. Bei mir hängen ganz viel Steuer Raspis an einem OpenVPN Server und es gibt ein paar mehr Nutzer die hier Zugrif auf diese Raspis haben müssen aber nicht jeder braucht Zugriff auf alle Netze hinter den Raspis. Vielen Dank für diesen “erleuchtenden” Artikel :-)!
18. Mrz. 2023 um 22:50
Hallo zusammen,
die Anleitung funtioniert einwandfrei danke in die runde
Hier nun meine Frage
Wie kann ich die netzwerke hinter den Clienten erreichen wenn ich eine andere subnetmask habe wie in meinen bsp. meine ip range ist 10.76.48.1-10.76.57.254 255.255.0.0 in den adressbereich 10.76.48.1-10.76.48.254 kann ich schon zugreifen aber nicht in den anderen was kann ich noch einstellen?
21. Mrz. 2023 um 9:17
Hallo Mike,
Im Falle eines größeren Netzbereiches musst du natürlich auch in den Configs die passende Netzmaske bzw. den passenden CIDR Prefix nutzen.
Alles mit “192.168.1.0 255.255.255.0” bzw. “192.168.1.0/24” in dem Beispiel oben musst du entsprechend ersetzen.
Bei deinem angegebenen Beispiel passt die Netzmaske nicht zum IP-Bereich.
Bei 255.255.0.0 (was /16 entspricht) wäre dein nutzbarer IP-Bereich 10.76.0.1 bis 10.76.255.254.
Am ehesten zu deinem Bereich passt 10.76.48.1/20 (Netzmaske 255.255.240.0), was einem nutzbaren IP-Bereich von 10.76.48.1 bis 10.76.63.254 entspricht.