Umstellung von Fritzbox LAN-LAN Kopplung auf Synology VPN Server

[FrAntje]

Hallo zusammen,

Bisher nutze ich für eine entfernte DS zu meinem VirtualBox DS eine VPN Verbindung über die Fritzbox (LAN-LAN Kopplung)
Das klappte super, jeder Zugriff klappte und es war so, als stünde die entferne DS auf meinem Schreibtisch

Nun ist mir aufgefallen, dass ich über die FritzVPN Verbindung Übertragungen von paar Kilobyte habe, nie über 1 MB. Das nervte ein wenig und ich wunderte mich warum es über Quickconnect - Webbrowser -Filestation so schnell war.
Also habe ich OpenVPN getestet und dort habe ich nun auch meine 4MB Übertragung.

Also entfernte DS = VPN Server
Mein PC mit VirtualBox DS hat OpenVPN GUI drauf. Jetzt klappt das ganze "eigentlich" auch. Ich kann die Geräte anpingen, über IP auf die DS zugreifen, Daten hochladen etc.

Nur können die Diskstations z.B. nicht mehr über CMS, ShareSync, Replication, HyperBackup etc. zugreifen.

Habt ihr eine Idee wo ich suchen kann? Würde ungern wieder die LAN-LAN Kopplung nutzen.


P.S: mit der QuickConnect ID kann zumindest die Virtuelle DS auf die echte entferne zugreifen, aber das ist ja nicht das Ziel.

 

[Fusion]

Was ist denn "virtualbox DS"? xpenology?

Prinzipiell mit zwei DS eine bidirektionale Verbindung geht. Einer Server, einer Client, Optionen Clients den Server LAN Zugriff erlauben und passende CCD files und Routen für den Weg vom Server zum Client.
Sollen auch andere Geräte im jeweiligen LAN das gegenüberliegende LAN erreichen können müssen noch passende Routen auf den jeweiligen lokalen Gateways (Router) gesetzt werden.
Gibt es ein paar Forums Threads dazu.
Nötig sind nur Portweiterleitungen/freigaben. Quickconnect würde ich komplett vergessen.

 

[FrAntje]

Ja genau xpenology.

Ich verstehe technisch nur nicht, warum es mit der LAN-LAN Kopplung geht. Ist diese Verbindung anders als ein OpenVPN.

Ich habe das jetzt erst einmal über Netzwerk - VPN Profil gelöst. Dort habe ich unter xpenology ein Profil mit dem Serverdaten erstellt.

Leichter ist natürlich die Kopplung.

 

[Fusion]

LAN-LAN oder Site to Site geht mit verschiedenen VPN Protokollen.

Die Fritzbox nutzt hier IPsec (die Synology unterstützt IPsec/L2TP, also nicht das gleiche) und wie du festgestellt hast ist sie CPU seitig so schwach aufgestellt, dass auch mit den neueren Modellen gerade mal der Upload einer VDSL 50/10 Leitung vollständig ausgenutzt werden kann (Bei Tests mit der 7590 habe ich auch nur 15 MBit/s erreicht. Mit openVPN und DS-DS bei einer 35MBit/s Leitung kamen immerhin 29MBit/s Netto raus)

Bei openVPN (bzw. allen unterstützten Protokollen) hat sich Synology leider auf Client-Server Betrieb eingeschränkt in der GUI. Auch Client/Server lassen sie nicht gleichzeitig auf der DS zu (sonst könnte man einfach zwei Tunnel, je einen pro Richtung auflegen).
Deshalb muss man für Site-to-Site eben ein wenig Hand anlegen und auch auf die Konsole der DS gehen um configs zu bearbeiten.

Stellt man in der GUI im openVPN Server "Clients den Server LAN Zugriff erlauben" ein, kann man von der Client DS schon mal die Server DS und die Geräte im Server LAN über deren lokale IPs erreichen.

Will man von der Server DS auf die IPs im Client-LAN (und nicht nur auf die dynamische Tunnel-Endpunkt-IP) zugreifen braucht es die genannten CCD Files (Client-Config-Directory), die auf dem Server eine Route zum Client-Netz aktivieren, wenn sich ein bestimmter Client verbindet.

Und die dritte Ausbaustufe wäre, dass man nicht nur von der jeweiligen DS die andere DS und das LAN auf der Gegenseite erreichen kann, sondern, dass man von jedem Rechner im lokalen Netz die Geräte im anderen Netz erreichen kann,
Da diese ja nichts vom VPN wissen, sondern nur Kenntnis des lokalen Gateways/Routers ins Internet haben, muss man auf diesen Gateway eine Route anlegen, die eben dafür sorgt, dass Anfragen für das entfernte Netz zur DS und durch den VPN Tunnel gehen und nicht vom Gateway direkt ins Internet (wo es diese Adressen ja nicht gibt).

 

[FrAntje]

