23
OpenVPN Client Netz mit gefiltertem Zugriff
Hallo zusammen,
meine Vorhaben:
1. Verbindung von zwei LANs mittels OpenVPN mit zwei RaspberryPi. Der Server steht im Heimnetz. Die Geräte in den beiden Netzen sollen untereinander kommunizieren können.
2. Einschränkung der Kommunikation: Im Netz des Raspberry-Clients steht eine NAS auf die ich zugreifen will und auch nur diese soll die VPN Verbindung nutzen können.
Da das Client-Netz weiter entfernt ist, sollte bereits alles bei der Einrichtung funktionieren. Daher ist es bisher nur Theorie, zu der ich Feedback brauche.
Zu 1.
Ich habe bereits eine funktionierenden OpenVPN-Server. Die Clients (iPhone) können auf die Geräte im Heimnetz zugreifen. Nun geht es um die Erweiterung, dass ich ich zwei LANs über OpenVPN mit einem Raspi verbinde
Es geht mir nun um die Modifikationen. Dabei habe ich mich an die Anleitung hier gehalten OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Mein theoretische Konfiguration hierfür sieht wie folgt aus:
Heimnetz: 192.168.178.0
..Router
Statische Routen:
10.8.0.0 (VPN-Netz) über Subnetz 255.255.255.0 und Gateway 192.168.178.11 (VPN-Server) # bereits eingerichtet
192.168.180.0 (Client-Netz) über Subnetz 255.255.255.0 und Gateway 192.168.178.11 (VPN-Server)
..RaspberryPi (VPN-Server)
Server Konfigurationsdatei
push „route 192.168.178.0 255.255.255.0“ # bereits eingerichtet
route 192.168.180.0 255.255.255.0
CCD Datei für Client-Netz
iroute 192.168.180.0 255.255.255.0
IP-Forwarding aktivieren # bereits eingerichtet
sudo nano /etc/sysctl.conf
net.ipv4.ip_forward=1
Client-Netz: 192.168.180.0
..Router
Statische Routen:
10.8.0.0 (VPN-Netz) über Subnetz 255.255.255.0 und Gateway 192.168.180.11 (VPN-Client)
192.168.178.0 (Client-Netz) über Subnetz 255.255.255.0 und Gateway 192.168.180.11 (VPN-Client)
..RaspberryPi (VPN-Client)
Client Konfigurationsdatei
route 192.168.178.0 255.255.255.0
IP-Forwarding aktivieren
sudo nano /etc/sysctl.conf
net.ipv4.ip_forward=1
Meine Fragen:
Was bewirkt "route 192.168.180.0 255.255.255.0" in der Server conf und warum muss es nicht ein "push" davor?
Wird das so funktionieren oder ist noch was einzurichten oder zu ändern?
Würden in der Konfiguration die Geräte im Client-LAN über den Router ins Internet gehen oder über den VPN Server? In der Basiskonfiguration des Servers ist push "redirect-gateway def1 bypass-dhcp" eingetragen. Ich möchte, dass die Geräte im Client-LAN über ihren Router den Weg ins Internet finden.
Zu 2.
Da ich nicht für die Sicherheit im Client-LAN "garantieren" kann, möchte ich, dass ich aus dem Heimnetz (192.168.178.0) nur die NAS mit IP 192.168.180.10 erreichen kann und umgekehrt. Alle anderen Geräte sollen hier blockiert sein. Welche zusätzlichen Einstellungen muss ich dafür vornehmen oder ändern?
Vielen Dank!
meine Vorhaben:
1. Verbindung von zwei LANs mittels OpenVPN mit zwei RaspberryPi. Der Server steht im Heimnetz. Die Geräte in den beiden Netzen sollen untereinander kommunizieren können.
2. Einschränkung der Kommunikation: Im Netz des Raspberry-Clients steht eine NAS auf die ich zugreifen will und auch nur diese soll die VPN Verbindung nutzen können.
Da das Client-Netz weiter entfernt ist, sollte bereits alles bei der Einrichtung funktionieren. Daher ist es bisher nur Theorie, zu der ich Feedback brauche.
Zu 1.
Ich habe bereits eine funktionierenden OpenVPN-Server. Die Clients (iPhone) können auf die Geräte im Heimnetz zugreifen. Nun geht es um die Erweiterung, dass ich ich zwei LANs über OpenVPN mit einem Raspi verbinde
Es geht mir nun um die Modifikationen. Dabei habe ich mich an die Anleitung hier gehalten OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Mein theoretische Konfiguration hierfür sieht wie folgt aus:
Heimnetz: 192.168.178.0
..Router
Statische Routen:
10.8.0.0 (VPN-Netz) über Subnetz 255.255.255.0 und Gateway 192.168.178.11 (VPN-Server) # bereits eingerichtet
192.168.180.0 (Client-Netz) über Subnetz 255.255.255.0 und Gateway 192.168.178.11 (VPN-Server)
..RaspberryPi (VPN-Server)
Server Konfigurationsdatei
push „route 192.168.178.0 255.255.255.0“ # bereits eingerichtet
route 192.168.180.0 255.255.255.0
CCD Datei für Client-Netz
iroute 192.168.180.0 255.255.255.0
IP-Forwarding aktivieren # bereits eingerichtet
sudo nano /etc/sysctl.conf
net.ipv4.ip_forward=1
Client-Netz: 192.168.180.0
..Router
Statische Routen:
10.8.0.0 (VPN-Netz) über Subnetz 255.255.255.0 und Gateway 192.168.180.11 (VPN-Client)
192.168.178.0 (Client-Netz) über Subnetz 255.255.255.0 und Gateway 192.168.180.11 (VPN-Client)
..RaspberryPi (VPN-Client)
Client Konfigurationsdatei
route 192.168.178.0 255.255.255.0
IP-Forwarding aktivieren
sudo nano /etc/sysctl.conf
net.ipv4.ip_forward=1
Meine Fragen:
Was bewirkt "route 192.168.180.0 255.255.255.0" in der Server conf und warum muss es nicht ein "push" davor?
Wird das so funktionieren oder ist noch was einzurichten oder zu ändern?
Würden in der Konfiguration die Geräte im Client-LAN über den Router ins Internet gehen oder über den VPN Server? In der Basiskonfiguration des Servers ist push "redirect-gateway def1 bypass-dhcp" eingetragen. Ich möchte, dass die Geräte im Client-LAN über ihren Router den Weg ins Internet finden.
Zu 2.
Da ich nicht für die Sicherheit im Client-LAN "garantieren" kann, möchte ich, dass ich aus dem Heimnetz (192.168.178.0) nur die NAS mit IP 192.168.180.10 erreichen kann und umgekehrt. Alle anderen Geräte sollen hier blockiert sein. Welche zusätzlichen Einstellungen muss ich dafür vornehmen oder ändern?
Vielen Dank!
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: 563766
Url: https://administrator.de/contentid/563766
Ausgedruckt am: 19.12.2024 um 12:12 Uhr
23 Kommentare
Neuester Kommentar
Ich erinnere mich, dass diese Frage vor kurzem bereits gestellt wurde. Such mal ein bisschen im Forum herum.
1.) Ist kein Problem. Siehe HIER oder etwas spezifischer auf dein Szenario bezogen hier:
OpenVPN - Erreiche Netzwerk hinter Client nicht
Zu deinen Fragen:
Ein ip route show oder netstat -r -n an den RasPis zeigt dir das immer bei aktivem VPN Client ! (Winblows: route print)
Normal haben ja alle Clients in dem netz den Internet Rozter als Gateway, folglich nutzen sie logischerweise auch diesen als Internet Zugang. Möglich ist das aber auch das über den VPN Tunnel umzubiegen wenn man will. Geht also beides. Normal ist aber immer der lokale Router.
Leuchtet dir sicher auch selber ein wenn du mal etwas über das Design nachdenkst, denn damit wird das Default Gateway auf den Server redirectet. Der OVPN Client routet dann sämtlichen Traffic in den Tunnel was diesen dann in der Performance massiv belastet.
Wenn das nicht zwingend gewollt ist sollte man IMMER Split Tunneling machen, sproch also mit "Push" nur diese IP Netze an die Clients routen die man remote erreichen will.
Damit routet man im VPN dann nur lokalen LAN Traffic der Netze die man verbinden will, der gesamte Internet Traffic wird aber überall lokal abgefackelt. Das ist der Default, siehe obiges Tutorial !
Tip:
Statt Raspberry Pi kannst du als Alternative einen Mikrotik hAP Router verwenden:
https://www.varia-store.com/de/produkt/33635-mikrotik-routerboard-rb941- ...
Ist preiswerter, kann OpenVPN und hat eine komplett grafische Firewall an Board wo das per Mausklick einfach aufzusetzen ist. Siehe HIER.
Da die LAN Ports nur 100Mbit können bist du aber auf diese Bandbreite festgenagelt. Alternativ bei Gig musst du dann einen hEX nehmen der aber dann teurer ist:
https://www.varia-store.com/de/produkt/36790-mikrotik-routerboard-hex-mi ...
OpenVPN - Erreiche Netzwerk hinter Client nicht
dass ich ich zwei LANs über OpenVPN mit einem Raspi verbinde
Wie gesagt, kein Thema, siehe oben !Zu deinen Fragen:
Was bewirkt "route 192.168.180.0 255.255.255.0" in der Server conf
Bewirkt das diese Route in die Kernel Routing Table eingetragen wird, also in die Routing Table des Betriebssystems was das Routing nach extern (LAN Port) macht.und warum muss es nicht ein "push" davor?
Push schiebt wie der Name selber schon sagt diese Route über den VPN Tunnel in die OVPN Routing Tabelle der remoten Clients. Damit macht OpenVPN automatisch beim Tunnelaufbau diese Routen an den Clients bekannt.Ein ip route show oder netstat -r -n an den RasPis zeigt dir das immer bei aktivem VPN Client ! (Winblows: route print)
Würden in der Konfiguration die Geräte im Client-LAN über den Router ins Internet gehen oder über den VPN Server?
Normal immer über den Router (VPN Split Tunneling). Letztlich ist das aber davon abhängig WIE du das Routing dort konfigurierst.Normal haben ja alle Clients in dem netz den Internet Rozter als Gateway, folglich nutzen sie logischerweise auch diesen als Internet Zugang. Möglich ist das aber auch das über den VPN Tunnel umzubiegen wenn man will. Geht also beides. Normal ist aber immer der lokale Router.
In der Basiskonfiguration des Servers ist push "redirect-gateway def1 bypass-dhcp" eingetragen.
Das ist ein Fehler und sollte man nur dann machen wenn man es wirklich braucht !Leuchtet dir sicher auch selber ein wenn du mal etwas über das Design nachdenkst, denn damit wird das Default Gateway auf den Server redirectet. Der OVPN Client routet dann sämtlichen Traffic in den Tunnel was diesen dann in der Performance massiv belastet.
Wenn das nicht zwingend gewollt ist sollte man IMMER Split Tunneling machen, sproch also mit "Push" nur diese IP Netze an die Clients routen die man remote erreichen will.
Damit routet man im VPN dann nur lokalen LAN Traffic der Netze die man verbinden will, der gesamte Internet Traffic wird aber überall lokal abgefackelt. Das ist der Default, siehe obiges Tutorial !
Ich möchte, dass die Geräte im Client-LAN über ihren Router den Weg ins Internet finden.
Was ja auch sehr sinnvoll ist. Fazit also: KEIN redirect-gateway def1 !!möchte ich, dass ich aus dem Heimnetz (192.168.178.0) nur die NAS mit IP 192.168.180.10 erreichen kann und umgekehrt.
iptables ist dann hier dann dein bester Freund. Stelle den Filter (Forwarding Chain) so ein das nur 192.168.180.10 passieren kann.Tip:
Statt Raspberry Pi kannst du als Alternative einen Mikrotik hAP Router verwenden:
https://www.varia-store.com/de/produkt/33635-mikrotik-routerboard-rb941- ...
Ist preiswerter, kann OpenVPN und hat eine komplett grafische Firewall an Board wo das per Mausklick einfach aufzusetzen ist. Siehe HIER.
Da die LAN Ports nur 100Mbit können bist du aber auf diese Bandbreite festgenagelt. Alternativ bei Gig musst du dann einen hEX nehmen der aber dann teurer ist:
https://www.varia-store.com/de/produkt/36790-mikrotik-routerboard-hex-mi ...
1
Aqui ist noch nicht im Freitagsmodus...
Ich hatte zu dem Thema mal was aus 2016 gefunden...was neueres wurde mir leider nicht angezeigt. Vielleicht kommt noch ein "Zufallstreffer".
Aqui ist noch nicht im Freitagsmodus... Ich hatte zu dem Thema mal was aus 2016 gefunden...
Bahnhof, Ägypten ???
Danke, aqui, für deine Antwort. Deine Links werden sicherlich auch helfen!
Du schreibst in deinen Artikeln, dass kein Masquerading erforderlich ist. In vielen Anleitungen ist aber genau das notwendig: -A POSTROUTING -s 10.8.0.0/24 -o eth0 -m comment --comment openvpn-nat-rule -j MASQUERADE
Schaffst du es mit route, dass man Masquerading nicht benötigt?
Normal haben ja alle Clients in dem netz den Internet Rozter als Gateway, folglich nutzen sie logischerweise auch diesen als Internet Zugang. Möglich ist das aber auch das über den VPN Tunnel umzubiegen wenn man will. Geht also beides. Normal ist aber immer der lokale Router.
Das ist so gewollt, da mein VPN hauptsächlich für mobile Geräte gedacht ist und ich auch Pihole auf dem Raspi aktiv habe.
Ich will mich hier nochmal klarer ausdrücken, damit wir nicht aneinander vorbeischreiben: In einer normalen Client(iPhone)-Server-Verbindung ist es gewünscht, dass Internet auch über den Server läuft. In meiner Client(Raspi)-Server-Verbindung, wo ich auch die NAS erreichen will, die hinter dem Raspi-Client ist, will ich das jedoch nicht.
iPhone--------Server = Internet über Server
Raspi---------Server = kein Internet über Server
Kannst du mir bei den iptables en Detail weiterhelfen und auf welchem Gerät(Client oder Server) ich sie so einrichten muss?
Was bewirkt "route 192.168.180.0 255.255.255.0" in der Server conf
Bewirkt das diese Route in die Kernel Routing Table eingetragen wird, also in die Routing Table des Betriebssystems was das Routing nach extern (LAN Port) macht.Du schreibst in deinen Artikeln, dass kein Masquerading erforderlich ist. In vielen Anleitungen ist aber genau das notwendig: -A POSTROUTING -s 10.8.0.0/24 -o eth0 -m comment --comment openvpn-nat-rule -j MASQUERADE
Schaffst du es mit route, dass man Masquerading nicht benötigt?
Würden in der Konfiguration die Geräte im Client-LAN über den Router ins Internet gehen oder über den VPN Server?
Normal immer über den Router (VPN Split Tunneling). Letztlich ist das aber davon abhängig WIE du das Routing dort konfigurierst.Normal haben ja alle Clients in dem netz den Internet Rozter als Gateway, folglich nutzen sie logischerweise auch diesen als Internet Zugang. Möglich ist das aber auch das über den VPN Tunnel umzubiegen wenn man will. Geht also beides. Normal ist aber immer der lokale Router.
In der Basiskonfiguration des Servers ist push "redirect-gateway def1 bypass-dhcp" eingetragen.
Das ist ein Fehler und sollte man nur dann machen wenn man es wirklich braucht !Ich möchte, dass die Geräte im Client-LAN über ihren Router den Weg ins Internet finden.
Was ja auch sehr sinnvoll ist. Fazit also: KEIN redirect-gateway def1 !!iPhone--------Server = Internet über Server
Raspi---------Server = kein Internet über Server
möchte ich, dass ich aus dem Heimnetz (192.168.178.0) nur die NAS mit IP 192.168.180.10 erreichen kann und umgekehrt.
iptables ist dann hier dann dein bester Freund. Stelle den Filter (Forwarding Chain) so ein das nur 192.168.180.10 passieren kann.Statt Raspberry Pi kannst du als Alternative einen Mikrotik hAP Router verwenden:
https://www.varia-store.com/de/produkt/33635-mikrotik-routerboard-rb941- ...
Ist preiswerter, kann OpenVPN und hat eine komplett grafische Firewall an Board wo das per Mausklick einfach aufzusetzen ist. Siehe HIER.
Danke für den Hinweis. Als Server finde ich den Raspi sehr sympathisch und ist nun auch schon in Betrieb. Nun fehlt die Erweiterung. Mit dem Pihole auch ein toller Werbeblocker.https://www.varia-store.com/de/produkt/33635-mikrotik-routerboard-rb941- ...
Ist preiswerter, kann OpenVPN und hat eine komplett grafische Firewall an Board wo das per Mausklick einfach aufzusetzen ist. Siehe HIER.
In vielen Anleitungen ist aber genau das notwendig: -
Nein, das ist Quatsch und ist nie notwendig ! Das ist eine reine DAU Sicherung bei doppelten IPs.Nur dann wenn man beim VPN Design falsche und dümmliche IP Adressierung gewählt hat ! Siehe dazu auch:
VPNs einrichten mit PPTP
Schaffst du es mit route, dass man Masquerading nicht benötigt?
Routing hat mit IP Adress Translation nicht das Geringste zu tun. 2 völlig verschiedene Baustellen. Vergiss bitte das unsägliche und überflüssige NAT/Masquerading !Das ist so gewollt, da mein VPN hauptsächlich für mobile Geräte gedacht ist
OK, dann ist das auch richtig und sollte man so machen. Da steht dann die Sicherheit im Vordergrund wenn man z.B. an öffentlichen WLAN Hotspots usw. ist. Keine Frage...Man sollte sich dann aber immer bewusst sein das dann mit aktivem VPN sämtlicher Client Traffic in den Tunnel geht. Entsprechend performant (Crypto Hardware) sollte dann auch der Server bzw. dessen Internet Anbindung sein !
In meiner Client(Raspi)-Server-Verbindung, wo ich auch die NAS erreichen will, die hinter dem Raspi-Client ist, will ich das jedoch nicht.
Das kannst du aber nicht trennen. Jedenfalls nicht wenn du nur eine einzige Server Instanz betreibst. Du kannst dann nicht Gateway Redirect und Split Tunneling parallel haben, das lässt die Konfig nicht zu. Das was da eingetragen ist gilt dann analog für alle Clients !Es ist aber nicht schlimm, denn die RasPi Clients die LAN 2 LAN machen arbeiten ja nicht als Endgeräte, erzeugen also selber keinerlei lokalen Traffic und routen nur.
In so fern kann man das ignorieren. Die LAN Clients im Netzwerk dort haben ja als default Gateway den Internet Router. Folglich routet der alles lokale dann ins Internet und nur was dort per statischer Route eingetragen ist geht via RasPi Client in den Tunnel. Sollte also auch so klappen.
Nur wenn du es partout trennen willst musst du eine 2te OpenVPN Server Instanz mit einer anderen Konfig auf dem Server starten. Damit könntest du dann Client und LAN2LAN Traffic sauber trennen.
Beides geht....
und auf welchem Gerät(Client oder Server) ich sie so einrichten muss?
Sollte man immer auf den Client RasPis einrichten die das Client Netz routen zum Ziel.Als Server finde ich den Raspi sehr sympathisch und ist nun auch schon in Betrieb.
Es ging nicht um den OVPN Server sondern die RasPis die als Clients arbeiten sollen um das lokale LAN dort zu routen !Aber egal...was du nimmst ist vollkommen Wumpe !
ptables ist dann hier dann dein bester Freund. Stelle den Filter (Forwarding Chain) so ein das nur 192.168.180.10 passieren kann.
Mit meinen bescheidenen iptable Kenntnissen komme ich zu folgendem Ergebnis. Aktuell sind keine Regeln etc hinterlegt:
sudo iptables -P FORWARD DROP
sudo iptables -A FORWARD -s 192.168.180.10 -j ACCEPT
Damit wird nach meinem Verständnis 192.168.180.10 ins VPN durchgelassen und wenn es eine andere IP ist, diese geblockt. Denkfehler oder stimmt so?
Da ich Input/Output weiter auf ACCEPT habe, sollte man aus dem Client-Netz ja trotzdem auf den Raspi zugreifen können.
Denkfehler oder stimmt so?
Stimmt so ! 
Besser ist aber noch die Destination IP einzutragen also:
iptables -A FORWARD -s 192.168.180.10 -d 192.168.178.0/24 -j ACCEPT
Da ich Input/Output weiter auf ACCEPT habe, sollte man aus dem Client-Netz ja trotzdem auf den Raspi zugreifen können.
Richtig !Aber immer zuerst alles zum Fliegen bringen und Erreichbarkeit checken und danach das Firewalling !
So kannst du immer sicher sein das wenn etwas nicht klappt, es nur an den Regeln liegen kann !
1
Ahja, one last thing
Du hast oben geschrieben, wenn ich redirect-gateway def1 bypass-dhcp eintrage, wird immer der Tunnel für Internet genutzt.
Um das zu umgehen und um hier flexibel die Verbindungen zu wechseln, habe ich mit folgendem Kommando helfen wollen:
pull-filter ignore "redirect-gateway def1 bypass-dhcp"
pull-filter ignore "dhcp-option DNS 10.8.0.1"
Nach meinem Verständnis habe ich damit die Server Konfiguration außer Kraft gesetzt. Die IP blieb aber die vom Server.
Was nun geholfen hat, ist:
route 0.0.0.0 192.0.0.0 net_gateway
route 64.0.0.0 192.0.0.0 net_gateway
route 128.0.0.0 192.0.0.0 net_gateway
route 192.0.0.0 192.0.0.0 net_gateway
Sieht nicht so elegant aus, aber läuft. Woran kann es liegen? Wo sind meine ignore Kommandos fehlerhaft?
Du hast oben geschrieben, wenn ich redirect-gateway def1 bypass-dhcp eintrage, wird immer der Tunnel für Internet genutzt.
Um das zu umgehen und um hier flexibel die Verbindungen zu wechseln, habe ich mit folgendem Kommando helfen wollen:
pull-filter ignore "redirect-gateway def1 bypass-dhcp"
pull-filter ignore "dhcp-option DNS 10.8.0.1"
Nach meinem Verständnis habe ich damit die Server Konfiguration außer Kraft gesetzt. Die IP blieb aber die vom Server.
Was nun geholfen hat, ist:
route 0.0.0.0 192.0.0.0 net_gateway
route 64.0.0.0 192.0.0.0 net_gateway
route 128.0.0.0 192.0.0.0 net_gateway
route 192.0.0.0 192.0.0.0 net_gateway
Sieht nicht so elegant aus, aber läuft. Woran kann es liegen? Wo sind meine ignore Kommandos fehlerhaft?
aber die externe IP ist weiterhin die vom Server.
Das ist ja auch klar, denn der Server benötigt ja zwingend immer eine entsprechende IP auf seinem Tunnel Interface genau so wie der Client. Das Manual zu dem Kommando ist da auch klar: (Zitat): ...note that this option still allows the server to set the TCP/IP properties of the client's TUN/TAP interface.Sonst wäre ein Routing ja auch unmöglich.
https://community.openvpn.net/openvpn/wiki/IgnoreRedirectGateway?__cf_ch ...
Vermutlich machst du hier aber auch einen Denkfehler, denn die IP Adressierung der Tunnel Interfaces ist ja für das Routing irrelevant. Einzig die Routing Tabelle interessiert hier !!
Ein ip route show zeigt dir dann ganz klar ob der aktive VPN Client immer noch ein Gateway Redirect macht oder ob er es mit dem obigen Kommando erfolgreich ignoriert !
Ignoriert es das Redirect muss aber mit dem route... Kommando noch eine manuelle Route gesetzt werden wenn remote IP Netze erreicht werden müssen und nicht nur der Server.
Die Routing Tabelle ist also immer das was zählt !
Kann es daran liegen, dass ich als DNS-Server den Pihole auf dem RasPi nutze?
Nein. DNS ist eine ganz andere Baustelle. Solange die PiHole DNS IP Adresse über den Tunnel erreichbar ist zur Abfrage ist alles OK.Vermutlich machst du hier aber auch einen Denkfehler, denn die IP Adressierung der Tunnel Interfaces ist ja für das Routing irrelevant. Einzig die Routing Tabelle interessiert hier !!
Okay, leider liest man genau diesen Denkfehler verdammt oft bzw. habe ich es dann auch so verstanden.
Auf dem Raspi-Client (aktuell im Heimnetz über LAN angeschlossen) habe ich es nun einmal ohne ignore redirect
ip route show
0.0.0.0/1 via 10.8.0.1 dev tun0
default via 192.168.178.1 dev eth0 proto dhcp src 192.168.178.106 metric 202
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.20
XXX.XXX.XX.XXX via 192.168.178.1 dev eth0
128.0.0.0/1 via 10.8.0.1 dev tun0
192.168.178.0/24 via 10.8.0.1 dev tun0
192.168.178.0/24 dev eth0 proto dhcp scope link src 192.168.178.106 metric 202
Und nun einmal mit ignore redirect
ip route show
default via 192.168.178.1 dev eth0 proto dhcp src 192.168.178.106 metric 202
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.20
192.168.178.0/24 via 10.8.0.1 dev tun0
192.168.178.0/24 dev eth0 proto dhcp scope link src 192.168.178.106 metric 202
Damit sollte nun alles passen?!
Bingo ! Passt... 👍
So, nun klappt doch etwas in der Praxis nicht.
Ich konnte von Geräten aus dem Netz (PC), wo nun der Client steht, nicht aufs Heimnetz zugreifen - Ping ging auch nicht.
Der Systemstatus des Clients sagt:
Apr 11 14:22:09 : TCP/UDP: Preserving recently used remote address: [AF_INET]99.999.99.999:1194
Apr 11 14:22:09 : UDPv4 link local: (not bound)
Apr 11 14:22:09 : UDPv4 link remote: [AF_INET]99.999.99.999:1194
Apr 11 14:22:09 : [PiServer] Peer Connection Initiated with [AF_INET]99.999.99.999:1194
Apr 11 14:22:10 : TUN/TAP device tun0 opened
Apr 11 14:22:10 : /sbin/ip link set dev tun0 up mtu 1500
Apr 11 14:22:10 : /sbin/ip addr add dev tun0 10.8.0.20/24 broadcast 10.8.0.255
Apr 11 14:22:10 : RTNETLINK answers: File exists
Apr 11 14:22:10 : ERROR: Linux route add command failed: external program exited with error status: 2
Apr 11 14:22:10 : Initialization Sequence Completed
Kommentiere ich die folgende Zeile in der client-Datei aus, ist der Status fehlerfrei, aber das Ergebnis natürlich nicht zufriedenstellend, weil die Route nicht funktioniert:
route 192.168.178.0 255.255.255.0
Was jedoch funktioniert: Im Raspi-Client selbst kann ich alle Geräte im Heimnetz anpingen und auch Netzlaufwerke mounten.
Ich konnte von Geräten aus dem Netz (PC), wo nun der Client steht, nicht aufs Heimnetz zugreifen - Ping ging auch nicht.
Der Systemstatus des Clients sagt:
Apr 11 14:22:09 : TCP/UDP: Preserving recently used remote address: [AF_INET]99.999.99.999:1194
Apr 11 14:22:09 : UDPv4 link local: (not bound)
Apr 11 14:22:09 : UDPv4 link remote: [AF_INET]99.999.99.999:1194
Apr 11 14:22:09 : [PiServer] Peer Connection Initiated with [AF_INET]99.999.99.999:1194
Apr 11 14:22:10 : TUN/TAP device tun0 opened
Apr 11 14:22:10 : /sbin/ip link set dev tun0 up mtu 1500
Apr 11 14:22:10 : /sbin/ip addr add dev tun0 10.8.0.20/24 broadcast 10.8.0.255
Apr 11 14:22:10 : RTNETLINK answers: File exists
Apr 11 14:22:10 : ERROR: Linux route add command failed: external program exited with error status: 2
Apr 11 14:22:10 : Initialization Sequence Completed
Kommentiere ich die folgende Zeile in der client-Datei aus, ist der Status fehlerfrei, aber das Ergebnis natürlich nicht zufriedenstellend, weil die Route nicht funktioniert:
route 192.168.178.0 255.255.255.0
Was jedoch funktioniert: Im Raspi-Client selbst kann ich alle Geräte im Heimnetz anpingen und auch Netzlaufwerke mounten.
Ich konnte von Geräten aus dem Netz (PC), wo nun der Client steht, nicht aufs Heimnetz zugreifen - Ping ging auch nicht.
Wie immer: WAS sagt die Routing Tabelle des Gerätes was den VPN Tunnel bedient ??Ist eine statische Route auf dem dortigen Imnternet Router auf die lokale Client IP zum remoten netz eingetragen ??
ERROR: Linux route add command failed: external program exited with error status: 2
Sieht auch nicht gut aus !!Vermutlich startest du den Prozess als normaler User OHNE root Rechte, kann das sein ??
Ein normaler User hat natürlich keine Rechte die Routing Tabelle anzupassen !
Ist in der Konfig ein
user nobody
group nogroup
konfiguriert ?
Hast du im Server eine entsprechende Client spezifische Konfig Datei um Client Verzeichnis die nach dem Common Name des Clients benamt ist und folgenden Inhalt hat ??
ifconfig-push 10.8.0.2 255.255.255.0
iroute 192.168.178.0 255.255.255.0
Hilfreich wäre mal deine aktuelle Client Konfig hier anonymisiert zu posten.
Vorab: Anders als oben geschrieben, habe ich die IP Adresse des Client-Netzes auf 192.168.188.0 geändert, da ich gelesen habe, auf 192.168.180.0 gibt es bei der fritzbox wohl Probleme mit VPN. Die 180er taucht in meinen Daten selbstredend nicht mehr auf.
Die Routing Tabelle des Client (kann mich über ssh vom VPN Server darauf einloggen):
default via 192.168.188.1 dev eth0 proto dhcp src 192.168.188.11 metric 202
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.20
192.168.178.0/24 via 10.8.0.1 dev tun0
192.168.188.0/24 dev eth0 proto dhcp scope link src 192.168.188.11 metric 202
Client: 192.168.188.11
statische Route in der Fritzbox des Client:
Die Routing Tabelle des Servers:
default via 192.168.178.1 dev eth0 src 192.168.178.11 metric 202
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
192.168.178.0/24 dev eth0 proto dhcp scope link src 192.168.178.11 metric 202
Server: 192.168.178.11
statische Route in der Fritzbox des Server:
Ich starte den Service als User "pi" mit sudo, habe den VPN aber auch in systemd enabled. Über SSH habe ich gerade den VPN als root neu gestartet mit dem gleichen Ergebnis im status-check.
Im CCD ist für den Client folgendes hinterlegt:
ifconfig-push 10.8.0.20 255.255.255.0
iroute 192.168.188.0 255.255.255.0
Da er mit der 10.8.0.20 verbunden ist, sollte hier alles richtig hinterlegt sein.
Hier die Client-Konfig:
client
remote 999.999.999.999 1194
dev tun
proto udp4
askpass /etc/openvpn/auth.data
resolv-retry infinite
pull-filter ignore "redirect-gateway"
route 192.168.178.0 255.255.255.0
nobind
tls-version-min 1.2
tls-cipher TLS-ECDHE....
remote-cert-tls server
auth SHA512
cipher AES-256....
auth-nocache
Wie immer: WAS sagt die Routing Tabelle des Gerätes was den VPN Tunnel bedient ??
Ist eine statische Route auf dem dortigen Imnternet Router auf die lokale Client IP zum remoten netz eingetragen ??
Ist eine statische Route auf dem dortigen Imnternet Router auf die lokale Client IP zum remoten netz eingetragen ??
Die Routing Tabelle des Client (kann mich über ssh vom VPN Server darauf einloggen):
default via 192.168.188.1 dev eth0 proto dhcp src 192.168.188.11 metric 202
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.20
192.168.178.0/24 via 10.8.0.1 dev tun0
192.168.188.0/24 dev eth0 proto dhcp scope link src 192.168.188.11 metric 202
Client: 192.168.188.11
statische Route in der Fritzbox des Client:
Die Routing Tabelle des Servers:
default via 192.168.178.1 dev eth0 src 192.168.178.11 metric 202
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
192.168.178.0/24 dev eth0 proto dhcp scope link src 192.168.178.11 metric 202
Server: 192.168.178.11
statische Route in der Fritzbox des Server:
Ich starte den Service als User "pi" mit sudo, habe den VPN aber auch in systemd enabled. Über SSH habe ich gerade den VPN als root neu gestartet mit dem gleichen Ergebnis im status-check.
user nobody
group nogroup
Ist nicht in der Client-Konfig enthaltengroup nogroup
Im CCD ist für den Client folgendes hinterlegt:
ifconfig-push 10.8.0.20 255.255.255.0
iroute 192.168.188.0 255.255.255.0
Da er mit der 10.8.0.20 verbunden ist, sollte hier alles richtig hinterlegt sein.
Hier die Client-Konfig:
client
remote 999.999.999.999 1194
dev tun
proto udp4
askpass /etc/openvpn/auth.data
resolv-retry infinite
pull-filter ignore "redirect-gateway"
route 192.168.178.0 255.255.255.0
nobind
tls-version-min 1.2
tls-cipher TLS-ECDHE....
remote-cert-tls server
auth SHA512
cipher AES-256....
auth-nocache
Die Routing Tabelle des Servers:
default via 192.168.178.1 dev eth0 src 192.168.178.11 metric 202
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
192.168.178.0/24 dev eth0 proto dhcp scope link src 192.168.178.11 metric 202
Da ist ja schon der Fehler !!default via 192.168.178.1 dev eth0 src 192.168.178.11 metric 202
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
192.168.178.0/24 dev eth0 proto dhcp scope link src 192.168.178.11 metric 202
Hier fehlt doch die Route ins lokale 192.168.188.0/24 Netz des Clients !!!
Das IP Netz müsste ins tun0 Interface geroutet werden ! Klar also das die Rückroute vom Server fehlt und es deshalb nicht klappt !!
Der Fehler liegt also klar in der Server Konfig. Die müsste so oder so ähnlich aussehen:
dev tun
proto udp4
port 1194
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/test-server.crt
key /etc/openvpn/server/test-server.key
dh /etc/openvpn/server/dh.pem
cipher AES-256-CBC
auth SHA256
user nobody
group nogroup
server 10.8.0.0 255.255.255.0
topology subnet
push "topology subnet"
persist-key
persist-tun
status /etc/openvpn/openvpn-status.log
push "route 192.168.178.0 255.255.255.0"
route 192.168.188.0 255.255.255.0
keepalive 10 120
explicit-exit-notify 1
client-config-dir /etc/openvpn/clientconf
Im Verzeichnis /etc/openvpn/clientconf muss dan eine Konfig Datei sein deren Dateiname identisch ist mit dem Common Name das Clients (Zertifikat) !
Diese muss folgenden Inhalt haben:
ifconfig-push 10.8.0.2 255.255.255.0
iroute 192.168.188.0 255.255.255.0
Hast du das entsprechend eingerichtet ??
Fehler ist ganz klar die fehlende Rückroute ins lokale 192.168.188.0er Client LAN auf der Server Seite !!
Problem gelöst!
Kann es sein, dass es an so einer "Kleinigkeit" wie den Rechten an der Client-CCD Datei lag? Ich habe diese nun auf 755 geändert und nun läuft es.
Hat push "topology subnet" noch eine Bedeutung für mich?
Noch eine Frage zu:
ip route show
default via 192.168.178.1 dev eth0 src 192.168.178.11 metric 202
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
192.168.178.0/24 dev eth0 proto dhcp scope link src 192.168.178.11 metric 202
192.168.188.0/24 via 10.8.0.2 dev tun0
Wieso geht 192.168.188.0.24 über 10.8.0.2? Der Client hat die IP 10.8.0.20
Ich kann die 10.8.0.2 auch nicht anpingen. Wer ist es also?
Kann es sein, dass es an so einer "Kleinigkeit" wie den Rechten an der Client-CCD Datei lag? Ich habe diese nun auf 755 geändert und nun läuft es.
Hat push "topology subnet" noch eine Bedeutung für mich?
Noch eine Frage zu:
ip route show
default via 192.168.178.1 dev eth0 src 192.168.178.11 metric 202
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
192.168.178.0/24 dev eth0 proto dhcp scope link src 192.168.178.11 metric 202
192.168.188.0/24 via 10.8.0.2 dev tun0
Wieso geht 192.168.188.0.24 über 10.8.0.2? Der Client hat die IP 10.8.0.20
Ich kann die 10.8.0.2 auch nicht anpingen. Wer ist es also?
Problem gelöst!
👍Hat push "topology subnet" noch eine Bedeutung für mich?
Ja, kann nicht schaden das im Server zu verwenden ! Das "pusht" dann die Subnetz Topo Adressierung auch sicher an die Clients. Das nutzt dann das gesamte interne Subnetz statt es wie früher in ein /30er pro Client aufzuteilen was addresstechnisch nicht günstig ist.Ich kann die 10.8.0.2 auch nicht anpingen. Wer ist es also?
Das ist sehr ungewöhnlich ! Darf so eigentlich nicht sein.Kann man nur so erklären das du einen anderen Client hast der zuvor schon die .2 bekommen hat und diese so dem routetnden Client nicht mehr zur Verfügung steht. Du kannst aber auch jede andere IP in die Client spezifische Datei eintragen die der Server dafür verwendet.
Das ifconfig-push 10.8.0.x 255.255.255.0 dient dazu dem Client immer eine feste IP zuzuteilen was für das Routing wichtig ist.
Ich habe mal irgendwo gelesen "die .2 wäre der Tunnel von .1" ... Kannst du damit was anfangen?
Ansonsten hat der Client richtigerweise die .20 erhalten, wie ich es in der CCD-Datei hinterlegt habe.
Richtigerweise sollte bei 192.168.188.0/24 via 10.8.0.2 dev tun0 also statt 10.8.0.2 die 10.8.0.20 stehen ...oder 10.8.0.1?
Ansonsten hat der Client richtigerweise die .20 erhalten, wie ich es in der CCD-Datei hinterlegt habe.
Richtigerweise sollte bei 192.168.188.0/24 via 10.8.0.2 dev tun0 also statt 10.8.0.2 die 10.8.0.20 stehen ...oder 10.8.0.1?
Ich habe mal irgendwo gelesen "die .2 wäre der Tunnel von .1" ... Kannst du damit was anfangen?
Ja ! Das ist doch genau was oben steht und dir erklärt wurde !Es gibt die Topologies subnet und net30. Guckst du hier:
https://community.openvpn.net/openvpn/wiki/Topology?__cf_chl_jschl_tk__= ...
Ohne den "subnet" Parameter nutzt OpenVPN das veraltete /30er Subnetz Verfahren. Sprich das für jeden einzelnen Client ein eigenes Subnetz mit einem /30er prefix eröffnet wird. Das frisst Resourcen und Perfromance, deshalb wird es in modernen OVPN Konfigs nicht mehr gemacht oder sollte nicht mehr gemacht werden. Derzeit ist es aber leider noch default wenn man die topology subnet nicht explizit konfiguriert !
Das zusätzliche push topology subnet erzwingt dann auch diese Topologie auf dem Client beim Tunnelaufbau. Es kann also de facto nicht schaden das auf dem Server zu konfigurieren !
Fazit:
Ja, "die .2 kann der Tunnel von .1 sein" wenn man das veraltete /30er (net30) Topologie Konzept nutzt. Sonst nicht !!
Ansonsten hat der Client richtigerweise die .20 erhalten, wie ich es in der CCD-Datei hinterlegt habe.
Perfekt ! So sollte es auch sein.Die .2 bekommt dann ein anderer Client, denn alle internen IPs außer der .20 werden der Reihe nach im Pool Verfahren vergeben je nach Subnetz Größe des internen Netzes.
Richtigerweise sollte bei 192.168.188.0/24 via 10.8.0.2 dev tun0
Je nachdem....Wenn der OVPN Server selber die .2 hat wäre diese Route auch gültig. Dazu müsstest du mal ein ifconfig auf den Server machen.
Ein paar interessante Zeilen aus dem Status log des Servers:
/sbin/ip route add 192.168.188.0/24 via 10.8.0.2
IFCONFIG POOL: base=10.8.0.2 size=252, ipv6=0
Obwohl der Server die 10.8.0.1 hat, macht er einen Tunnel über 10.8.0.2. Siehe ifconfig:
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.8.0.1 netmask 255.255.255.0 destination 10.8.0.1
In meiner Server-Konfig ist ja subnet und nun auch push subnet eingetragen. Das hätte von Beginn an passen sollen.
Falls du jetzt auch keine Idee mehr hast, lasse ich es einfach so. Denn wie gesagt, Ping auf 10.8.0.2 nicht möglich und da hängt auch kein Client von mir dran. Die bekommen die IP alle über CCD. Da aber alles gerade rund läuft, soll es vielleicht so sein.
/sbin/ip route add 192.168.188.0/24 via 10.8.0.2
IFCONFIG POOL: base=10.8.0.2 size=252, ipv6=0
Obwohl der Server die 10.8.0.1 hat, macht er einen Tunnel über 10.8.0.2. Siehe ifconfig:
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.8.0.1 netmask 255.255.255.0 destination 10.8.0.1
In meiner Server-Konfig ist ja subnet und nun auch push subnet eingetragen. Das hätte von Beginn an passen sollen.
Falls du jetzt auch keine Idee mehr hast, lasse ich es einfach so. Denn wie gesagt, Ping auf 10.8.0.2 nicht möglich und da hängt auch kein Client von mir dran. Die bekommen die IP alle über CCD. Da aber alles gerade rund läuft, soll es vielleicht so sein.
Ist zwar komisch aber wenn es so rennt...who cares ?! Never touch a running system !
