11
OpenVPN Client2Client
Hallo,
ich habe Probleme mit einem auf Linux basierenden OpenVPN Server.
Die Hauptfunktionen stehen soweit. Er stellt eine VPN zu den einzelnen Clients ausserhalb des LANs her. Jedoch kann nur der Server auf die Clients zugreifen.
Jedoch würde ich gerne von bestimmten Rechner/Clients im VPN auf die anderen Clients zugreifen.
Hintergrund, die Clients sind hauptsächlich extern stehende Rechner auf die mit VNC zugegriffen werden muss. Die externen Clients/Clientnetze sollen dabei nicht auf andere Clients zugreifen. Das ist derzeit so gegeben.
Jedoch sollen eine Hand voll Rechner auf alle Clients zugreifen. Auf dem Server läuft eine SQL Datenbank. Ebenfalls hinterlegt sind die VNC Verbindungen. Diese VNC Verknüpfungen sind auf einem Sambashare freigegeben. Nun ist es mir nicht möglich, diese VNC Verknüpfungen zu starten, da die IP Adresse nicht erreichbar ist. Das Routing vom bestimmten Client zum Server und dann zum gesuchten Client geht nicht.
Wäre für jede Hilfe dankbar. Im Anhang hier die server.conf. Sensible Daten sind mit ??? auskommentiert.
Gruß
ich habe Probleme mit einem auf Linux basierenden OpenVPN Server.
Die Hauptfunktionen stehen soweit. Er stellt eine VPN zu den einzelnen Clients ausserhalb des LANs her. Jedoch kann nur der Server auf die Clients zugreifen.
Jedoch würde ich gerne von bestimmten Rechner/Clients im VPN auf die anderen Clients zugreifen.
Hintergrund, die Clients sind hauptsächlich extern stehende Rechner auf die mit VNC zugegriffen werden muss. Die externen Clients/Clientnetze sollen dabei nicht auf andere Clients zugreifen. Das ist derzeit so gegeben.
Jedoch sollen eine Hand voll Rechner auf alle Clients zugreifen. Auf dem Server läuft eine SQL Datenbank. Ebenfalls hinterlegt sind die VNC Verbindungen. Diese VNC Verknüpfungen sind auf einem Sambashare freigegeben. Nun ist es mir nicht möglich, diese VNC Verknüpfungen zu starten, da die IP Adresse nicht erreichbar ist. Das Routing vom bestimmten Client zum Server und dann zum gesuchten Client geht nicht.
Wäre für jede Hilfe dankbar. Im Anhang hier die server.conf. Sensible Daten sind mit ??? auskommentiert.
Gruß
# Which TCP/UDP port should OpenVPN listen on?
port 1194
# TCP or UDP server?
proto udp
# Routed IP tunnel
dev tun
# SSL/TLS root certificate (ca), certificate
# (cert), and private key (key). Each client
# and the server must have their own cert and
# key file. The server and all clients will
# use the same ca file.
ca ./easy-rsa2/keys/ca.crt
cert ./easy-rsa2/keys/server.crt
key ./easy-rsa2/keys/server.key # This file should be kept secret
# Diffie hellman parameters.
dh ./easy-rsa2/keys/dh2048.pem
# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
# The server will take 10.8.0.1 for itself,
# the rest will be made available to clients.
# Each client will be able to reach the server
# on 10.8.0.1. Comment this line out if you are
# ethernet bridging. See the man page for more info.
server 10.8.0.0 255.255.255.0
# 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 ipp.txt
client-config-dir /etc/openvpn/ccd
route ???.???.???.??? 255.255.255.0 # client ???
route ???.???.???.??? 255.255.255.0 # client ???
route ???.???.???.??? 255.255.255.0 # client ???
route 192.???.???.??? 255.255.255.255 # client ???
push "route 192.168.1.0 255.255.255.0" # server
# Uncomment this directive to allow different
# clients to be able to "see" each other.
# By default, clients will only see the server.
# To force clients to only see the server, you
# will also need to appropriately firewall the
# server's TUN/TAP interface.
client-to-client
# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down.
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 120 second time period.
keepalive 10 120
# Enable compression on the VPN link.
# If you enable it here, you must also
# enable it in the client config file.
comp-lzo
# 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 nogroup
# 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 openvpn-status.log
# By default, log messages will go to the syslog (or
# on Windows, if running as a service, they will go to
# the "\Program Files\OpenVPN\log" directory).
# Use log or log-append to override this default.
# "log" will truncate the log file on OpenVPN startup,
# while "log-append" will append to it. Use one
# or the other (but not both).
log /home/???/Schreibtisch/openvpn.log
;log-append openvpn.log
# 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
# Silence repeating messages. At most 20
# sequential messages of the same message
# category will be output to the log.
;mute 20
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: 251566
Url: https://administrator.de/contentid/251566
Ausgedruckt am: 22.11.2024 um 17:11 Uhr
11 Kommentare
Neuester Kommentar
Servus,
Client2Client ist etwas missverständlich.
1. Wenn du willst, dass aus dem Privaten Netz ein Client mit einem VPN Client kommunzieren kann, musst du eine statische Route einrichten.
Auf einem Win-Client im Privaten Netz geht das so:
route ADD 10.8.0.0 MASK 255.255.255.0 192.168.0.254
wenn: 10.8.0.0 dein VPN-Netz mit der Subnetzmaske 255.255.255.0 ist. Das musst du anpassen.
192.168.0.254 musst du durch die LAN-IP von deinem VPN-Gateway ersetzen.
2. Auch wenn ein Server "zurück" ins VPN funken können soll, muss jeder dieser Server der da antworten soll, diese Route ins VPN Netz kennen. (DHCP option für die Clients, Statisch eingerichtet an den Servern)
ODER:
3. Wenn du willst, dass zwei Rechner sich ins VPN einloggen, und diese miteinander kommunizieren können, dann genügt eine Server-Option, da diese ja bereits im selben Subnetz sind. Die Option dafür lautet dann:
client-to-client
Bitte kläre deine Begrifflichkeiten.
Rechner - ?
Server - Der VPN Server
Client - Rechner der VPN mit dem Server macht. ?
Hoffe das klärt einiges auf.
Gruß,
Kay
Client2Client ist etwas missverständlich.
1. Wenn du willst, dass aus dem Privaten Netz ein Client mit einem VPN Client kommunzieren kann, musst du eine statische Route einrichten.
Auf einem Win-Client im Privaten Netz geht das so:
route ADD 10.8.0.0 MASK 255.255.255.0 192.168.0.254
wenn: 10.8.0.0 dein VPN-Netz mit der Subnetzmaske 255.255.255.0 ist. Das musst du anpassen.
192.168.0.254 musst du durch die LAN-IP von deinem VPN-Gateway ersetzen.
2. Auch wenn ein Server "zurück" ins VPN funken können soll, muss jeder dieser Server der da antworten soll, diese Route ins VPN Netz kennen. (DHCP option für die Clients, Statisch eingerichtet an den Servern)
ODER:
3. Wenn du willst, dass zwei Rechner sich ins VPN einloggen, und diese miteinander kommunizieren können, dann genügt eine Server-Option, da diese ja bereits im selben Subnetz sind. Die Option dafür lautet dann:
client-to-client
Bitte kläre deine Begrifflichkeiten.
Rechner - ?
Server - Der VPN Server
Client - Rechner der VPN mit dem Server macht. ?
Hoffe das klärt einiges auf.
Gruß,
Kay
Hallo Kay,
im internen Netzwerk hinter dem Router hängt ein kleines ITX Board mit einem Linux BS auf dem OpenVPN Server läuft. Im gleichen (nicht VPN) befinden sich 2 weitere Rechner. Die ebenfalls Zugriff auf die Datenbank haben. Das geht soweit alles.
Nun sind einige VNC Verknüpfungen nur über eine VPN Verbindungen aufzurufen. Diese VNC Verknüpfungen greifen auf ein VNC Router zu, der extern steht. Hierbei habe ich bereits verbunden, sodass ich nicht nur den VPN Router erreiche sonder auch die daran angeschlossenen Geräte.
Diese ganze Geschichte erfüllt bereits den Anforderungen, da von diesen Schnittstellen nicht einem Client zum anderen Client eine Verbindung aufgebaut werden soll.
Nun müssen aber die Rechner, die sich im gleichen lokalen Netzwerk befinden, auf den Server zugreifen. Das ist zum einen möglich über die LAN-Adresse. Testweise habe ich hierfür auch VPN Zertifikate erstellt, da es sich bei einem Rechner um einen Laptop handelt, der auch ausserhalb des Netzwerks darauf Zugriff haben muss.
Nun, sobald ich mit diesen Rechner eine VNC Verknüpfung öffnen möchte, die nur vom VPN aus erreichbar ist, gibt es das Problem, dass nicht geroutet wird.
Begrifflichkeiten:
Rechner: siehe Client
Client:
Hier gibt es 2 verschiedene Typen:
Client Gruppe 1: Es gibt Clients, die sich bereits im selben lokalen Netzwerk befinden (insgesamt 2). Diese müssen alle Clients der Gruppe 2 erreichen können.
Client Gruppe 2:
Hier handelt es sich um Rechner/Steuerungen (Linux) auf die zugegriffen werden muss über eine VNC Verbindung. Hier können keine Routen o.ä. eingetragen werden. Verbunden sind diese mit einem OVpn Router der soweit mit Zertifikaten gefüllt ist, dass er die Verbindung zum Server aufbaut. (Routen siehe server.conf).
Vom Server aus habe ich somit auf alle Geräte Zugriff. Den gleichen Zugriff auf Clients der Gruppe 2 müssen die Clients der Gruppe 1 haben.
Server: Das ist der Linux OVpn Server, dieser befindet sich mit den Client1 im selben lokalen Netzwerk
im internen Netzwerk hinter dem Router hängt ein kleines ITX Board mit einem Linux BS auf dem OpenVPN Server läuft. Im gleichen (nicht VPN) befinden sich 2 weitere Rechner. Die ebenfalls Zugriff auf die Datenbank haben. Das geht soweit alles.
Nun sind einige VNC Verknüpfungen nur über eine VPN Verbindungen aufzurufen. Diese VNC Verknüpfungen greifen auf ein VNC Router zu, der extern steht. Hierbei habe ich bereits verbunden, sodass ich nicht nur den VPN Router erreiche sonder auch die daran angeschlossenen Geräte.
Diese ganze Geschichte erfüllt bereits den Anforderungen, da von diesen Schnittstellen nicht einem Client zum anderen Client eine Verbindung aufgebaut werden soll.
Nun müssen aber die Rechner, die sich im gleichen lokalen Netzwerk befinden, auf den Server zugreifen. Das ist zum einen möglich über die LAN-Adresse. Testweise habe ich hierfür auch VPN Zertifikate erstellt, da es sich bei einem Rechner um einen Laptop handelt, der auch ausserhalb des Netzwerks darauf Zugriff haben muss.
Nun, sobald ich mit diesen Rechner eine VNC Verknüpfung öffnen möchte, die nur vom VPN aus erreichbar ist, gibt es das Problem, dass nicht geroutet wird.
Begrifflichkeiten:
Rechner: siehe Client
Client:
Hier gibt es 2 verschiedene Typen:
Client Gruppe 1: Es gibt Clients, die sich bereits im selben lokalen Netzwerk befinden (insgesamt 2). Diese müssen alle Clients der Gruppe 2 erreichen können.
Client Gruppe 2:
Hier handelt es sich um Rechner/Steuerungen (Linux) auf die zugegriffen werden muss über eine VNC Verbindung. Hier können keine Routen o.ä. eingetragen werden. Verbunden sind diese mit einem OVpn Router der soweit mit Zertifikaten gefüllt ist, dass er die Verbindung zum Server aufbaut. (Routen siehe server.conf).
Vom Server aus habe ich somit auf alle Geräte Zugriff. Den gleichen Zugriff auf Clients der Gruppe 2 müssen die Clients der Gruppe 1 haben.
Server: Das ist der Linux OVpn Server, dieser befindet sich mit den Client1 im selben lokalen Netzwerk
Howdy,
Also - jeder Rechner, der über VPN - VNC machen soll braucht ne static route zum VPN Client der ausserhalb steht.
Entweder einfach gleich die Interne IP des VPN Rechners als Gatewayadresse nehmen, und das VPN Subnetz komplett über das gateway routen.
Mach am Client im LAN in ner Admin-Console (cmd)
~# route add 10.8.0.0 MASK 255.255.255.0 <interne-vpn-server-ip> -p
Und dann ping mal die VPN! adresse eines externen vpn clients an. NICHT die LAN IP vom externen VPN client!!!
also vom LAN Client
~# ping 10.8.0.2
o.ä.
Du solltest ggf darauf achten, dass jeder client stets die selbe Openvpn - IP bekommt, sonst wirst verrückt ; )
Aber so sollte das zum testen erst mal reichen.
Greetz,
Kay
Also - jeder Rechner, der über VPN - VNC machen soll braucht ne static route zum VPN Client der ausserhalb steht.
Entweder einfach gleich die Interne IP des VPN Rechners als Gatewayadresse nehmen, und das VPN Subnetz komplett über das gateway routen.
Mach am Client im LAN in ner Admin-Console (cmd)
~# route add 10.8.0.0 MASK 255.255.255.0 <interne-vpn-server-ip> -p
Und dann ping mal die VPN! adresse eines externen vpn clients an. NICHT die LAN IP vom externen VPN client!!!
also vom LAN Client
~# ping 10.8.0.2
o.ä.
Du solltest ggf darauf achten, dass jeder client stets die selbe Openvpn - IP bekommt, sonst wirst verrückt ; )
Aber so sollte das zum testen erst mal reichen.
Greetz,
Kay
Hallo Kay,
hört sich gut an, werde ich sofort testen. Die OVpn Clients bekommen immer eine identische IP Adresse zugewiesen, die nach der ersten Verbindung dauerhaft hinterlegt werden.
Edit: Die Route hat leider nicht funktioniert.
C:\WINDOWS\system32>route ADD 10.8.0.0 MASK 255.255.255.0 10.8.0.1 -p
OK!
Oder muss die client-to-client in der server.conf zwingend wieder abgeändert werden? Das werde ich gleich noch mal selber testen.
hört sich gut an, werde ich sofort testen. Die OVpn Clients bekommen immer eine identische IP Adresse zugewiesen, die nach der ersten Verbindung dauerhaft hinterlegt werden.
Edit: Die Route hat leider nicht funktioniert.
Mach am Client im LAN in ner Admin-Console (cmd)
~# route add 10.8.0.0 MASK 255.255.255.0 <interne-vpn-server-ip> -p
~# route add 10.8.0.0 MASK 255.255.255.0 <interne-vpn-server-ip> -p
C:\WINDOWS\system32>route ADD 10.8.0.0 MASK 255.255.255.0 10.8.0.1 -p
OK!
Oder muss die client-to-client in der server.conf zwingend wieder abgeändert werden? Das werde ich gleich noch mal selber testen.
STOP!
die Route muss ja auf die LAN IP vom Server zeigen, doch nicht auf dessen VPN IP.
Der Server wird im LAN ja ne IP Adresse haben, wie die Clients auch (192.168.x.x)
DAS muss dein Gateway sein!
Nicht die 10.8.0.1 - die ist ja nicht im gleichen subnet wie der Client.
Merke - das GW muss der LAN-Rechner ja kennen, bzw. finden!
Sprich, der Server hat ne LAN IP - und ne VPN IP (ggf. manchmal auch direkt ne externe, oder DMZ, aber vernachlässigen wir das mal)
Der Server routet die VPN Netze/Kommunikation immer zur 10.8.0.1 rein/raus - und die LAN Kommunikation immer über die 192.168.x.y - wie auch immer die lautet.
Also route nomma löschen und das GW ändern ; )
die Route muss ja auf die LAN IP vom Server zeigen, doch nicht auf dessen VPN IP.
Der Server wird im LAN ja ne IP Adresse haben, wie die Clients auch (192.168.x.x)
DAS muss dein Gateway sein!
Nicht die 10.8.0.1 - die ist ja nicht im gleichen subnet wie der Client.
Merke - das GW muss der LAN-Rechner ja kennen, bzw. finden!
Sprich, der Server hat ne LAN IP - und ne VPN IP (ggf. manchmal auch direkt ne externe, oder DMZ, aber vernachlässigen wir das mal)
Der Server routet die VPN Netze/Kommunikation immer zur 10.8.0.1 rein/raus - und die LAN Kommunikation immer über die 192.168.x.y - wie auch immer die lautet.
Also route nomma löschen und das GW ändern ; )
Die interne LAN-IP steht mir gerade nicht zur Verfügung. Ich teste hier mit meinem Rechner, der nicht in dem Netz sich befindet. Bin über OpenVPN mit der Console des Servers nur verbunden. Alternativ könnte ich noch die GUI starten und entsprechend mit VNC drauf zugreifen.
Route gelöscht.
Route gelöscht.
Auf dem Server:
~# ifconfig
sollte dir die IPs des Servers ausgeben.
Btw: diese Route ist ausschließlich auf den Clients im LAN (dort wo der VPN server steht) nötig.
Greetz,
KAy
~# ifconfig
sollte dir die IPs des Servers ausgeben.
Btw: diese Route ist ausschließlich auf den Clients im LAN (dort wo der VPN server steht) nötig.
Greetz,
KAy
Das könnte ich heute Abend ggf. testen, was muss ansich dann für extern gemacht werden?
Komme definitiv noch nicht meinem Client auf einen anderen Client. Mein Client auf Server geht,.
Komme definitiv noch nicht meinem Client auf einen anderen Client. Mein Client auf Server geht,.
Hallo,
habe nun folgendes getestet jedoch noch ohne Erfolg.
Am Client, der auf andere Clients zugreifen soll.
Die anzupingenden Geräte selber sind lediglich VPN Router. Diese stellen eine Verbindung zum VPN Server her. Hintern den VPN Routern befindet sich in der Regel ein Gerät, welches angesprochen werden kann. In diesem Fall über eine 192.168.101.* IP Adresse. Diese Netzwerke sind im VPN Server entsprechend geroutet.
Es bleibt nach wie vor, auf dem Server selber gibt es keinerlei Probleme. Jedoch kann nur der Server die Clients ansprechend, nicht jedoch der Client die anderen Clients (Client -> Server geht selbstverständlich).
Wäre für weitere Ratschläge dankbar. Eventuell eine beispielhafte Konfiguration, bzw. Beispiel, welche Einstellungen in diesem Moment interessant/wichtig sind. Die server.conf hatte ich ja bereits im ersten Post gekürzt um die Kommentare sowie verschlüsseln/verschleiern der Routen.
habe nun folgendes getestet jedoch noch ohne Erfolg.
Am Client, der auf andere Clients zugreifen soll.
route ADD 10.8.0.0 MASK 255.255.255.0 192.168.2.103 -p
Wobei hier die *103 die feste IP Adresse des VPN Servers darstellt im internen Netzwerk.Die anzupingenden Geräte selber sind lediglich VPN Router. Diese stellen eine Verbindung zum VPN Server her. Hintern den VPN Routern befindet sich in der Regel ein Gerät, welches angesprochen werden kann. In diesem Fall über eine 192.168.101.* IP Adresse. Diese Netzwerke sind im VPN Server entsprechend geroutet.
Es bleibt nach wie vor, auf dem Server selber gibt es keinerlei Probleme. Jedoch kann nur der Server die Clients ansprechend, nicht jedoch der Client die anderen Clients (Client -> Server geht selbstverständlich).
Wäre für weitere Ratschläge dankbar. Eventuell eine beispielhafte Konfiguration, bzw. Beispiel, welche Einstellungen in diesem Moment interessant/wichtig sind. Die server.conf hatte ich ja bereits im ersten Post gekürzt um die Kommentare sowie verschlüsseln/verschleiern der Routen.
Okay.
Vorab:
Ein Router wird der VPN-Server sein, alle anderen Clients - ich kenne derzeit keine praktikable Möglichkeit ein VPN in physikalischer Netzform zu bilden, sondern immer den Stern, mit dem VPN-Server im Zentrum.
Firewallregeln lasse ich derzeit mal alle außer acht, den ohne die, bekommt man ja nicht mal das vpn aufgezogen, daher setze ich das als funktionierend gegeben voraus.
Folgendes ist essentiell:
1. Jedes Netz hinter einem VPN-Router sollte in einem anderen Subnet liegen, wenn die dahinter liegenden Clients miteinander kommunizieren können sollen.
Z.B. Im LAN des VPN Servers:
192.168.0.0 / 255.255.255.0
IP des VPN-Servers intern:
192.168.0.253
extern:
194.25.2.129 (Beispiel)
VPN Netz:
10.8.0.0 / 255.255.255.0
VPN-Server-IP
10.8.0.1 / 255.255.255.0
Außennetze: (lan netze hinder den anderen vpn routern/clients)
192.168.1.0 / 255.255.255.0
192.168.2.0 / 255.255.255.0
192.168.3.0 / 255.255.255.0
192.168.4.0 / 255.255.255.0
etc.
VPN-GW hat immer die .253 im entfernten Netz auf der LAN-Seite
2. Jeder Client hinter einem VPN Router(auch hinter den vpn clients), auf den zugegriffen werden soll, braucht die Route ins VPN-Netz 10.8.0.0
~# route add 10.8.0.0 MASK 255.255.255.0 <interne-vpn-gateway-ip> -p
Damit ist "nur" sichergestellt, dass sich einwählende Clients, die SELBST im 10-er netz sind eine Antwort erhalten.
Was du offenbar möchtest ist offenbar kein roadwarrior-zugang (was die einfachere variante wäre) d.h. genau DER rechner wählt sich ins vpn, auf den zugegriffen werden soll. (Host-to-Net) Sondern:
die Netze sollen gekoppelt werden (Net-to-net).
Dies setzt voraus, dass jeder vpn-Client (Gateway) eine Route in die übrigen netze bekommt.
Fasse zusammen: Der jeweilige Client hat sein standardgateway ins internet und braucht routen in die übrigen LANs über sein eigenes VPN GW.
Das VPN-GW macht die verbindung zum server und muss die übrigen LANs durch die 10.8er ip Routen
Der Server bekommt Pakete durchs VPN die an ein anderes LAN adressiert sind. daher braucht er ebenfalls Routen in die Außen-LANs - die fix mit den GW-adressen verdrahtet werden müssen: zurordnung von 192.168.X auf 10.8.0.X, 192.168.Y.0 auf 10.8.0.Y, etc
Schritt 1:
Clients benötigen Route in andere Netze über deren VPN-GW
(Wenn die Clients auch in das lan vom VPN Server sollen, einfach die Route nach 192.168.0.0 noch hinzufügen)
Z.B:
Clients in netz 192.168.1.0 so zu konfigurieren:
Route nach 192.168.2.0 / 255.255.255.0 / über GW 192.168.2.253 -p
Route nach 192.168.3.0 / 255.255.255.0 / über GW 192.168.3.253 -p
Route nach 192.168.4.0 / 255.255.255.0 / über GW 192.168.4.253 -p
Clients in netz 192.168.2.0 so zu konfigurieren:
Route nach 192.168.1.0 / 255.255.255.0 / über GW 192.168.1.253 -p
Route nach 192.168.3.0 / 255.255.255.0 / über GW 192.168.3.253 -p
Route nach 192.168.4.0 / 255.255.255.0 / über GW 192.168.4.253 -p
etc.
Schritt 2
### VPN GWs benötigen Routen über den VPN Server:
GW in netz 192.168.1.0 (also mit 192.168.1.253) so zu konfigurieren:
Route nach 192.168.2.0 / 255.255.255.0 / über GW 10.8.0.1 -p
Route nach 192.168.3.0 / 255.255.255.0 / über GW 10.8.0.1 -p
Route nach 192.168.4.0 / 255.255.255.0 / über GW 10.8.0.1 -p
etc.
Schritt 3
### VPN-Server benötigt Routen für die Clientnetze:
(Sinnvoll den VPN-Clients fixe zuordnungen fürs 10.8er netz zu verpassen, aber das ist n anderes thema - denn sonst stimmen diese routenzuordnungen iwann nicht mehr - aber das hier ist die zentrale konfiguration, da der vpn server alles handhaben muss.)
Route nach 192.168.1.0 / 255.255.255.0 / über GW 10.8.0.11 -p
Route nach 192.168.2.0 / 255.255.255.0 / über GW 10.8.0.12 -p
Route nach 192.168.3.0 / 255.255.255.0 / über GW 10.8.0.13 -p
Route nach 192.168.4.0 / 255.255.255.0 / über GW 10.8.0.14 -p
ENDE DER EINSTELLUNGEN
Jetzt solte jeder Client seine Gateways haben - und jedes Gateway die Routen zum Server und den übrigen Teilnetzen.
TESTING:
a. Reiss die Firewalls komplett auf zum testen, eigentlich würde ich eine geschlossene Umgebung vorschlagen, aber das ist halt nicht immer drinne.
b. Pinge zunächst von jeder beteiligten Node jede kürzeste Teilstrecke an, und anschließend die dahinter liegende Node.
z.b. vom 192.168.1.11 (client im Aussennetz 1)
ping auf die 192.168.1.253 (vpn gw)
ping auf die 10.8.0.11 (vpn-ip des eigenen GW) (nur wenn du die unter ZUSATZ genannten routen auch hast)
ping auf die 10.8.0.1 (vpn-ip des servers) (nur wenn du die unter ZUSATZ genannten routen auch hast)
ping auf die 192.168.0.X (irgendein host im Lan des VPN Servers, nur wenn du die Route nach 192.168.0.0 auch hast!)
ping auf die 10.8.0.12 (vpn-ip von aussen GW2 in netz 192.168.2.0) (nur wenn du die unter ZUSATZ genannten routen auch hast)
ping auf die 192.168.2.X (ping auf client in aussennetz 2)
c. wenn du pings an anfang durchbekommst und irgendwann nicht mehr, ist die strecke über di du ihn nicht mehr bekommst zu untersuchen.
d. dann geht man am besten auf die node wo es noch ging und pingt die node bei der es nicht mehr ging. - geht der ping hier durch, fehlt meist ne route, oder ist falsch konfiguriert (zahlendreher, o.ä), denn die nodes selbst sehen sich ja.
e. wenn alles geht, kannst du die routen in die 10.8er netze von den Clients auch wieder weg nehmen, da die vpn GWs ja eh alles unter sich über den vpn server routen. zum testen ist diese aber essentiell.
Zusatz:
die Regel CLIENT-TO-CLIENT besagt nicht die verbindung der entsprechenden Netze, sondern lediglich die Verbindung der Clients untereinander, die vom Server eine 10.8.0.0er IP bekommen haben.
Deshalb, wie bereits unter 2.:
Im Außennetz 1 auf den Clients:
~# route add 10.8.0.0 MASK 255.255.255.0 192.168.1.253 -p
In netz 2:
~# route add 10.8.0.0 MASK 255.255.255.0 192.168.2.253 -p
etc...
Grüße
Vorab:
Ein Router wird der VPN-Server sein, alle anderen Clients - ich kenne derzeit keine praktikable Möglichkeit ein VPN in physikalischer Netzform zu bilden, sondern immer den Stern, mit dem VPN-Server im Zentrum.
Firewallregeln lasse ich derzeit mal alle außer acht, den ohne die, bekommt man ja nicht mal das vpn aufgezogen, daher setze ich das als funktionierend gegeben voraus.
Folgendes ist essentiell:
1. Jedes Netz hinter einem VPN-Router sollte in einem anderen Subnet liegen, wenn die dahinter liegenden Clients miteinander kommunizieren können sollen.
Z.B. Im LAN des VPN Servers:
192.168.0.0 / 255.255.255.0
IP des VPN-Servers intern:
192.168.0.253
extern:
194.25.2.129 (Beispiel)
VPN Netz:
10.8.0.0 / 255.255.255.0
VPN-Server-IP
10.8.0.1 / 255.255.255.0
Außennetze: (lan netze hinder den anderen vpn routern/clients)
192.168.1.0 / 255.255.255.0
192.168.2.0 / 255.255.255.0
192.168.3.0 / 255.255.255.0
192.168.4.0 / 255.255.255.0
etc.
VPN-GW hat immer die .253 im entfernten Netz auf der LAN-Seite
2. Jeder Client hinter einem VPN Router(auch hinter den vpn clients), auf den zugegriffen werden soll, braucht die Route ins VPN-Netz 10.8.0.0
~# route add 10.8.0.0 MASK 255.255.255.0 <interne-vpn-gateway-ip> -p
Damit ist "nur" sichergestellt, dass sich einwählende Clients, die SELBST im 10-er netz sind eine Antwort erhalten.
Was du offenbar möchtest ist offenbar kein roadwarrior-zugang (was die einfachere variante wäre) d.h. genau DER rechner wählt sich ins vpn, auf den zugegriffen werden soll. (Host-to-Net) Sondern:
die Netze sollen gekoppelt werden (Net-to-net).
Dies setzt voraus, dass jeder vpn-Client (Gateway) eine Route in die übrigen netze bekommt.
Fasse zusammen: Der jeweilige Client hat sein standardgateway ins internet und braucht routen in die übrigen LANs über sein eigenes VPN GW.
Das VPN-GW macht die verbindung zum server und muss die übrigen LANs durch die 10.8er ip Routen
Der Server bekommt Pakete durchs VPN die an ein anderes LAN adressiert sind. daher braucht er ebenfalls Routen in die Außen-LANs - die fix mit den GW-adressen verdrahtet werden müssen: zurordnung von 192.168.X auf 10.8.0.X, 192.168.Y.0 auf 10.8.0.Y, etc
Schritt 1:
Clients benötigen Route in andere Netze über deren VPN-GW
(Wenn die Clients auch in das lan vom VPN Server sollen, einfach die Route nach 192.168.0.0 noch hinzufügen)
Z.B:
Clients in netz 192.168.1.0 so zu konfigurieren:
Route nach 192.168.2.0 / 255.255.255.0 / über GW 192.168.2.253 -p
Route nach 192.168.3.0 / 255.255.255.0 / über GW 192.168.3.253 -p
Route nach 192.168.4.0 / 255.255.255.0 / über GW 192.168.4.253 -p
Clients in netz 192.168.2.0 so zu konfigurieren:
Route nach 192.168.1.0 / 255.255.255.0 / über GW 192.168.1.253 -p
Route nach 192.168.3.0 / 255.255.255.0 / über GW 192.168.3.253 -p
Route nach 192.168.4.0 / 255.255.255.0 / über GW 192.168.4.253 -p
etc.
Schritt 2
### VPN GWs benötigen Routen über den VPN Server:
GW in netz 192.168.1.0 (also mit 192.168.1.253) so zu konfigurieren:
Route nach 192.168.2.0 / 255.255.255.0 / über GW 10.8.0.1 -p
Route nach 192.168.3.0 / 255.255.255.0 / über GW 10.8.0.1 -p
Route nach 192.168.4.0 / 255.255.255.0 / über GW 10.8.0.1 -p
etc.
Schritt 3
### VPN-Server benötigt Routen für die Clientnetze:
(Sinnvoll den VPN-Clients fixe zuordnungen fürs 10.8er netz zu verpassen, aber das ist n anderes thema - denn sonst stimmen diese routenzuordnungen iwann nicht mehr - aber das hier ist die zentrale konfiguration, da der vpn server alles handhaben muss.)
Route nach 192.168.1.0 / 255.255.255.0 / über GW 10.8.0.11 -p
Route nach 192.168.2.0 / 255.255.255.0 / über GW 10.8.0.12 -p
Route nach 192.168.3.0 / 255.255.255.0 / über GW 10.8.0.13 -p
Route nach 192.168.4.0 / 255.255.255.0 / über GW 10.8.0.14 -p
ENDE DER EINSTELLUNGEN
Jetzt solte jeder Client seine Gateways haben - und jedes Gateway die Routen zum Server und den übrigen Teilnetzen.
TESTING:
a. Reiss die Firewalls komplett auf zum testen, eigentlich würde ich eine geschlossene Umgebung vorschlagen, aber das ist halt nicht immer drinne.
b. Pinge zunächst von jeder beteiligten Node jede kürzeste Teilstrecke an, und anschließend die dahinter liegende Node.
z.b. vom 192.168.1.11 (client im Aussennetz 1)
ping auf die 192.168.1.253 (vpn gw)
ping auf die 10.8.0.11 (vpn-ip des eigenen GW) (nur wenn du die unter ZUSATZ genannten routen auch hast)
ping auf die 10.8.0.1 (vpn-ip des servers) (nur wenn du die unter ZUSATZ genannten routen auch hast)
ping auf die 192.168.0.X (irgendein host im Lan des VPN Servers, nur wenn du die Route nach 192.168.0.0 auch hast!)
ping auf die 10.8.0.12 (vpn-ip von aussen GW2 in netz 192.168.2.0) (nur wenn du die unter ZUSATZ genannten routen auch hast)
ping auf die 192.168.2.X (ping auf client in aussennetz 2)
c. wenn du pings an anfang durchbekommst und irgendwann nicht mehr, ist die strecke über di du ihn nicht mehr bekommst zu untersuchen.
d. dann geht man am besten auf die node wo es noch ging und pingt die node bei der es nicht mehr ging. - geht der ping hier durch, fehlt meist ne route, oder ist falsch konfiguriert (zahlendreher, o.ä), denn die nodes selbst sehen sich ja.
e. wenn alles geht, kannst du die routen in die 10.8er netze von den Clients auch wieder weg nehmen, da die vpn GWs ja eh alles unter sich über den vpn server routen. zum testen ist diese aber essentiell.
Zusatz:
die Regel CLIENT-TO-CLIENT besagt nicht die verbindung der entsprechenden Netze, sondern lediglich die Verbindung der Clients untereinander, die vom Server eine 10.8.0.0er IP bekommen haben.
Deshalb, wie bereits unter 2.:
Im Außennetz 1 auf den Clients:
~# route add 10.8.0.0 MASK 255.255.255.0 192.168.1.253 -p
In netz 2:
~# route add 10.8.0.0 MASK 255.255.255.0 192.168.2.253 -p
etc...
Grüße
Sollte das nun zu kompliziert oder zuviel des guten gewesen sein, kann ich auch gern - sofern es sich um private Infrastruktur handelt - Support via Fernwartung anbieten.
