OpenVPN 2 Diskstations, Datensicherung in beide Richtungen

[joha1908]

Danke für Deine Antwort.

Ich bin was VPN und Routing angeht nicht so fit.
Ist folgendes Szenario ohne eine weitere VPN Verbindung möglich:
DS 2 am Standort B ist als VPN-Client mit DS 1 am Standort A verbunden.
DS 3 ist nur im lokalen Netz am Standort B. DS 1 kann über die VPN-Verbindung mit DS 2 auf DS 3 zugreifen - idealerweise mit der lokalen IP aus dem Netz von Standort B

Geht das?

 

[Fusion]

Teils denke ja.

Ohne jetzt alle Details durchzugehen (das müsste ich mir erst selber überlegen/testen)
Wenn die DS3 eine Route gesetzt bekommt, dass sie das remote Netz von Standort A über die DS2 erreicht. Eventuell muss dann noch ipv4 forwarding in der DS2 aktiviert werden.

Am einfachsten wäre vermutlich, wenn die Router an beiden Standorten ein Site-2-Site VPN aufspannen können, dann setzen diese normal selbst alle notwendigen Routen und Clients können die lokalen IPs auf der anderen Seite erreichen.

 

[joha1908]

Am Standort A ist leider nur ein Speedport Router zur Verfügung. Der unterstützt kein Site-To-Site VPN.

Wichtig wäre, dass DS 1 via Hyper Backup auf DS 3 backupen kann. Reicht dann eine statische Route auf der DS 3 an DS 2?
Hab erst heute Abend die Möglichkeit es zu testen.

 

[joha1908]

Mittlerweile kann ich von DS3 (Standort B) auf DS1 (Standort A) zugreifen, ohne dass DS3 selbst als VPN-Client mit DS1 verbunden ist. Habe dazu auf DS3 eine statische Route eingerichtet.
Allerdings kann ich von DS1 noch nicht auf DS3 zugreifen.

 

[Fusion]

Gleiches Problem. Routen werden nicht in beide Richtungen gesetzt.

Server auf Client Zugriff, ccd-files u.a. sollten Infos liefern.

 

[joha1908]

Ich glaube es funktioniert jetzt. Das Problem lag jetzt an der Firewall-Einstellung der DS2.
Danke für die Unterstützung.

 

[Fusion]

Keine Ursache. Hab ja nicht viel gemacht. Freut mich.

 

[DaCapitalist]

Hallo fpo4711 (und auch Fusion)!

Vielen Dank für die tolle Anleitung.
Ich habe mich jetzt auch mal an so ein ähnliches Projekt gemacht und mich dabei an Deine Anleitung gehalten.

Folgendes Setup:
DNS-323 mit openVPN (192.168.178.9) --> FritzBox7490 (192.168.178.1) --> Internet (IPs über DynDNS transparent) --> FritzBox 7490 (192.168.1.1) --> Synology DS216play (192.168.1.2) mit VPNCenter (VPN Subnetz hat die 192.168.3.0)

Wenn ich mich über die DNS-323 mit dem Server auf der DS verbinde, sehe ich die Verbindung im VPNCenter der DS.
Ich kann von der DNS-323 (Client) per nmap erfolgreich die Server-IP der DS (192.168.3.1) sowie die lokale IP (192.168.1.2) scannen. Auch funktioniert der Scan für die lokale Fritzbox im Server-Netz (192.168.1.1).

Allerdings funktionieren ein paar Sachen nicht wie geplant

• Die DNS-323 (Client) bekommt nicht die im CCD angegebene Virtuelle IP (192.168.3.2), sondern 192.168.3.6
• Von einem Client im Server-Netz komme ich aber noch nicht in das lokale Netz hinter der DNS-323 (Client). Nmap von einem Client im Server-Netz auf die virtuelle IP der DNS-323 (192.168.3.6) klappt. Auf 192.168.178.9 oder 192.168.178.1 komme ich nicht.

Es scheint also ein wenig, als ob mein CCD file nicht angewertet wird. Kannst Du / könnt ihr mir dabei vielleicht helfen? Was übersehe ich?

Hier die relevanten Files:

openvpn.conf auf dem Server:

dev tun

management 127.0.0.1 1195

server 192.168.3.0 255.255.255.0

client-config-dir /var/packages/VPNCenter/target/etc/openvpn/ccd
route 192.168.178.0 255.255.255.0
client-to-client

ifconfig-pool 192.168.3.3 192.168.3.100 255.255.255.0

push "route 192.168.1.0 255.255.255.0"

push "dhcp-option DNS 192.168.1.1"

push "route 192.168.3.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 4

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

