Beiträge von ::1

Zitat von alpha_zulu

nicht automatisch eskaliert werden zu höheren Service-Levels.

Vermutung: Die gibt's da halt nicht.

Zitat von HubeBube

Es sei mir die Anmerkung gestattet, das sowohl curl, als auch wget unter Windows (nicht das Subsystem for Linux) lediglich ein Alias auf das Powershellkommando:

Invoke-WebRequest

darstellen.

Wohl "Jein", siehe https://www.andysblog.de/windows-curl-c…url-for-windows

Da mein Skript in einer CMD-Shell läuft, kommt hier tatsächlich die "curl.exe" zum Einsatz, nicht jedoch das Cmdlet "Invoke-WebRequest".

Zitat von Phino

Ich finde aber der optimale Standort ist der Router, der weis so etwas doch immer als erster.

Der bekommt an einem Internet-Anschluss mit CGNAT doch aber auch nicht die Änderung der CGNAT-Adresse mit!

Es mag für den einen oder anderen aus verschiedenen Gründen interessant sein, an Internet-Zugängen mit CGNAT (z.B. "Deutsche Glasfaser") die jeweils für den eigenen Kundenanschluss verwendete CGNAT-Adresse zu ermitteln, und zwar nicht nur einmalig bei Bedarf und interaktiv durch Aufruf geeigneter Websites (z.B. https://www.wieistmeineip.de/), die die eigene öffentliche IPv4-Adresse anzeigen, sondern (relativ) permanent per Logging über ein Skript, das die CGNAT-Adresse in regelmäßigen Zeitabständen ermittelt und versehen mit Datum/Uhrzeit in eine Log-Datei schreibt.

Inspiriert durch https://www.howtogeek.com/839170/how-to-…ux-bash-script/ habe ich so eine Lösung mal für Windows umgesetzt:

• Ich habe ein Batch-Skript "getmycgnat.cmd" erstellt, das bei Start meines Windows-PC mit gestartet wird und in regelmäßigen Zeitabständen die aktuelle CGNAT-Adresse inklusive Zeitstempel in eine LOG-Datei namens CGNAT.log schreibt.
• Nachteil ist dabei, dass das Logging nur erfolgt, wenn mein Windows-PC läuft. Aber ich habe nun mal keinen 24/7 laufenden Linux-Server, der für so etwas natürlich deutlich besser geeignet wäre. Und meinem Windows-Desktop starte ich ohnehin nahezu täglich.

Wen die Lösung interessiert und sie evtl. für sich adaptieren möchte, hier meine "Implementierung":

In dem oben verlinkten "howtogeek" werden zwei zentrale Kommandos genannt, die die aktuelle CGNAT-Adresse ermitteln, hier mal unter meinem Windows gezeigt:

C:\>dig -4 @resolver1.opendns.com myip.opendns.com +short
94.31.113.244

C:\>curl -s --ipv4 ifconfig.me
94.31.113.244

Der Vorteil von 'curl' ist, dass dieses Tool schon eine Weile Bestandteil von Windows ist. Möchte man hingegen 'dig' verwenden, das zudem ja auch eine deutlich bessere Alternative zum Windows-Werkzeug 'nslookup' darstelllt, muss man sich dieses Tool allerdings erst beschaffen - eine relativ einfache Möglichkeit, die ich verwendet habe, beschreibe ich unten.

Als Ablageort für Tools und Skripte verwende ich einen Ordner C:\CMD, den ich auch in den System-Suchpfad (PATH-Variable) aufnehme (Erweiterte Systemeinstellungen | TAB Erweitert | Umgebungsvariablen | Systemvariablen | Variable "Path" bearbeiten | C:\CMD via "Neu" hinzufügen), damit die Tools auch ohne Pfadangabe gefunden werden.

Dort habe ich also ein Skript namens "getmycgnat.cmd" mit folgendem Inhalt erstellt:

@echo off
SETLOCAL ENABLEDELAYEDEXPANSION
set LOG=D:\Daten\Log\CGNAT.log
if not exist "%LOG%" echo %DATE% %TIME%: DATEI %LOG% -- ERSTELLT >"%LOG%"  

:LOOP
for /f %%i in ('dig -4 @resolver1.opendns.com myip.opendns.com +short') do (
	echo %DATE% %TIME%: %%i >>"%LOG%"
)
timeout 3600 1>nul 2>&1
goto LOOP

Dazu folgende Hinweise für individuelle Anpassungen:

• Name und Ort der Log-Datei (hier D:\Daten\Log\CGNAT.log) können natürlich beliebig individuell festgelegt werden.
• Das Skript verwendet 'dig'. Wer 'curl' verwenden möchte, muss in der for-Schleife statt 'dig -4 @resolver1.opendns.com myip.opendns.com +short' das Kommando 'curl -s --ipv4 ifconfig.me' verwenden.
• Das Skript ermittelt die aktuelle CGNAT-Adresse alle 3600s. Wer andere Zeitabstände wünscht, kann dies durch entsprechende Modifikation von timeout 3600 anpassen.

Damit das Skript bei Rechnerstart und unabhängig von einem Benutzer-Login startet, habe ich einen Task in der Windows-"Aufgabenplanung" wie folgt erstellt:

• TAB "Allgemein": Name: GETMYCGNAT; Benutzerkonto: SYSTEM; Sicherheitsoptionen: "Unabhängig von der Benutzeranmeldung ausführen"
• TAB "Trigger": Trigger: "Beim Start" | Details: "Beim Systemstart"
• TAB "Aktionen": Aktion: "Programm starten" | Details: "C:\CMD\getmycgnat.cmd"
• TAB "Bedingungen": Energie: "Aufgabe nur starten, falls Computer im Netzbetrieb ausgeführt wird"
• TAB "Einstellungen": Ausführung der Aufgabe bei Bedarf zulassen.

Hier noch ein einfacher Weg, um an ein 'dig' für Windows heranzukommen:

Unter https://downloads.isc.org/isc/bind9/ kann man für die letzte Version mit Windows-Unterstützung V.9.17.15 das "Windows Non-Debug Build" BIND9.17.15.x64.zip (Direktlink) herunterladen. Aus den ZIP-Archiv einfach das Tool 'dig.exe' und alle DLL-Dateien in einem gemeinsamen Ordner kopieren, zweckmäßigerweise in einen Ordner im System-Suchpfad, in meinem Fall also C:\CMD.

Man muss nicht alle DLL-Dateien kopieren: Wenn man erst Mal nur dig.exe kopiert und aufruft, meckert es aber jede fehlende DLL an, diese kann man dann solange nachkopieren, bis dig.exe zufrieden ist (in dieser Version sind es insgesamt 11 DLL-Dateien, die mit kopiert werden müssen).

Zitat

leider ändert sich an dieser IP gar nichts.

Muss wahrscheinlich damit leben.

Die CGNAT-Adresse ändert sich ab und zu - allerdings kann es länger dauern. Ich habe meine aktuelle CGNAT-Adresse z.B. seit 23.06. 2025, davor hatte ich eine andere ab 21.03.2025, also für etwa 3 Monate. Es gab auch Phasen, in denen sie sich täglich änderte.

Ich gehe davon aus, dass sich dein Problem irgendwann "in Luft auflöst", spätestens mit der Zuweisung einer neuen CGNAT-Adresse.

Zitat von wildfire87

Was genau sagt mir das jetzt? Ipv6 ist in meiner Fritzbox auch deaktiviert

Es ging nur darum, deine aktuelle CGNAT-Adresse (Ihre IPv4 Internet-Adresse ist höchstwahrscheinlich 94.31.74.179) herauszufinden, die bei viki.com vermutlich geblockt wird. Wenn du in der Fritzbox mal "Neu verbinden " ausführst, könnte die sich ändern (nochmal mit ipv6-test nachschauen) und der Zugriff auf viki.com plötzlich funktionieren.

Ansonsten solltest du in deiner Fritzbox natürlich auch IPv6 aktivieren, wenn du (neben IPv4) auch IPv6 nutzen möchtest. Vorteil: Internet-Ziele, die auch über IPv6 erreichbar sind (viki.com gehört leider nicht dazu), benötigen kein CGNAT - du hast eine NAT-freie Ende-zu-Ende-Verbindung von deinem LAN-PC zum Internet-Ziel.

Zitat von Elemir

Ich würde mal sagen viki.com nutzt IPv4 und das CGNAT- oder DS-Lite-Gateway wird von viki.com als Proxy angesehen, weil mehrere Kunden von dort aus bei viki.com "ankommen".

Stimme zu, hier mal in "ausführlich" formuliert:

viki.com scheint nur via IPv4 erreichbar zu sein:

C:\>nslookup
Standardserver:  localhost
Address:  ::1

> viki.com.
Server:  localhost
Address:  ::1

Nicht autorisierende Antwort:
Name:    viki.com
Address:  34.102.157.214

> www.viki.com.
Server:  localhost
Address:  ::1

Nicht autorisierende Antwort:
Name:    web-glb.viki.com
Address:  34.102.157.214
Aliases:  www.viki.com

Ich habe an meinem DG-Anschluss aber keinerlei Probleme, auf viki.com zuzugreifen. Deren Server "sehen" als meine IPv4-Quelladresse folglich meine CGNAT-Adresse (aktuell: 94.31.113.244). Die CGNAT-Adressen liegen bei DG laut meinem Analysen im Range 94.31.64.0/18 (94.31.64.0 - 94.31.127.255). Kann natürlich sein, dass bei viki.com einige Adressen aus diesem Range geblockt werden, weil sie fälschlicherweise als Proxies oder VPN-Gateways betrachtet werden (wahrscheinlich ein dynamischer Prozess: Ansatz: "Blocke, wenn zu viele Requests von derselben IP-Adresse kommen" - aus deren Sicht muss das dann ein Proxy oder VPN-Gateway sein, die Möglichkeit einer CGNAT-Adresse wird nicht gesehen).

wildfire87 : Ruf doch bitte mal z.B. https://test-ipv6.com/ auf, dort kannst du u.a. sehen ("Ihre IPv4 Internet-Adresse ist höchstwahrscheinlich ..."), welcher CGNAT-Adresse der DG dein Anschluss aktuell zugeordnet ist.

Für diesen Erklärungsversuch würde sprechen, wenn das Problem verschwindet, sobald die DG dir eine andere CGNAT-Adresse zuordnet (passiert gelegentlich), die bei viki.com bisher nicht geblockt ist. Möglicherweise kannst du das durch eine "Neuverbindung" in deinem Router auch provozieren.

Ansonsten siehe #13.

Zitat von mbo77

Ich kenne keine Dienste, die IPv6-only sind.

hier

Wenn du möchtest, kannst du einen Paketmitschnitt machen, der die technischen Probleme ziemlich genau nachweisen könnte. Ich würde dir eine entsprechende Anleitung für eine geeignete Vorgehensweise schreiben, andernfalls erspare ich mir das.

Zitat von oggear51

Nach Deaktivierung von Ipv6 habe ich jetzt keine Probleme mehr, dass Internet läuft einwandfrei

Genau das war erwartbar. IPv4 ist ok. IPv6 ist kaputt. Wird nicht einfach, das der DG zu verklickern.

Zitat von HubeBube

Immer noch verblüffen mich die zugewiesenen DNS-Server. Dies sollten die folgenden sein:

Ein weiteres Indiz einer DG-seitig fehlerhaften Konfiguration des Kundenzugangs.

Zitat von oggear51

Meine Verbindung wird alle 12 Std getrennt.

Die Meldungen sind harmlos, sie bedeuten lediglich, dass deine DHCPv4-Leasedauer wieder auf den Maximalwert (3600s) verlängert wird. Das passiert alle 30 Minuten, die FB loggt das allerdings nur alle 12 Stunden - warum, weiß nur AVM.

Ich habe das Eventlog der FRITZ!Box (im folgenden "FB") (siehe #37) nun mal analysiert:

Es erstreckt sich über den Zeitraum 26.05.2025 20:49:23 - 01.07.25 17:21:37 und zerfällt in Abschnitte, die jeweils durch ein manuelles Neuverbinden in der FB (Internet | Online-Monitor | TAB "Verbindungsdetails" | Schaltfläche "Neu verbinden") ausgelöst wurden. Dies ist im Eventlog daran erkennbar, dass die beiden Ereignisse ...

• Internetverbindung IPv6 wurde getrennt, Präfix nicht mehr gültig.
• Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: ...

... im Abstand von nur wenigen Sekunden auftreten - es werden also stets sowohl IPv4-WAN-Adresse als auch IPv6-Adressen (WAN-Adresse und PD-Präfix) neu bezogen.

Abgesehen von irrelevanten Abschnitten, in denen experimentiert wurde (DS-Lite/AFTR, 6to4, "Globale Adresse aus dem zugewiesenen Präfix ableiten"), gibt es bezogen auf IPv6 zwei spezifische Abschnittstypen mit unterschiedlichen Charakteristika:

1. Einen Abschnitt (26.05.2025 20:49:23 - 27.05.2025 12:49:24), der von DHCPv6 Lease-Timeouts dominiert wird.
2. Alle übrigen Abschnitte (außer denen mit Konfigurations-Experimenten, s.o.), die sich bzgl. IPv6 wie folgt charakterisieren lassen: Während die eingangs neu (aber jedes Mal geänderte) WAN-Adresse in dem Abschnitt konstant bleibt, wechselt (vermutlich im Rahmen von DHCPv6-Renews) das PD-Präfix in unregelmäßigen Zeitabständen zwischen 0,5h und maximal ~56h (allerdings beendet durch manuelles Neuverbinden). Die Zeiträume eines konstanten PD-Präfix sind immer Vielfache von 0,5h (DHCPv6-Renew-Time T1: 1800s), was darauf hindeutet, dass die PD-Präfix-Änderungen im Rahmen von DHCPv6-Renews erfolgen.

Die Lease-Timeouts des Abschitt-Typs 1 tauchen regelmäßig jede Stunde auf, weil dann jeweils die Leasedauer abläuft. DHCPv6-Renews und -Rebinds scheiterten also in dieser Phase. Immerhin wurden aber im Rahmen eines sich anschließenden neuen DHCPv6-Exchanges dieselben IPv6-Adressen (WAN-Adresse und PD-Präfix) zugewiesen.

Das änderte sich nach Ende des ersten Abschnitts dann wie folgt:

• Es folgt ein "experimenteller" Abschnitt (27.05.2025 12:51:13 - 27.05.2025 12:51:21) mit einer DS-Lite-Konfiguration. Die lieferte noch dieselben IPv6-Adressen wie im voran gegangenen Abschnitt 1.
• Der nächste Abschnitt mit (vermutlich) korrekter Standardkonfiguration (27.05.2025 12:54:58 - 27.05.2025 12:55:16) liefert nun erstmals neue IPv6-Adressen (WAN-Adresse und PD-Präfix).
• Es folgt noch ein "experimenteller" Abschnitt (27.05.2025 12:56:56 - 27.05.2025 12:56:58) mit "6to4"

Alle folgenden Abschnitte (ab 27.05.2025 12:57:50) sind jetzt nur noch vom Typ 2. Gelegentlich treten auch innerhalb eines solchen Abschnitts DHCPv6 Lease-Timeouts auf, die (im Unterschied zu Abschnitt 1) auch jeweils geänderte IPv6-Adressen (WAN-Adresse und PD-Präfix) nach sich ziehen (Abschnitte 27.05.2025 12:57:50 - 27.05.2025 14:28:05, 28.05.2025 07:15:38 - 31.05.2025 22:47:54, 08.06.2025 13:28:46 - 08.06.2025 17:29:04). Gelegentlich tritt auch der Fehler "IPv6-Präfix konnte nicht bezogen werden, Fehlergrund: 4001 (server failure: requested IA_PD not provided)" auf, der aber nur eine kurze Verzögerung bis zum Bezug eines PD-Präfix bewirkt.

Man könnte jetzt vermuten, dass DG mit diesem neuen "Konzept" möglicherweise versucht, von quasi-statischen IPv6-Adressen für Privatanschlüsse wegzukommen, um echte statische Adressen den Business-Anschlüssen vorzubehalten.

Es ist aus meiner Sicht aber keine gute Idee, einen PD-Präfix "unter Tage" zu tauschen, indem man den altem Präfix entzieht und einen neuen zuweist - das ist der Tod für jede bestehende Netzverbindung (insbesondere TCP-Verbindungen), der Anwender wird das als Netzwerkunterbrechung wahrnehmen.

Ich gehe also davon aus, dass die hohe "IPv6-Dynamik" ein Indiz für eine Fehlkonfiguration bei DG darstellt.

Zudem scheint es so zu sein, dass ein gerade neu zugewiesenen PD-Präfix nur eine begrenzt lange Zeit (lt. Anwenderangabe etwa 20-30 Minuten) im DG-Backend tatsächlich auch geroutet wird. Das bedeutet, dass bis zur nächsten Zuweisung eines (geänderten) PD-Präfix das bestehende Präfix im Kundennetz zwar noch announced wird, aber längst schon nicht mehr funktioniert - das ist ziemlich tödlich für eine "IPv6 User Experience".

Eine Validierung dieser These erfordert allerdings einen Paket-Mitschnitt am WAN-Port der FB (während eines Dauerpings auf eine IPv6-Adresse im Internet). Der wäre auch sehr aufschlussreich für die Analyse, wie genau der PD-Präfixwechsel erfolgt und wie lange das neue Präfix bei DG auch geroutet wird.

Ergänzung:

Die nach Anwender-Beobachtung ausbleibende IPv6-Erreichbarkeit des Internets (keine IPv6-Ping-Antworten) kann evtl. auch dadurch begründet werden, dass zwar mit Neuzuweisung eines PD-Präfix für kurze Zeit auch gültige Router-Advertisements (RA) mit einer Router-Lifetime von 1800s gesendet werden, danach jedoch nicht mehr, so dass die IPv6-Defaultroute nach einem Timeout von 30 Minuten ungültig wird. Oder es werden nach einer Weile fehlkonfigurierte unsolicited RA mit einer Router-Lifetime=0 gesendet, die die IPv6-Defaultroute sofort ungültig werden lassen. Auch derlei würde man nur in einem Paketmitschnitt sehen können.

Zitat von HubeBube

Palo Altos Global Connect funktioniert sehr gut in dem Dual Stack mit CGNAT Netz von Deutsche Glasfaser.

Ist das als Bestätigung für OpenVPN zu verstehen - weil Global Connect auf OpenVPN zu basieren scheint (siehe hier, würde ich jetzt allerdings nicht unter "Allgemeinwissen" verbuchen)? Andernfalls weiß ich nicht, ob ZTNA mit Palo Altos Prisma Access hier für das Umfeld des OP in Frage kommt, ist doch eher was für "big enterprises" - oder ordne ich das jetzt falsch ein, bzw. für welchen evtl. anderen Use Case nutzt du Global Connect?

Vorschlag:

Deaktiviere vorerst IPv6 in der Fritzbox für ein paar Tage. Beobachte, ob wenigstens IPv4 konstant/stabil läuft - inklusive guter Performance beim Laden von Websites etc. Bei IPv4 zeigt die FB in der Ereignisanzeige auch die Leaseverlängerungen der IPv4-Adresse etwa 2x am Tag an. Wäre interessant, ob die IPv4-Adresse dabei konstant bleibt oder sich auch regelmäßig ändert - dies aber nur nebenbei.

Danach könnte man IPv6 wieder aktivieren, um einen geeigneten Paketmitschnitt am WAN-Port der FB durchzuführen, der das IPv6-Fehlverhalten mitschneidet. Wenn du willst kann ich dich dabei unterstützen (muss mir noch überlegen, wie man das "am dümmsten" macht), so dass du der DG in einem Ticket das Problem auch technisch fundiert nachweisen kannst. Dann wärst du in jedem Fall auf der sicheren Seite - auch wenn im DG-Support erst mal keiner Paketmitschnitte lesen kann und du vermutlich 10 Tickets aufmachen musst, bis dir evtl. geholfen wird.

Und das hier ist auch witzig:

"Internetverbindung wurde erfolgreich erneuert. IP-Adresse: 100.102.133.109, DNS-Server: 185.22.44.50 und 185.22.44.50, Gateway: 100.102.128.1"

Der DHCP-Server weist zweimal 185.22.44.50 als DNS-Server zu. Sollte eigentlich so aussehen: "DNS-Server: 185.22.44.50 und 185.22.45.50"

Auch deine IPv4-Adresse wechselt recht oft - sollte eigentlich auch über sehr lange Zeiträume konstant sein.

Ja, IPv6 funktioniert nach Zuweisung eines Präfix eine Weile, danach dann aber nicht mehr - bis wieder eine neues Präfix zugewiesen wird. Das Log zeigt auch Lease-Timeouts, es gibt also gelegentlich Probleme, eine Lease zu verlängern. Stattdessen weist DG einfach ein neues zu, dass dann wieder eine Weile funktioniert.

Kritisch wird es dann (schlechte "User experience" bei dir), wenn dein Router das letzte zugewiesene Präfix im LAN noch propagiert, dieses im DG-Backend (vermutlich) aber nicht mehr geroutet wird. Das sind die Phasen, wo der Dauerping in deinem Test vorhin keine Antworten geliefert hat.

Danke für die TXT-Datei!

Muss ich erst mal analysieren, um Muster zu erkennen.

Eine Zeile sticht aber hervor: "Internetverbindung IPv6: AFTR konnte nicht bezogen werden: Grund 7 (got no aftr)"

Wie sieht denn die IPv6-Konfiguration in deiner FB aus?

Du solltest am DG-Anschluss _nicht_ "DS-Lite" konfiguriert haben!

Idealerweise sollte "Native IPv4-Anbindung verwenden" konfiguriert sein.

Zitat von oggear51

das ipv6 Präfix wurde nur einmal um 17:21:37 Uhr aktualisiert und um 16:51:37 Uhr neu Bezogen aber das habe ich verursacht

Egal, ob "aktualisiert" oder "von dir verursacht": Wird dabei jedes Mal ein anderes LAN-Präfix 2a00:6020:91WX:YZ00::/56 zugeordnet, oder bleibt der Teil WX:YZ konstant?

Würdest du außerdem sagen: Die Pings lieferten immer dann (für etwa 20-30 Minuten) Antworten, nachdem gerade ein neues LAN-Präfix zugeordnet wurde?

Zitat von oggear51

So knapp 2 stunden später die Antworten kommen und gehen ich würd sagen in 20-30 min Takt

Naja, das scheint meine Vermutung, die ich oben formuliert habe, offenbar zu bestätigen.

Wenn du mal in die Fritzbox-Ereignisanzeige schaust: Korreliert diese mit dem 20-30 min Takt dahingehend, dass etwa alle 40-60 Min ein neues IPv6-Präfix zugewiesen wird?