Beiträge von ::1

Zitat von mbo77

1&1 übernimmt den Kunden-Traffic auf Layer 2. Layer 3 wäre bereits die IP-Adresse.

DG stellt demnach die Konnektivität im (G/XGS)-PON bereit und übergibt den gesamten Datenstrom unverändert je Kunde an das Netz von 1&1.

Der DG-Support kann bekanntermaßen mit L3 (IPv4, IPv6) nichts anfangen - wäre für mich tatsächlich ein Grund, zu 1&1 zu wechseln, in der Hoffnung, bei Problemlagen ab L3 auf kompetenteren Support zu treffen, bzw. bestenfalls den Support gar nicht erst zu benötigen, weil 1&1 hoffentlich "Internet einfach besser kann" als DG. Umgekehrt wird's dann aber bei L2-Problemen blöd, weil 1&1 nicht der L2-Betreiber, sondern nur der Vermittler "in the middle" zu DG ist.

Zitat von DFens

Warum gibt es so wenige bzw. keine symmetrischen Privatkundentarife, zumindest keine ohne extra Gebühr für dieses Feature?

Die Forderung nach "Symmetrie" impliziert den Bedarf für größere Upload-Bandbreite. Unter den Gründen für diesen Mehrbedarf mögen aus Sicht der ISP einige dabei sein, die sie an Privatkunden-Anschlüssen nicht so gerne sehen, z.B. den Betrieb von Webservern. Dafür benötigte Features (hohe Upload-Raten nebst festen IP-Adressen) möchten sie doch gerne den Business-Anschlüssen vorbehalten und dafür gerne mehr kassieren.

Zitat von mbo77

Das war die von mir verkürzte Dauer, um den Renewal zu provozieren.

Ist trotzdem nicht zielführend - es sollte da keine lokal konfigurierte Leasetime zurück kommen. Aber ich wiederhole mich hier schon mehrfach.

Zitat von mbo77

Was ist da der genaue Hintergrund?

Naja, DHCP Renew/Reply erfolgen ja per Unicast zwischen den Adressen von DHCP-Client/OpenWRT (hier 10.143.196.88) und ISP-DHCP-Servers (hier 10.143.196.89). Deren gegenseitige ARP-Requests/Replies werden bei aktiviertem Proxy-ARP stellvertretend durch den Zyxel mit dessen MAC-Adresse beantwortet.

Was mich aber wundert: Ist die Leasetime im DHCP-Reply mit nur 120 Sekunden der Wert, den der ISP liefert, oder ist das die lokale Einstellung des DHCP-Proxy im Zyxel? Idealerweise, sollte das der vom ISP gelieferte Wert sein. Andernfalls weiß dein OpenWRT doch gar nicht, wann die Lease beim ISP ausläuft.

Könnte es evtl. sein, dass du im Zyxel noch "Proxy ARP" aktivieren musst?

Zitat von mbo77

Schwerwiegender ist die verkorkste DHCP-Proxy/Relay Funktion. Dafür möchte ich eigentlich einen möglichst langen Lease haben.

Du musst genau die Leasedauer haben, die der DHCP-Server des ISP vorgibt - die muss der DHCP-Proxy korrekt weitergeben (was er nicht tut).

Zitat von mbo77

Hier wird der Renewal offenbar sauber bestätigt. Die Frage ist, weshalb das im Passthrough nicht funktioniert.

Du beschreibst deinen Aufbau nur sehr dürftig - man muss viel raten!

Was ich glaube herausgelesen zu haben:

• Es besteht ein VLAN-Trunk zwischen deinem OpenWRT und dem Zyxel:
  VLAN 57: 192.168.1.0/24 mit der Zyxel-IP 192.168.1.1 - wird genutzt für IP-Passthrough
  VLAN 2: 192.168.2.0/24 mit der Zyxel-IP 192.168.2.1 und der OpenWRT-IP 192.168.2.140 - "administratives Netz" (zum Managen des Zyxel)
• Solange noch kein APN-Login erfolgt ist, bekommt der OpenWRT im VLAN 57 eine IP-Adresse aus 192.168.1.0/24. Danach soll dem OpenWRT aber natürlich eine WAN-Port-IP vom ISP via DHCP über IP-Passthrough zugewiesen werden. Das wäre dann die IP-Adresse 10.132.0.189 aus dem Netz 10.132.0.188/30, mit der ISP-DHCP-Server-ID 10.132.0.190 und der Broadcast-Adresse 10.132.0.191 (private Adresse, weil hinter CGNAT).