ccd/vpn auf dem Server (Der User heißt "vpn"):

ifconfig-push 193.168.3.2 255.255.255.255

iroute 192.168.178.0 255.255.255.0

/etc/openvpn/client.conf auf der DNS-323 (Client):

dev tun
tls-client

remote xxx.no-ip.org 1194 udp4

# The "float" tells OpenVPN to accept authenticated packets from any address,
# not only the address which was specified in the --remote option.
# This is useful when you are connecting to a peer which holds a dynamic address
# such as a dial-in user or DHCP client.
# (Please refer to the manual of OpenVPN for more information.)

float

# If redirect-gateway is enabled, the client will redirect it's
# default network gateway through the VPN.
# It means the VPN connection will firstly connect to the VPN Server
# and then to the internet.
# (Please refer to the manual of OpenVPN for more information.)

#redirect-gateway def1

# dhcp-option DNS: To set primary domain name server address.
# Repeat this option to set secondary DNS server addresses.

#dhcp-option DNS DNS_IP_ADDRESS

pull

# If you want to connect by Server's IPv6 address, you should use
# "proto udp6" in UDP mode or "proto tcp6-client" in TCP mode
proto udp

script-security 2


comp-lzo

reneg-sec 0

cipher AES-256-CBC

auth SHA512

auth-user-pass /etc/openvpn/credentials.conf

<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----  
                                                               
</ca>

 

[Fusion]

Probier mal in deiner ccd/cpn zu setzen (ersteres war vermutlich ein copy&paste/Tippfehler?

ifconfig-push 19[B]2[/B].168.3.2 255.255.255.[B]0[/B]

Was sagt das Client log zum Verbindungsaufbau? Welches OS auf dem Client?
VPNServer neu gestartet nach den config Änderungen?

Edit: Nachtrag
Und in der Server config noch

topology subnet

eintragen. Dann bist auch die veraltete net30 los (eingeschränkter IP Adressbereich, andere Angaben in ccd notwendig).

https://community.openvpn.net/openvpn/wiki/Concepts-Addressing

 

[DaCapitalist]

Oh man, manchmal ist man selbst echt blind... -.-

edit: sorry, zunächst zu deinen Fragen -> auf dem Client läuft auch ein Linux (Alt-f firmware). Den VPN Server habe ich immer mit der kompletten DS neu gestartet. Die Logs schaue ich mir gerade noch an

Ich habe es direkt mal ausprobiert:
nmap 192.168.3.6 --> Host is up (wie vorher)
nmap 192.168.178.9 --> Host seems down. (wie vorher)

Aber ich habe mal noch etwas tiefer gecheckt:
nmap -Pn 192.168.178.9 --> Host is up

Das verwirrt mich noch mehr. Weiterhin wird der Client im VPNCenter als 192.168.3.6 angezeigt und nicht als 192.168.3.2. (Problem Nr. 1)
Gleichzeitig scheint aber irgendwas bis ins Client-Netz durchzukommen (oder nmap zeigt mir hier irgendwelche anderen Hosts). (Problem Nr. 2) --> Muss ich in der Firewall der DS noch etwas umstellen, oder macht das alles das IP-forwarding unabhängig von der Firewall?

Andere mögliche Ursache: Die Anmeldung des Clients am Server läuft ja derzeit mit Username und Passwort. Muss das vielleicht Zertifikat-basiert stattfinden, damit der Server auf das CCD-File zurückgreift? Denn das wird ja scheinbar immernoch nicht berücksichtigt.

Hier auch mal per Ping:

ping 192.168.3.6
PING 192.168.3.6 (192.168.3.6) 56(84) bytes of data.
From 192.168.1.1: icmp_seq=1 Redirect Host(New nexthop: 192.168.1.2)
^C
--- 192.168.3.6 ping statistics ---
26 packets transmitted, 0 received, 100% packet loss, time 25136ms

Routen sind in der Fritzbox auf Server-Seite eingerichtet:
Netzwerk -> Gateway
192.168.3.0 -> 192.168.2.1
192.168.178.0 -> 192.168.2.1

Und auf der Fritzbox auf Client-Seite:
Netzwerk -> Gateway
192.168.3.0 -> 192.168.178.9
192.168.178.0 -> 192.168.178.9

Routen auf der DiskStation:

Administrator@DS:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         fritz.box       0.0.0.0         UG    0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.3.0     192.168.3.2     255.255.255.0   UG    0      0        0 tun0
192.168.3.2     0.0.0.0         255.255.255.255 UH    0      0        0 tun0

Auch hier wieder das Problem: Geroutet werden soll über 192.168.3.2, aber der Client wird als 192.168.3.6 verbunden.

 

[DaCapitalist]

Hier das Client-log:

Sun May  3 16:32:15 2020 WARNING: file '/etc/openvpn/credentials.conf' is group or others accessible                                                                      
Sun May  3 16:32:15 2020 OpenVPN 2.4.8 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Apr 19 2020                                 
Sun May  3 16:32:15 2020 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.10                                                                                          
Sun May  3 16:32:15 2020 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.                      
Sun May  3 16:32:15 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]89.xxx:1194                                                                    
Sun May  3 16:32:15 2020 UDPv4 link local (bound): [AF_INET][undef]:1194                                                                                                  
Sun May  3 16:32:15 2020 UDPv4 link remote: [AF_INET]89.xxx:1194                                                                                                   
Sun May  3 16:32:15 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this                                         
Sun May  3 16:32:20 2020 [synology.com] Peer Connection Initiated with [AF_INET]89.xxx:1194                                                                        
Sun May  3 16:32:21 2020 TUN/TAP device tun0 opened                                                                                                                       
Sun May  3 16:32:21 2020 /sbin/ifconfig tun0 192.168.3.6 pointopoint 192.168.3.5 mtu 1500                                                                                 
Sun May  3 16:32:21 2020 Initialization Sequence Completed

 

