Es gibt seit weit über 10 Jahren AES in Hardware. Und da sind 40MBit/s nix was signifikant Last erzeugt.
Leider können Fritzboxen WireGuard nur in Software! IPsec dagegen ist hardwarebeschleunigt. Wobei neuere Fritzboxen auch bei Wireguard in Software recht performant sind.
Schon klar, aber ChaCha20-Poly1305 lässt sich sehr effektiv ohne spezielle Befehlserweiterungen oder Spezielle Recheneinheiten auf einer CPU verarbeiten. Daher schaffen damit die alten 7490 Gurken auch noch diese Bandbreiten, was sie bei IPsec nie hinbekommen würden.
Was genau meinst du damit? Den SSH Port von 22 auf einen hohen Wert ändern und dann auch den Im Router weiterleiten?
Für IPv4:
In der Fritzbox unter Internet → Freigaben → Portfreigabe→ Gerät auswählen oder hinzufügen → Freigaben bearbeiten oder hinzufügen, und dann im Dialog Port an Gerät mit 22 belegen (das ist ssh), Port extern gewünscht mit nnnnn, wobei 32768 ≤ nnnnn ≤ 65535.
Wenn du dann dein Gerät von extern ansprichst, musst du ssh Adresse -p nnnnn verwenden.
Bei IPv6 ist eine Änderung des Ports nicht nötig.
Durch die Verwendung eines anderen Ports für den externen ssh-Zugang erhältst du zwar keinen zusätzlichen Schutz per se, denn ein Angreifer kann auch den Port herausfinden, aber in der Praxis gibt es wesentlich weniger Angriffsversuche. Bei IPv6 ist das nicht nötig, da der IPv6-Adressraum derzeit noch nicht gescannt werden kann.
Was ich nicht verstehe: wieso ist es für SSH okay den Port weiterzuleiten, für die QVPN App aber nicht?
Das ist eine Risikoabschätzung.
Wenn du z. B. die Qnap Weboberfläche (Port 80) per Weiterleitung freigibst, dann kann sich, vorausgesetzt du hast sichere Passwörter gewählt, ein Angreifer nicht durch Raten oder Durchprobieren des Passwortes Zugang verschaffen. Aber die Http(s)-Schnittstelle hat eine große Angriffsfläche (viele unterschiedliche HTTP-Anfragen sind möglich), die Qnap-GUI ist komplex, in einer neuen Version und wird nur von Qnap genutzt und ist folglich vergleichsweise schlecht getestet und analysiert. Die Wahrscheinlichkeit, dass hier durch einen Fehler eine Lücke vorhanden ist, mit der ein Angreifer sich ohne Passwort Zugriff verschaffen kann, ist relativ hoch.
ssh ist zum sicheren Login geschaffen worden, hat eine kleine Angriffsfläche (nur der Login-Mechanismus) und wird millionenfach dafür eingesetzt. Daher ist der ssh-Login sehr gut getestet und analysiert. Die Wahrscheinlichkeit, dass ein Angreifer hier über einen Fehler in der Implementierung reinkommt, ist sehr gering. Qnap hat bei ssh eine Standardimplementierung (ältere Version, aber sicher) im Einsatz.
VPN ist im Allgemeinen auch sicher, aber lt. FSC830 hat Qnap wohl bei der Implementierung geschlampt und damit eine Lücke gerissen, weswegen QVPN nicht so vertrauenswürdig ist wie ssh.
VPN in der Fritzbox ist besser getestet, kann natürlich trotzdem einen Fehler enthalten. Da Fritzboxen sehr viel im Einsatz sind, halte ich da das Risiko für gering.
Der CDU-Hack letztes Jahr wahr wohl durch einen Fehler in der VPN-Implementierung der genutzten Sicherheitssoftware möglich.
Wirklich sicher bist du nur, wenn du das NAS nicht mit dem Internet verbindest. Dann ist es in deinem Falle aber auch nutzlos.
VPN ist im Allgemeinen auch sicher, aber lt. FSC830 hat Qnap wohl bei der Implementierung geschlampt und damit eine Lücke gerissen, weswegen QVPN nicht so vertrauenswürdig ist wie ssh.
Das ist schon eine Weile her, aber dennoch bemerkenswert, daß eine Software, die für "sicheren" Zugang gedacht ist, selbst zum Schwachpunkt geworden ist.
Und da wir ja alle hier die wunderbaren Sicherheitsvorkehrungen und abgeschotteten QNAP Systeme kennen (</Sarkasmus> würde ich mich niemals auf derartiges Verlassen. Schon gar nicht auf so einem alten NAS unt entsprechend alter Firmware.
Zumal der NAS als Endpunkt für VPN für mich nur letzte Wahl wäre.
Fritzbox mit Wireguard ist leider auch etwas tricky, da sich AVM hier auch nicht wirklich an Standards hält.
Hat mich 2 Abende beschäftigt, bis mein S2S Tunnel mit einer Fritte endlich lief.
Gruss
da sich AVM hier auch nicht wirklich an Standards hält
Daher nehme ich auch pivpn, da haste original wireguard.
3. Auf dem lokalen NAS in HBS bei Rsync oder RTRR den ssh-Tunnel und den ssh-Port wählen
Alle Schritte außer diesen habe ich hinbekommen. Wenn ich den RTRR Server des entfernten NAS beim lokalen NAS hinzufügen will, finde ich keine Option für SSH. Kann es sein, dass HBS nur mit Rsync über SSH gehen kann, nicht jedoch mit RTRR?
Rsync hat aber leider auch nicht funktioniert. Bei dem alten TS 110 ist es wohl so, dass Rsync nicht über SSH geht sondern nur über den Rsync Dienst/Port. Werde es nun anders herum nochmal probieren: RTTR und Rsync Server beim lokalen NAS und das entfernte greift darauf zu.
Ich synchronisiere zwischen einem Qnap TS-877 und einem Synology NAS. Da gibt es ohnehin kein RTRR, da man dafür zwei Qnap bräuchte, und Rsync hat auf Anhieb inklusive ssh-Tunnel funktioniert. RTRR hat wohl eine Verschlüsselung eingebaut, zumindest wenn mann "SSL" ankreuzt, aber da RTRR wohl schon mal der Einfallspunkt für eine üble Schadsoftware war, gebe ich keine Empfehlung für Qnaps Selbstbaulösung ab.
Wenn du es nicht schaffst, über HBS direkt, d. h. mit Einstellungen in HBS, den ssh-Tunnel zu nutzen, gibt es noch Plan B, den ssh-Tunnel manuell aufzubauen.
Für RTRR über ssh-Tunnel Plan B: Dazu gibst du auf dem lokalen NAS in der Shell ein
ssh benutzer@Adresse_fernes_LAN -p nnnnn -L 38899:localhost:8899Dabei ist nnnnn der Port, den du in der fernen Fritzbox auf Port 22 deines fernen NAS weitergeleitet hast.
In HBS auf dem lokalen NAS legst du dann einen einen RTRR-Server an, nimmst als "IP-Adresse/Hostname" localhost, als Port 38899 und schaltest "SSL" nicht ein (die Verschlüsselung erfolgt ja schon über den Tunnel).
Nachteil davon ist erst einmal, dass so ein ssh-Tunnel gerne zusammenbricht und dass er nicht automatisch geöffnet wird. Die Nachteile kann man beseitigen, aber das gehen wir erst an, wenn die Lösung prinzipiell funktioniert.
Plan B ist allerdings keine Out-of-the-Box-Lösung mehr.
Kann es daran liegen, dass das entfernte NAS nach außen nur eine IPv6 Adresse hat?
Das geht auch mit IPv6, und die Syntax des ssh-Befehls ist dieselbe. Du brauchst in der Fritzbox dann natürlich eine IPv6-Freigabe. Für IPv6 kannst du keinen alternativen Port wählen, sondern der Port ist zwingend 22 (was bei IPv6 nicht zu dem Problem erhöhter Angriffsversuche führt, wie man es bei v4 hat, s. o.). Damit ist nnnnn aus dem ssh-Befehl dann 22.
Damit wir nicht raten müssen,
Mach In beiden Fällen die externe Adresse unkenntlich, aber lass die interne Adresse stehen.
Zu dem Passwort-Problem: Sagt er wirklich, Passwort falsch, oder sagt er "User/Passwort" falsch? Letzteres kann auch vorkommen, wenn der Benutzer existiert aber sich nicht per ssh anmelden darf.
Muss ich nun auf dem Lokalen oder auf dem entfernten NAS den RTRR Server starten?
Wenn ich dich richtig verstanden habe, dann willst du vom lokalen NAS auf das entfernte NAS sichern.
In dem Fall musst du nur auf dem entfernten NAS den RTRR-Server starten.
Muss ich die 38899 sowohl bei Server als auch beim Client als Port angeben oder nur bei einem von beiden?
Du hast einen Tunnel, der nicht nur von einem NAS zu einem anderen geht, sondern auch von einem Port zu einem anderen. Auf dem lokalen NAS gehen die Daten in Port 38899 rein und kommen auf dem fernen NAS aus Port 8899 raus, und die Antworten gehen auf dem fernen NAS in Port 8899 rein und kommen auf dem lokalen NAS auf Port 38899 raus.
Also nimmst du auf dem lokalen NAS (das ist der Client) immer den Port 38899, auf dem fernen NAS (das ist der Server) immer den Port 8899, auch wenn es sich um dieselbe Verbindung handelt.
"IP-Adresse/Hostname" localhost >> das kann ich nur beim Client eintragen, korrekt?
Als IP-Adresse/Hostname nimmst du in beiden Fällen nicht die tatsächliche Adresse des Gegenübers, sondern den Eingang des ssh-Tunnels, und der ist jeweils auf dem Gerät selbst, also localhost auf Client wie auch auf Server. Da man aber, so ich das recht in Erinnerung habe, auf dem Server keine Adresse des Gegenübers braucht, es ihm also egal ist, von woher die Daten kommen, musst du im Endeffekt doch nur auf dem Clienten localhost eintragen.
Sieht für mich so aus, dass es geklappt hat.
Ja, das hat geklappt.
Nur nutzt es dir nichts.
An dieser Stelle endet die Analogie des Tunnels. Bei einem Straßentunnel kannst du in beide Richtungen gleichermaßen ein- und ausfahren, beim ssh-Tunnel nicht. Beim ssh-Tunnel können Anfragen nur auf der Seite reingehen, die den Tunnel aufgebaut hat, und in der anderen Richtung können nur Antworten auf genau diese Anfragen geschickt werden. Die andere Seite kann nicht von sich aus neue Anfragen durch den Tunnel schicken, aber genau dies hast du versucht.
Wenn du wie jetzt den Tunnel vom fernen NAS auf das lokale NAS aufbaust, dann muss der RTRR-Client auf den fernen NAS und der RTRR-Server auf dem lokalen NAS laufen, und damit kannst du dann Backups vom fernen NAS auf das lokale NAS machen. Da du dies gar nicht vorhast, da die falsche Richtung, brauchst du keine Energie mehr in die Fehlersuche zu stecken.
Also zurück auf Start.
Du musst mit Putty auf das lokale NAS und dort den Tunnel zum fernen NAS aufbauen.
Da das nicht funktioniert hat, zur Fehlersuche. Funktioniert ssh benutzer@Adresse_fernes_LAN (also Parameter für den Tunnel weggelassen)?
Wenn nein, funktioniert es, wenn du statt den Namens die numerische IP (IPv4 oder IPv6) angibst?
Mod: Zitate ohne Quellenangabe ... korrigiert! 
Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen
Wenn du wie jetzt den Tunnel vom fernen NAS auf das lokale NAS aufbaust, dann muss der RTRR-Client auf den fernen NAS und der RTRR-Server auf dem lokalen NAS laufen, und damit kannst du dann Backups vom fernen NAS auf das lokale NAS machen.
Den Server auf dem Lokalen NAS und vom fernen NAS aus verbinden, hat aber auch nicht geklappt. Aber wie du sagst, jetzt auch egal.
Funktioniert ssh benutzer@Adresse_fernes_LAN (also Parameter für den Tunnel weggelassen)?
Nein.
Wenn nein, funktioniert es, wenn du statt den Namens die numerische IP (IPv4 oder IPv6) angibst?
Nein.
Hier die Port Freigabe im fernen Vodafone Router
Hier Putty auf dem Lokalen NAS. Ich habe nochmal alle von dir genannten Befehle getestet.
Aber mit Putty kannst du dich per ssh mit dem fernen NAS verbinden?
Wie sind denn da deine Aufrufparameter?
(Du hast mit der IPv6-Anbindung und dem Vodafone-Router zwei Komponenten, die ich nicht habe, weswegen ich das hier nicht nachstellen oder verifizieren kann.)
Bei Putty nimmst du einen anderen Weg, da gehst du über MyQnapCloud,
Versuch auf dem lokalen NAS einmal
ssh benutzer@Wxxxxx.mqnapcloud.com -p nnnnn -L 38899:localhost:8899(also halt mit der Adresse, die auch in Putty steht).
Geht es dann?
Der direkte Weg, also ohne MyQnapCloud, auf dein fernes NAS, hat vermutlich noch überhaupt nicht funktioniert. Das kann daran liegen, dass der ferne Internetprovider etwas blockiert, dass es an IPv6 liegt oder dass du etwas falsch machst. Mit der Verbindung an ein fernes NAS über IPv6 habe ich noch keine Erfahrung.