Was mich irritiert (oder auch nicht): Der Zyxel scheint sich als eine Art DHCP-Proxy (nicht zu verwechseln mit DHCP-Relay!) in die Bridge-Funktion des IP-Passthrough 'reinzuhängen'. Er scheint das aber irgendwie nicht richtig zu machen: Solange kein APN-Login besteht, bedient er den OpenWRT in VLAN 57 aus einem lokalen IP-Pool (192.168.1.0/24). Leider gibt es bei DHCPv4 m.W. keine Funktion, mit der man eine Lease aktiv wieder zurückziehen kann, was ja notwendig wäre, sobald ein APN-Login erfolgt ist. Daher muss die Leasedauer dieser lokalen Lease (aus 192.168.1.0/24) sehr kurz eingestellt sein, damit der OpenWRT seinerseits aktiv wird und eine neue Lease anfordert.

Bei dieser zweiten Lease-Anforderung muss der Zyxel-DHCP-Server aber nun die Rolle eines Proxy für den DHCP-Server des ISP (10.132.0.190) einnehmen, d.h. er muss insbesondere auch die von diesem gelieferten Leasedauern (sowie RN/RB) weitergeben und nicht etwa seine lokal konfigurierten Werte (macht er aber nicht). Das NAK als Antwort auf ein Renew scheint daraus zu resultieren, dass er die Adresse 10.132.0.189 des OpenWRT in seinen lokalen DHCP-Pools nachschaut, dort existiert sie natürlich nicht. Das Renew für 192.168.2.140 funktioniert hingegen, weil diese Adresse aus einem lokalen DHCP-Pool des Zyxel stammt.

Eine Proxy-Funktion scheint mir tatsächlich auch nötig, da IP-Passthrough eine Form einer Bridge darstellt, bei der MAC-Adressen ersetzt werden. Da die MAC-Adresse des OpenWRT (82:62:a4:e2:85:c0) auch als Client-Ethernet-Address im DHCP-Paket steckt, muss diese dort (im Sinne einer ALG-Funktion) gegen die MAC-Adresse des Zyxel ausgetauscht werden, die der DHCP-Server des Providers (10.132.0.190) zu sehen bekommt.

Möglicherweise musst du im Zyxel bzgl. der erwünschten (tatsächlich aber nicht vorliegenden) DHCP-Proxy-Funktion noch irgendwo Einstellungen ändern.

Evtl. ist die Frage, wie der Zyxel-IP Passthrough Mode im Detail arbeitet. Denkbar wäre ja, dass der Zyxel DHCP-Renews/Rebinds oder deren Replies von der Gegenstelle nicht weiterleitet (warum auch immer), so dass der OpenWRT regelmäßig in Lease-Timeouts liefe (bei DG alle 3600s sowohl für IPv4, als auch für IPv6). Es käme dann jeweils zu Netzunterbrechungen, solange, bis in einem neuen DHCPv4/DHCPv6-Exchange (der offenbar mit IP Passthrough funktioniert) wieder IP- bzw IPv6-Adressen zur Verfügung stehen (hoffentlich dieselben wie zuvor).

Nur so ein Gedanke, der die Beobachtungen erklären könnte.

Zitat von seedschi

und seit zwei Wochen sind die Rufnummern aus der Box verschwunden, also kann ich auch nicht mehr telefonieren

Ist deine Fritzbox ein Mietrouter oder kundeneigener Router? Im letzten Fall kann DG ja nichts für das "Verschwinden der Rufnummern aus der Box". Dann musst du sie einfach wieder anlegen - die SIP-Account-Daten findest du in der Auftragsbestätigung (Dokumente im Postfach des DG-Kundencenters).

IPv6 ist in der Box sicherlich aktiviert?

Zitat von mbo77

Ich halte es in meinem Setup so, dass jedes System in Netzwerk selbstständig seinen Record im DynDNS updated. Dazu gibt es ddclient und viele andere Lösungen.

