Zugriff aus dem LAN auf VPN Tunnel

Hallo,

ich habe gerade ein kleines Problem, dass ich nicht weiß, ob es anders zu lösen ist. Ich habe auf einem Linux/Debian System einen OpenVPN Server am laufen.
Die Clients (VPN Router Digicomm) stellen ihr eigenes Netz dem Server zur Verfügung. Soll heißen, der Server kann auf das Netzwerk hinter dem Client zugreifen. Dort befindet sich in der Regel ein Client, der direkt an dem Switch des VPN Routers angeschlossen ist.

Nun besteht derzeit aber keine Möglichkeit, aus dem eigentlichen LAN Netz (192.168.100.x) auf die Clients und deren Netzwerke zuzugreifen. Ist das denn theoretisch möglich? Derzeit baut jeder Rechner im LAN Netz eine VPN Verbindung zum VPN Server auf. Halte ich für weniger hilfreich.

Hier einmal der Auszug aus meiner conf Datei. Die Ordner sind entsprechend angelegt. Auch habe ich die passenden irouten in den ccds abgelegt.
Also wie gesagt, der Server hat als LAN Adresse eine 192.168.100.2 Adresse. In diesem Netz befindet sich auch noch ein paar andere Rechner. Mit diesen würde ich auch gerne auf die Clients und deren dahinterhängenden Netzwerk zugreifen. Andersherum sollen die Clients selber keinen Zugriff auf die Rechner im 100.x Netz haben. Da es derzeit nur mit den zusätzlichen VPN Verbindungsaufbau auf den lokalen Rechnern geht, steht noch client-to-client in der conf. Vielleicht kann mir einer da näheres zu sagen.

# Which local IP address should OpenVPN
# listen on? (optional)
;local a.b.c.d
;local 192.168.100.2

port 11940
proto udp
dev tun

# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel if you
# have more than one.  On XP SP2 or higher,
# you may need to selectively disable the
# Windows firewall for the TAP adapter.
# Non-Windows systems usually don't need this. 
;dev-node gfe-ovpn

# Zertifikate
ca 		server/ca.crt
cert 	server/server.crt
key 	server/server.key
dh 		server/dh2048.pem

server 10.8.0.0 255.255.255.0					# OpenVPN Server Adresse

# Maintain a record of client <-> virtual IP address
# associations in this file.  If OpenVPN goes down or
# is restarted, reconnecting clients can be assigned
# the same virtual IP address from the pool that was
# previously assigned.
ifconfig-pool-persist server/ipp.txt

# Push routes to the client to allow it to reach other private subnets behind the server.
push "route 192.168.101.0 255.255.255.0"	  
push "route 192.168.102.0 255.255.255.0"	  
push "route 192.168.103.0 255.255.255.0"    

client-config-dir server/ccd
route 192.168.101.0 255.255.255.0
route 192.168.102.0 255.255.255.0
route 192.168.103.0 255.255.255.0 


# Die Clients können sich untereinander sehen
client-to-client

keepalive 10 120

# Einschalten der Komprimierung
comp-lzo

# The maximum number of concurrently connected
# clients we want to allow.
max-clients 100

# It's a good idea to reduce the OpenVPN 
# daemon's privileges after initialization. 
#
# You can uncomment this out on
# non-Windows systems.
;user nobody
;group nobody

# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
persist-key
persist-tun

# Output a short status file showing
# current connections, truncated
# and rewritten every minute.
status 		server/status.txt
log 	    server/log.txt

# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 3		# Protokollierung Stufe 3

# Silence repeating messages.  At most 20
# sequential messages of the same message
# category will be output to the log.
mute 20

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 341236

Url: https://administrator.de/forum/zugriff-aus-dem-lan-auf-vpn-tunnel-341236.html

Ausgedruckt am: 24.12.2024 um 12:12 Uhr

4 Kommentare

Neuester Kommentar

Ist das denn theoretisch möglich?

Nicht nur theoretisch sondern auch praktisch, das ist eines der Grundfunktionen von OpenVPN mit der LAN zu LAN Koppelung ! Sollte man eigentlich wissen wenn man VPNs einrichtet ?!

Derzeit baut jeder Rechner im LAN Netz eine VPN Verbindung zum VPN Server auf.

Das ist natürlich Schwachsinn...sorry und wie du schon selber richtig bemerkst wenig hilfreicher Blödsinn.

Hier einmal der Auszug aus meiner conf Datei.

Welche Conf Datei ?? Die des Servers ??
OK, nehmen wir mal an die ist es, dann hat die gravierende Fehler im Routing und da ist es kein Wunder das nix geht.
Hier mal die Dinge die auffällig bzw. falsch sind:

port 11940 Ist das so gewollt ?? Normal ist der OVPN Port UDP 1194. Wenn du bewusst andere Ports nehmen willst dann besser keine aus der ofiziell zugewiesenen IAN Port Range sondern aus dem Bereich der freien Ports 49152 bis 65535. Z.B. 51194 oder 61194. Ist aber kosmetisch und nicht ursächlich für dein Problem.
push "route 192.168.101 und .102 und .103. Hiermit sagst du den Clients das sie alles was in die IP Netze .101.0, .102.0 und .103.0 soll auch in den Tunnel geroutet werden soll. Vermutlich sind das aber die lokalen Client LANs (geraten ) was diese Routen dann vollkommen blödsinning macht, denn der Server darf doch niemals die lokalen Client LANs nochmals an die Clients in deren Routing Tabelle injizieren. Vollommener Unsinn denn das sind die loaklen LANs !

Wenn das lokale LAN am Server die 192.168.100.0 /24 ist dann darf dort lediglich push "route 192.168.100-0 stehen und sonst nichts mit push route.
Das Routing in die Client Netze macht allein das route xyz... Kommando !

Du kannst das ganz einfach kontrollieren indem du dir mit route print (Windows) die Routing Tabelle ansiehst. Bei unixoiden OS geht das mit netstat -r.
Das zeigt dir was an netzen in den Tunnel geht und was nicht.
Wenn du deine Konfig sauber einstellst sollte das sofort funktionieren.

Hallo, das mit den "Grundfunktionen" ist klar. Ich habe die Clients ja entsprechend auch gekoppelt. Den zweiten Punkt verstehe ich deinerseits nicht ganz. push "route 101, 102 ..." sind alles die externen Clients. Also sollte das soweit mMn stimmen.

So wie es aussieht, hat der Lancom Router ein Problem mit den Routen gehabt. Habe diese gelöscht und gleich wieder aufgesetzt. Nun wird aus dem internen LAN alles soweit durchgeleitet ;)