Ah ok, vielen Dank für die gute Erklärung. Dann such ich mich mal durchs Thema der Routen

 

[laserdesign]

@Fusion,

super klasse erklärt, wollte dir mal ein Lob für deine Aktivität und deine guten Beiträgen hier im Forum aussprechen.

 

[FrAntje]

Ok, habe mich soweit ich das überschauen kann durchgelesen und das beste ist wohl dieser Ansatz hier
http://www.synology-forum.de/showth...ide-Richtungen&p=395676&viewfull=1#post395676

Jedoch habe ich es nach vielen Versuchen nicht hinbekommen. Kann jemand von euch helfen, der Ersteller diese Posts ist derzeit wohl abwesend.

Was könnte euch helfen, den Fehler zu finden?
Ich verstehe die Routingtabellen in der DS auch nicht ganz.
192.168.10.X ist der Client
192.168.20.X ist der Server
10.8.0.0.X ist der VPN Bereich

10.8.5.10
10.8.5.6 sind verbundene Clients
Wer ist denn dann 10.8.0.5?

Hier ist die openvpn.conf unter /var/packages/VPNCenter/etc/openvpn/

push "route 192.168.20.0 255.255.255.0"
push "route 10.8.0.0 255.255.255.0"
dev tun

route 192.168.10.0 255.255.255.0
client-config-dir ccd
client-to-client

management 127.0.0.1 1195

server 10.8.0.0 255.255.255.0

dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh3072.pem
ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt
cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt
key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key

max-clients 5

comp-lzo

persist-tun
persist-key

verb 3

#log-append /var/log/openvpn.log

keepalive 10 60
reneg-sec 0

plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf
client-cert-not-required
username-as-common-name
duplicate-cn

status /tmp/ovpn_status_2_result 30
status-version 2
proto udp6
port 1194
cipher BF-CBC
auth SHA1

 

[Fusion]

10.8.0.5 und 10.8.0.6 sind die Endpunkte des einen VPN Tunnels
10.8.0.9 und 10.8.0.10 sind die Endpunkte des zweiten VPN Tunnels

Hast du die radiusplugin.cnf auch angepasst?

Hast du das Verzeichnis /var/packages/VPNCenter/etc/openvpn/ccd angelegt und darin eine Datei mit Name "admin" und Inhalt
iroute 192.168.10.0 255.255.255.0

Du hast zwei verbundene Clients? Kommen die mit demselben Benutzer aus demselben Client Netz, oder was ist das?

An den Routingtabellen musst du gar nichts machen.

In der Situation wie sie in den Bildern oben ist müsstest du von der Client DS aus IP Adresssen im 192.168.20.x Netz erreichen können.

Bei den Server Einstellungen würde ich noch empfehlen mindestens auf AES-128-CBC und SHA256 zu wechseln.
Für BF-CBC und SHA1 gibt es reale funktionierende Angriffsszenarien.

 

[FrAntje]

Danke für deine Antwort!

Die /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf enthält die Zeile

overwriteccfiles=false

Ich habe im Ordner /var/packages/VPNCenter/etc/openvpn einen Ordner ccd angelegt mit der Datei admin und der IP des Clients.

iroute 192.168.10.0 255.255.255.0

Was mich jedoch wundert ist, dass im Verzeichnis /var/packages/VPNCenter/etc/openvpn bereits eine Datei admin existierte mit folgendem Inhalt

ifconfig-push 10.8.0.10 255.255.255.0

Ja, es verbinden sich derzeit 2 identische Benutzer aus dem gleichen Netz. Einmal die lokale DS und einmal mein PC.

Die Client Adressen (192.168.10.X) konnten auch ohne Änderungen die Server Adresssen (192.168.20.X) erreichen.
Das klappt ja durch einfaches Aktivieren des VPN Servers.
Ich möchte aber ja über den Server den Client erreichen. Also von 192.168.20.x zu 192.168.10.x

 

[Fusion]

Und mit den Änderungen klappt es immer noch nicht?
Wie / wo testet du? Ping oder tracert oder...?

Die zusätzliche Admin Datei mit der dynamischen Tunnelroute darfst ignorieren.
Hauptsache der ccd Ordner und Inhalt sind da und bleiben es auch nach einem vpn Server Neustart.

 

[FrAntje]

Ich teste einfach mit Programmen der DS. CMS, ShareSync, HyperBackup etc.
Beim client die lokale Server IP = klappt alles
Beim Server die lokale Client IP = Keine Verbindungen möglich

Passt denn die Routingtabelle oder gibt die keinen Aufschluss darüber? Die 10.8.0.2 kann ich auch nicht zuordnen.

Btw. Stelle ich auf AES-128-CBC und SHA256 kann die Client DS keine Verbindung aufbauen bzw. Baut auf, direkt getrennt, baut wieder auf usw.
Also löse ich erst einmal das erste Problem.

Was ein Theater

 

[Fusion]

