Top-Themen

Aktuelle Themen (A bis Z)

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWünsch Dir wasWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

gelöst OpenVPN Client Netz mit gefiltertem Zugriff

Mitglied: meltinsands

meltinsands (Level 1) - Jetzt verbinden

08.04.2020, aktualisiert 21:17 Uhr, 655 Aufrufe, 23 Kommentare, 2 Danke

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 https://administrator.de/wissen/openvpn-server-installieren-pfsense-fire ...

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!
Mitglied: NordicMike
09.04.2020 um 10:26 Uhr
Ich erinnere mich, dass diese Frage vor kurzem bereits gestellt wurde. Such mal ein bisschen im Forum herum.
Bitte warten ..
Mitglied: aqui
09.04.2020, aktualisiert um 10:39 Uhr
1.) Ist kein Problem. Siehe HIER oder etwas spezifischer auf dein Szenario bezogen hier:
https://administrator.de/content/detail.php?id=530283&token=984#comm ...
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 ...
Bitte warten ..
Mitglied: NordicMike
09.04.2020 um 10:42 Uhr
Aqui ist noch nicht im Freitagsmodus...
Bitte warten ..
Mitglied: meltinsands
09.04.2020, aktualisiert um 11:06 Uhr
Ich hatte zu dem Thema mal was aus 2016 gefunden...was neueres wurde mir leider nicht angezeigt. Vielleicht kommt noch ein "Zufallstreffer".
Bitte warten ..
Mitglied: aqui
09.04.2020 um 11:08 Uhr
Aqui ist noch nicht im Freitagsmodus... Ich hatte zu dem Thema mal was aus 2016 gefunden...
Bahnhof, Ägypten ???
Bitte warten ..
Mitglied: meltinsands
09.04.2020 um 11:24 Uhr
Danke, aqui, für deine Antwort. Deine Links werden sicherlich auch helfen!

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 !
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 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 !!
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

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.
Kannst du mir bei den iptables en Detail weiterhelfen und auf welchem Gerät(Client oder Server) ich sie so einrichten muss?

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.
Bitte warten ..
Mitglied: aqui
09.04.2020 um 13:48 Uhr
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:
https://administrator.de/wissen/vpns-einrichten-pptp-117700.html#toc-7
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 !
Bitte warten ..
Mitglied: meltinsands
09.04.2020, aktualisiert um 21:07 Uhr
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.
Bitte warten ..
Mitglied: aqui
10.04.2020, aktualisiert um 00:28 Uhr
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 !
Bitte warten ..
Mitglied: meltinsands
10.04.2020, aktualisiert um 11:01 Uhr
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?
Bitte warten ..
Mitglied: aqui
10.04.2020 um 11:04 Uhr
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.
Bitte warten ..
Mitglied: meltinsands
10.04.2020, aktualisiert um 11:42 Uhr
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?!
Bitte warten ..
Mitglied: aqui
10.04.2020 um 18:35 Uhr
Bingo ! Passt... 👍
Bitte warten ..
Mitglied: meltinsands
11.04.2020 um 15:38 Uhr
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.
Bitte warten ..
Mitglied: aqui
11.04.2020 um 18:24 Uhr
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.
Bitte warten ..
Mitglied: meltinsands
11.04.2020, aktualisiert um 22:07 Uhr
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.


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 ??

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:
bildschirmfoto 2020-04-11 um 14.48.06 - Klicke auf das Bild, um es zu vergrößern



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:
bildschirmfoto 2020-04-11 um 18.37.06 - Klicke auf das Bild, um es zu vergrößern


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 enthalten

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
Bitte warten ..
Mitglied: aqui
LÖSUNG 11.04.2020, aktualisiert um 20:53 Uhr
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 !!
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 !!
Bitte warten ..
Mitglied: meltinsands
11.04.2020, aktualisiert um 22:10 Uhr
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?
Bitte warten ..
Mitglied: aqui
12.04.2020 um 10:12 Uhr
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.
Bitte warten ..
Mitglied: meltinsands
12.04.2020 um 10:24 Uhr
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?
Bitte warten ..
Mitglied: aqui
12.04.2020 um 11:27 Uhr
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.
Bitte warten ..
Mitglied: meltinsands
12.04.2020 um 12:09 Uhr
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.
Bitte warten ..
Mitglied: aqui
12.04.2020 um 13:41 Uhr
Ist zwar komisch aber wenn es so rennt...who cares ?! Never touch a running system !
Bitte warten ..
Ähnliche Inhalte
Linux Netzwerk
Openvpn client Netz ereichbar machen
Frage von schlampLinux Netzwerk33 Kommentare

