12
Geräte hinter VPN Server freigeben
Hallo,
ich habe derzeit ein Problem, dass diverse Geräte hinter einem VPN Server nicht auftauchen.
Auf die Geräte der Clients kann ich zugreifen. Dieses sind DigiCom VPN Router, hinter denen sich diverse Geräte befinden.
Jedoch komme ich nicht auf die Geräte, die sich im gleichen LAN befinden. Muss ich hier noch zusätzlich einen VPN Client auf dem Server mitlaufen lassen?
Es befindet sich in dem Netzwerk ein Brother Netzwerkdrucker mit der IP Adresse 192.168.2.29, der von den anderen Geräten aus benutzt werden muss über das Internet hinweg.
--- server.conf (Auszug)
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.2.0 255.255.255.0" # Lokales Netzwerk am VPN Server
ush "route 192.168.101.0 255.255.255.0" # VPN Client
...
client-config-dir /etc/openvpn/ccd
route 192.168.2.0 255.255.255.0 # Lokales Netzwerk am VPN Server
route 192.168.101.0 255.255.255.0 # VPN Client
...
keepalive 10 60 # Timeout für den Servermode.
ich habe derzeit ein Problem, dass diverse Geräte hinter einem VPN Server nicht auftauchen.
Auf die Geräte der Clients kann ich zugreifen. Dieses sind DigiCom VPN Router, hinter denen sich diverse Geräte befinden.
Jedoch komme ich nicht auf die Geräte, die sich im gleichen LAN befinden. Muss ich hier noch zusätzlich einen VPN Client auf dem Server mitlaufen lassen?
Es befindet sich in dem Netzwerk ein Brother Netzwerkdrucker mit der IP Adresse 192.168.2.29, der von den anderen Geräten aus benutzt werden muss über das Internet hinweg.
--- server.conf (Auszug)
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.2.0 255.255.255.0" # Lokales Netzwerk am VPN Server
ush "route 192.168.101.0 255.255.255.0" # VPN Client
...
client-config-dir /etc/openvpn/ccd
route 192.168.2.0 255.255.255.0 # Lokales Netzwerk am VPN Server
route 192.168.101.0 255.255.255.0 # VPN Client
...
- Die Clients können sich untereinander sehen
keepalive 10 60 # Timeout für den Servermode.
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: 277230
Url: https://administrator.de/contentid/277230
Ausgedruckt am: 23.11.2024 um 03:11 Uhr
12 Kommentare
Neuester Kommentar
Hi,
ifconfig-push 10.8.0.2 10.8.0.1
iroute 192.168.101.0 255.255.255.0
192.168.101.0 255.255.255.0
192.168.102.0 255.255.255.0
192.168.103.0 255.255.255.0
...und die sich untereinander erreichen sollen.
Gruß orcape
push "route 192.168.2.0 255.255.255.0" # Lokales Netzwerk am VPN Server
OKush "route 192.168.101.0 255.255.255.0" # VPN Client
Das remote Netzwerk musst Du nicht pushen.....route 192.168.101.0 255.255.255.0 # ist OK
client-config-dir /etc/openvpn/ccd
...sollte so aussehen...ifconfig-push 10.8.0.2 10.8.0.1
iroute 192.168.101.0 255.255.255.0
Die Clients können sich untereinander sehen
client-to-client
Der Eintrag ist nur notwendig, wenn Du mehrere OpenVPN-Clientnetze betreibst, also z.B....client-to-client
192.168.101.0 255.255.255.0
192.168.102.0 255.255.255.0
192.168.103.0 255.255.255.0
...und die sich untereinander erreichen sollen.
Gruß orcape
Hallo orcape,
das mit dem Remote Netzwerk habe ich nachträglich reingemacht, ohne war die gleiche Funktion.
Die Textfiles in dem ccd Ordner sehen bislang so aus,
iroute 192.168.102.0 255.255.255.0 # irgendeinclient
Bei mir will gerade nicht reingehen, wieso die ifconfig-push hier notwendig ist. Betrifft dass jedem Client? Bislang ging es ohne.
Die client-to-client sollte drin bleiben. Denn es gibt eine VPN-Router im Netzwerk (3G), die jeweils einen Client am LAN haben, auf den ich Zugriff haben muss. Die Geräte haben keine Möglichkeit, selber als VPN Client tätig zu werden. Diese haben dann die Adressen 192.168.10x.x.
Des weiteren sind auch einige Rechner direkt als VPN Client ausgestattet. Um diese Geräte handelt es sich in diesem Fall. Diese müssen auf einem Drucker hinter dem VPN Server zugreifen. Es betrifft Windows7/8 Rechner, auf denen die OpenVPN Software installiert ist.
Zugriff auf die anderen OpenVpN Clientnetzwerke ist kein Problem, jedoch kein Zugriff, bzw. der Drucker wird nicht gefunden. Die config-Files sind dort recht simpel gestaltet
--
port 1194
dev tun
remote dyndns 1194
tls-client
ca ca.crt
cert client.crt
key client.key
pull
comp-lzo
verb 1
Danke aber schon einmal für eine Rückmeldung! Gruß
das mit dem Remote Netzwerk habe ich nachträglich reingemacht, ohne war die gleiche Funktion.
Die Textfiles in dem ccd Ordner sehen bislang so aus,
iroute 192.168.102.0 255.255.255.0 # irgendeinclient
Bei mir will gerade nicht reingehen, wieso die ifconfig-push hier notwendig ist. Betrifft dass jedem Client? Bislang ging es ohne.
Die client-to-client sollte drin bleiben. Denn es gibt eine VPN-Router im Netzwerk (3G), die jeweils einen Client am LAN haben, auf den ich Zugriff haben muss. Die Geräte haben keine Möglichkeit, selber als VPN Client tätig zu werden. Diese haben dann die Adressen 192.168.10x.x.
Des weiteren sind auch einige Rechner direkt als VPN Client ausgestattet. Um diese Geräte handelt es sich in diesem Fall. Diese müssen auf einem Drucker hinter dem VPN Server zugreifen. Es betrifft Windows7/8 Rechner, auf denen die OpenVPN Software installiert ist.
Zugriff auf die anderen OpenVpN Clientnetzwerke ist kein Problem, jedoch kein Zugriff, bzw. der Drucker wird nicht gefunden. Die config-Files sind dort recht simpel gestaltet
--
port 1194
dev tun
remote dyndns 1194
tls-client
ca ca.crt
cert client.crt
key client.key
pull
comp-lzo
verb 1
Danke aber schon einmal für eine Rückmeldung! Gruß
Bei mir will gerade nicht reingehen, wieso die ifconfig-push hier notwendig ist. Betrifft dass jedem Client? Bislang ging es ohne
Wenn das so funktioniert, Ok. Bei mir laufen die Server auf pfSense und durch den GUI wird das automatisch kreiert. Wenn Du mehrere OpenVPN-Clients hast, kannst Du aber mit dem ersten Eintrag die IP des Tunnelendpunktes festlegen, z.B. 10.8.0.2 etc...Die client-to-client sollte drin bleiben. Denn es gibt eine VPN-Router im Netzwerk (3G), die jeweils einen Client am LAN haben, auf den ich Zugriff haben
muss. Die Geräte haben keine Möglichkeit, selber als VPN Client tätig zu werden. Diese haben dann die Adressen 192.168.10x.x.
Ok.muss. Die Geräte haben keine Möglichkeit, selber als VPN Client tätig zu werden. Diese haben dann die Adressen 192.168.10x.x.
Des weiteren sind auch einige Rechner direkt als VPN Client ausgestattet. Um diese Geräte handelt es sich in diesem Fall. Diese müssen auf einem Drucker > hinter dem VPN Server zugreifen.
- Portforwarding 1194 auf dem Router ?- Worauf läuft der Server ?
- Wie sieht das Netzwerk lokal aus ?
Hallo orcrape,
das OpenVpn Server Testsystem läuft auf LinuxMint 17 Quinia. Soll später auf Arch Linux ggf. wechseln. Portfowarding ist auf dem Speedport aktiv.
Das Netzwerk sieht lokal so aus,
die Testplattform (OpenVpn Server) hat die interne IP Adresse 192.168.2.103. Die anderen am Switch angeschlossenen Geräte habe die IP Adresse 192.168.2.1-x
Ich habe in den ccd-Files ifconfig-push hinzugefügt, habt aber darauf keine Auswirkung.
das OpenVpn Server Testsystem läuft auf LinuxMint 17 Quinia. Soll später auf Arch Linux ggf. wechseln. Portfowarding ist auf dem Speedport aktiv.
Das Netzwerk sieht lokal so aus,
die Testplattform (OpenVpn Server) hat die interne IP Adresse 192.168.2.103. Die anderen am Switch angeschlossenen Geräte habe die IP Adresse 192.168.2.1-x
Ich habe in den ccd-Files ifconfig-push hinzugefügt, habt aber darauf keine Auswirkung.
Habe nun soweit gesehen, dass für die ganze Sache der tap (Bridge-Modus) notwendig ist.
Habe in der server.conf
"dev tap # geaendert von tun auf tap -> Bridging Mode anstatt Routing Mode"
geändert. Gleiches gilt für meinen Client, der über das Internet auf das VPN Netzwerk zugreift. Mit einem IP Scanner bekomme ich nun schon einmal einen Ping auf den besagten Drucker.
Verbindung zum Drucker kann aber nicht aufgebaut werden und danach sind die externen Clients nicht mehr erreichbar (Einstellung wegen tun /tap). An diesen möchte ich ungern alles über die Ferne ändern. Da bei einigen bei falscher Einstellung kein Service Zugang von ausserhalb mehr bestehen würde.
Habe in der server.conf
"dev tap # geaendert von tun auf tap -> Bridging Mode anstatt Routing Mode"
geändert. Gleiches gilt für meinen Client, der über das Internet auf das VPN Netzwerk zugreift. Mit einem IP Scanner bekomme ich nun schon einmal einen Ping auf den besagten Drucker.
Verbindung zum Drucker kann aber nicht aufgebaut werden und danach sind die externen Clients nicht mehr erreichbar (Einstellung wegen tun /tap). An diesen möchte ich ungern alles über die Ferne ändern. Da bei einigen bei falscher Einstellung kein Service Zugang von ausserhalb mehr bestehen würde.
Habe nun soweit gesehen, dass für die ganze Sache der tap (Bridge-Modus) notwendig ist
Wenn Du Server-LAN und Remotes-LAN unterschiedliche Netzwerke hast, funktioniert der TAP-Device so nicht.Dazu müssen beide Netze gleich sein, würde ich aber so nicht empfehlen, da Du damit den gesamten Broadcast Traffic mit über den Tunnel ziehst.
Hast Du auf dem Linux-Server das Routing aktiviert ?
Das könnte schon Dein Problem sein.
Hallo,
wenn du das meinst, ja, ansonsten bitte kurze Info, wo du das genau meinst.
--
$ netstat -r
Kernel-IP-Routentabelle
Ziel Router Genmask Flags MSS Fenster irtt Iface
default speedport.ip 0.0.0.0 UG 0 0 0 eth0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
10.8.0.2 * 255.255.255.255 UH 0 0 0 tun0
192.168.2.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
192.168.2.0 * 255.255.255.0 U 0 0 0 eth0
192.168.101.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
...
wenn du das meinst, ja, ansonsten bitte kurze Info, wo du das genau meinst.
--
$ netstat -r
Kernel-IP-Routentabelle
Ziel Router Genmask Flags MSS Fenster irtt Iface
default speedport.ip 0.0.0.0 UG 0 0 0 eth0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
10.8.0.2 * 255.255.255.255 UH 0 0 0 tun0
192.168.2.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
192.168.2.0 * 255.255.255.0 U 0 0 0 eth0
192.168.101.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
...
Die Routingtabelle sieht gut aus.
Im File /proc/sys/net/ipv4/ip_forward sollte eine 1 stehen.
Blockt da vielleicht noch ne Firewall ?
Dann trag mal den Wireshark auf und check das wo 's hängt.
echo 1 > /proc/sys/net/ipv4/ip_forward
als Root eingeben.Im File /proc/sys/net/ipv4/ip_forward sollte eine 1 stehen.
Blockt da vielleicht noch ne Firewall ?
Dann trag mal den Wireshark auf und check das wo 's hängt.
Hallo,
habe vorgestern noch einiges probiert, zwischenzeitig hatte ich mit einer Route die Verbindung zur internen LAN Adresse (Clients im eigenen Netzwerk konnten den OpenVPN Servern nicht über interne IP mehr ansprechen) gekappt. Habe das ganze soweit wieder in Ordnung gebracht,
was ich nun gemacht habe.
IP Forwarding ist aktiv.
Mit cat überprüft, der Wert steht auf 1.
Die server.conf sieht wie folgt aus
So noch einmal zur Netzwerkinfrastruktur.
Folgende Probleme sind noch vorhanden.
Im internen Netz (192.168.2.xxx) können die Geräte nicht auf OpenVPN-Clients zugreifen.
z.B. ist es nicht möglich, die RemoteControl (VNC) von einem Gerät aufzurufen, der sich hinter einem OpenVPN-Client mit hinterliegenden LAN befindet.
Beispiel 192.168.101.2
An dieser IP Adresse ist ein Gerät hinter, auf dem ich zugreifen möchte. Das geht aus dem internen Netz 192.168.2.xxx nicht. Befinde ich mich auf dem OpenVPN Server, kann diese Verbindung aufgebaut werden.
Wenn ich nun von meinem Client (einzelner Rechner an einer beliebigen Internet-Adresse) mit dem VPN verbinde, habe ich die Möglichkeit, darauf zuzu greifen.
Das weitere Problem ist, ich finde mit meinem Client einen Drucker auf der internen LAN-Adresse meines OpenVPN-Servers (192.168.2.29). Diese kann ich anpingen, jedoch nicht zu meinen Druckern hinzufügen. Portfreigabe zusätzlich für 9100 nötig? Was ich noch gleich testen wollte ist, wenn ich auf dem OpenVPN Server eine Druckerfreigabe mache. Ob ich diese dann evtl. ansprechen kann.
Die Routen sehen derzeit wie folgt aus
Mit WireShark finde ich auf dem Linux System leider keine Interfaces, kann das nicht testen.
habe vorgestern noch einiges probiert, zwischenzeitig hatte ich mit einer Route die Verbindung zur internen LAN Adresse (Clients im eigenen Netzwerk konnten den OpenVPN Servern nicht über interne IP mehr ansprechen) gekappt. Habe das ganze soweit wieder in Ordnung gebracht,
was ich nun gemacht habe.
IP Forwarding ist aktiv.
$ echo 1 > /proc/sys/net/ipv4/ip_forwardDie server.conf sieht wie folgt aus
# Server Konfiguration
port 1194
proto udp
dev tun
# Zertifikate
[...] ca, cert, key, dh
server 10.8.0.0 255.255.255.0 # OpenVPN Server Adresse
ifconfig-pool-persist ipp.txt
push "route 192.168.2.0 255.255.255.0" # LAN hinter OpenVPN Server
push "route 192.168.101.0 255.255.255.0" # LAN hinter einem über internet verbundenen OpenVPN Router
client-config-dir /etc/openvpn/ccd
route 192.168.101.0 255.255.255.0 # LAN hinter einem über internet verbundenen OpenVPN Router
# Die Clients können sich untereinander sehen
client-to-client
keepalive 10 60 # Timeout für den Servermode.
# Pingt alle 10 Sekunden,
# Neustart falls nach 60 Sekunden keine
# Rückantwort kommt.
# Einschalten der Komprimierung
comp-lzo
# You can uncomment this out on
# non-Windows systems.
user nobody
group nogroup
persist-key
persist-tun
# Optimierung
# Protokoll
status ovpn-status.txt
log ovpn-log.txt
verb 1 # Protokollierung Stufe 3
mute 10 # Maximal 50 Protokollierungen der gleichen Artport 1194
dev tun
remote xy.dyndns.org 1194
tls-client
ca ca.crt
cert client.crt
key client.key
pull
comp-lzo
verb 1So noch einmal zur Netzwerkinfrastruktur.
Im internen Netz des OpenVPN-Servers lauten die IP-Adressen 192.168.2.xxx
Die OpenVPN Clients haben eine IP-Adresse mit 10.8.0.xxxFolgende Probleme sind noch vorhanden.
Im internen Netz (192.168.2.xxx) können die Geräte nicht auf OpenVPN-Clients zugreifen.
z.B. ist es nicht möglich, die RemoteControl (VNC) von einem Gerät aufzurufen, der sich hinter einem OpenVPN-Client mit hinterliegenden LAN befindet.
Beispiel 192.168.101.2
An dieser IP Adresse ist ein Gerät hinter, auf dem ich zugreifen möchte. Das geht aus dem internen Netz 192.168.2.xxx nicht. Befinde ich mich auf dem OpenVPN Server, kann diese Verbindung aufgebaut werden.
Wenn ich nun von meinem Client (einzelner Rechner an einer beliebigen Internet-Adresse) mit dem VPN verbinde, habe ich die Möglichkeit, darauf zuzu greifen.
Das weitere Problem ist, ich finde mit meinem Client einen Drucker auf der internen LAN-Adresse meines OpenVPN-Servers (192.168.2.29). Diese kann ich anpingen, jedoch nicht zu meinen Druckern hinzufügen. Portfreigabe zusätzlich für 9100 nötig? Was ich noch gleich testen wollte ist, wenn ich auf dem OpenVPN Server eine Druckerfreigabe mache. Ob ich diese dann evtl. ansprechen kann.
Die Routen sehen derzeit wie folgt aus
$ netstat -r
Kernel-IP-Routentabelle
Ziel Router Genmask Flags MSS Fenster irtt Iface
default speedport.ip 0.0.0.0 UG 0 0 0 eth0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
10.8.0.2 * 255.255.255.255 UH 0 0 0 tun0
192.168.2.0 * 255.255.255.0 U 0 0 0 eth0
192.168.101.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0Mit WireShark finde ich auf dem Linux System leider keine Interfaces, kann das nicht testen.
push "route 192.168.101.0 255.255.255.0" # LAN hinter einem über internet verbundenen OpenVPN Router route 192.168.101.0 255.255.255.0 # LAN hinter einem über internet verbundenen OpenVPN Routerclient-config-dir /etc/openvpn/ccd # ist Ok in der Server.conf
dann in die /etc/openvpn/ccd eintragen....
iroute 192.168.101.0 255.255.255.0 # LAN hinter einem über internet verbundenen OpenVPN RouterDie Routen sehen derzeit wie folgt aus
Die sind OK.Wenn Du vom Server den Client-Router pingen kannst, das remote LAN nicht....
...dann wirst Du wohl noch ein paar Firewallregeln auf dem remoten Router erstellen müssen.
Gruß orcape
Hallo,
bislang ging ich davon aus, dass die externen vpnclients (Router)
sowohl die push route, als auch route und iroute brauchten. Habe somit erst einmal die push routen auskommentiert mit #.
Das hat nun zur folge, dass ich diese Netzwerke intern nicht mehr anpingen kann, was vorher ging.
Oder hast du dich hier mit den Namen vertan?
192.168.101.x ist ein Client mit VPNRouter. 192.168.2.x ist das LAN des OpenVPN Servers.
bislang ging ich davon aus, dass die externen vpnclients (Router)
sowohl die push route, als auch route und iroute brauchten. Habe somit erst einmal die push routen auskommentiert mit #.
Das hat nun zur folge, dass ich diese Netzwerke intern nicht mehr anpingen kann, was vorher ging.
Oder hast du dich hier mit den Namen vertan?
192.168.101.x ist ein Client mit VPNRouter. 192.168.2.x ist das LAN des OpenVPN Servers.
Oder hast du dich hier mit den Namen vertan?
Nein. Push brauchst Du um Netze im Server-LAN zu erreichen.Für den Remoten Zugriff nicht nötig.
Wenn Du die Tunnelendpunkte pingen kannst und auch per ssh auf Deinen Remoten Router kommst, also von 10.8.0.1 auf 10.8.0.2, aber nicht auf das Client-LAN, blockt da wohl die FW.
Was sind das für Client-Router ?
