[Problem] Client hinter fritz.box OpenVPN Client

NightY91

Neuer User
Mitglied seit
9 Mrz 2007
Beiträge
27
Punkte für Reaktionen
0
Punkte
0
Hi,

ich befasse mich momentan mit OpenVPN, steige da aber mehr quer als direkt ein.. folgende Konfiguration liegt vor, die auch schon gut seinen Dienst tut:

OpenVPN Server:
“server.ovpn” -> https://gist.github.com/dennisoderwald/7115dd3fc721989b0cf8

In der Config für den Client die ich nannte “de-han-01″ weil mein Client so heißt, hab ich drin: iroute 192.168.178.0 255.255.255.0

OpenVN Client (fritz.box #1):
“vpnclient.conf” -> https://gist.github.com/dennisoderwald/7796375e7ca541883c14

Zielsetzung: Es gibt einen OpenVPN Server, mit einer statischen IP-Adresse, ich möchte, dass ich jede Menge Clients ins Netzwerk hängen kann, auch in Form von fritz.box'n an mehreren Standorten, die aber im Grunde natürlich sich dadurch im VPN befinden mit der o.g. Konfiguration und untereinander über Standorte hinweg, erreichbar sind. Der Traffic soll weiterhin wie es konfiguriert ist, lokal verlaufen - nur die interne Erreichbarkeit soll gegeben sein.

Problematik: OpenVPN Server kommt auf die fritz.box, fritz.box Client kommt auf OpenVPN Server, aber Clients hinter fritz.box können nicht verbinden oder erreicht werden.. (also genau das Ziel noch verfehlt..) – und wenn ja, auf welchen IP-Adressen müssten die Geräte dann via OpenVPN Server heuchen?

Bin über jede Hilfe dankbar, falls noch Informationen fehlen, einfach bescheid geben :)
 
