rawweissm
Goto Top

OpenVPN - Lokales IP-Bereich identisch mit Server-IP-Bereich

Herstellen der Verbindung zwar möglich, jedoch kein Zugriff auf entfernte IPs

hey jungs,

wir haben in unserer firma einen ipcop mit openvpn am laufen.
der ip-bereich ist 10.0.0.x (255.255.255.0) und das herstellen der verbindung von den mitarbeitern zu hause klappt wunderbar (die befinden sich alle jeweils im 192.168.x.x bereich).

jetzt bin ich jedoch in einem hotel, wessen netzwerk sich ebenfalls im 10.0.0.x-bereich (subnet 255.255.255.0) befindet, d. h. deren router/dhcp-server hat 10.0.0.1 genau wie unserer ipcop.
das herstellen der verbindung klappt zwar, jedoch habe ich im anschluss keinen zugriff auf unseren windows-server, der unter 10.0.0.2 läuft, weil sich diese ip ja zum lokalen lan hier im hotel gehört.

wie komme ich trotzdem an unseren server ran?
irgendeine lösung muss es ja geben, sonst gibt es ja an jedem hotspot trouble, dessen ip-bereich mit unserem firmennetzwerk identisch ist... oder sehe ich das falsch?

Content-Key: 112834

Url: https://administrator.de/contentid/112834

Printed on: April 25, 2024 at 20:04 o'clock

Member: aqui
aqui Mar 31, 2009 at 11:34:48 (UTC)
Goto Top
Gar nicht, denn damit ist eine der grundlegenden Vorgaben für VPNs verletzt !!
Eine eindeutige Wegefindung ist so nicht mehr möglich durch doppelte IP Netze !

Mit Verlaub gesagt ist es auch etwas dümmlich das VPN Netz gerade auf das offensichtlichste aller 10er Netze zu legen, oder ??? Sorry....
Genau so dumm wäre auch die 192.168.0.0 usw., bzw. alle von Consumer Routerherstellern benutzte default IPs im LAN !!
Warum liegt ja auf der Hand !

Wenn du z.B. 10.137.76.0 /24 oder 10.241.143.0 /24 oder oder... eine etwas seltenere IP Adress Kombination intelligenterweise benutzt hättest, wäre so ein Zufall höchst selten oder vermutlich so gut wie unwahrscheinlich bei deiner VPN Nutzung !!

Alle diese Netze gehören zu den Privaten IP Netzen nach RFC 1918
http://de.wikipedia.org/wiki/Private_IP-Adresse

Es kann daher immer zu gleichen IPs kommen, davor bist du nie ganz gefeit sofern du dich in RFC 1918 Netzen bewegst als VPN Client.
Allerdings geht diese Chance gegen Null, wählt man etwas exotischere RFC1918 IPs und nicht gerade die am meisten kritiklos oder von Laien immer verwendeten 10.0.0.x oder 192.168.x.x.
Mit nur etwas Nachdenken kommt man bei VPN Einrichtungen auch von selber darauf....

Fazit: Umstellen des VPN Netzes beim IP Cop löst dein Problem final und sicher für die Zukunft !!
Member: mkuchen
mkuchen Mar 31, 2009 at 12:04:23 (UTC)
Goto Top
dein IPCop kann doch sicher dyndns, oder?? Probier´s damit
Member: godlie
godlie Mar 31, 2009 at 12:20:40 (UTC)
Goto Top
@aqui

full ack face-smile
192.168.178 ist auch keine gute idee wird von AVM gern verwendet.

@mkuchen
wohl die Fragestellung net gelesen?
Mitglied: 45877
45877 Mar 31, 2009 at 12:34:17 (UTC)
Goto Top
am ipcop kann man doch dem user fest ne ip zuweisen die dann doch nicht zwingend aus dem vpn pool stammen muss.
Member: aqui
aqui Mar 31, 2009 at 12:53:01 (UTC)
Goto Top
Nützt nur nichts wenn das lokale IP Netzwerk in demselben IP Netzbereich liegt, was hier ja der Fall ist !!

Damit hast du 2 identische IP Netze (lokal und im VPN) und wo soll nun der Client mit seinen Paketen hin ???!!
No way !!
Member: rawweissm
rawweissm Apr 01, 2009 at 17:21:44 (UTC)
Goto Top
vielen dank für eure antworten, das hat mir alles sehr geholfen!

ich fand halt immer, dass man sich die windows-server-adresse 10.0.0.2 für remote-desktop gut merken konnte, aber offensichtlich taugt das nicht in einem solchen fall

/24 bedeutet 255.2555.255.0, oder?
Member: aqui
aqui Apr 02, 2009 at 13:53:30 (UTC)
Goto Top
Ja, genau ist die 24 Bit Subnetzmaske.

Mmmmhhh ob das in dem Fall taugt kannst du dir selber beantworten....oder hast du ja indirekt schon !

Einfach merkbare Kombinationen wie :

10.111.11.0 /24
10.101.202.0 /24
10.202.101.0 /24
10.222.33.0 /24
10.11.22.0 /24

und so weiter und so fort....
wären halt geringfügig intelligenter gewesen in deinem Falle !!


Wenns das denn nun war bitte
How can I mark a post as solved?
nicht vergessen !