Ja, das wäre eine Alternative. Da Luki aber schon dynv6 via Fritzbox nutzt, wird er es sicherlich auch für die Registrierung seiner IPv6-nginx-Adresse nutzen wollen.

Nachtrag zu DnyDNS: Es gibt in der c't 11/2020 diesen Beitrag: Wegbereiter - Fritzbox: DynDNS mit IPv6 leicht gemacht. Der erklärt hervorragend, wie du DynDNS (u.a.) bei dynv6.com einrichten musst, um dort die IPv6-Adresse deines nginx registriert zu bekommen. Unter dem Link kannst du die c't-Ausgabe als PDF käuflich für 5,20€ erwerben.

Oder hier mal kurz das Wesentliche zusammengefasst:

Du musst bei dynv6.com einen "Record" des Typs AAAA mit dem Namen (z.B.) www.[yourdomain].dynv6.net anlegen, wobei ich jetzt mal unterstelle, dass du deinen nginx standarmäßig via Name="www" ansprechen möchtest. Unter "Data" musst du die IPv6-Interface-ID pppp:ppff:feqq:qqqq deines nginx angeben (siehe mein letzter Beitrag).

In der Fritzbox musst du DynDNS für dynv6 im Modus "benutzerdefiniert" einrichten. Was du dort als "Update-URL" eintragen musst, sagt dir die Website von dynv6.com.

Die Funktionsweise ist dann etwa wie folgt: Die Fritzbox meldet per DynDNS lediglich das aktuelle LAN-Präfix "2a00:6020:xxxx:xxxx". dynv6 setzt dann beide Teile (Präfix 2a00:6020:xxxx:xxxx und Interface-ID pppp:ppff:feqq:qqqq) zur IPv6-Adresse 2a00:6020:xxxx:xxxx:pppp:ppff:feqq:qqqq zusammen und registriert sie im DNS unter dem FQDN www.[yourdomain].dynv6.net.

Have fun

Mit LAN-Server meine ich natürlich deinen Raspberry/Nginx Server. Für die Freigaben (Ports 80,443\tcp) in der Fritzbox musst du die "richtige" IPv6-Adresse deines Nginx erwischen. Im besten Falle ist das diejenige und einzige, die dem Schema 2a00:6020:xxxx:xxxx:pppp:ppff:feqq:qqqq genügt. Hat der Nginx evtl. zwei Adressen, die mit 2a00:6020: beginnen, und keine von beiden enthält das Muster "ff:fe", wird es schwieriger, die richtige zu finden. Du darfst nicht diejenige verwenden, die als "temporär" gekennzeichnet ist.

In der Fritzbox erfolgt die Freigabe nur anhand der "Interface-ID", das sind die hinteren 64 Bits der Adresse, also pppp:ppff:feqq:qqqq. Das ist klar, denn der Präfix 2a00:6020:xxxx:xxxx ist ja prinzipiell dynamisch und kann sich ändern, die FB ist dann so schlau, die Freigabe für den geänderten Präfix intern anzupassen.

Wenn du die Freigabe für die korrekte IPv6-Adresse eingerichtet hast, kannst du sie zunächst ohne DynDNS testen, in dem du an einem Gerät im Internet (z.B. Smartphone mit abgeschaltetem WLAN, d.h. LTE zum Internet, aber der Mobilprovider muss dem Phone natürlich IPv6 zuweisen) im Webbrowser via https://[2a00:6020:xxxx:xxxx:pppp:ppff:feqq:qqqq] (Zertifikatsfehler ignorieren) bzw. http://[2a00:6020:xxxx:xxxx:pppp:ppff:feqq:qqqq] zugreifst. Die Klammern [] sind dabei wichtig!

Zitat von Luki

Die Port 80 & 443 auf dem Fritzbox sind an der IPv4 und v6 Adressen im LAN weitergeleitet

Für IPv4 ist das hinter CGNAT sinnlos. Und für IPv6 musst du eine Freigabe für die IPv6-Adresse deines LAN-Servers einrichten. Im DynDNS muss die IPv6-Adresse des LAN-Servers registriert werden und nicht die IPv6-WAN-Portadresse des Routers (die ist völlig irrelevant).

Hm, hier ging es eigentlich um Logging von CGNAT-Adressen und nicht um Shell-Diskussionen ...

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.