Zuletzt bearbeitet:
Kann die Links nicht aufrufen?? Bitte hänge die Configs doch als "Code"-Blöcke (zwischen [noparse]
Code:
 und
[/noparse]; im erweiterten Editor #) direkt hier an.
 
Kann die Links nicht aufrufen?? Bitte hänge die Configs doch als "Code"-Blöcke (zwischen [noparse]
Code:
 und
[/noparse]; im erweiterten Editor #) direkt hier an.
Ärgerlich. Alles klar.

server.ovpn:
Code:
# Zertifikate
ca $PATH
cert $PATH
key $PATH
dh $PATH
client-config-dir "./config/clients/"
 
# Server und Netzwerk
local $ip
port 1194
proto udp
dev tap
server 192.168.10.0 255.255.255.0
ifconfig-pool-persist ipp.txt
comp-lzo
persist-key
persist-tun
keepalive 10 120
 
push "route 192.168.0.0 255.255.255.0"
 
# Log
status $PATH
log $PATH
log-append $PATH
verb 3

vpnclient.conf
Code:
client # wir sind Client
dev tap #
dev-node /var/tmp/tun # Hier wird das Devide angegeben. wichtig!
proto udp # wir nutzen UDP, kein TCP
remote $IP 1194 # die IP/ DNS Name der Gegenseite und Port
resolv-retry infinite # Namensauflösung immer
nobind # wir brauchen den Port nicht zu binden.
persist-key
persist-tun
ca $PATH # Die Zertifikate (Pfadangabe muss richtig sein)
cert $PATH
key $PATH
comp-lzo # Komprimierung, sofern auf der Gegenseite auch aktiv.
verb 3 # Fuer Debugging ruhig bis 8 hochsetzen.
mute 20 # Nach x Wiederholungen im Log ruhe.

P.S.: Was definiert den Client-Namen? Gibt es dafür eine Konstante Variable? Ansonsten denke ich er geht vom Key-Info (Name) aus?
 
Also, wegen der "Erreichbarkeit" des Netzes: Ein iroute-Eintrag im "client-config-dir" ist nötig, muss aber immer im Paar mit einen gleichlautenden "route"-Eintrag in der Config auftreten.
Also "iroute 192.168.178.0 255.255.255.0" im CCD zusammen mit "route 192.168.178.0 255.255.255.0".
Der "Client-Name" ist das, was im Zertifikat als "CN" (common name) "zertifiziert" wird.

Als Folgerung der obrigen Ausführung können sich nur Clients verbinden, die verschiedene Netze haben, damit das eindeutig ist (also z.B. nur einmal 192.168.178.0).

Edit:
Wenn die Netze "unterneinader" kommunizieren sollen, muss der Server die anderen Netze an die Clients "bekannt machen". Und ein "client-to-client" muss in die Config des Servers.
Kommt also "192.168.100.0 und 192.168.101.0 hinzu, muss der Server die jeweils "anderen" Netze (in der Config im "client-config-dir") bekannt geben, so in etwa:
Code:
# Config für de-han-01
ifconfig-push 192.168.10.10 255.255.255.0
iroute 192.168.178.0 255.255.255.0
push "route 192.168.100.0 255.255.255.0"
push "route 192.168.101.0 255.255.255.0"
und so weiter ...
Code:
# Config für de-han-02
ifconfig-push 192.168.10.11 255.255.255.0
iroute 192.168.100.0 255.255.255.0
push "route 192.168.178.0 255.255.255.0"
push "route 192.168.101.0 255.255.255.0"
und so weiter ...
 
Zuletzt bearbeitet:
Mal kurz gefragt, wenn ich sagen würde, jeder Standort hat einzigartige IP-Adressen die es an einem anderen Standort nicht gibt, könnte man es dann so lösen, dass egal wo ich bin die IP-Adresse des eigentlichen PC's auch die Adresse im VPN Bereich ist, die so erreichbar ist? Wenn ja, wäre das fantastisch und ich würde einfach überall den DHCP aktivieren und Bereiche vergeben 192.168.100 (bspw. für -01) und 192.168.101 für han-02..

Oder geht dies nicht und ich muss immer Client-IP's wie auch getrennte VPN IP-Adressen pro Client â Standort haben?

(Falls es ein wenig kompliziert beschrieben ist, bescheid sagen.. bin mehr der Entwickler und Netzwerk-Fummler als Profi dadrin..)
 
Habs nicht so ganz verstanden...
 
Habs nicht so ganz verstanden...
Kein Problem, on Detail..

Ich habe einen OpenVPN Server, der hat bereits eine statische IP-Adresse auf den der OpenVPN Server heucht, durch den VPN hat er automatisch aktuell die 192.168.10.1 - jeder weitere Client .2 usw. - die fritz.box aktuell, die ich einbinden möchte, in dem Falle die Erste von dreien, hat die Grundkonfiguration der fritz.box mit dem IP-Adressen Bereich 192.168.178 - nun war meine Überlegung, sofern das klappt, es folgendermaßen zu machen..

Standort #1 (fritz.box - Clients dahinter): Gateway > 192.168.100.1 - Clients ab .10 oder .20
Standort #2 (fritz.box - Clients dahinter): Gateway > 192.168.101.1 - Clients ab .10 oder .20
usw.

So das am Ende jeder Standort ein eigenen IP-Adressen Bereich hat, der mit keinem im VPN in Konflikte stoßen kann und von überall aus in den Bereichen auch erreichbar ist, so dass diese 192.168.10.* Variante wegfällt, wo jeder Client auch wieder eine eigene IP-Adresse im VPN Bereich bekommen würde..

Ich hoffe nun war es verständlicher und das was ich mir wünsche, ist überhaupt technisch möglich.. ansonsten bin ich für jegliche Vorschläge offen, wie man es anderweitig lösen könnte..
 
Ich beantworte das mal so, wie ich es verstanden habe ;-)

Die "Verschiedenheit" der Netze ist erstmal immer eine Voraussetzung dafür, dass (ohne weitere Klimmzüge) eine Erreichbarkeit der Netze untereinander möglich ist.
Damit eine Konfig dieser Art "zwingend" nötig, wobei die jeweiligen Netze "unabhängig" vom VPN sind (also z.B. die "lokale" FB vergibt die lokalen IPs per DHCP):
Standort #1: fritz.box hat die IP 192.168.101.1 die Clients sind im Netz 192.168.101.X
Standort #2: fritz.box hat die IP 192.168.102.1 die Clients sind im Netz 192.168.102.X
Standort #1: fritz.box hat die IP 192.168.103.1 die Clients sind im Netz 192.168.103.X
usw
"Clients" bezieht sich hier nicht auf das VPN sondern "DHCP-Clients" ( wie PC, Smartphone usw.) und es gilt X !=1, X < 254 ;-))

