8
An Linux Rechner durchrouten
Hallo,
ich habe hier einen Lancom, der als Hauptrouter/Modem dient. Nun möchte ich, dass ein entsprechender IP-Bereich an einen weiteren "Router" durchgeleitet wird. Hierbei handelt es sich um einen kleinen Linux Rechner (Linux Mint Ubuntu).
Auf diesem läuft ein VPN Server. Der Linux Rechner ist selbst wie auch der Lancom Router im Hauptnetz 192.168.99.xxx. Nun soll im 192.168.99.xx Netzwerk auch die IP-Adressen bzw. die dahinterliegenden Protokolle ansprechbar sein.
Ich habe im Lancom Router unter IP-Router -> Routing bereits die Route wie folgt eingerichtet
Mit einem tracert aus dem 192.168.99.xx Netz habe ich bereits herausgefunden, dass der Linux Rechner angesprochen wird. Weiter komme ich aber nicht.
Explizit geht es mir darum, dass ich aus dem Firmennetzwerk auf diverse VNC-Server zugreifen kann, die sich über VPN mit dem Linux Rechner verbinden.
ich habe hier einen Lancom, der als Hauptrouter/Modem dient. Nun möchte ich, dass ein entsprechender IP-Bereich an einen weiteren "Router" durchgeleitet wird. Hierbei handelt es sich um einen kleinen Linux Rechner (Linux Mint Ubuntu).
Auf diesem läuft ein VPN Server. Der Linux Rechner ist selbst wie auch der Lancom Router im Hauptnetz 192.168.99.xxx. Nun soll im 192.168.99.xx Netzwerk auch die IP-Adressen bzw. die dahinterliegenden Protokolle ansprechbar sein.
Ich habe im Lancom Router unter IP-Router -> Routing bereits die Route wie folgt eingerichtet
IP-Adresse: 192.170.0.0
Subnetz: 255.255.0.0
Routing-Tag: 0
Subnetz: 255.255.0.0
Routing-Tag: 0
Router: 192.168.99.103 (ist der Linux Rechner)
Distanz: 0
Distanz: 0
Mit einem tracert aus dem 192.168.99.xx Netz habe ich bereits herausgefunden, dass der Linux Rechner angesprochen wird. Weiter komme ich aber nicht.
C:\Users\Stefan>tracert 192.170.0.6
Routenverfolgung zu 192.170.0.6 über maximal 30 Hops
1 <1 ms <1 ms <1 ms LC_Berges.intern [192.168.99.1]
2 1 ms <1 ms <1 ms GFE-MINI [192.168.99.103]
2 1 ms <1 ms <1 ms GFE-MINI [192.168.99.103]
Explizit geht es mir darum, dass ich aus dem Firmennetzwerk auf diverse VNC-Server zugreifen kann, die sich über VPN mit dem Linux Rechner verbinden.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 371297
Url: https://administrator.de/contentid/371297
Printed on: April 19, 2024 at 21:04 o'clock
8 Comments
Latest comment
Hallo,
Der IP Adressenbereich 192.170.0.0 /22 gehört der Firma Hewlett Packard! Das ist kein Privater Bereich!
Und wozu brauchst du im Privaten Umfeld ein /16er Netz??
Du solltest dir über dein Netzdesign noch mal Gedanken machen!
Brammer
IP-Adresse: 192.170.0.0
Subnetz: 255.255.0.0
Routing-Tag: 0
Subnetz: 255.255.0.0
Routing-Tag: 0
Der IP Adressenbereich 192.170.0.0 /22 gehört der Firma Hewlett Packard! Das ist kein Privater Bereich!
Und wozu brauchst du im Privaten Umfeld ein /16er Netz??
Du solltest dir über dein Netzdesign noch mal Gedanken machen!
Brammer
Moin,
Zum IP-Netz hat Braamer ja schon etwas geschrieben.
Warum lässt du den VPN-Tunnel nicht am Lancom terminieren, erstellst dort ein zweites Netz, in dem dann dein noch zu korrigierendes 192.170.0.0/16er Netz hängt?
Weniger Fehlerquellen und eine höhere Sicherheit, da nicht irgendwelche Ports geöffnet werden müssen
Gruß
em-pie
Zum IP-Netz hat Braamer ja schon etwas geschrieben.
Warum lässt du den VPN-Tunnel nicht am Lancom terminieren, erstellst dort ein zweites Netz, in dem dann dein noch zu korrigierendes 192.170.0.0/16er Netz hängt?
Weniger Fehlerquellen und eine höhere Sicherheit, da nicht irgendwelche Ports geöffnet werden müssen
Gruß
em-pie
Routing Grundlagen erklärt auch dieses Foren Tutorial:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Bzw. das Design in Verbindung mit einem VPN Tunnel ist hier nochmal im Detail erklärt:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Letztlich hat Kollege em-pie aber Recht. Aus Sicherheitssicht ist es ja vollkommen unnötig ein Loch in die Lancom Firewall zu bohren und Traffic aus dem Internet ungeschützt auf ein internes Device forzuwarden wo der Lancom ja schon einen VPN Server gleich von sich aus an Bord hat.
Dort kann man z.B. denn kostenfreien Klassiker Shrew_VPN_Client verwenden für den VPN Zugriff ohne noch weitere Hardware ins Netzwerk zu integrieren.
Den Client gibt es für alle erdenklichen Plattformen. Bzw. Alternativ die onboard Clients.
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Bzw. das Design in Verbindung mit einem VPN Tunnel ist hier nochmal im Detail erklärt:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Letztlich hat Kollege em-pie aber Recht. Aus Sicherheitssicht ist es ja vollkommen unnötig ein Loch in die Lancom Firewall zu bohren und Traffic aus dem Internet ungeschützt auf ein internes Device forzuwarden wo der Lancom ja schon einen VPN Server gleich von sich aus an Bord hat.
Dort kann man z.B. denn kostenfreien Klassiker Shrew_VPN_Client verwenden für den VPN Zugriff ohne noch weitere Hardware ins Netzwerk zu integrieren.
Den Client gibt es für alle erdenklichen Plattformen. Bzw. Alternativ die onboard Clients.
Moin,
Abgesehen von der IP-Netz-Problematik:
Du bist in Deinen Angaben so unspezifisch, daß wir hier nur raten können.
lks
Abgesehen von der IP-Netz-Problematik:
- Stimmt denn dss Routing und IP-Forwarding auf dem LinuxRechner und der VPN-Gegenstelle?
- Ist da auch nirgendwo ein NAT dazwischen? Denn sonst müssten sich zwei VPN-Server eine IP-Adresse teilen, was nur dann funktioniert, wenn sie verschiedene VPN-Protokolle benutzen.
- Lassen die Firewalls auch die richtigen Protokolle durch?
Du bist in Deinen Angaben so unspezifisch, daß wir hier nur raten können.
lks
Hallo, ich versuchs noch einmal etwas genauer zu beschreiben.
Vorab, hatte ich nicht mehr im Kopf, dass das Klasse C Netz nur auf 192.x.x.x beschränkt ist. Das 192.er Netzwerk ist schon relativ voll. Etwas Platz findet sich da noch, aber meist nur kleinere Adressbereiche. Wundert mich nur, dass sich die Telekom selbst auch für interne Einstellung darin nicht so ganz hält.
Das mit den ~65k Adressen /16 ist bereits verworfen. Habe nun das ganze so, dass ich die ipp.txt statisch angelegt habe mit Schreibschutz. Nun bezieht jeder Client seine Adresse aus dieser Liste.
Wie das genau im Lancom mit dem Terminieren gemeint ist, muss ich erst einmal schauen. Der Router wurde vor 2 Jahren von der Telekom fürs M2M System errichtet. Haben dort nur wenige Einstellung selber ändern müssen.
@aqui: Aussage Telekom war damals, es kann nur ein VPN System auf dem Router laufen. Fürs M2M System wird hierfür soweit richtig gesehen IPSec genutzt. Die Geräte im VPN Netzwerk sind keine Desktop Rechner, Smartphone o.ä. Dort sind VPN Router verbaut, an denen Automatisierungssteuerung angeschlossen sind. Nur Zuschauermodus.
Vorab, hatte ich nicht mehr im Kopf, dass das Klasse C Netz nur auf 192.x.x.x beschränkt ist. Das 192.er Netzwerk ist schon relativ voll. Etwas Platz findet sich da noch, aber meist nur kleinere Adressbereiche. Wundert mich nur, dass sich die Telekom selbst auch für interne Einstellung darin nicht so ganz hält.
Das mit den ~65k Adressen /16 ist bereits verworfen. Habe nun das ganze so, dass ich die ipp.txt statisch angelegt habe mit Schreibschutz. Nun bezieht jeder Client seine Adresse aus dieser Liste.
Wie das genau im Lancom mit dem Terminieren gemeint ist, muss ich erst einmal schauen. Der Router wurde vor 2 Jahren von der Telekom fürs M2M System errichtet. Haben dort nur wenige Einstellung selber ändern müssen.
@aqui: Aussage Telekom war damals, es kann nur ein VPN System auf dem Router laufen. Fürs M2M System wird hierfür soweit richtig gesehen IPSec genutzt. Die Geräte im VPN Netzwerk sind keine Desktop Rechner, Smartphone o.ä. Dort sind VPN Router verbaut, an denen Automatisierungssteuerung angeschlossen sind. Nur Zuschauermodus.
Du solltest weniger von dem Zeug nehmen, das Dich so wirr reden läßt. Du machst es nur noch verwirrender.
Dir RFC1918-Bereiche sind klar definiert (u.a.):
- 192.168.0.0/16
- 172.16.0.0/12
- 10.0.0.0/8
Diese darfst Du nach Belieben aufteilen und verteilen, solange Du Dich nciht mit andern privaten Netzen verbindest und an Deinen Netzgrenzen zum Internet nicht durchläßt (NAT oder blockieren). Üblicherweise macht man das in /24 oder in /16-Blöcken, je nach lokalen Gegebenheiten.
Ob die Telekom selber die RFC1918-Bereiche nutzt oder nicht ist unerheblich, das macht jeder Provider. Die schotten das aber normalerweise vor dem Kunden ab.
Du solltest erstmal einen Netzplan mit IP-Adressen/Netzen und den Knotenpunkten zeichnen, daß wir erstmal überhaupt eine vorstellugn haben, was bei Dir vor ort los ist.
lks
Hoffe das ist so gemeint. Vielleicht noch die Erklärung dazu.
Die Geräte am Lancom nutzen alle die IP-Adressen 192.168.99.x. Auf dem Linux-PC befindet sich der OpenVPN Server mit der Adresse 10.0.0.1.
Die VPN Clients befinden sich ausserhalb des internen Hardware-Netzes. Diese bauen eine Verbindung zum VPN Server auf. Das funktioniert auch soweit schon. Vergeben werden die Adressen 10.0.0.6, 10, .... Im internen Netz, also PC1 und PC2 kann ich auf diese 10er Adressen bereits zugreifen.
Nun versuche ich, dass der Punkt (unten links) auf die Öffentliche IP-Adresse:Port auf einen VPN Client zugreifen kann.
Im Lancom habe ich bereits unter Konfiguration > IP-Router > Masikerung > Portforwarding einen Eintrag gemacht.
Port 6000TCP an Intranet Adresse 192.168.99.3 mit Port 60000TCP.
Auf dem Linux-Rechner habe ich ein PREROUTING aktiv.
Wobei diese Einstellung würde ich lieber im Lancom hinterlegen, wenn das möglich ist.
Nachtrag: Dem Lancom scheint das 10.0.1.x Netz nicht bekannt zu sein. Habe gerade mit dem LanMonitor versucht auf diese Adresse einen Ping abzusetzen
Die Geräte am Lancom nutzen alle die IP-Adressen 192.168.99.x. Auf dem Linux-PC befindet sich der OpenVPN Server mit der Adresse 10.0.0.1.
Die VPN Clients befinden sich ausserhalb des internen Hardware-Netzes. Diese bauen eine Verbindung zum VPN Server auf. Das funktioniert auch soweit schon. Vergeben werden die Adressen 10.0.0.6, 10, .... Im internen Netz, also PC1 und PC2 kann ich auf diese 10er Adressen bereits zugreifen.
Nun versuche ich, dass der Punkt (unten links) auf die Öffentliche IP-Adresse:Port auf einen VPN Client zugreifen kann.
Im Lancom habe ich bereits unter Konfiguration > IP-Router > Masikerung > Portforwarding einen Eintrag gemacht.
Port 6000TCP an Intranet Adresse 192.168.99.3 mit Port 60000TCP.
Auf dem Linux-Rechner habe ich ein PREROUTING aktiv.
iptables -t nat -A PREROUTING -p tcp --dport 60000 -j DNAT --to-destination 10.0.1.6:1000
Wobei diese Einstellung würde ich lieber im Lancom hinterlegen, wenn das möglich ist.
Nachtrag: Dem Lancom scheint das 10.0.1.x Netz nicht bekannt zu sein. Habe gerade mit dem LanMonitor versucht auf diese Adresse einen Ping abzusetzen
dass das Klasse C Netz
"Klassen" gibt es schon lange nicht mehr in IP Netzen. Das sind Uralt Begriffe aus der Steinzeit die kein Mensch mehr benutzt.Seit 1993 mit der Einführung von CIDR sind diese dümmlichen "Klassen" damit Geschichte:
https://de.wikipedia.org/wiki/Classless_Inter-Domain_Routing
Das sollte man als Netzwerker aber langsam endlich mal wissen !!
Zurück zum Thema...
dass das Klasse C Netz nur auf 192.x.x.x beschränkt ist.
Ist damit dann natürlich völliger (IP) Quatsch wie du hoffentlich jetzt mal selber siehst ! Zeigt aber auch das dir das Thema IP Adressierung wohl nicht wirklich geläufig ist. Routing vermutlich noch weniger... 
uch für interne Einstellung darin nicht so ganz hält.
Im Gegensatz zu dir weiss die Telekom was CIDR ist !dass ich die ipp.txt statisch angelegt habe mit Schreibschutz. Nun bezieht jeder Client seine Adresse aus dieser Liste.
Dann sag uns aber auch das du OpenVPN als VPN nutzt ! So müssen wir nicht raten und können zielgerichtet helfen !Die VPN Clients befinden sich ausserhalb des internen Hardware-Netzes.
Wie das ja nun mal so üblich ist bei jeder beliebigen, millionfachen VPN Implementation ! Ein simpler Klassiker also.Vergeben werden die Adressen 10.0.0.6, 10, ....
Nicht besonders Intelligent dieses IP Netz zu verwenden. Ist der Client mit der Adresse mal in einem Netz was auch die 10.0.0.0 hat (was sicher wegen der Banalität nicht selten ist) dann ists aus mit dem VPN.Hilfreicher wäre eine etwas exotischere interne OpenVPN IP gewesen,. Warum ?? Siehe hier:
VPNs einrichten mit PPTP
Aber glücklicherweise kann man das mit einem kurzen Fix in der OpenVPN Serverkonfig in ein paar Sekunden ändern.
Nun versuche ich, dass der Punkt (unten links) auf die Öffentliche IP-Adresse:Port auf einen VPN Client zugreifen kann.
Das ist ja generell kein Problem !Hier gibt es nur diverse Punkte zu beachten:
- WAS nutzt der Client für ein Betreibssystem ?
- Bei jedem Client Betriebssystem ist in der Regel IPv4 Forwarding deaktiviert ! Das muss bei sowas dann immer zwingend aktiviert sein, damit der Client vom virtuellen OpenVPN Adapter auf den lokalen LAN oder WLAN Adapter durchrouten kann.
- Hat der Client eine lokale Firewall ? Wenn ja muss diese entsprechend angepasst werden damit Traffic vom OVPN Adapter zum LAN oder WLAN passieren kann.
- Der Client muss mit ip route xyz einen entsprechenden Routing Eintrag in der OVPN Konfig haben um das lokale IP Netz im VPN bekannt zu machen.
Ohne diese Anpassung ist ein lokales Erreichen der Client Adapter logischerweise nicht möglich.
Den Lancom anzupassen ist dabei völliger Quatsch. Verstärkt leider den Eindruck das du nicht wirklich weisst was du da tust
Der Lancom muss doch lediglich nur den VPN Tunnel auf den Linux VPN Server passieren lassen ! Mehr nicht !
Es reicht also dort vollkommen ein Port Forwarding von WAN Inbound UDP 1194 (OVPN Default) auf die lokale Linux Server IP einzustellen.
Port 6000TCP an Intranet Adresse 192.168.99.3 mit Port 60000TCP.
OK, bedeutet dann du arbeitest mit dem OVPN Server auf TCP 60000, richtig ?Dazu nur ein Tip:
Du solltest für den VPN Tunnel niemals TCP Encapsulation nutzen. OVPN selber rät dringenst davon ab, da das den VPN Overhead extrem vergrößert und den Processiong Aufwand im Server. Es geht also massiv zu Lasten der Performance ! Zeigt auch das du wenig in der OVPN Doku gelesen hast
Wenn, dann sollte man immer wenn irgend möglich UDP Encapsulation verwenden.
Das gesamte OVPN Routing macht doch der Linux Server, niemals der Lancom !!
Der Lancom bekommt lediglich eine statische Route auf das interne OVPN IP Netz UND auf die lokalen Client Netze, da diese ja auch über den OVPN Server geroutet werden. Der Linux Server hat ne Default Route dahin.
Der Linux Server macht KEIN NAT (Masquerading) ! Das verschlimmert die Sache nur, also ausschalten. Wozu sollte er auch NAT machen müssen ?!
würde ich lieber im Lancom hinterlegen, wenn das möglich ist.
Ja, denn auf dem OVPN Server ist das überflüssiger Unsinn !Dem Lancom scheint das 10.0.1.x Netz nicht bekannt zu sein.
Klar ! Wenn du, wie zu vermuten ist, vergessen hast dem eine statische Route auf den OVPN Server einzutragen kann er das doch auch nicht kennen ! Woher denn auch ?!Dort muss sowas stehen wie:
Zielnetz: 10.0.0.0, Maske: 255.255.255.0, Gateway: <192.168.99.linux_server>
So sähe das dann aus wenn es richtig ist:
