Hyper Backup Probleme Hyper Backup auf weiteres NAS

[blurrrr]

sondern nur ein einziges Quell-NAS und ein Ziel-NAS

Ups, dann hab ich das hier aber drastisch durcheinander gehauen... aber: ändert ja prinzipiell erstmal nichts daran, dass der Zugriff von NAS1 auf NAS2 nicht funktioniert, von daher bleib ich einfach mal ka**frech bei der DNS/Routing-Theorie (zumindestens solange, bis das auch ausgeschlossen ist).

Aus Sicht der OSI-Layer macht es auch überhaupt keinen Sinn, sich mit Problemen der oberen Schichten zu beschäftigen, wenn es schon an den unteren hapert (z.B. sind Einstellungen am Mailserver völlig egal, wenn das LAN-Kabel nicht steckt), von daher klärt man besser erstmal ab, ob denn die generellen Dinge funktionieren, bevor man sich in irgendwelchen Einstellungen/Logs/Löschungen/Neueinrichtungen verliert ??

Jetzt ist es vorbei... @blurrrr weiß wo ich wohne...

?

 

[luddi]

Ups, dann hab ich das hier aber drastisch durcheinander gehauen...

Was glaubst du wie lange ich gebraucht habe das hier beschriebene Setup zu verstehen... Man muss ja vielen leider oft alles aus der Nase ziehen bis man alle Fakten auf dem Tisch hat.

@Joogibaer Ich würde auch sagen dass du erst wie von @blurrrr erwähnt wurde auf dem Quell-NAS sicher stellst welche IP Adresse es über DNS aufgelöst bekommt.

 

[Joogibaer]

Das ist unfair, Blurr weiß es und ich nicht. Aber mal im Ernst Männer ist seid klasse. Nein, das Problem ist noch nicht gelöst, aber eure Unterstüzung ist Klasse und wenn ich wüsste das wir alle in der Nähe wohnen würden, stünde hier ein Kasten Gerstensaft

Genau, bei mir gibt es nur ein Quell Nas

 

[Joogibaer]

Was glaubst du wie lange ich gebraucht habe das hier beschriebene Setup zu verstehen... Man muss ja vielen leider oft alles aus der Nase ziehen bis man alle Fakten auf dem Tisch hat.

@Joogibaer Ich würde auch sagen dass du erst wie von @blurrrr erwähnt wurde auf dem Quell-NAS sicher stellst welche IP Adresse es über DNS aufgelöst bekommt.

Das liegt daran, das ich leider nur Laie bin und gar nicht verstehe was ihr von mir wollt. Die Sprache mit dem Autofahren, das habe ich verstanden

 

[luddi]

Also dann gehe doch bitte nochmals über Putty auf die Kommandozeile und gib folgendes ein.

nslookup <FQDN> | awk '/^Address: / { print $2 }'

Und für <FQDN> trägst du die Domain des Ziel-NAS ein.

Die Ausgabe sollte eine IP-Adresse sein die natürlich mit dem Anschluss an Standort B übereinstimmt.

 

[Joogibaer]

Synology hat gerade geantwortet. sie kommen jetzt wieder drauf.

Er sagt das Protokoll ist nicht gültig? Ist aber bis 2033 gültig?

 

[Joogibaer]

