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.

[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

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:

[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.

Zitat von Anthracite

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. 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):

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

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

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.

Hi,

Zitat von Anthracite

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).

Zitat von Anthracite

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.

Zitat von Anthracite

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 AttributErrorMuß ich nochmal in Log-Daten durchforsten.

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

UPDATE - Logeintrag gefunden:

2021-07-05 00:01:13,837(ERROR) [rtrr(1620):_failover_service_error()] {
    "case": "failed run func=_get_account_info with unexpected error",
    "detail": {
        "adater": {
            "IP": "xxx.xxx.xxx.xxx",
            "direction": "local2remote",
            "display_name": "Virtual Switch 3",
            "free": 1310718594,
            "interfaceName": "qvs0",
            "speed": 1310720000,
            "speed_bytes": 1310720000
        },
        "ex_name": "AttributeError",
        "traceback": [
            "Traceback (most recent call last):",
            "  File \"/var/lib/jenkins/jobs/CC3_PY3_QPKG/workspace/ARCH/x86_64/master/master/qpkg/output/shared/python/lib/python3.7/site-packages/ucc/rtrr.py\", line 1591, in _failover_service_error",
            "  File \"/var/lib/jenkins/jobs/CC3_PY3_QPKG/workspace/ARCH/x86_64/master/master/qpkg/output/shared/python/lib/python3.7/site-packages/ucc/rtrr.py\", line 1471, in _run_func_with_retrying",
            "  File \"/var/lib/jenkins/jobs/CC3_PY3_QPKG/workspace/ARCH/x86_64/master/master/qpkg/output/shared/python/lib/python3.7/site-packages/ucc/rtrr.py\", line 1869, in _get_account_info",
            "  File \"/var/lib/jenkins/jobs/CC3_PY3_QPKG/workspace/ARCH/x86_64/master/master/qpkg/output/shared/python/lib/python3.7/site-packages/ucc/rtrr.py\", line 1680, in _check_login_server",
            "  File \"/var/lib/jenkins/jobs/CC3_PY3_QPKG/workspace/ARCH/x86_64/master/master/qpkg/output/shared/python/lib/python3.7/site-packages/ucc/rtrr.py\", line 1631, in _check_auth_error",
            "AttributeError: 'list' object has no attribute 'get'",
            ""
        ]
    },
    "ex_msg": "'list' object has no attribute 'get'"
}

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

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

Zitat von Anthracite

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:

2021-07-06 00:01:15,661(ERROR) [rtrr(1636):_check_auth_error()] error share_dirs={
    "_elapsed": "0.45 sec",
    "_trace_log": "/mnt/ext/opt/HybridBackup/rr2/logs/rr2__rr2_api.get_remote/trace.log",
    "error": {
        "case": "Rr2Client.run_plugin()",
        "detail": {
            "ex_name": "Rr2ExClientGetEofError",
            "plugin_args": {},
            "plugin_name": "get_server_settings",
            "traceback": [
                "Traceback (most recent call last):",
                "  File \"/home/sw5/build/qpkg/hbs/Hybrid_3/shared/rr2/bin/connector/rr2_conn.py\", line 90, in __init__",
                "  File \"/home/sw5/build/qpkg/hbs/Hybrid_3/shared/rr2/bin/connector/rr2_conn.py\", line 120, in _create_conn",
                "  File \"/home/sw5/build/qpkg/hbs/Hybrid_3/shared/rr2/bin/connector/rr2_conn.py\", line 113, in _retry_call",
                "  File \"/home/sw5/build/qpkg/hbs/Hybrid_3/shared/rr2/bin/rru/util_time.py\", line 197, in retry_call",
                "  File \"/home/sw5/build/qpkg/hbs/Hybrid_3/shared/rr2/bin/rru/util_time.py\", line 137, in __retry_internal",
                "  File \"/home/sw5/build/qpkg/hbs/Hybrid_3/shared/rr2/bin/connector/rr2_conn.py\", line 142, in _connect",
                "  File \"/home/sw5/build/qpkg/hbs/Hybrid_3/shared/rr2/bin/connector/rtrr_fastconn.py\", line 667, in Client",
                "  File \"/home/sw5/build/qpkg/hbs/Hybrid_3/shared/rr2/bin/connector/rtrr_fastconn.py\", line 213, in do_auth",
                "EOFError: Connection reset during authentication",
                "",
                "During handling of the above exception, another exception occurred:",
                "",
                "Traceback (most recent call last):",
                "  File \"/home/sw5/build/qpkg/hbs/Hybrid_3/shared/rr2/bin/rr2_client.py\", line 201, in run_plugin",
                "  File \"/home/sw5/build/qpkg/hbs/Hybrid_3/shared/rr2/bin/rr2_client_bas.py\", line 841, in new_conn_and_login",
                "  File \"/home/sw5/build/qpkg/hbs/Hybrid_3/shared/rr2/bin/rr2_client_bas.py\", line 836, in new_conn_and_login",
                "  File \"/home/sw5/build/qpkg/hbs/Hybrid_3/shared/rr2/bin/connector/rr2_conn.py\", line 101, in __init__",
                "rr2_error.Rr2ExClientGetEofError: Connection reset during authentication",
                ""
            ]
        },
        "ex_msg": "Connection reset during authentication"
    }
}

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

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

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.

Zitat von Anthracite

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.

Zitat von Anthracite

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.

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

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.

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. 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.

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".

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.

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