Beiträge von ::1

Zitat von Phino

Aber wo müssen sie hin, um physikalisch eindringlich auf das Problem aufmerksam zu machen?

Sternmarsch nach

Deutsche Glasfaser Holding GmbH
Am Kuhm 31
46325 Borken

Zitat von early.camp7097

Es werden zwar noch eine IPv6-Adresse (2a00:6020:9800::xxx/64) und ein IPv6-Präfix (2a00:6020:9841:2a00::/56) zugewiesen, wird aber netzseitig nicht gerouted.

Da kannst du dich mit themaze (siehe dieser Thread) zusammentun, der hängt mit seinem DG-Anschluss am selben BNG-Cluster wie du mit deinem (/56-PD-LAN-Präfixe aus 2a00:6020:9800::/41 = 2a00:6020:9800:100::/56 - 2a00:6020:987f:ff00::/56, WAN-Adressen aus 2a00:6020:9800::/112).

Zitat von lukas52

Mir ist auf dem Weg zu der Firewall Einstellungen so viele Aktive private Netzwerke.

Diese Beobachtung wirkt auf mich auch irritierend!

Eine Nachfrage bei Tante Google ("Windows Firewall zeigt mehrere aktive private Netzwerke mit gleichem Namen an") ergab die KI-Antwort:

Zitat

Wenn die Windows-Firewall mehrere aktive private Netzwerke mit demselben Namen anzeigt (z. B. "Netzwerk 1", "Netzwerk 1"), liegt meist eine fehlerhafte Registrierung von Netzwerkprofilen nach Treiberupdates, VPN-Nutzung oder Adapterwechseln vor . Ein Neustart, das Löschen der Netzwerkprofile über die Registrierung (Registry) oder die Neuinstallation der Netzwerkadapter im Geräte-Manager schafft Abhilfe.

Lösungsmöglichkeiten:

• Netzwerkadapter zurücksetzen: Öffnen Sie den Geräte-Manager, deinstallieren Sie die Netzwerkadapter (WLAN/LAN) und starten Sie den PC neu, damit sie frisch erkannt werden.
• Netzwerkprofile löschen (Registry):
  1. regedit in die Windows-Suche eingeben und starten.
  2. Navigieren zu: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles.
  3. Die dort aufgelisteten Schlüssel (Ordner) können gelöscht werden. Nach einem Neustart wird das Netzwerk neu erkannt.
• Netzwerkverbindungen bereinigen: Deaktivieren Sie nicht benötigte virtuelle Adapter (z. B. von VirtualBox, VMware oder VPN-Software), die als separate Netzwerke erscheinen könnten.
• IP-Stack zurücksetzen: Öffnen Sie die Eingabeaufforderung als Administrator und führen Sie netsh int ip reset aus, gefolgt von einem Neustart.

Diese Schritte führen dazu, dass Windows die Duplikate entfernt und die Netzwerkkonfiguration bereinigt

Ich würde insbesondere mal das Löschen der Netzwerkprofile per Registry durchführen: Also alle "Unterordner/Schlüssel" {...} in der linken Baumstruktur unterhalb "Profiles" löschen:

Grandiose, aber wahrscheinlich unbeliebte Idee: Fritzbox-Einstellungen sichern, Fritzbox dann auf Werkseinstellungen zurücksetzen, dann die Sicherung wieder einspielen könnte helfen.

Das Problem tritt bei mir erst seit einigen Tagen und nur sporadisch an jenen meiner PC auf, auf denen ich den validierenden Resolver unbound verwende. Und es hilft dann immer ein Neustart des unbound-Dienstes, vermutlich weil dadurch dessen Resolver-Cache geleert wird, der zuvor vermutlich einen Sperreintrag (does not exist) für "glasfaserforum.de" enthielt.

Ich würde vermuten, dass das Problem mit jedem validierenden Resolver auftreten könnte, und das sollten heutzutage eigentlich alle Resolver sein, die von Internet-Providern zur Nutzung durch deren Kunden bzw. von den big Playern wie Google u.s.w. für die allgemeine Verwendung bereitgestellt werden.

Ich stecke jetzt fachlich nicht so tief im DNSsec, aber ich deute die Situation so, dass die NSEC3-Einträge in der de-Domain die Nicht-Existenz der Child-Domain "glasfaserforum.de" behaupten. Andererseits nutzt "glasfaserforum.de" selbst kein DNSsec (vielleicht einführen?). Wie da genau die Regeln der Delegierung von signierten Parent- (de) zu nicht-signierten Child-Zonen (glasfaserforum.de) aussehen müssen, damit validierende Resolver bzw. deren Nutzer keine Probleme bekommen (sprich ein NXDOMAIN zurückgeben bzw. erhalten), vermag ich an dieser Stelle auch nicht zu sagen.