nslookup <https://xxxx.de> | awk '/^Address: / { print $2 }'
-ash: syntax error near unexpected token `|'


???

 

[luddi]

Lass mal bitte die eckigen Kalmmern weg und auch das https://

Beispiel: nslookup google.de | awk '/^Address: / { print $2 }'

 

[blurrrr]

Also wenn das der korrekte FQDN im Zertifikat ist, bringt es nichts, nur die Adresszeile zu schwärzen, also nimm mal lieber wieder raus den Screenshot (oder schwärz noch weiter). ??

@luddi Das mit dem awk hätte ich aber nicht gemacht, so sieht man nämlich nicht, welcher DNS-Server gefragt wird (mitunter liegt da ja schon das Problem). Findet der DNS-Server nix (oder ist keiner eingetragen), gibt es auch genau "nichts" zurück ?

 

[luddi]

[...] gibt es auch genau "nichts" zurück ?

Und genau dann ist ja ohnehin etwas faul
Aber du magst ja recht haben, einfach mal blank nur nslookup <FQDN> eingeben ohne awk.

Somit sieht man auch den DNS Server von dem wir die IP Adresse bekommen. Und ich traue mich wetten es wird zu 99,9%-iger Warhscheinlichkeit die Fritzbox sein die im lokalen Netzwerk den DNS spielt.

Ich bin jedenfalls gespannt ob hierbei die richtige IP Adresse durch die DNS Anfrage ankommt.

 

[blurrrr]

Interessant wäre natürlich noch die Frage nach dem "wann" und ob was im fraglichen Zeitraum passiert ist (Umstellung des Internetanschlusses, Routerwechsel, sonstige Veränderungen im Netz, etc.). Auch war hier ja schon öfters die Rede davon, dass die Syno den DNS-Server-Eintrag verliert (warum auch immer)... war meine ich nach irgendeinem Update... Aber grundsätzlich... immer OSI-Modell von unten nach oben, dann dauert es meist nicht so lang (oder man kann es sowieso nicht lösen) - Dinge wie "Kabel" und so, haben sich ja durch die Rechner-Erreichbarkeit direkt erledigt (ansonsten hätte ich da nämlich angefangen) ?

 

[Joogibaer]

Lass mal bitte die eckigen Kalmmern weg und auch das https://

Beispiel: nslookup google.de | awk '/^Address: / { print $2 }'

so bekomme eine ip Adresse aufgelöst, aber nur ip4 ....

Und es ist die selbe, die Strato in der Umwandlung hinterlegt hat, also alles gut

Jetzt weiß ich auch wo du wohnst Aber du machst nicht auf

 

[blurrrr]

so bekomme eine ip Adresse aufgelöst, aber nur ip4 ....

Und es ist die selbe, die Strato in der Umwandlung hinterlegt hat, also alles gut

Das ist aber garnicht gut, weil Du nicht zu Google willst... oder hast Du google.de durch Deinen FQDN ersetzt? ?

 

[Joogibaer]

Und genau dann ist ja ohnehin etwas faul
Aber du magst ja recht haben, einfach mal blank nur nslookup <FQDN> eingeben ohne awk.

Somit sieht man auch den DNS Server von dem wir die IP Adresse bekommen. Und ich traue mich wetten es wird zu 99,9%-iger Warhscheinlichkeit die Fritzbox sein die im lokalen Netzwerk den DNS spielt.

Ich bin jedenfalls gespannt ob hierbei die richtige IP Adresse durch die DNS Anfrage ankommt.

Server: 192.168.10.1
Address: 192.168.10.1#53

Non-authoritative answer:
Name: xxxx.de
Address: xxx.xx.xxx.xxx

IP Passt

 

[Joogibaer]

Das ist aber garnicht gut, weil Du nicht zu Google willst... oder hast Du google.de durch Deinen FQDN ersetzt? ?

ist meine IP das habe ich gemacht

 

[blurrrr]

? Ok, das ist schon mal sehr gut. Jetzt machste nochmal ein "traceroute <FQDN>" (vom Quell-NAS aus)

EDIT: Danach bleiben nur noch die Ports auf der Gegenseite (denke, Du wirst lokal keine explizite Firewall laufen haben, welche die Pakete der Quell-Syno wegwirft) und wenn mit den Remote-Ports auch alles in Butter ist, wird das Problem irgendwo am Remote-NAS liegen.

 

[Joogibaer]

Interessant wäre natürlich noch die Frage nach dem "wann" und ob was im fraglichen Zeitraum passiert ist (Umstellung des Internetanschlusses, Routerwechsel, sonstige Veränderungen im Netz, etc.). Auch war hier ja schon öfters die Rede davon, dass die Syno den DNS-Server-Eintrag verliert (warum auch immer)... war meine ich nach irgendeinem Update... Aber grundsätzlich... immer OSI-Modell von unten nach oben, dann dauert es meist nicht so lang (oder man kann es sowieso nicht lösen) - Dinge wie "Kabel" und so, haben sich ja durch die Rechner-Erreichbarkeit direkt erledigt (ansonsten hätte ich da nämlich angefangen) ?

es war der 13.04, dass lässt sich lokalisieren. Die erste Backups um 5 Uhr gingen durch, das letzte große nicht mehr.

Das Kabel steckt. Es ist weder was am Router noch ähnliches geändert worden. Kann es denn mit dem Zertifikat zusammen häängen?

 

[blurrrr]

Ist natürlich auch gut möglich, sofern das nicht nochmal explizit bestätigt wurde (ich meine, solche Fälle gab es hier auch schon öfters). Ich würde trotzdem noch den traceroute laufen lassen, danach nochmal von extern die Ports des betroffenen Anschlusses prüfen und wenn da alles tutti ist - wie gesagt - wird es irgendwas in den oberen OSI-Layern sein (sprich Dienst-/Anwendung-spezifisch). Vorteil ist, dass diese "grundlegenden" Dinge, ziemlich schnell abgeklopft sind. DNS und Routing kurz checken (dauert - wenn man weiss, was man zu machen hat - keine Minute), Remote-Ports scannen (kann laufen lassen, während man sich um DNS/Routing kümmert), damit ist dann aber direkt sichergestellt, dass es an solchen Dingen nicht liegt. Man ist ja auch gerne versucht, immer sofort "rumzufummeln" (keine Sorge, hab ich mich letztens auch wieder bei erwischt (interner Kram, passiert mir bei Kunden irgendwie nie) ?), da eh immer der Gedanke da ist "Ich hab doch nix gemacht, das müsste doch aber...", oftmals sind es dann aber irgendwelche Banalitäten... (mindestens in 80+% aller Fälle - sagt die Berufserfahrung), deswegen ist von unten nach oben hocharbeiten meist auch das effektiveste - machste es andersrum, frisst es nur unnötig viel Zeit.

Traceroute + Ports prüfen und danach guckste mal wegen dem Zertifikat (wäre jetzt meine Reihenfolge)

 

[luddi]

Danach bleiben nur noch die Ports auf der Gegenseite

Das war ja der Punkt den ich dachte schon geklärt zu haben gemeinsam mit @Joogibaer
Weder Firewall auf dem Ziel-NAS ist aktiv und die Ports der Fritzbox am Zielstandort sind eingerichtet.
Siehe Screenshots aus #20 (Firewall) und #35 (Fritzbox Ports).

 

[blurrrr]

Zwischen "eingerichtet" und "funktioniert" liegen aber auch irgendwie "Welten" und grade die Fritzbox spackt dabei manchmal recht gern rum. Kurzum: Vertrauen ist gut, Kontrolle ist besser ??

EDIT: Wenn der Port nicht offen sein sollte, Portweiterleitung löschen und Portweiterleitung neu einrichten.