OpenVPN Berechtigung definieren

dcst55

Cadet 4th Year
Registriert
Dez. 2014
Beiträge
106
Hallo zusammen,

ich möchte folgendes umsetzen:

Ich möchte einen OpenVPN Server auf einem WebServer aufsetzen, den ich zum Surfen über unverschlüsselte WLAN's (HotSpots) nutzen möchte.

Zudem möchte ich an diesen OpenVPN Server, ebenfalls eine Raspberry PI anbinden, der in meinem Heimnetz steht und das Routing in mein Heimnetz ermöglichen soll. Bspw. um auf meine NAS zuzugreifen. Da habe ich leider nur eine DS-Light IP und über die mir zur Verfügung stehenden HotSpots erhalte ich nur eine IPv4 Adresse.

Der Gedanke ist, dass ich diesen OpenVPN Server mit einem Kollegen zusammen zu nutzen. Das Routing in mein Heimnetz soll allerdings nur für mich ermöglicht werden.

Hat jemand eine Idee wie ich das umsetzen kann? Gibt es in OpenVPN die Möglichkeit solche Berechtigungen zu definieren?
 
Man kann für jeden sich verbindenen Client ein eigenes Profil anlegen.

Beispiel für Client-Netz:
Code:
ifconfig-push 192.168.200.17 255.255.255.0
push "route 192.168.2.1 255.255.255.0 192.168.200.1"
Erklärung: Deine IP ist die 192.168.200.17
Du kommst ins 192.168.2.0 Netz über die 192.168.200.1

Beispiel für Netz-Netz:
Code:
ifconfig-push 192.168.200.2 255.255.255.0
push "route 192.168.200.1"
iroute 192.168.188.0 255.255.255.0
Erklärung: Deine IP ist die 192.168.200.17

Hierbei gibt man den Clients nur die Routen vor, die er tatsächlich auch nutzen soll.
Also z.B. nur 192.168.2.0 und nicht 192.168.3.0

Am sichersten wäre es aber wohl 2 OpenVPN Server, die auf unterschiedlichen Ports horchen, laufen zu lassen.
Da kann man dann auch gleich 2 verschiedene User auf dem Server haben...
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: dcst55
Sehe ich ähnlich. Das Problem mit den "Berechtigungen" ist, dass es effektiv keine gibt. Es gibt zwar durchaus client-spezifische Optionen im Server (Stichwort: ccd), aber da werden dann lediglich wie im obigen Beispiel zu sehen Routen zum Client gepusht - oder eben nicht. Sogesehen hindert das den Client aber nicht daran, diese Routen manuell hinzuzufügen.

Um dies zu unterbinden, könnte man höchstens im VPN-Server selbst die Firewall entsprechend konfigurieren, dass sie tatsächlich nur den einen VPN-Client durchlässt und alle anderen blockiert - auch wenn sie die Route manuell hinzugefügt haben. Da dies aber tiefergehende Kenntnisse im Bereich Firewall benötigt, würde ich wohl auch einfach auf 2 Server setzen, einen quasi für "Mitbenutzer" und einen für "Admins".
 
  • Gefällt mir
Reaktionen: dcst55
Raijin schrieb:
Sehe ich ähnlich. Das Problem mit den "Berechtigungen" ist, dass es effektiv keine gibt. Es gibt zwar durchaus client-spezifische Optionen im Server (Stichwort: ccd), aber da werden dann lediglich wie im obigen Beispiel zu sehen Routen zum Client gepusht - oder eben nicht. Sogesehen hindert das den Client aber nicht daran, diese Routen manuell hinzuzufügen.

Um dies zu unterbinden, könnte man höchstens im VPN-Server selbst die Firewall entsprechend konfigurieren, dass sie tatsächlich nur den einen VPN-Client durchlässt und alle anderen blockiert - auch wenn sie die Route manuell hinzugefügt haben. Da dies aber tiefergehende Kenntnisse im Bereich Firewall benötigt, würde ich wohl auch einfach auf 2 Server setzen, einen quasi für "Mitbenutzer" und einen für "Admins".
Genau das war auch mein Gedankengang.. Ich war mir allerdings nicht sicher ob ich damit richtig liege...

2 Server = doppelt so teuer... auch doof!

Ist es evtl. mit IPTables möglich, dass bspw. nur die IP 10.6.0.6 auf das Netz 192.168.200.0 zugreifen darf?!
 
"2 mal OpenVPN installieren" ist dabei auch nicht wörtlich zu nehmen. Einmal OpenVPN installieren, aber 2!!! server.conf anlegen, zB gastserver.conf und adminserver.conf. In den confs wird dann jeweils ein anderer Port benutzt (zB OpenVPN-Standard 1194 für den Gast-Server und 1195 für den Admin-Server). Natürlich muss auch jede .conf ein eigenes VPN-Subnetz abbilden, also zB 10.8.0.x und 10.8.1.x.

Mit den mitgelieferten Scripts kann man nun eine übergeordnete CA erstellen und davon ausgehend zwei server-Zertifikate und entsprechend die Client-Zertifikate. Anschließend sollte man noch ein kleines Verify-Script schreiben, das beim Connect das Client-Zertifikat checkt und so zB am admin-server nur Zertifikate zulässt, die beispielsweise im Common Name "Admin_" stehen haben.

Alternativ kann man auch zwei CAs bauen und dann die Zertifikate auf beiden Servern von vornherein trennen. Als Admin bräuchtest du dann aber auch ein Zertifikat für den Gast-Server, wenn du mal was testen willst.
 
  • Gefällt mir
Reaktionen: dcst55
Zurück
Oben