Wie groß ist denn der DHCP-Pool in der Fritzbox? (von: ? bis ?)

Als würde der DHCP-Server der Fritzbox per DHCP NAK die angeforderte/erneuerte IPv4-Adresse ablehnen ...

Also ich hätte zu Analyse eine Idee, ist aber leider etwas aufwändig:

Man würde sich wünschen, man könnte per Wireshark den Netzwerk-Traffic während der Netzinterface-Initialisierung (LAN oder WLAN) mitschneiden. Das ist leider so nicht möglich.

Aber es funktioniert mit folgendem Trick (aber sehr aufwändig):

Installiere dir auf einem betroffenen Windows-PC eine virtuelle Maschine (z.B. mittels "Virtualbox") mit Windows und konfiguriere den virtuellen LAN-Adapter der VM in "Bridge-Modus" (verbunden mit dem LAN- oder WLAN-Adapter auf dem Windows-Host).

Jetzt kannst du auf dem Windows-Host einen Wireshark-Mitschnitt starten (entweder für den LAN- oder WLAN-Adapter, ja nachdem, welchen die VM nutzt) und die VM hochfahren. Dann siehst du im Mitschnitt anschließend den gesamten Initialisierungs-Traffic des virtuellen VM-Adapters, woraus man im besten Fall erkennen könnte, wo das Problem liegt (erfordert allerdings tiefes Netzwerk-Know-how).

Zitat von HubeBube

Da ist das Setup im höchsten Maße strubbelig.

Eigentlich nicht, er bekommt nur keine IPv4-Adressen via DHCP, und es wäre zu klären, warum die Windows-Clients den DHCP-Server der FB nicht erreichen, bzw. dieser die DHCP-Requests der Windows-Clients nicht beantwortet.

Ich habe ja immer noch eine falsche WLAN-Konfiguration im Verdacht, deswegen wäre interessant, an einem Windows-Client das WLAN mal abzuschalten und ihn per LAN-Kabel direkt an die FB anzuschließen.

Zitat von HubeBube

Die IPv6 DNS Server sind nämlich nicht die von Deutsche Glasfaser sondern eigene im Heimnetz:

DNSServer : fd3f:347a:fd1f:0:ab6:57ff:fe8c:2df2
2a00:6020:461b:a300:ab6:57ff:fe8c:2df2

Ja, das ist doch normal: Eine FB gibt immer sich selbst als DNS-Server an die LAN-Clients bekannt. Sie arbeitet schließlich als DNS-Proxy/Forwarder. Nur sie selbst verwendet die in ihr konfigurierten Resolver (z.B. die von DG) zur DNS-Weiterleitung.

Zitat von HubeBube

Ich vermute mal, dass diese Seite funktioniert: https://test-ipv6.com/

Zitat von lukas52

ja genau die Seite funktioniert.

Das erstaunt mich, denn "test-ipv6.com" ist ausschließlich über IPv4 erreichbar [Begründung]

C:\>nslookup -q=A test-ipv6.com
Server:  localhost
Address:  ::1

Nicht autorisierende Antwort:
Name:    test-ipv6.com
Address:  139.162.169.184


C:\>nslookup -q=AAAA test-ipv6.com
Server:  localhost
Address:  ::1

Name:    test-ipv6.com

Wie konnte also die Seite erreicht werden, wenn IPv4 gar nicht funktioniert (bzw. nur APIPA-Adressen 169.254.x.x. vorhanden sind)?

Zitat von themaze

Langfristig macht das alleine Finanziell Sinn, vielleicht endet es ja in einer Sonderkündigung und einem Wechsel.

1&1 macht, wenn ich nicht irre, aber DS-Lite over PPPoE - das muss dein Router dann können.

Zitat von lukas52

Würde ich auch so sehen aber was mich stutzig macht, dass es jetzt echt lange alles geklappt hat und plötzlich auf allen Windows PC's im Netzwerk die Probleme sind

Sind die Windows-PC über LAN oder WLAN angebunden? Falls über WLAN, kannst du es mal testweise für einen dieser PC mit Anbindung über LAN-Kabel versuchen?

Falls über WLAN: Hast du evtl. ein anderes Gerät im Netz, das als WLAN-Station (aber ohne DHCP-Serverfunktion) dient, und das dummerweise dieselbe SSID verwendet wie die Fritzbox?