Soweit die "Vorgabe", alles ist noch immer "komplett ohne VPN" nutzbar und nur "Vorbereitung".

Letztlich ist jetzt das VPN-Netz "dazwischen" erstmal nebensächlich. Das kann eigentlich "beliebig" gesetzt sein, es wird nur als "Transportmittel" eingesetzt, um vom Netz-1 in Netz-2 zu kommen.
Ich Versuche es mal mit dem Straßen-Bild: Jede FB "verwaltet" eine eigene Straße, die IPs sind die verschiedenen Hausnummern. Solange die Straßennamen (=Netze) eindeutig sind, ist jedes Haus mit Straße+Nummer eindeutig zu erreichen.
Das VPN baut quasi eine "Querstraße", an der zwar alle FB-en auch "angeschlossen" werden, die Straßen selbst aber nicht. Um dann in eine Straße hinein zu gelangen, muss man immer "in die richtige FB" hineingehen, weil am anderen Ende der FB ja die gewünschte Straße ist.

Damit ist der "Name der Querstraße" (also das VPN-IP-Netz) nebensächlich und beliebig, solange man nur weiß, dass durch die FB-Hausnummer-17 in dieser Straße das Netz 192.168.117.0 erreicht werden kann...

Ich hoffe, ich habe die richtige Frage beantwortet ;-)
 
Ich denke schon, solang ich nun nicht an der Umsetzung scheitere.. bin gerade sogar am überlegen, ob ich den VPN Client von der hauseigenen fritz.box nutze und auf einen IPSec Server connecten lasse, da ich nun auch von Nachteilen bei OpenVPN laß, native Verwendung mit dem iPhone bspw. bis heute..
 
Kannst du auch versuchen. Um aber "zwischen den Netzen" zu kommunizieren, und nicht nur zwischen den "direkten VPN-Teilnehmern" ist es auch hier wichtig, verschiedene Netze zu haben, damit die Netze eindeutig sind.
 
Mit verschiedenen Netzen meinst du, dass wie gesagt jeder Standort sein eigenes internes Netz bekommt, so dass es zu keinen Überschneidungen kommt? Noch hat es nicht ganz *click* gemacht, leider..
 
Ja, ganz genau. Das ist notwendig, damit es "eindeutige" Zuordnungen gibt. An allen möglichen teilnehmenden Netzen im VPN muss jede einzelne Adresse einzig sein. Es muss letztlich klar sein, wo denn ein bestimmtes Gerät ist, und gäbe es mehrere "Standard-Fritzboxen", könnte z.B. 192.168.178.123 in jedem Netz vorkommen (im Zweifel sogar "im eigenen", so dass es gar nicht durch das VPN müsste).
Damit das nicht passiert, müssen die Netze ("Straßennamen" ;-)) alle unterschiedlich sein.
 
Genau, so war ja auch meine Bezeichnung oben geplant. Das ist ja kein Problem, jeder Standort bekommt ein eigenes internes Netz, .. dass am Ende zu keinen Überschneidungen beim VPN führen sollte.. kein Problem :) Nun fehlt mir nur noch das nötige Know-How genau das, umzusetzen.. herje :)
 
Vorbereitungen in soweit getroffen:

Standort #1 (fritz.box):

Router (DHCP für Standort #1): 192.168.101.1
Subnetzmaske: 255.255.255.0
DHCP vergibt von .20 - .200

Standort #2 (fritz.box):

Router (DHCP für Standort #2): 192.168.102.1
Subnetzmaske: 255.255.255.0
DHCP vergibt von .20 - .200

[..]

Nun geht es ja dadrum den VPN Server einzurichten, ob OpenVPN oder einen anderen IPSec, sei mal dahingestellt..

Rückfragen dessen:

- Welche Route müsste ich in dem Falle nun damit alle aufeinander erreichbar sind in der Push-Route setzen?
- Welche Route ("iroute") in der Client-Config zum dazugehörigen Common-Name?
- Welche allgemeine IP-Range müsste ich dem VPN geben für das VPN-Netz? (192.168.100.X?)

Danke im Voraus! :)
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.