Hast du die config auf den Clients neu importiert nachdem du die Ciphers geändert hattest?

Kannst die Bilder von den Routingtabellen nochmal im zoom / größer posten, danke.

 

[FrAntje]

Mehr oder weniger. In den Einstellungen von DSM gibts nichts zu ändern, dort habe ich immer nur die neue ca.crt Datei importiert.
Beim OpenVPN Client auf dem PC klappte es natürlich sofort. Nur bei der DS nicht.




Die roten Adressen sind aus dem Client Netz
Die grünen Adressen sind aus dem Server Netz.
192.168.10.1 ist die FritzBox im Client Netz
192.168.20.1 ist die FritzBox im Server Netz

Kann hier noch etwas falsch sein? Viel gibt es da ja nicht.
Habe aber auch alle Kombinationen durch, nichts davon geht.
Aktiviere ich Standard Gateway auf Remote Computer verwenden ändert sich die Zeile mit default in default -> 10.8.0.5


Erstelle ich ein Profil über den import einer .ovpn Datei, die ich zuvor am Server exportiere (dort den ddns Namen von Synology eintrage und die # vor redirect-gateway def1 entferne)
Dann sieht die Tabelle am Client noch seltsamer aus

 

[Fusion]

Ich weiß, dass es in der Verbindung nichts zu bearbeiten gibt, deshalb auch die Aussage: Verbindung auf dem Client löschen und neu anlegen, wenn Parameter wie die Cipher geändert werden.
Auf dem PC nimmst du ja auch die neue config Datei und kopierst nicht nur dasselbe ca.crt erneut rüber.

Standard Gateway auf Remote Netzwerk bewirkt, dass sämtlicher ausgehender Verkehr durch den VPN Tunnel geht und nicht nur der explizit für das Remote Netzwerk angedachte.
Deshalb ist auch die default Route dann auf die VPN-IP des Tunnelendpunktes gesetzt.
Der Eintrag in der config "redirect-gateway def1" bewirkt eigentlich das gleiche. Wenn man beides setzt macht die DS vielleicht Müll, keine Ahnung.

Auf dem Bild "VPN Server entfernte DS" sehe ich jetzt gerade keinen Fehler oder fehlende Route, sollte eigentlich funktionieren.
Hast du dort in der LAN 1 Table noch einen Eintrag stehen?

Auf der Client DS habe ich auch die gleichen Einträge, nur den Eintrag mit der öffentlichen IP der Server Seite habe ich nicht. Aber ich habe auch nicht am Standard-Gateway gespielt, oder seit wann ist dieser Eintrag vorhanden?

Noch ein Unterschied wäre, dass meine Clients mit verschiedenen Benutzernamen (und aus verschiedenen Netzwerken) zugreifen.
Die DS lässt zwar mehrere Verbindungen mit demselben Nutzer zu, aber ein Versuch wäre es mal wert, pro Client ein Benutzer zu nehmen (mit eigener CCD).
Die letzte Tabelle sieht echt durcheinander aus, aber da hab ich mich jetzt noch nicht durch gedacht.

 

[FrAntje]

Danke für deine Antwort und deine Zeit!!!!

Ich habe die gestrigen Tests alle ohne den 2. Client vom PC gemacht. Ich dachte mir einfach alles versuchen.
Vielleicht lege ich mal einen extra Benutzer an und ein neues File im ccd Ordner.

In der Routingtabelle unter LAN Tabelle steht:

 

[Fusion]

Komisch, da habe ich auch nur die beiden Einträge mit der IP des Servers/Clients als Gateway.
Die Doppelung der default Route aus der Haupttabelle steht bei mir nicht drin.

Allerdings habe ich jetzt gerade auch Probleme z.B. in der File Station einen Remote-CIFS Ordner des Gegenübers zu mounten.
Das CMS hingegen hat sich vom Client mit der lokalen IP der Server DS verbunden.

Edit:
Das mit dem SMB liegt daran, dass die File Station hier versucht per SMBv1 eine Verbindung herzustellen. Ich habe aber nur noch SMBv2 und v3 zugelassen. Mega Fail, Synology...

Auch HyperBackup bekommt Verbindung. Also bei mir noch alles in Ordnung von der Server DS die Client DS mit ihrer lokalen IP anzusprechen.

 

[FrAntje]

Habe das mit dem Benutzer auch jetzt getestet. Neuen Benutzer, neue Datei im ccd Ordner.
Keine Besserung

 

[Fusion]

Dann fällt mir jetzt nur noch die Konsole ein um mal ein ping und tracert oder ähnliches laufen zu lassen um zu sehen wo man hängen bleibt.

Oder du musst mal genau niederschreiben was du mit welchen Anwendungen genau testest und welche exakten Eingaben du dort machst, ob das vielleicht noch irgendwas nicht ganz stimmt.

 

[laserdesign]

und zeige doch auch gleich die Ausgaben:

ifconfig

und

route -n

 

[FrAntje]