Zitat

Ich verstehe deren System nicht.

Siehe hierzu die Hinweise von HubeBube in #10: Ticket via DG Portal offen halten durch den Punkt "Nachfrage zu Ticket #...".

Bei denen ist jedes Ticket immer ein neues Problem ...

Zitat

Ich kann in eine Nachricht im Ticketsystem nicht mal alles Schreiben was ich an Details gesammelt haben und übermitteln möchte. Auch den Packet-Capture kann ich nicht als pcap oder zip sondern nur als Textdatei anhängen.

PDF als Attach werden m.W. akzeptiert: Du kannst das Problem z.B. in einem Word-Dokument ausführlich beschreiben (und den Packet-Capture als Bild dort einfügen, das ist aussagekräftig genug) und dieses als PDF speichern. Im Ticket dann nur eine Kurz-Darstellung mir Verweis auf das PDF.

Lazze : Mit dem DNSsec-Validator (https://dnsviz.net/d/www.glasfaserforum.de/dnssec/) wird mir aktuell folgendes Problem angezeigt:

Mit einem Mouseover auf NSEC3 bekommt man sinngemäß die Diagnose:

"NSEC3 record(s) proving non-existence (NODATA) of glasfaserforum.de/DS"

Es liegt vermutlich daran, dass "glasfaserforum.de" an meinem Windows-PC mit dem dort verwendeten DNSsec-validierenden Resolver unbound zeitweise nicht auflösbar ist (ich muss den unbound-Dienst dann immer stoppen und neu starten ).

Zitat von themaze

In der Tat habe ich ein komplexeres Netzwerk aber nur einen OPNsense Router welcher direkt am Modem hängt mit mehreren Netzwerke. Das mit den Interfaces ist soweit kein Problem bei wechselnden Adressen. Nur Jetzt wo IPv6 ins und vom Internet Tot ist, ist das nervig.

Vielleicht noch ein Hinweis, aber vermutlich muss ich dir das gar nicht erzählen:

Ich würde parallel zu dynamisch zugewiesenen globalen IPv6-Adressen im LAN noch permanent ULA (fd00::/8 -> fdxx:xxxx:xxxx::/48 (xx:xxxx:xxxx auswürfeln) -> LAN1: fdxx:xxxx:xxxx:1::/64, LAN2: fdxx:xxxx:xxxx:2::/64, LAN3: fdxx:xxxx:xxxx:3::/64, ...) verwenden.

Die sind fest und immer verfügbar. Sie werden bei rein LAN-interner Kommunikation bevorzugt genutzt und sind dynamisch in einem lokalen DNS-Server registrier- und somit in einer LAN-internen DNS-Domain komfortabel auflösbar . Voraussetzung ist bei allen Endgeräten allerdings eine aktuelle Default Policy Table (kann man sich unter Windows via netsh int ipv6 show pref anzeigen lassen), die einen Eintrag für fc00::/7 enthält - zur Not muss man diesen von Hand ergänzen, falls das jeweilige System dafür eine Schnittstelle bietet (problematisch bei IOT-Geräten wie Druckern usw., aber die spricht man halt zur Not ausschließlich via IPv4 an)

So könntest du das Inside-Interface deines Proxies (falls "one-armed" ULA als secondary IPv6 address) stets über eine feste ULA adressieren.

Zitat von themaze

Gibt es Business Tarife (von der DG) mit fixen Prefixen für Ottonormalos?

Kann ich nicht sagen - aber DG berät dich hier bestimmt hervorragend bei der Auswahl eines geeigneten Business-Tarifs.
Mir ist jedenfalls nicht bekannt, dass DG gegen einen geringfügigen Aufpreis feste IPv6-Adressen an Privat-Anschlüssen bereitstellt.

Das ist dann wohl das LAN-Interface deines Routers.

Hier das Ping-Ergebnis an meinem DG-Anschluss

Und so sieht es aus Sicht von London und Amsterdam aus:

Aber es bestätigt meine Vermutung aus #11.

Zitat von themaze

Anhand des Suffixes erkenne ich dass es mein Reverseproxy ist.

Die scheinst ein komplexeres strukturiertes LAN mit mehreren LAN-Segmenten (VLANs) und evtl. nachgelagerten Routern zu betreiben?

So etwas ist m.E. nicht gut verträglich mit wechselnden IPv6-LAN-Präfixen - da muss man sich (zu) sehr darauf verlassen, dass die dynamischen Prozesse, die mit einem Präfix-Wechsel ausgelöst werden, auch zuverlässig funktionieren (z.B. nachgelagerte IPv6-PD an sekundäre LAN-Router, DynDNS für von außen erreichbare LAN-Instanzen, dynamische Anpassung von Firewall-/Proxy-Regeln, usw.)

In solchen Fällen wäre m.E. ein Business-Anschluss mit festen IPv6-Adressen die bessere Wahl.

Zitat von archerbyte

Bis lang hatte ich zuhause eine eigene VPN (OpenVPN) und hab mit DynDNS (DuckDNS) meine IP auflösen können und konnte immer auf mein Netzwerk zugreifen. Seit kurzem haben wir Glasfaser von der deutschen Glasfaser bekommen und jetzt klappt gar nichts mehr.

Ich nutze einen TP-Link MR550.

Wie schon in den anderen Kommentaren erklärt, wird dein Szenario, wenn überhaupt, an einem DG-Anschluss aufgrund von CGNAT nur noch mit IPv6 funktionieren.

Voraussetzung dafür ist aber ein stabiles IPv6. Falls die IPv6-Adresse des WAN-Ports deines Routers mit "2a00:6020:1000:" beginnt, ist die Chance für stabiles IPv6 sehr hoch, denn dann liegt die ältere/frühere Adressierungs-Systematik vor, bei der man auch nach Neuverbindungen i.d.R. stets dieselben IPv6-Adressen für LAN und WAN zugewiesen bekommt (also quasistatische Adressen - allerdings ist das seitens DG nicht garantiert).

Andernfalls hast du einen DG-Anschluss mit neuer Adressierung-Systematik. Wie erst vor kurzem gelernt, zeichnet der sich dadurch aus, dass du bei einer Neuverbindung häufig neue IPv6-Adressen für LAN und WAN bekommst, bzw. DG auch Zwangstrennungen in gewissen Zeitabständen durchführt, die im Ergebnis ebenfalls zu geänderten IPv6-Adressen führen. Und diese Neuanschlüsse fallen in letzter Zeit dadurch negativ auf, dass IPv6 schlicht nicht funktioniert.

Nun kannst du bzgl. deiner OpenVPN-Verbindung argumentieren: Kein Problem, ich habe ja DynDNS!

Richtig - DynDNS ist in Verbindung mit IPv6 aber variantenreicher in der Umsetzung, insbesondere weil der Endpunkt der OpenVPN-Verbindung nicht zwingenderweise mit der WAN-Adresse des Routers zusammenfällt (der Router also zugleich der OpenVPN-Peer ist), sondern auch im LAN hinter dem Router liegen kann (weil die IPv6-LAN-Adressen per Definition öffentlich erreichbar sind).

Der zweite Fall führt dann zu der Frage, wer DynDNS macht: Das OpenVPN-Gerät im LAN für seine LAN-IPv6-Adresse? Oder der Router stellvertretend für das OpenVPN-Gerät, d.h. der Router muss nicht deine IPv6-WAN-Adresse, sondern die IPv6-LAN-Adresse des OpenVPN-Geräts im DynDNS registrieren. Ob dein TP-Link MR550 das kann, sei mal dahingestellt. Hinzu kommt dann ja auch noch die Thematik, dass in der Firewall des Routers eine Freischaltung für den Zugriff von außen auf dein OpenVPN-Gerät vorhanden sein muss (bei IPv4 würde man hier eine "Portweiterleitung" einrichten - dies "Denke" bei IPv6 bitte komplett vergessen), die der Router bei einem IPv6-Adresswechsel auch dynamisch anpassen können muss. Eine Fritzbox kann das z.B. dadurch, dass die Freigabe nur den IPv6-Host-Identifier des OpenVPN-Geräts enthält und der IPv6-LAN-Präfix dynamisch ergänzt wird. Aber auch das scheitert, wenn der Hersteller des OpenVPN-Geräts sich dem aktuell bei mehreren Herstellern zu beobachtenden Trend anschließt, den IPv6-Host-Identifier nicht mehr konstant nur aus der MAC-Adresse des Gerätes zu erzeugen, sondern ihn zusätzlich vom zugewiesenen IPv6-LAN-Präfix abhängig zu machen.

Am besten wird daher das OpenVPN-Szenario mit IPv6 nur dann betriebssicher funktionieren, wenn OpenVPN direkt im Router terminiert wird und somit nur die IPv6-WAN-Adresse des Routers im DynDNS registriert werden muss (so, wie man es auch von IPv4 kennnt). Falls TP-Link MR550 das nicht kann, wäre ggf. also ein neuer Router fällig, der auch VPN-Funktionen mitbringt.