[Fusion]

Nein, ein Client Cert ist keine Voraussetzung. Und Firewalls entweder ausschalten zum Testen, oder passend konfigurieren.
Eventuell eher Ort und Pfad. Meine liegen unter /var/packages/VPNCenter/etc/openvpn/ccd/
und in der config nur

client-config-dir ccd
client-to-client

Willst du wirklich von allen Clients in einem Netz auf alle Clients im anderen Netz zugreifen?

Und dann musst du deinen ganzen IPs und Routen nochmal durchgehen.
Schreibst von 192.168.2.1 dann wieder 192.168.1.2 etc. da blicke ich nicht durch, wo du welche Verdreher eingebaut hast.
Deshalb ist es immer gut, wenn man für den Tunnel bei 10.x.x.x bleibt bzw. eben Tunnel, lokal und remote deutlicher trennt.

Oder bei den Routen "Und auf Client-Seite", heißt das in der Fritzbox dort?
Wieso eine Router für 178.0 auf 178.9? Soll der Internetzugriff von dort nur noch durch den VPN Tunnel erfolgen?

Oder du musst nochmal auf Anfang und Schritt für Schritt einrichten und testen.
VPN Client Verbindung
VPN Client Verbindung mit fester Tunnel IP
... mit Zugriff auf andere LAN Geräte auf Server Seite
--- mit Zugriff von Server auf LAN Geräte auf Client Seite
--- mit Zugriff von LAN Geräten auf LAN Geräte der anderen Seite.

Edit:
Client Log, point2Point -> Doku nachsehen, ob dafür andere Syntax im ccd verwendet werden muss, etc.

 

[DaCapitalist]

Hi Fusion,

nochmal danke für Deine Untersützung.

Zur Erläuterung:
192.168.1.0 ist das Netz in dem der VPN Server steht
192.168.178.0 ist das Netz in dem der VPN Client steht
192.168.3.0 ist das virtuelle Netz

Ich verstehe immer noch nicht, warum er überhaupt auf das pointtopoint kommt.
Ich habe sowohl in der Client- als auch in der Server-Config die Direktive "topology subnet".
Wie kommt er denn darauf?

 

[Fusion]

Kann ich dir auch nicht genau sagen. Ich hatte bei mir *buntu Linux nur den Hinweis, dass er net30 erkennt und ob der Angaben im CCD (subnet anstatt IP als zweiter Eintrag) auf subnet zurückfällt und durch expliziten Eintrag war die Meldung/Hinweis dann weg beim nächsten Verbindungsversuch.

 

[DaCapitalist]

Nein, ein Client Cert ist keine Voraussetzung.

Dieser Post hier scheint genau das als Problem zu sehen und empfiehlt das Client Zertifikat als Identifikation.
https://forums.openvpn.net/viewtopic.php?t=18835#p52021

Muss heute Abend nochmal weiter testen...

 

[DaCapitalist]

Vielen Dank für die Hilfe!

Es war tatsächlich nur das falsche Config-File auf dem Server, in dem ich gearbeitet habe.
Ich war unter "/var/packages/VPNCenter/target/etc/openvpn/" unterwegs. Das VPNCenter liest aber tatsächlich von "/var/packages/VPNCenter/etc/openvpn/".

