Probleme beim Wechsel der WAN IP

    Hallo, Leute!


    Bei meinem NAS (TS-464 mit QTS 5.0.1.2277) tritt folgendes Problem auf:

    Wenn sich die WAN-IP ändert, während sich der NAS im Betrieb befindet, kann ich mich nicht mehr mit dem Hostnamen anmelden, sondern nur noch mit der IPv4/IPv6. Betrieb über SMB ist auch nicht möglich, da die Anmeldung ebenfalls über den Hostnamen passiert. Fehlermeldung:

    Code
    "Netzadresse nicht gefunden"

    Dieses Fehlverhalten kann ich auflösen, in dem ich das LAN-Kabel des NAS ziehe und stecke. Der Switch ist ein QSW-2104-2T, der mit dem Fehler aber nichts zu tun hat - passiert auch mit einem Netgear-Switch. Das Fehlverhalten kann auch beseitigt werden, indem man hier den Übernehmen-Button betätigt:


    SMB.jpg


    Bei dem Versuch, ein /ect/init.d/smb.sh restart zu erzeugen, wird allerdings jede ausgeführte Zeile mit "Access denied" quittiert, obwohl ich Admin (mit neuem Namen) bin. Auf meinem NAS ist die Qu-Firewall installiert. Egal, ob die ein- oder ausgeschaltet ist. Wie beschrieben passiert das nur beim Wechsel der WAN-IP.


    Hat jemand von euch auch mal ein solches Verhalten beobachtet?

    Kennt jemand den Grund, warum der SMB-Restart per SSH nicht funktioniert?


    Bin für jede Antwort dankbar! :)

    Ich behaupte mal, das in Deinem Netzwerk etwas nicht richtig konfiguriert ist.

    Die WAN IP sollte überhaupt keinen Einfluss auf die interne Namensauflösung haben!

    Wenn Du über eine öffentliche Adresse (z.B. "meinNAS.de") zugreifst, dann ist das auch schlecht, wenn kein VPN benutzt wird.

    Da würde ich einen Fehler in der DynDNS Konfiguration suchen.

    Aber wenn die Namensauflösung nur "interne" Hostnamen kennt, dann darf der Wechsel der WAN IP keinen Einfluss haben.


    Gruss


    P.S. User mit Admin-Rechten haben bei QNAP nicht die gleichen Möglichkeiten wie der echte Admin.

    Entweder den Befehl mit sudo davor testen, oder den echten Admin nehmen.

    Die Empfehlung, diesen Account zu deaktivieren, ist der größte Bull...t, den QNAP von sich gibt.

    Danke für deine Meinung!


    Das mit dem "sudo" hab ich mir schon gedacht. Aber geht das auch in einem Script? Ich meine das Passwort für Sudo??


    Zum DNS: Es handelt sich nicht um das DDNS sondern um das einfachen DNS! Deine Aussage

    Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiert! :handbuch::arrow: Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

    Zitat von FSC830

    Die WAN IP sollte überhaupt keinen Einfluss auf die interne Namensauflösung haben!

    teile ich durchaus mit dir. Es ist aber trotzdem so. Die Namensauflösung in einer Windows11 Command Box funktioniert über IPv4 und IPv6 (ping -4 (-6) Hostname". Trotzdem kann ich weder im MS-Edge noch bei "Netzwerk" (Win11) den Hostnamen angeben. Man sollte annehmen, dass es Windows Problem wäre, aber in der Command Box werden die Namen aufgelöst. Außerdem, wenn ich den bewussten Button drücke, oder die LAN-Verbindung kurz trenne (siehe #1), dann geht's ja wieder. Übrigens "Hostname = NAS.fritz.box" und der Ping geht (auch ohne .fritz.box), aber der Name wird im Brownser und der Netzwerkumgebung nicht aufgelöst - IP geht.

    Einmal editiert, zuletzt von q.tip ()

    Ich kenne den Unterschied zwischen DNS und DynDNS ;) , aber da war noch nicht klar, ob der Hostname extern zu erreichen ist oder nicht.

    Bei externem Zugriff käme bei WAN IP Änderung ein fehlerhaft konfiguriertes DynDNS in Frage.


    Bei interner Namensauflösung stellt sich die Frage, wo die intern erfolgt.

    Hast Du einen DNS Server (außer der Fritzbox)?

    Sind die Geräte in der FB mit ihrem Hostnamen registriert?

    Haben die Geräte, die den Namen nicht auflösen können, eine statische oder eine DHCP Adresse?

    Wird der DNS Server über DHCP mit verteilt?

    Sind zusätzliche DNS eingetragen?

    Was sagen in beiden Fällen (Auflösung möglich/nicht möglich) traceroute und nslookup?


    Gruss

    Problem erkannt! Es ist IPv6. Mit nur IPv4 funktioniert alles. Es geht um die interne Namensauflösung. Wenn sich die IPv4 ändert, dann ändert sich auch der Präfix von der IPv6. Window10/11 nutzt primär IPv6. Leider nicht intern mit der linklokalen Adresse. Es nutz die globale IPv6. Entweder QTS 5.01 kommt mit IPv6 nicht richtig zurecht, oder es liegt an der Qu-Firewall. Eine Lösung wäre IPv6 zu deaktivieren.


    Danke nochmals für deine Hilfe.

    Einmal editiert, zuletzt von q.tip ()

    Wohl eher kommt QTS nicht richtig damit zurecht, dass wir Deutschen nicht mit IPv6 zurechtkommen und sich die GUA tatsächlich an ein und dem selben Anschluss ändern kann :S

    Wie oft kommt das denn bei dir vor? Eigentlich sollte es ja niemals vorkommen, aber mehr als 1x im Jahr wäre schon übel...

    Bei der Telekom und co. die immer noch Zwangstrennung haben bei jeder Neuverbindung.

    Daher kannst da IPv6 nur zum spielen aber nicht produktiv nutzen.

    =O =O

    Und ich dachte, dass ich mit DG schon schlecht bedient bin, wo sich die v6 alle Jubeljahre (aus unerfindlichen Gründen) mal ändert.

    Reicht für produktives Arbeiten aber auch nicht aus...

    Aber gut, wir bezahlen ja auch um Fernsehen in HD sehen zu können... irgendwann kommen bestimmt auch wir im Jahr 2018 an :/

    tiermutter

    Bei mir ändert sich jede Nacht zwischen 3-4Uhr die IP-Adresse. Das ist von mir auch so gewollt und entsprechend eingestellt. Das sehe ich als (kleinen) Sicherheitsaspekt. Ich denke auch, dass QTS für mein Problem verantwortlich ist. Ich denke, hierfür ein Ticket aufzumachen, stellt für den QNAP Support eine unüberwindliche Herausforderung dar, oder? Und so sehr stört es mich auch nicht mehr, seitdem ich mein NAS nachts ausschalte. Was mich wundert ist, dass es hier im Forum keine ähnlichen Probleme gibt. DualStack (IPv4 und IPv6 simultan) sollten doch eigentlich weit verbreitet sein. Wahrscheinlich liegt es daran, dass die meisten User keine "Zwangstrennung" aktiviert haben, wenn sie ihr NAS im Dauerbetrieb laufen haben.


    Crazyhorse

    Die Telekom hat schon lange keine Zwangstrennung mehr! Du kannst sie aktivieren, wenn du in der Fritz!Box dafür den Haken setzt, sonst passiert da gar nichts!


    Allerdings wird alle 180 Tage bei den IP-basierten Anschluss der Telekom wirklich zwangsgetrennt! ;)

    Zitat von q.tip

    Wahrscheinlich liegt es daran, dass die meisten User keine "Zwangstrennung" aktiviert haben, wenn sie ihr NAS im Dauerbetrieb laufen haben.

    Ja, erstens keine Zwangstrennung bzw ständige v6 Änderungen bei mir und zudem verwende ich keine Hostnamen, weil ich mir v4 Adressen viel leichter merken kann :S

    Viele andere haben v6 oft deaktiviert, weil v6 scheinbar etwas zum Fürchten ist ;)



    Ich würde erstmal noch nicht an QNAP herantreten, sondern schauen wo das Problem nun wirklich angesiedelt ist. Da ich mit der internen Namensauflösung nichts am Hut hab, kann ich aber leider nicht helfen...

    Hier mal ein kleines Update zum Problem: Ich habe bei QNAP Anfang März ein Ticket aufgemacht. Nach diversen Traces, die ich dem Support auf Verlangen zugeschickt habe, können die Entwickler den Fehler aber nicht finden - Problem immer noch ungelöst. Weitere Erkenntnisse von mir: Mit der Windows11 Netzwerkumgebung: Eingegebenen Zeile: \\2003-c61-32d-c700-2df1-beff-725e-dda2.ipv6-literal.net\ komme ich nicht rein (Netzwerkfehler), wohl aber mit der Link Lokalen IPv6 (fe80::). Der Befehl /etc/init.d/smb.sh restart beseitigt den Fehler. Der Entwickler hatte behauptet, bei ihm würde der Fehler nicht auftreten. Vielleicht hat jemand von euch auch eine Fritz!Box und einen Dual-Stack IP-Anschluss und könnte mal testen, ob der Fehler auch bei ihm auftritt. Einfach in der Fritz!Box unter "Online-Monitor" auf "Neu Verbinden" klicken und dann versuchen, mit der globalen IPv6 per SMB auf den NAS zu kommen.

    Ich weiß leider nicht, wie genau die prefix delegation abläuft, aber ganz offensichtlich bekommt QTS nichts von dem Wechsel mit und bezieht demnach nicht das neue Prefix, sodass es nicht erreichbar ist. Ob jetzt aber QTS selbst dafür Sorge tragen muss, sich über eine Änderung zu informieren oder ob das der Router machen muss, weiß ich nicht. Hier wäre Barungar ein guter Ansprechpartner, aber der ist hier nicht mehr aktiv und nur noch in anderen Foren aufzufinden.

    Dabei stellt sich dann auch die Frage, wie IPv6 bei Dir verteilt wird und was am NAS eingestellt ist.


    Wie dem auch sei, testen kann ich nichts, weil ich mein v6 Präfix gar nicht ohne weiteres geändert bekomme und genau das ist ja die Krux: IPv6 ist nicht dafür vorgesehen, dass wir wie die Blöden unser Präfix ändern. Eventuell gehen ja manche Entwickler wie die von MS darauf ein und bauen wieder Krücken, damit man auch in der technischen Hinterwelt zurechtkommt :|... Aber da wäre halt die eingangs gestellte Frage: Wessen Aufgabe ist es denn (sich) über einen Präfixwechsel zu informieren?

    Achja, Deine IPv6 Adresse solltest Du trotz sich änderndem Präfix nicht vollständig bekannt geben, denn daraus lassen sich Deine MAC und das default PW ableiten ;)

    Einmal editiert, zuletzt von tiermutter () aus folgendem Grund: Ein Beitrag von tiermutter mit diesem Beitrag zusammengefügt.

    Hallo tiermutter

    Danke für deine Antwort. Alles was dort oben als IP/Präfix/Interface-ID zu sehen ist, habe ich schon "modifiziert". Die Präfix Delegation wird von QTS in sofern korrekt behandelt, dass ja nach Präfixwechsel alle Protokolle wieder korrekt arbeiten, außer SMB über die globale IPv6 - die link Lokale IPv6 funktioniert ja auch. Im "Netzwerk-und virtueller Switch" wird die neue globale IPv6 auch korrekt angezeigt. Irgendwas im SMB-Protokoll bekommt den Präfixwechsel nicht mit. Momentan behelfe ich mich damit, dass ich in meinem Script "DDNS-Updater.sh" ja sowieso den Präfixwechsel erkenne und dann ein /etc/init.d/smb.sh restart ausführe. Nur das ist ein weinig "mit Kanonen auf Spatzen geschossen". Die Routine läuft relativ lang und ist entsprechend aufwändig. Es soll ja auch in der Linux-Welt ein reload anstatt des restart für die smb.sh geben, aber eben nicht bei QNAP. Wenn ich nur wüsste, welche Routine beim Klick auf "Übernehmen" (siehe #1) ausgeführt wird. Das scheint fixer zu gehen.

    Einmal editiert, zuletzt von q.tip ()

    Zitat von q.tip

    außer SMB über die globale IPv6

    Ah ok, das hatte ich nicht rausgelesen... das ist dann ja richtig komisch... Da habe ich aber auch keinerlei Ideen... außer halbgare Workarounds:

    - Zwangstrennung abschalten

    - Statt GUA die LLA oder eine ULA für IPv6 intern verwenden

    - Intern ganz auf v6 verzichten

    - Eine Revolte starten, damit die dummen Präfix Wechsel endlich aufhören :)

    Die Präfixwechsel durch die "Zwangstrennung" sind ja erwünscht! :) Jede Nacht um 03:00 Uhr. Ist ein Teil meiner Sicherheitsstrategie! ;) Außerdem kann ich ja auch mit IPv4 reinkommen, oder wie du schreibst, mit der link Lokalen IPv6. Trotzdem erwarte ich von QNAP, dass die solch einen krassen Fehler fixen können!!

    Ich find das schon traurig, dass hier im Forum keiner in der Lage ist, diesen Fehler einmal zu verifizieren! :rolleyes:

    Es scheint offensichtlich kein Interesse an ein fehlerfreies QTS zu geben, solang man von fehlerfrei überhaupt reden kann.

    Ich denke, es gibt schlimmere Fehler, die die Leute beschäftigt ;)


    Davon abgesehen handelt es sich um IPv6, das auch in 2023 noch nicht überall angekommen ist. Ich kann es nicht so einfach testen, da sich meine v6 nicht einfach so ändert, sonst hätte ich dir den Gefallen getan.

    Das weiß ich doch. Du bist ja auch die gute Fee des Forums und hättest mir bestimmt geholfen. Aber das Forum besteht ja nicht nur aus uns beiden! Und IPv6 hat heute wohl fast jeder(!), denn die IPv4-Adessen sind eher aufgebraucht!

    Danke für die Blumen, ich trage mir diesen bedeutsamen Tag samt bedeutsamen Titel im Kalender ein 8o


    IPv6 haben und v6 nutzen / im LAN verteilen sind zwei Paar Schuhe. Oft liest man noch, dass empfohlen wird v6 zu deaktivieren, weil es Probleme bringen kann. Die Masse hat halt noch Angst vor v6 und ganz ehrlich: wenn man nicht unbedingt den direkten Zugriff mittels v6 auf das NAS braucht, werden es auch die wenigsten im NAS (und anderen Geräten) aktivieren. Wozu auch, denn kaum jemand wird intern mittels v6 zugreifen. Ich habe es überall wo es geht auch nur aktiv, damit ich in x Jahren nicht doof dastehe weil ich mich nie damit auseinander gesetzt habe, wenn v6 wirklich wichtig geworden ist und es vllt kein v4 mehr gibt.

    Tatsächlich kenne ich nur sehr wenige Leute, die v6 aktiv nutzen und auch Verfechter sind, es zu nutzen. Im Gegensatz dazu kenne ich einige Leute die eigentlich so richtig tief in der Networking Materie drin stecken und einen Sch**** auf v6 geben. Und selbst das finde ich nicht verwerflich, da es noch zu viele Unklarheiten gibt und die Vorteile insbesondere in Deutschland nichtmal ausgespielt werden, stattdessen werden wieder Krücken gebaut, damit wir Blöden halbwegs mit dem zurechtkommen, was uns die Provider liefern.

    Es ist 2023, aber die Welt ist immer noch nicht bereit für IPv6 ;(

    Zitat von tiermutter

    Achja, Deine IPv6 Adresse solltest Du trotz sich änderndem Präfix nicht vollständig bekannt geben, denn daraus lassen sich Deine MAC und das default PW ableiten ;)

    Somit ist IPv6 für mich (solange ich es nicht verstehe) die größte Sicherheitslücke schlechthin. Deshalb ist bei mir das auch komplett abgeschaltet. :mcup: