Beiträge von ::1

vergiss bitte KI, die ist dumm und käut nur "Angelesenes" unverstanden wieder.

Versuch bitte nochmal einen Paketmitschnitt und beachte vorher die Dinge meines letzen Posts

Ändere doch bitte mal im Browser deiner Wahl die Grundeinstellung dahingehend, dass er Downloads per Default nicht einfach im Standard-Download-Ordner von Windows ablegt, sondern dass er dich zuvor fragt, in welchem Ordner er die Datei ablegen soll:

Edge: edge://settings/downloads: Aktiviere "Vor dem Download fragen, wo die einzelnen Dateien gespeichert werden sollen"
Chrome: chrome://settings/downloads: Aktiviere "Vor dem Download von Dateien nach dem Speicherort fragen"
Firefox: about:preferences#general: Dateien und Anwendungen | Downloads | Aktiviere "Jedes Mal nachfragen, wo eine Datei gespeichert werden soll"

Nach Start des Paketmitschnitts klicke bitte erst dann auf auf "Neu verbinden", nachdem du den Speicherort der Mitschnitt-Datei bestimmt hast. Zum Beenden des Paketmitschnitts auf "Stopp" klicken und warten, bis die Anzeige dort wieder auf "Start" wechselt (das kann eine Weile dauern - hier bitte nicht ungeduldig werden und keinesfalls mehrfach auf "Stopp" und/oder "Start" klicken!). Erst dann ist der Mitschnitt beendet. Bitte keinesfalls vorher den Browser-TAB schließen - dadurch würde die Mitschnitt-Datei gelöscht.

Noch ein Nachtrag:

Ich habe über einen lokalen Paketmitschnitt an meinem Windows-PC eben eruiert, wie der Datentransport der Mitschnitt-Daten von der Fritzbox zum Speicherort der Mitschnitt-Datei auf meinem PC funktioniert: Dies erfolgt über eine HTTPS-Verbindung, die mein PC zur Fritzbox über IPv4 aufbaut. Daher bleibt diese Verbindung auch bestehen, wenn man in der Fritzbox auf "Neu verbinden" klickt. Die Verbindung würde auch mittels IPv6-ULA bestehen bleiben. Nur falls dummerweise diese Verbindung mit den globalen IPv6-Adressen aus dem PD-LAN-Block erfolgen würde, würde sie natürlich mit Klick auf "Neu verbinden" wegbrechen - da hätte man sich dann den Ast abgesägt, auf dem man sitzt.

Noch ein Nachtrag:

Wenn man zur DNS-Auflösung die Fritzbox-Adresse als DNS-Server verwendet, dann liefert die Fritzbox für die Auflösung ihres Namens "fritz.box" alle 3 LAN-Adressen zurück: IPv4, ULA und IPv6-GUA. Es besteht daher tatsächlich die Gefahr, dass man für den Paket-Mitschnitt die IPv6-GUA verwendet, so dass es bei Klick auch "Neu verbinden" zu einem Abbruch des Paket-Mitschnitts kommt.

Um das zu verhindern, würde ich an dem Windows-PC die HOSTS-Datei wie folgt modifizieren:

1. Eingabeaufforderung "Als Administrator ausführen" (wichtig: andernfalls kann man Änderungen in der HOSTS-Datei nicht speichern).

2. Kommandos wie folgt eingeben:

   C:\Windows\System32>cd drivers\etc
   C:\Windows\System32\drivers\etc>notepad hosts

3. In der HOSTS-Datei folgende Zeile ergänzen:
   192.168.178.1                fritz.box
   (hier die tatsächliche IP-Adresse der Fritzbox anpassen, falls sie nicht dem Default-Wert 192.168.178.1 entspricht)
4. HOSTS-Datei speichern (wenn hier ein Fehler kommt, dass das nicht geht, war man kein Administrator --> go back to 1)
5. Zurück in der administrativen Eingabeaufforderung folgendes Kommando eingeben:
   C:\Windows\System32\drivers\etc>ipconfig /flushdns
6. Eingabeaufforderung schließen.

Wenn man nun per Browser auf die Fritzbox zugreift, erfolgt dies nur noch via IPv4, weil die Auflösung von "fritz.box" nun per HOSTS-Datei in den "DNS-Auflösungscache" vorgeladen wird und daher nicht mehr aktiv aufgelöst werden muss.

Luki : Also, wenn du genau wissen willst, was los ist, kommst du um einen Paketmitschnitt nicht herum.

Ich kopiere mal alles aus anderen Beiträgen zusammen:

An einem beliebigen Windows-PC in deinem LAN:

• Installiere dort Wireshark (Download - "Windows x64 Installer"), um damit später den Paketmitschnitt auszuwerten. Die Komponente npcap muss dafür nicht mit installiert werden.
• Öffne im Webbrowser deiner Wahl einen TAB (TAB1) und melde dich dort an der Fritzbox an.
• Öffne im Webbrowser einen zweiten TAB (TAB2) und melde dich dort ein zweites Mal an der Fritzbox an.
• Navigiere auf TAB2 zu "Hilfe und Info (dort ganz nach unten scrollen) | FRITZ!Box Support | Paketmitschnitte". Wähle dort neben "1. Internetverbindung" den Knopf "Start" - damit löst du den Paketmitschnitt aus: Es poppt ein Fenster auf, in dem die Fritzbox dich fragt, wo auf deinem Windows-PC die Mitschnitt-Datei (fritzbox-vcc0_[Datum]_[Nummer].eth) gespeichert werden soll - wähle einen Ordner deiner Wahl und bestätige mit "Speichern".
• Wechsele zu TAB1: Navigiere dort zu "Internet | Online-Monitor | Verbindungsdetails" und klicke dort am Ende der Seite auf "Neu verbinden"
• Warte eine hinreichend Zeit, z.B. 5 Minuten - in dieser Zeit sollte die Box eine neue IPv4- und IPv6-Verbindung aufgebaut haben.
  Sobald die IPv6-Verbindung lt. Anzeige in der Fritzbox aufgebaut ist, starte in einer Eingabeaufforderung deines Windows-PC einen IPv6-Dauerping auf eine wellknown IPv6-Adresse (z.B. die von google.com = 2a00:1450:4001:802::200e):
  ping -t 2a00:1450:4001:802::200e
• Wechsel nach Ablauf der 5 Minuten wieder auf TAB2: Falls die Fritzbox dich dort wieder abgemeldet haben sollte, melde dich dort wieder an und navigiere erneut zu "Hilfe und Info (dort ganz nach unten scrollen) | FRITZ!Box Support | Paketmitschnitte": Drücke dort neben "1. Internetverbindung" auf den Knopf "Stopp", um den Paketmitschnitt zu beenden.
• Auf deinem Windows-PC liegt in dem von dir gewählten Ordner nun die Mitschnitt-Datei fritzbox-vcc0_[Datum]_[Nummer].eth, die du nun mit Wireshark zwecks Analyse öffnen kannst.

Um dort "den Wald vor lauter Bäumen" zu finden, solltet du in der oberen Zeile "Anzeigefilter anwenden" die folgenden Ansichtsfilter eingeben: icmpv6 || dhcpv6 || icmp || arp || dhcp. Das sollte reichen, um IPv4- und IPv6-Reconnect anzuzeigen. Für IPv6 alleine wäre der Filter icmpv6 || dhcpv6 ausreichend (entsprechend für IPv4 der Filter icmp || arp || dhcp).

Falls du aus der ursprünglichen Mitschnitt-Datei nur die durch den Filter icmpv6 || dhcpv6 || icmp || arp || dhcp generierte Ansicht in einer separaten Datei speichern möchtest:

1. Wähle in der Filteransicht das Menü "Datei | Ausgewählte Pakete exportieren...".
2. In dem folgenden Dialogfenster belasse die Voreinstellungen ("Alle Pakete" + "Angezeigt" + "unkomprimiert") und speichere am besten auch in eine Datei mit dem voreingestellten Suffix ".pcap".

Das ergibt eine schön kleine Datei.

Am Ende wäre es schön, wenn du die Anzeige deines Paketmitschnitts in Wireshark in der Filtersicht icmpv6 || dhcpv6 hier im Forum zur weiteren Analyse posten würdest.

Ggf. kannst du dann Screenshot und die PCAP-Datei des Mitschnitts in einem Ticket an die DG senden.

Zitat von Luki

Das zeigt dass die Konfiguration und die Verkabelung und allgemein alles stimmt und liegt nicht an dem FritzBox - das sind zwei Fritzboxen - 5690 für DG und 6660 für Vodafone, identisch konfiguriert

Ui - dann hast du eine Multihoming-Situation: Die wird leider nicht ordentlich mit IPv6 funktionieren (du kannst nicht sicherstellen, dass je nach Quell-IPv6-Adressauswahl an deinem PC das jeweils dazu passende IPv6-Gateway genommen wird: Vodofone wird keine DG-Quelladressen akzeptieren/routen und umgekehrt wird DG keine Vodafone-Quelladressen akzeptieren/routen).

Bzgl. IPv6 musst du dich für einen Anbieter entscheiden. Am anderen Router musst du dann IPv6 deaktivieren.

was mir sofort auffällt: Du hast zwei IPv6-Default-Gateways:

fe80::ab6...
fe80::223...

Da sind also zwei IPv6-Router im LAN, die beide Router-Advertisements (RA) announcen.
Stelle sicher, dass nur ein IPv6-Default-Gateway (fe80-LAN-Adresse deiner Fritzbox) im Netz vorhanden ist, bzw. stelle das Senden von RA am anderen Router ab!

Zitat von Luki

in dem Fritzbox 5690 Pro Oberfläche ist alles im grünen Bereich, sowohl IPv4 als auch IPv6, die Geräte im lokalen Netz bekommen alle ihre IPv6 Adressen, leider sind die IPv6 Adressen im INternet nicht pingbar und die Geräte im eigenen Netz aus dem INternet ebenso nicht erreichbar.

Ich würde erst Mal gerne deine Aussagen validieren, und zwar vorerst nur IPv6 outbound:

1. Zeige bitte einen Screenshot der Webseite https://test-ipv6.com.
2. In einer "Eingabeaufforderung" an einem Windows-PC im LAN: Copy&Paste den Output folgender Kommandos:
   ipconfig /all
   nslookup google.com. 2001:4860:4860::8888
   ping -6 google.com.
   

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 ...