8
Zugriff aus dem LAN auf VPN Clients
Hallo,
ich hoffe es lässt sich soweit verständlich erklären.
Gegeben ist ein LANCom Router (192.168.99.1). An diesem hängen über einen Switch diverse Arbeitsplätze. In diesem Netz aus Arbeitsplätzen befindet sich ua. auch ein Linux Server (192.168.99.103), der einige VPN Verbindungen als Server verwaltet, sowie auch als VPN Client fungiert.
Die Clients, welches unser Linux Server als Server managed, kann ich soweit von jedem Arbeitsplatz über entsprechende Routen erreichen.
Nun habe ich aber ein Netzwerk, dass des VPN Clients, welches ich ebenfall an den Arbeitsplätzen zur Verfügung stellen würde. Die Clients werden mit 10.2.x.x angesprochen. Die Route habe ich Lancom hinterlegt.
IP-Adresse
10.2.0.0
Netzmaske
255.255.0.0
Router
192.168.99.103
Mache ich nun von einem Arbeitsplatzrechner einen trace, so kann ich sehen, dass die Adressbereich von 10.2.x.x an den Linux Server (192.168.99.103) weitergeleitet werden. Dann ist jedoch Schluss.
Routenverfolgung zu 10.2.35.15
1 1 ms <1 ms <1 ms Lancom.intern [192.168.99.1]
2 1 ms <1 ms 1 ms LinuxServer [192.168.99.103]
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.
In der Routingtabelle (netstat -nr) werden mir diverse Geräte aus dem 10.2.x.x Netz angezeigt.
Ziel 10.2.13.15
Router 172.99.0.77
Genmask 255.255.255.255
Flag UGH
Es erfolgt jedoch keine Weiterleitung scheinbar zum Endgerät. Greife ich über den Linuxserver auf die Dienste hinter den 10.2.x.x zu, funktioniert da. Lediglich aber nicht der Zugriff von der Arbeitsplätzen. Weiß einer Rat, ob noch etwas gesetzt werden muss?
Falls euch noch Infos fehlen, einfahc bescheid geben.
Gruß Stefan
ich hoffe es lässt sich soweit verständlich erklären.
Gegeben ist ein LANCom Router (192.168.99.1). An diesem hängen über einen Switch diverse Arbeitsplätze. In diesem Netz aus Arbeitsplätzen befindet sich ua. auch ein Linux Server (192.168.99.103), der einige VPN Verbindungen als Server verwaltet, sowie auch als VPN Client fungiert.
Die Clients, welches unser Linux Server als Server managed, kann ich soweit von jedem Arbeitsplatz über entsprechende Routen erreichen.
Nun habe ich aber ein Netzwerk, dass des VPN Clients, welches ich ebenfall an den Arbeitsplätzen zur Verfügung stellen würde. Die Clients werden mit 10.2.x.x angesprochen. Die Route habe ich Lancom hinterlegt.
IP-Adresse
10.2.0.0
Netzmaske
255.255.0.0
Router
192.168.99.103
Mache ich nun von einem Arbeitsplatzrechner einen trace, so kann ich sehen, dass die Adressbereich von 10.2.x.x an den Linux Server (192.168.99.103) weitergeleitet werden. Dann ist jedoch Schluss.
Routenverfolgung zu 10.2.35.15
1 1 ms <1 ms <1 ms Lancom.intern [192.168.99.1]
2 1 ms <1 ms 1 ms LinuxServer [192.168.99.103]
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.
In der Routingtabelle (netstat -nr) werden mir diverse Geräte aus dem 10.2.x.x Netz angezeigt.
Ziel 10.2.13.15
Router 172.99.0.77
Genmask 255.255.255.255
Flag UGH
Es erfolgt jedoch keine Weiterleitung scheinbar zum Endgerät. Greife ich über den Linuxserver auf die Dienste hinter den 10.2.x.x zu, funktioniert da. Lediglich aber nicht der Zugriff von der Arbeitsplätzen. Weiß einer Rat, ob noch etwas gesetzt werden muss?
Falls euch noch Infos fehlen, einfahc bescheid geben.
Gruß Stefan
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: 347096
Url: https://administrator.de/forum/zugriff-aus-dem-lan-auf-vpn-clients-347096.html
Ausgedruckt am: 23.12.2024 um 16:12 Uhr
8 Kommentare
Neuester Kommentar
Hallo,
Gruß,
Peter
Zitat von @sschultewolter:
Lediglich aber nicht der Zugriff von der Arbeitsplätzen. Weiß einer Rat, ob noch etwas gesetzt werden muss?
Was sagt dein Logging vom Lancom? Mal geschaut warum der Lancom das nicht erlaubt?Lediglich aber nicht der Zugriff von der Arbeitsplätzen. Weiß einer Rat, ob noch etwas gesetzt werden muss?
Gruß,
Peter
Hallo Peter,
danke vorab für die Rückmeldung.
Der Lancom ist meiner Meinung nach korrekt an dieser Stelle eingestellt, bzw. er blockiert den Zugriff nicht. Aus dem Trace geht ja hervor, dass er bis zum Linux Server bereits kommt.
danke vorab für die Rückmeldung.
Der Lancom ist meiner Meinung nach korrekt an dieser Stelle eingestellt, bzw. er blockiert den Zugriff nicht. Aus dem Trace geht ja hervor, dass er bis zum Linux Server bereits kommt.
Hallo,
Du redest von einen (1) Linux server mit der IP 192.168.99.103. jetzt hast du wohl noch Clients aus einem 10.2.0.0/16er Netz welche auch versuchen diesen Linux Rechner zu erreichen? Richtig? Dieser Linux nimmt Pakete vom 10.2.0.0/16 Nezu an und kennt auch die Rückroute bzw. dein LanCom kennt ebebfalls alle Routen? Male doch mal auf ein Blatt Paier dir alle involvierten geräte auf, schreibe dir richtigen IPs und GWs und DNS zu den jeweilig genutzten Port. Dann sollte Klarheit herrschen wer wimt wemm wann Reden und auch die Antwort verstehen muss.
Gruß,
Peter
Du redest von einen (1) Linux server mit der IP 192.168.99.103. jetzt hast du wohl noch Clients aus einem 10.2.0.0/16er Netz welche auch versuchen diesen Linux Rechner zu erreichen? Richtig? Dieser Linux nimmt Pakete vom 10.2.0.0/16 Nezu an und kennt auch die Rückroute bzw. dein LanCom kennt ebebfalls alle Routen? Male doch mal auf ein Blatt Paier dir alle involvierten geräte auf, schreibe dir richtigen IPs und GWs und DNS zu den jeweilig genutzten Port. Dann sollte Klarheit herrschen wer wimt wemm wann Reden und auch die Antwort verstehen muss.
Gruß,
Peter
Hallo Stefan,
3 Subnetze, kürze ab :
L = LanCom ( 192.168.99/24 ),
S = Linux Vpn-Server ( irrelevant ),
C = Linux Vpn-Client ( 10.2/16 ).
Host :
X = Linux
In 'C' fehlt vielleicht die Route nach 'L' über das Portal 'C.X'
( z.B. in openVpn über 'client-to-client', 'route ...' und 'push "route ..."', muss aber natürlich auf dem Server von 'C' eingerichtet werden ).
Hypothese überprüfen mit 'ping -I ... ...' ( interface nach 'L' entsprechend 'ifconfig' ) auf dem Linux-Rechner.
Grüße
3 Subnetze, kürze ab :
L = LanCom ( 192.168.99/24 ),
S = Linux Vpn-Server ( irrelevant ),
C = Linux Vpn-Client ( 10.2/16 ).
Host :
X = Linux
In 'C' fehlt vielleicht die Route nach 'L' über das Portal 'C.X'
( z.B. in openVpn über 'client-to-client', 'route ...' und 'push "route ..."', muss aber natürlich auf dem Server von 'C' eingerichtet werden ).
Hypothese überprüfen mit 'ping -I ... ...' ( interface nach 'L' entsprechend 'ifconfig' ) auf dem Linux-Rechner.
Grüße
Hallo,
die Clients aus dem 10.2.0.0/16 Netz will ich erreichen. Die Clients in diesem Netz bauen selber zu mir keine Verbindung auf. Auf den Clients befinden sich lediglich Geräte mit einem VNC Server.
Der Linux Recher baut als Client eine Verbindung zu einem externen Server auf, den wir nicht verwalten. Ich erhalte von diesem folgende IP Adresse zugeteilt.
Dieser stellt dann über diese Schnittstelle die Clients aus dem 10.2.x.x Netz zur Verfügung. Wenn diese Schnittstelle aufgebaut ist, sollen auch alle Anfragen von den Arbeitsplatz Rechnern vom Lancom an 10.2.xx.xx über den Linux Server weitergeleitet werden.
Eine Skizze müsste ich nachher per Hand anfertigen.
die Clients aus dem 10.2.0.0/16 Netz will ich erreichen. Die Clients in diesem Netz bauen selber zu mir keine Verbindung auf. Auf den Clients befinden sich lediglich Geräte mit einem VNC Server.
Der Linux Recher baut als Client eine Verbindung zu einem externen Server auf, den wir nicht verwalten. Ich erhalte von diesem folgende IP Adresse zugeteilt.
tun1 Link encap:UNSPEC Hardware Adresse
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet Adresse:172.16.0.78 P-z-P:172.16.0.77 Maske:255.255.255.255
UP PUNKTZUPUNKT RUNNING NOARP MULTICAST MTU:1500 Metrik:1
RX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
TX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:100
RX-Bytes:0 (0.0 B) TX-Bytes:0 (0.0 B)Dieser stellt dann über diese Schnittstelle die Clients aus dem 10.2.x.x Netz zur Verfügung. Wenn diese Schnittstelle aufgebaut ist, sollen auch alle Anfragen von den Arbeitsplatz Rechnern vom Lancom an 10.2.xx.xx über den Linux Server weitergeleitet werden.
Eine Skizze müsste ich nachher per Hand anfertigen.
Hallo Stefan,
OK, neue Informationen :
C = Linux Vpn-Client Tunnel ( 172.16.0.78 p2p ),
D = Linux Vpn-Client Zielnetz ( 10.2/16 ),
beides nicht in Deinem Einflussbereich.
Dann Linux-Kiste zum NAT-Router machen, in der Art
'iptables -t nat -A POSTROUTING -o tun0 -d 10.2/16 -j SNAT --to 172.16.0.78'.
Grüße
OK, neue Informationen :
C = Linux Vpn-Client Tunnel ( 172.16.0.78 p2p ),
D = Linux Vpn-Client Zielnetz ( 10.2/16 ),
beides nicht in Deinem Einflussbereich.
Dann Linux-Kiste zum NAT-Router machen, in der Art
'iptables -t nat -A POSTROUTING -o tun0 -d 10.2/16 -j SNAT --to 172.16.0.78'.
Grüße
vertippt :
-o tun1
-o tun1
Spannend wäre mal zu erfahren welches Routing Protokoll verwendet wird ??
Normalerweise ist es vollkommener Unsinn das man für jeden Client eine Route eintragen muss. Das zeigt eigentlich das hier ein Fehlkonfiguartion des VPN Netzes oder der IP Adressierung vorliegt.
Die recht oberflächliche Beschreibung des VPNs hört sich etwas nach OpenVPN an und das das OpenVPN Netz bzw. die Server Konfig mit dem internen OpenVPN Netzwerk 10.2.0.0 /16 arbeitet also das Kommando server 10.2.0.0 255.255.0.0 konfiguriert hat.
Essentiell ist dann ebenso das Kommando push "route 192.168.99.0 255.255.255.0" in der Konfig das das lokale Netz automatisch an die VPN Clients in deren Routing Tabelle überträgt.
Ebenso zwingend ist eine statische Route:
ip route 10.2.0.0 255.255.0.0 <lan_ip_adr_VPN-Server>
Niemals sollte der VPN Server irgendeine Art von NAT machen, das ist vollkommen überflüssig, kostet sinnlose Performance und ist letztlich kontraproduktiv da es die IP Konfig unübersichtlich macht. Probleme im transparenten Routing durch das NAT mal gar nicht betrachtet.
Vergiss also bitte diesen Unsinn mit NAT im VPN Server !!
Sofern das also alles so eigerichtet ist kannst du das korrekte Routing in den Clients checken indem du dir bei aktivem VPN einmal die Routing Tabbele mit route print (Winblows) ansiehst.
Dort solltest du Einträge sowohl für das 192.168.99.0 /24 und das 10.2.0.0. /16 Netz finden.
Ist das der Fall und stimmt die statische Route auf dem Lancom dann sollten die Clients alles im lokalen .99.0er Netz erreichen können.
Wenn es kneift, dann liegt es einzig und allein nur an der lokalen Firewall von Winblows. Denke immer daran das das VPN Netz über einen virtulenn Netzwerk Adapter abgewickelt wird der ebenfalls Firewall Regeln unterworfen ist.
Das OpenVPN Interface dekalriert die Win Firewall durch das fehlende Gateway imm Auto Erkennungs Modus immer als öffentliches Netz und macht daher dann dort ALLE Schotten dicht.
Du musst also zwangsweise die interne Firewallder Clients immer entsprechend anpassen das dort Zugriffe aus dem 192.168.99er <netz usw. erlaubt sind. Entsprechend auch ICMP erlauben was den Ping anbetrifft.
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Wenn du all das beachtest funktioniert das auch fehlerlos.
Normalerweise ist es vollkommener Unsinn das man für jeden Client eine Route eintragen muss. Das zeigt eigentlich das hier ein Fehlkonfiguartion des VPN Netzes oder der IP Adressierung vorliegt.
Die recht oberflächliche Beschreibung des VPNs hört sich etwas nach OpenVPN an und das das OpenVPN Netz bzw. die Server Konfig mit dem internen OpenVPN Netzwerk 10.2.0.0 /16 arbeitet also das Kommando server 10.2.0.0 255.255.0.0 konfiguriert hat.
Essentiell ist dann ebenso das Kommando push "route 192.168.99.0 255.255.255.0" in der Konfig das das lokale Netz automatisch an die VPN Clients in deren Routing Tabelle überträgt.
Ebenso zwingend ist eine statische Route:
ip route 10.2.0.0 255.255.0.0 <lan_ip_adr_VPN-Server>
Niemals sollte der VPN Server irgendeine Art von NAT machen, das ist vollkommen überflüssig, kostet sinnlose Performance und ist letztlich kontraproduktiv da es die IP Konfig unübersichtlich macht. Probleme im transparenten Routing durch das NAT mal gar nicht betrachtet.
Vergiss also bitte diesen Unsinn mit NAT im VPN Server !!
Sofern das also alles so eigerichtet ist kannst du das korrekte Routing in den Clients checken indem du dir bei aktivem VPN einmal die Routing Tabbele mit route print (Winblows) ansiehst.
Dort solltest du Einträge sowohl für das 192.168.99.0 /24 und das 10.2.0.0. /16 Netz finden.
Ist das der Fall und stimmt die statische Route auf dem Lancom dann sollten die Clients alles im lokalen .99.0er Netz erreichen können.
Wenn es kneift, dann liegt es einzig und allein nur an der lokalen Firewall von Winblows. Denke immer daran das das VPN Netz über einen virtulenn Netzwerk Adapter abgewickelt wird der ebenfalls Firewall Regeln unterworfen ist.
Das OpenVPN Interface dekalriert die Win Firewall durch das fehlende Gateway imm Auto Erkennungs Modus immer als öffentliches Netz und macht daher dann dort ALLE Schotten dicht.
Du musst also zwangsweise die interne Firewallder Clients immer entsprechend anpassen das dort Zugriffe aus dem 192.168.99er <netz usw. erlaubt sind. Entsprechend auch ICMP erlauben was den Ping anbetrifft.
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Wenn du all das beachtest funktioniert das auch fehlerlos.
