SSH Tunnel für RTRR?

  • Hi Zusammen,


    ich hoffe hier ist ne RTRR-Experte. Aktuell habe ich noch keine VPN-Server, werde eins besorgen (braucht allerdings etwas Zeit, weil ich dann gleich gescheit machen will).


    Als Übergangslösung habe ich einen SSH-Tunnel für den RTRR-Backup eingerichtet. Blöderweise mag der QNAP nicht und behauptet, es wäre keine Verbindung zum RTRR Server vorhanden.


    Code
    [Hybrid Backup Sync] Failed to complete Backup job: "Daily Backup". Cloud storage service unavailable. Try again later, or contact your cloud storage provider for details.. Check logs for more information.

    Dabei habe ich auf dem Terminal vom Quell-QNAP erfolgreich per Telnet mit Port 8899 auf Ziel-QNAP getestet (kommt ne Salat, aber vielversprechend). Wird evtl. neben Port 8899 noch weitere gebraucht? Oder funktioniert das nicht mit TCP?


    VPN-Vorschläge ist leider nicht geeignet in meinem Fall da ich keine entsprechende Host hierfür habe, aber auf Quell-Ort und Ziel-Ort sind jeweils eine Linux-Maschine 24/8 am Laufen, daher SSH-Tunnel. Und nein, auf Linux-Maschinen richte ich VPN nicht ein, das hat meine Gründen.


    Übrigens: Ist RTRR ein proprietäre QNAP-Lösung? Ich dachte, RTRR wäre das übliche wie Rsync.:/


    Viele Grüße

    Floh

  • Erst mal vorweg: Gut, dass du die RTRR-Synchronisation mit ssh oder vpn absichern willst. RTRR war ein möglicher Einfallspunkt des letzten massiven Verschlüsselungsangriffs. Mit ssh oder vpn abgesichert ist ein solcher Angriff nicht möglich.


    ssh kannst du genauso sicher machen wie vpn, wenn du wirklich sichere Passwörter verwendest oder komplett auf ssh-Keys gehst und vor allem keine Accounts mit simplen Standardpasswörtern vergisst. Meiner Erfahrung nach läuft ssh stabiler als vpn. Ich nutze ssh ausschließlich über ssh-Keys. Ein Wechsel auf vpn ist nicht angedacht.


    RTRR ist, zumindest mit dem Namen, eine proprietäre Qnap-Lösung. Wenn du keine Echtzeitsynchronisation willst, sondern dir (nächtliche) Backup-Jobs reichen, kannst du mMn. ebenso gut Rsync nehmen.


    Ich benutze hier in HBS eine Rsync-Verbindung über ssh auf ein Synology-NAS (da geht RTRR ohnehin nicht). Das Backup läuft stabil und zuverlässig. Auf deine Frage nach dem Problem kann ich daher nur bedingt antworten.


    Die Fehlermeldung heißt eigentlich nur, es geht nicht, weil der RTRR-Server nicht gefunden wird. Aber ob nun die IP falsch ist, der ssh-Login nicht klappt oder der RTRR-Server nicht läuft, wird nicht gesagt. Schau mal, wenn möglich, in das Logfile rein, auf das in der Fehlermeldung verwiesen wird. Das könnte sehr aufschlussreich sein.


    Klappt denn die ssh-Verbindung? Mir ist nicht klar, was du da mit Telnet machen willst. Telnet hat im Internet heute nichts mehr verloren (außer man bastelt gerade an den ssh-Einstellungen herum und braucht einen Noteingang, falls man die Konfiguration zerschießt), da die Daten einschließlich Passwort im Klartext übertragen werden. Der Port ist nicht 8899, sondern 22 (bzw. besser nicht 22, sondern den sollte man auf einen hohen Port umlegen, das aber bei der Portweiterleitung im Router/Fritzbox).


    Wenn du in HBS bei Speicherplätze den RTRR-Server angelegt hast mit ssh-Verschlüsselung, kannst du dann die Verbindung erfolgreich testen? Funktioniert anschließend in der Konfiguration die Auswahl der Laufwerke auf dem Ziel-NAS?

  • Hallo Anthracite, erstmal vielen Dank für die Rückmeldung.


    Wenn mit der SSH gut funktioniert, kann ich auch gern auf VPN verzichten, aber erstmal testen... (Bin eher ein Fan von SSH-Tunnel als VPN-Tunnel, aber man darf natürlich nicht pauschalisieren)


    Das Absichern ist für mich eine Selbstverständlichkeit und alles andere kommt für mich nicht in Frage! Grundsätzlich nutze ich SSH mit der Konfigurationen:

    • Andere Port (also bloß nicht default-Port 22), ist schon mal halber Miete
    • root-Anmeldung über SSH verweigert (wozu? Wenn dann erst dort mit sudo)
    • Ausschließlich mit Pubkey, also Password-Only ist nicht zugelassen (PW-Brute-Force ohne Key laufen ins Leere)

    Damit habe ich langjährig gute Erfahrung, aber das ist jetzt erstmal andere Geschichte.


    Aktuell habe ich gute Gründen RTRR statt RSync zu nehmen, müsste ich nochmal nachschauen was genau der Grund war...


    Ich würde liebend gerne Log-Daten schauen, aber ich habe verschiedene stellen gesucht und werde da einfach nicht fündig. :/ Das was ich am nächsten Gefunden habe ist diese Fehlermeldung:

    system.log:

    Code
    [Hybrid Backup Sync] Backup job "Daily Backup": Failed to complete data integrity check. Cloud storage service unavailable. Try again later, or contact your cloud storage provider for details.

    Klappt denn die ssh-Verbindung?

    Meinst Du den SSH von Quell-QNAP zum Ziel-QNAP, oder meinst Du den SSH-Tunnel?


    SSH Tunnel steht ja. Das habe ich per Telnet überprüft. Zum Telnet möchte ich hinweisen, daß ich das nur zum Testen benutze, sonst nix. Getestet habe ich so:

    Auf Quell-QNAP den Telnet-Befehl eingegeben, auf dem Quell-SSH-Server per Port 8899 zuzugreifen und da habe ich Rückmeldung von der Ziel-QNAP erhalten. D.h. telnet [lokaler-SSH-Server-IP] 8899


    Gerade, beim Schreiben dieses Post, erneut mit Telnet getestet und dieses Mal fehlgeschlagen. Ich habe festgestellt, daß es sich um einen DNS-Problem handelt da dort die IPv6-Adresse leider einen Zahlendreher hat. Behebe ich gleich... also erstmal zum Büro fahren. :rolleyes: Melde mich nochmal...


    UPDATE:

    Zurück vom Büro, DNS-Einstellungen korrigiert. Eben nochmal getestet mit Telnet und da passt (192.168.X.X ist die IP-Adresse von der lokaler SSH-Server der per Tunnel an Ziel-SSH-Server geht):

    Code
    [~] # telnet 192.168.X.X 8899
    ?ʥ]?

    Auf dem lokalen SSH-Server läuft ein Dienst:

    Code
    autossh -p XXX22 -o ServerAliveInterval 60 -o ServerAliveCountMax 3 -N -L 0.0.0.0:8899:backup-qnap:8899 floh@XXXXX.XXXXXX.XXX

    XXX = Aus Sicherheitsgründen maskiert ;)

    backup-qnap = Ziel QNAP


    Und nun? :/ Was mir auffällt, wenn ich unter Externes NAS auf aktualisieren anklicke (also das Kreisrunde Pfeil Symbol rechts oben). Mal seht keine Kapazität, mal wird es angezeigt, mal ist es nicht auffindbar, mal ist er erreichbar... warum eigentlich? :/


    Bildschirmfoto 2021-07-04 um 14.51.56.pngBildschirmfoto 2021-07-04 um 14.53.45.pngBildschirmfoto 2021-07-04 um 14.54.41.png


    Idee? Verbindung zu Remote ist stabil.

    Einmal editiert, zuletzt von floh79 ()

  • Vorweg wieder: Ich stochere hier im Trüben, da ich weder RRTR noch Windows benutze, sondern Rsync und Mac.


    Die Fehlermeldung hilft und leider noch nicht weiter.


    -L 0.0.0.0:8899:backup-qnap:8899

    Die Bindadresse 0.0.0.0 ist mMn. unnötig. Ob sie schadet, weiß ich nicht. Ich hätte den Parameter gesetzt zu -L 8899:backup-qnap:8899.


    Wichtig ist aber, dass backup-qnap die Adresse ist, die dein Backup-NAS auf dem SSH-Endpunkt hat. Wenn du dich mit ssh direkt zum Backup-NAS verbindest, also ssh-Endpunkt und Backup-NAS dasselbe sind, dann ist backup-qnap gleich localhost. Eine nummerische Adresse geht aber auch und vermeidet eventuell Missverständnisse.


    HBS kann den SSH-Tunnel selbst aufbauen. Diese Möglichkeit scheinst du aber nicht nutzen zu wollen, da du den SSH-Tunnel als Service startest. In dem Falle musst du HBS ohne SSH konfigurieren, d. h. den Punkt "ssh-Verbindung verwenden" darfst du nicht ankreuzen. Das RTRR-Ziel ist dann der Rechner, auf dem der SSH-Service gestartet wurde. Wenn es sich dabei um das Ausgangs-NAS, also dasjenige, auf dem HBS läuft, handelt, könntest du Probleme kriegen, da dort der Port 8899 schon belegt sein dürfte, eben für das lokale RTRR. Dann müsstest du im SSH-Aufruf einen anderen Port zuweisen.


    Besser ist es mMn. aber, man lässt HBS den SSH-Tunnel selbst aufbauen. Der SSH-Service wird nicht gestartet, dafür wird "ssh-Verbindung verwenden" angekreuzt. HBS kann (nach meinen Versuchen) keine Passphrase für den ssh-Key setzen. Wenn du Login über ssh-Keys machst, musst du das Passwort in HSB leer lassen und den ssh-Key ohne Passphrase anlegen. Das entstehende Sicherheitsrisiko kannst du vermeiden, indem du mit mehreren ssh-Key-Dateien arbeitest, den ssh-Key mit leerer Passphrase ausschließlich zur RTRR-Synchronisation nimmst und eventuell auf dem Zielrechner in authorized_keys ausschließlich das zur Synchronisation nötige Kommando (vermutlich ein rsync-Aufruf) zulässt. (Aber erst versuchen, ob es überhaupt geht, bevor man an der Sicherheit weiter bastelt.)


    Wie gesagt, mit rsync funktioniert's ...

  • Hi,

    Die Bindadresse 0.0.0.0 ist mMn. unnötig. Ob sie schadet, weiß ich nicht. Ich hätte den Parameter gesetzt zu -L 8899:backup-qnap:8899.

    0.0.0.0 ist in meinem Fall notwendig, da sonst der Tunnel nur für localhost erreichbar ist. Das liegt vermutlich daran, daß ich den Tunnel per Service, also Root starte. Ich muß bei Gelegenheit schauen, daß ich den Tunnel-Service ohne root starte (ich versuche grundsätzlich auf root zu verzichten, wenn es nicht sein muß. Aber jetzt erstmal gehts darum, daß RTRR über SSH funktioniert).


    HBS kann den SSH-Tunnel selbst aufbauen. Diese Möglichkeit scheinst du aber nicht nutzen zu wollen, da du den SSH-Tunnel als Service startest.

    Diese Möglichkeit ist mir nicht bekannt und den Option habe ich bis jetzt nicht gesehen. Sonst hätte ich das gleich so gemacht. Wo finde ich das? (evtl. Screenshot?) Wer weiß ob das bei QuTS Hero anders ist.:/


    Wichtig ist aber, dass backup-qnap die Adresse ist, die dein Backup-NAS auf dem SSH-Endpunkt hat. Wenn du dich mit ssh direkt zum Backup-NAS verbindest, also ssh-Endpunkt und Backup-NAS dasselbe sind, dann ist backup-qnap gleich localhost. Eine nummerische Adresse geht aber auch und vermeidet eventuell Missverständnisse.

    Genau richtig, so hab ich auch eingestellt. Hier ein Überblick:

    [Lokaler QNAP] => [Lokaler SSH-Server] => Tunnel (-L 0.0.0.0:8899:backup-qnap:8899) =>

    (... BÖSES Internet ...)

    => [Remote SSH-Server] => [Remote QNAP aka backup-qnap]


    Auf Lokaler QNAP habe ich bei HBS den lokale SSH-Server als RTRR Host eingetragen mit Port 8899.

    Hätte ich hier was falsch gemacht, würde ich gar keine Information von der Remote-QNAP erhalten (siehe letzten 3 Screenshots, wo es mal geht und mal nicht geht :/ )


    Jetzt, nachdem ich den Fehler mit DNS auf dem Remote-Ort korrigiert habe, erhalte ich ein AttributError:?:Muß ich nochmal in Log-Daten durchforsten.


    Danke für den Tipp, aber ich benutze bereits mehrere Keys.:thumbup: So kann ich gezielt bestimmte Keys wieder rausnehmen (z.B. Laptop Abhande gekommen, auch wenn er verschlüsselt ist).


    UPDATE - Logeintrag gefunden:

    Wie immer xxx = von mir maskiert. Interessant zu sehen, daß QNAP mit Jenkins arbeitet. :)

    Nur versteh ich nicht, warum solche Fehler passiert? Zugangsdaten ist *definitiv* korrekt.


    Vor allem warum Failover? Wenn Failover, wird dann andere Port benutzt den ich vielleicht auch Tunneln sollte?:/


    Grüße

    Floh

    2 Mal editiert, zuletzt von floh79 ()

  • Diese Möglichkeit ist mir nicht bekannt und den Option habe ich bis jetzt nicht gesehen. Sonst hätte ich das gleich so gemacht. Wo finde ich das? (evtl. Screenshot?) Wer weiß ob das bei QuTS Hero anders ist.

    Ich habe diese Option (Checkbox) in QuTS Hero:


    quts_rtrr_ssl.jpg

    Einmal editiert, zuletzt von binam ()

  • Danke an binam, genau die Stelle meinte ich.


    Bei Rsync heißt das "Verschlüsselungsport verwenden" und erlaubt noch die Angabe einer Portnummer (dafür wird der weiter oben angegebene Port nicht benutzt). Die Funktion dürfte dieselbe sein.


    Die Fehlermeldung ist blöde, denn die sieht nach Programmierfehler aus, wo du nichts machen kannst, sondern nur versuchen kannst, den Fehler zu umgehen.

  • Achso, das ist aber SSL, nicht SSH-Tunnel (also das Tunneling an sich). ;) Oder habe ich da was falsch verstanden.

    Die Fehlermeldung ist blöde, denn die sieht nach Programmierfehler aus, wo du nichts machen kannst, sondern nur versuchen kannst, den Fehler zu umgehen.

    Das habe ich befürchtet. :/ Ich probier mal mit Ticket, erhoffe dabei wenig ala: "Das ist eine sehr spezielle Konstellation, den wir nicht offiziell Supporten. Ticket geschlossen.".


    Übrigens, eben nochmal kontrolliert, nun andere Fehlermeldung:

    Hm... Connection reset during authentication was ist jetzt wieder? :rolleyes:


    Ich glaube RTRR taugt einfach nicht für SSH-Tunnel.

    Einmal editiert, zuletzt von floh79 ()

  • Achso, das ist aber SSL, nicht SSH-Tunnel (also das Tunneling an sich). ;) Oder habe ich da was falsch verstanden

    Da habe ich was falsch verstanden. Oder besser gesagt nicht genau genug gelesen. 'tschuldigung. Das Kreuzchen für ssl ist an genau der Stelle, wo bei Rsync die ssh-Verbindung gewählt werden kann. Da habe ich ohne Nachdenken geschlossen, das sei dasselbe. Ist es aber nicht, wie du auch schreibst.


    Auf ssl würde ich mich nicht verlassen. Das sichert zwar die Verbindung gegen ungewollte Lauscher, nicht jedoch den Anmeldeprozess. Und beim Qlocker-Angriff war, wenn ich das richtig in Erinnerung habe, der RTRR-Zugang in Verbindung mit dem fest codierten Testaccount einer von zwei Angriffspunkten.


    Funktioniert denn die RTRR-Verbindung ohne den VPN-Tunnel, also wenn man direkt an den RTRR-Port geht? Das halte ich von der Sicherheit nicht für eine Dauerlösung, sollte aber vertretbar sein für ein Stündchen, wenn du eine qts-Version nach April 21 hast. Ganz einfach um Fehler auszuschließen.


    Hast du mal ausprobiert, ob es geht, wenn du sowohl im Tunnelaufbau als auch in HBS ausschließlich nummerische IP-Adressen an Stelle von Namen verwendest? (Um die Namensauflösung als Fehler auszuschließen.)


    Da ich kein zweites Qnap-NAS habe, kann ich nicht mal eben einen Test machen, um zu sehen, ob es funktioniert.


    Was ich als Lösungen sehe:

    1) Du löst die Probleme und bringst RTRR mit deinem ssh-Tunnel zum Laufen.


    2) Du nimmst VPN.


    3) Du synchronisierst mit Rsync über ssh-Tunnel.


    Ich würde 3) machen. Sowohl Rsync als auch ssh sind weit verbreitete und damit gut getestete und untersuchte Programme.

  • Alles klar, japp SSL allein mag zwar etwas helfen, aber den Port möchte ich trotzdem nicht öffnen. So wie Du schriebst nicht darauf verlassen, daß alles gut ist.:thumbup:

    unktioniert denn die RTRR-Verbindung ohne den VPN-Tunnel, also wenn man direkt an den RTRR-Port geht?

    Japp es funktioniert ohne SSH-Tunnel und zwar als der Ziel-QNAP noch neben der Quell-QNAP stand, also bevor ich den Ziel-QNAP zum Büro gebracht und deshalb SSH-Tunnel aufgebaut habe.


    Hast du mal ausprobiert, ob es geht, wenn du sowohl im Tunnelaufbau als auch in HBS ausschließlich nummerische IP-Adressen an Stelle von Namen verwendest?

    Eben nochmal alles auf IP umgestellt, leider mit selben Fehlermeldung. Hab sogar 2mal getestet, einmal mit AttributError und einmal ServiceError: Connection reset during authentication.


    Habe eben Ticket aufgemacht, erhoffe wir schon geschrieben wenig, aber wer weiß... evtl. ist da tatsächlich ein Bug, oder es wird mehr als nur Port 8899 benötigt (z.B. 22? Oder 8080?).


    Sieht so aus, daß ich doch auf VPN-Router warten soll. :/


    UPDATE: Eben habe ich zurück auf URLs umgestellt (statt IP-Adressen da ich dies vorhin testhalber umgestellt habe), hab Spaßhalber trotzdem Backup gestartet und siehe, es hat funktioniert und wurde erfolgreich abgeschlossen. Dann habe ich nochmal gestartet... Fehlermeldung.:cursing::thumbdown:


    Das Problem ist also, es funktioniert nur sporadisch, ähnlich wie bei Informationen Abrufen. Aber warum eigentlich? Timeout-Problem? X/ Das ganze beweist, daß die Konfigurationen meinerseits alles korrekt sind (URLs, IP, Authinfos, ...).

    2 Mal editiert, zuletzt von floh79 ()

  • Japp es funktioniert ohne SSH-Tunnel und zwar als der Ziel-QNAP noch neben der Quell-QNAP stand,

    Hast du in dem Moment, als die noch nebeneinander standen, eine Verbindung über den ssh-Tunnel ausprobiert? Das würde wieder ein paar Fehler wie schlechte Verbindung, Firewall oder Router im Büro ausschließen.


    Ansonsten, wenn der VPN-Router ohnehin kommen soll, würde ich auf den warten.

  • Als der Ziel-QNAP noch hier stand, habe ich das leider nicht getestet da mir nicht klar war daß das Probleme bereiten würde.


    Vielen Dank, daß Du Dir Zeit genommen hast und mit mir darüber ausgetauscht hast. :thumbup:


    Ich werde hier berichten, was von QNAP-Support zurückgekommen ist, egal ob mit positiver oder negativer Ausgang.


    UPDATE:

    Support weigert die Unterstützung mit der Begründung: Der Ziel QNAP (TS-569Pro) ist ein EOL-Gerät und somit die alte Firmware nicht supported ist.:rolleyes: Ja ne schon klar, ich soll also auf Gut und Glück neues QNAP kaufen für Backup? So viel zum Nachhaltigkeit...


    Hab ihm geschrieben, daß auf dem Ziel-QNAP die neueste verfügbare HBS-Version installiert ist, also Version 3.0.210506 von 14. Mai 2021.

    Einmal editiert, zuletzt von floh79 ()

  • Hallo floh79

    unter Linux kann man jedes System mounten, dass einen SSH-Server laufen hat.

    Da braucht man aber fuse und sshfs dazu.

    Eventuell lässt sich ja dies per entware-ng installieren.

  • frosch2: Muß ich mir mal anschauen. Danke für den Hinweis.


    Mir ist heute erst eingefallen, daß ich eine neuen Kunden-QNAP bei mir stehen habe. Prompt zum Testen "ausgeliehen". :saint:


    Ich habe hier lokal eine SSH-Tunnel (D.h. über einen dritten Linux-PC) aufgebaut und konnte erfolgreich testen. Dann habe ich den Kunden-QNAP zum Büro gebracht, angeschlossen und daheim nochmal (aber dieses Mal remote über SSH-Tunnel) und da funktioniert auch einwandfrei.


    Support von QNAP meint, sie können nicht eskalieren, weil mein Backup-QNAP EOL ist. Auf diesem QNAP (TS-569Pro) hat die Installierte HBS leider nur Version 3.0.210506 und die neuen QNAPs haben 17.0.0512. :rolleyes:

    Sieht nicht so aus, daß ich mit Trick Version 17 auf dem ollen TS-569Pro installieren kann. :(


    D.h. für TS-569Pro muß ich wohl anders lösen.


    Danke Euch!

    Grüße

    Floh