Guten Tag ich bin neu hier! Habe des öfteren schon hier im Forum mitgelesen und bin begeistert. Jetzt möchte ...

Netzwerke
OpenVPN kein zugriff auf internes Netz
Frage von raxxis990Netzwerke10 Kommentare

Hallo Auf meinen hinter dem Speedport Hybrid geschalteten DD-WRT Router läuft ein OpenVPN Server um von außerhalb in das ...

Netzwerkgrundlagen

OpenVPN Server erlaubt keinen Zugriff auf eigenes Netz

Frage von istike2Netzwerkgrundlagen4 Kommentare

Hallo, ich richte jetzt die 3. Synology 2600AC Router für ein Kleinunternehmen ein. Meine bisherigen Versuche scheiterten auf den ...

Linux Netzwerk

OpenVPN Client-to-Client

Frage von FreezzenLinux Netzwerk

Moin Moin. Vorweg, Ubuntu war bis Ostern uninteressant für mich. Seitdem lerne ich es lieben. Moment beschäftige ich mich ...

Neue Wissensbeiträge
Sicherheit

Mehrere Sicherheitslücken in QNAP-NAS-Systemen aufgetaucht

Information von transocean vor 21 StundenSicherheit

Moin, QNAP hat drei Sicherheitsprobleme publik gemacht und empfiehlt sofortiges Update. Gruß Uwe

DNS

"Quickie": Mozillas "DNS over HTTPS" in pfSense blockieren

Anleitung von FA-jka vor 1 TagDNS4 Kommentare

Hallo, Mozilla macht jetzt wohl wirklich Ernst mit "DNS over HTTPS" (kurz: DoH). Damit werden sämtliche DNS-Anfragen zu entsprechenden ...

Sicherheit
Störung bei Telematikinfrasturktur GEMATIK
Information von lcer00 vor 1 TagSicherheit

Am 27. Mai 2020 ist es offenbar zu einer Fehlkonfiguration in der Zentralen Telematikinfrastruktur gekommen. Nähreres dazu findet sich ...

Informationsdienste

Trump vs Twitter - Angriff auf die Meinungsfreiheit?

Information von Frank vor 2 TagenInformationsdienste3 Kommentare

Trump nutzt Twitter rege. Nach Hinweisen auf Falschbehauptungen drohte er dem Dienst. Was das bedeutet und die Konsequenzen dazu ...

Heiß diskutierte Inhalte
Batch & Shell
Ip-Adresse-Konfiguration speichern zur Wiederherstellung
gelöst Frage von alex1991Batch & Shell20 Kommentare

Hallo, ich bin eigentlich nicht in der IT-Abteilung, aber als Programmierer bin ich noch am nächsten dran. Deshalb wurde ...

Exchange Server
Automatische Antwort - Weiterleitung - zweite automatische Antwort - keine Weiterleitung?
Frage von dertowaExchange Server18 Kommentare

Hallo zusammen, da mich der Microsoftsupport ein wenig fassungslos machte versuche ich hier mal mein Glück und wenn es ...

Netzwerkgrundlagen
PF Sense - Keine Verbindung nach "außen"
gelöst Frage von mario89Netzwerkgrundlagen14 Kommentare

Hallo Leute, muss euch nochmalum Rat fragen. Weil irgendwie komme ich nicht weiter. Hintergrund ist, dass ich bei meiner ...

Batch & Shell
Computer bei disconnecting mit bluetoothgerät herunterfahren
gelöst Frage von Renrep88Batch & Shell14 Kommentare

Hallo, ist es mithilfe von einer .cmd oder .bat datei möglich einen computer herunterzufahren wenn die verbindung zu einem ...