Nun muss ich nur noch zwei neue Probleme lösen:
- Geringer Datendurchsatz (mag an der DNS-323 liegen, die ja auch keine starke CPU hat, allerdings ist die nicht ganz ausgelastet, also kann man scheinbar noch optimieren)
- Verbindungsabbruch, wenn eine der beiden FritzBoxen eine neue IP erhält. Ich bekomme dann die Meldung, dass die User Authentifizierung fehlgeschlagen ist (vllt versucht er es zu früh und dann nicht lang genug, sodass die IP noch nicht komplett aktualisiert wurde). Schaue ich mir heute abend mal an, aber wenn ihr schon Tipps habt, versuche ich die dann gern zuerst.

Vielen Dank nochmal!

 

[DaCapitalist]

Hallo zusammen,

die meisten meiner Probleme konnte ich lösen. Die DNS-323 habe ich durch einen Raspberry Pi4 ersetzt. Damit laufen jetzt ~31Mbit/s Upstream über VPN durch meine DSL100er-Leitung.
Den Verbindungsabbruch habe ich über connect-retry und ping-restart Direktiven gelöst. Abbrechen kann er ja, aber danach verbindet er sich ohne erneute Passwort-Abfrage automatisch neu.

Nun habe ich noch das Problem, dass sich jedes Mal wenn der TSL-Handshake neu ausgehandelt wird, für einige Zeit keine Verbindung habe, vermutlich weil die Authentifizierung über das Radius-Plugin nicht funktioniert.
(Ich nutze Zertifikate in Kombination mit einer User/Password Authentifizierung mit dem Synology Radius-Plugin. User und Passwort sind im Client in einer credentials-Datei gespeichert.)
Im Ergebnis habe ich einmal pro Stunde für etwa 15-20min keine Verbindung. Das bringt natürlich nichts, aber ich möchte auf den Re-Handshake aus SIcherheitsgründen eigentlich auch nicht verzichten.

Hier das Server-Log:

2020-06-07T11:14:39+02:00 NAS_D openvpn[4807]: vpn/xx.xxx.xxx.xxx:48282 PLUGIN_CALL: plugin function PLUGIN_AUTH_USER_PASS_VERIFY failed with status 1: /var/packages/VPNCenter/target/lib/radiusplugin.so
2020-06-07T11:14:39+02:00 NAS_D openvpn[4807]: vpn/xx.xxx.xxx.xxx:48282 TLS Auth Error: Auth Username/Password verification failed for peer
2020-06-07T11:15:41+02:00 NAS_D openvpn[4807]: vpn/xx.xxx.xxx.xxx:48282 TLS Error: local/remote TLS keys are out of sync: [AF_INET]xx.xxx.xxx.xxx:48282 [1]

Das Problem mag sein, dass für den angegebenen Port kein Forwarding im Router eingestellt ist, sondern nur 1194 für OpenVPN. Wie kann ich dem Plugin erklären, dass er die lokale IP des Clients abfragen soll und nicht die externe IP?
Geht das überhaupt?

Danke!

 

[JonTec]

Hallo zusammen ich hoffe mir kann vielleicht jemand weiter helfen.

Ich habe alle beschriebenen Konfigurationsschrite gesetzt und es funktioniert auch alles, bis auf eine kleine Sache.

Folgende Netzwerk Konfiguration:
Server Netz: 192.168.1.0/24
Server IP: 192.168.1.40
Client Netz: 192.168.0.0/24
Server IP 192.168.0.30
VPN Netz: 10.8.0.0/24
Server IP: 10.8.0.1
Client IP: 10.8.0.2

Nun folgendes Problem befinde ich mich auf dem VPN Server (192.168.1.40) und setze Pings ab:
auf 192.168.0.1 (anderes Gerät im Client Netz) funktioniert
auf 10.8.0.2 funktionier
auf 192.168.0.30 funktioniert NICHT

Hat jemand eine Idee, warum ich vom VPN Server/ VPN Server Netz auf meine Client NAS (192.168.0.30) ohne Probleme über die VPN Tunnel Addresse(10.8.0.2) komme und auch auf jedes andere Gerät(z.B. 192.168.0.1) im Client Netz komme, aber keine Rückmeldung für die Adresse 192.168.0.30 bekomme?

 

[plang.pl]

Schon mal mit einer traceroute geschaut, wo der ping endet?
Und evtl Firewall-Regeln im Spiel?

 

[JonTec]

Firewall habe ich bereits testweise ausgeschaltet.

Bei traceroute auf 192.168.0.30 kommt nur * * *
Bei traceroute auf 192.168.0.1 kommt:
20 19 20 10.8.0.2
21 20 21 192.168.0.1