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-ID: 112834

Url: https://administrator.de/forum/openvpn-lokales-ip-bereich-identisch-mit-server-ip-bereich-112834.html

Ausgedruckt am: 23.12.2024 um 06:12 Uhr

aqui
aqui 31.03.2009 um 13:34:48 Uhr
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 !!
mkuchen
mkuchen 31.03.2009 um 14:04:23 Uhr
Goto Top
dein IPCop kann doch sicher dyndns, oder?? Probier´s damit
godlie
godlie 31.03.2009 um 14:20:40 Uhr
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?
45877
45877 31.03.2009 um 14:34:17 Uhr
Goto Top
am ipcop kann man doch dem user fest ne ip zuweisen die dann doch nicht zwingend aus dem vpn pool stammen muss.
aqui
aqui 31.03.2009 um 14:53:01 Uhr
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 !!
rawweissm
rawweissm 01.04.2009 um 19:21:44 Uhr
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?
aqui
aqui 02.04.2009 um 15:53:30 Uhr
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
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !