Mich würde mehr interessieren, ob die Leute, die in letzter Zeit Threads zu diesen Problemen eröffnen auch das Problem haben, dass eine Traceroute mit fc00:1 endet, so wie bei uns im Ort?
Genau das würde mich auch interessieren. Deshalb stelle ich immer die Frage nach den Traces von außen und innen.
Also gibt es zu dem fc00:1 Problem aktuell keine Lösung...
Richtig. Da hilft nur, die Tickets offen zu halten und am Ball zu bleiben.
Genau das würde mich auch interessieren. Deshalb stelle ich immer die Frage nach den Traces von außen und innen.
Stimmt, ich stand vorhin irgendwie auf dem Schlauch, ich dachte erst du meinst mit traces etwas anderes (hatte irgendwie Wireshark sniffing im Sinn), sorry.
Schade, dass die meisten Leute sich nicht die Mühe machen kurz die traceroute Ergebnisse zu posten, dann hätten alle, die sich beim Support beschweren deutlich mehr Beweise in der Hand damit dort endlich Bewegung in die Sache kommt.
Ich habe gerade einige Threads angeschaut, in jedem bist du aktiv und fragst danach und in manchen werden die Leute sogar pampig.... das kann ich absolut nicht nachvollziehen.
Man hat ein Problem, will es analysieren und ist dann nicht bereit ein paar Minuten zu investieren, dabei würde es allen helfen weil man mehr Druck machen kann beim Support und wenn das Problem gefunden wird, würde das den Fehler vermutlich auch bei vielen bzw. allen beheben.
Alles anzeigenOK,
das hatte ich falsch verstanden. Ich hatte gefragt, was Ihr für traces braucht. Nachdem ich da keine Antwort bekommen habe, habe als Trace das WireGuard-Log verstanden und das geliefert.
Die Tracert Abfrage ist wie folgt
im WLAN (intern)
C:\Users\Ralf>tracert 2a00:6020:5664:4300:9209:d0ff:fe36:d077Routenverfolgung zu Diskstation.fritz.box [2a00:6020:5664:4300:9209:d0ff:fe36:d077]
über maximal 30 Hops:1 75 ms 42 ms 78 ms Diskstation.fritz.box [2a00:6020:5664:4300:9209:d0ff:fe36:d077]
Ablaufverfolgung beendet.
Über Handy als Hotspot im Mobilfunk (extern)
C:\Users\Ralf>tracert 2a00:6020:5664:4300:9209:d0ff:fe36:d077
Routenverfolgung zu 2a00:6020:5664:4300:9209:d0ff:fe36:d077 über maximal 30 Hops
1 * Zielhost nicht erreichbar.
Ablaufverfolgung beendet.
C:\Users\Ralf>
mikado Nur zur Klarstellung: dich habe ich nicht gemeint mit meinem Kommentar, ich hatte vorhin einige andere Threads durchsucht nach meinem Problem und dort ist mir das aufgefallen, dass manche einfach nicht mitarbeiten wollen.
Könntest du mal ein "tracert -6 ipv6.google.com" machen, mich würde interessieren was da rauskommt.
Bekommst du da auch fc00::1 als letzten Hop?
mikado: In dem Trace stimmt schon was nicht, da braucht man nicht mehr weiterzusuchen. Über 90ms zum ersten Hop, der ja bei dir im Heimnetz sein müsste, da kann was nicht sein. Das lässt sich auch nicht mit WLAN erklären, und wenn, dann ist das die Ursache für alle weiteren Probleme, denn dann gibt es offenbar massive Verbindungsprobleme.
Hast du irgendwo VPNs oder sowas aktiv?
C:\Users\Ralf>tracert -6 ipv6.google.com
Routenverfolgung zu ipv6.l.google.com [2a00:1450:4001:81d::200e]
über maximal 30 Hops:1 91 ms 74 ms 86 ms fritz.box [2a00:6020:5664:4300:e208:55ff:fe81:512f]
2 * * * Zeitüberschreitung der Anforderung.
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.
5 * * * Zeitüberschreitung der Anforderung.
Danke dir, das sieht definitiv anders aus als bei mir.
Bei mir kommt bei 1 auch die IPv6-Adresse der Fritzbox 5590 mit <1ms und dann direkt fc00::1.
Dein hoher Ping zum Router (innerhalb deines LAN) ist komisch, aber ich erinnere mich, dass ich so ein Problem mal bei einem Freund gesehen hatte, dort lag es am Stromsparmodus des WLAN-Adapters im Notebook.
Nachdem wir dort den Stromsparmodus deaktiviert hatten (siehe Screenshot) waren die Ping spikes weg, ob das in deinem Fall hilft, ist allerdings fraglich, denn bei dir kommt schon gar kein zweiter Hop mehr danach.
Danke, aber das hilft nicht. Ich habe den Rechner hier im Keller mal per Kabel an einen Fritz-Repeater 1200AX gehängt, der sich dann im Mesh mit der 7590AX verbindet. Da werden die Zeiten auch nicht besser. Liegt wohl an der Stahlbetondecke dazwischen 
Auch 15 ms sind viel zu lang, auch im WLAN. 2-3 ms würde ich als normal betrachten, mehr nicht.
Und die ersten paar Hops nach der Fritzbox reagieren bei der DG nie bei Traceroutes. Das geht frühestens bei Hop 4 oder 5 los, teilweise auch noch später.
Ich teste ja immer gerne via Powershell...
Ignoriert bitte im folgenden "http://" das fügt die Software leider automatisch hinzu.
> Resolve-DnsName -Type AAAA -Name http://www.google.de | Format-List
Name : http://www.google.de
Type : AAAA
TTL : 300
DataLength : 16
Section : Answer
IPAddress : 2a00:1450:4001:831::2003
Interessant ist hierbei, dass bei wiederholtem Aufruf sich die TTL Werte ändern.
Die Ausgabe von "Resolve-DnsName -Type AAAA -Name ipv6.google.de | Format-List" spare ich mir jetzt an dieser Stelle.
> Test-NetConnection -ComputerName 2a00:1450:4001:810::2003 -TraceRoute -InformationLevel "Detailed"
ComputerName : 2a00:1450:4001:810::2003
RemoteAddress : 2a00:1450:4001:810::2003
NameResolutionResults : 2a00:1450:4001:810::2003
fra16s50-in-x03.1e100.net
InterfaceAlias : WLAN
SourceAddress : 2a00:6020:b398:bc00:1d1b:ef8b:a1e5:2c6a
NetRoute (NextHop) : fe80::de15:c8ff:fece:1c36
PingSucceeded : True
PingReplyDetails (RTT) : 29 ms
TraceRoute : 2a00:6020:b398:bc00:de15:c8ff:fece:1c36
::
::
2a00:6020::d
2a00:1450:8153::1
::
2001:4860:0:1::8886
2001:4860::c:4003:364f
2001:4860::9:4001:31f2
2001:4860:0:1::869b
2001:4860:0:1::3167
2a00:1450:4001:810::2003
Und das Ganze noch einmal klassisch:
> ping /6 /n 3 http://www.google.de
Ping wird ausgeführt für http://www.google.de [2a00:1450:4001:81d::2003] mit 32 Bytes Daten:
Antwort von 2a00:1450:4001:81d::2003: Zeit=11ms
Antwort von 2a00:1450:4001:81d::2003: Zeit=17ms
Antwort von 2a00:1450:4001:81d::2003: Zeit=11ms
Ping-Statistik für 2a00:1450:4001:81d::2003:
Pakete: Gesendet = 3, Empfangen = 3, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 11ms, Maximum = 17ms, Mittelwert = 13ms
> tracert /6 2a00:1450:4001:81d::2003
Routenverfolgung zu tzfraa-aa-in-x03.1e100.net [2a00:1450:4001:81d::2003]
über maximal 30 Hops:
1 3 ms 3 ms 5 ms 2a00:6020:b398:bc00:de15:c8ff:fece:1c36
2 * * * Zeitüberschreitung der Anforderung.
3 * 88 ms * 2a00:6020:0:d::1
4 15 ms 7 ms 14 ms be10-704.pr2.int63-fra.dg-w.de [2a00:6020::d]
5 * * * Zeitüberschreitung der Anforderung.
6 9 ms 9 ms 11 ms 2001:4860:0:1::1882
7 15 ms 6 ms 9 ms 2001:4860:0:1::8698
8 8 ms 11 ms 12 ms 2001:4860::c:4003:364d
9 13 ms 11 ms * 2001:4860::1:0:d0d8
10 9 ms 7 ms 8 ms 2001:4860:0:1::9f
11 11 ms 9 ms 6 ms tzfraa-aa-in-x03.1e100.net [2a00:1450:4001:81d::2003]
Ablaufverfolgung beendet.
Und beachtet bitte mal die Auflösungsergebnisse für http://www.google.de
Hast Du dafür schonmal über einen Cloudflared Tunnel nachgedacht.
Läuft im Prinzip so:
Dein Nextcloud-Instanz baut einen Tunnel in Richtung Cloudflare auf (unabhänging von deiner IP) und Cloudlfare macht die Übersetzung in IPv4&IPv6.
Musst dich danach nicht mehr um Updates der IP kümmern, läuft alles über den Tunnel.
Keine Portfreigaben, kein VPN, usw.
Gibt auch andere Anbieter die das machen.
ZUm Beispiel: https://ipv64.net/reverse_proxy
in einen VPN-Tunnel über Tailscaile in mein Heimnetz zu integrieren ist nicht zielführend.
Ohne ein paar Tunnel wird es nicht so einfach funktionieren. Außer natürlich, alle deine Clients arbeiten sauber in IPv6.
Auf was willst du denn konkret via IPv6 erreichen? Nextcloud ist bei dir im Heimnetz aktiv?
Die Lösung liegt darin, dass DG IPv6 repariert.
Bis dahin gibt es Lösungen auf IPv4-Basis und einem VPS für 1 €/Monat. Findest du über die Suchfunktion.
So musste ich das jetzt auch lösen. Hab zum Glück noch einen Hetzner-Server. SSH-Tunnel vom Home-Server zum Hetzner-Server und auf dem Hetzner-Server dann einen Reverse-Proxy mit Nginx, der über den SSH-Tunnel dann zu den Containern auf dem Home-Server verbindet.
Hilft aber erstmal nicht, wenn man auf IPV6-Only-Services zugreifen muss, dafür gibts auch technische Lösungen über externe Server/Dienstleister, aber das ist halt auch nur eine Krücke.
Die DG antwortet mir aktuell garnicht mehr. Wenn sich da nichts tut, bleibt nur schriftliche Fristsetzung zur Behebung des Mangels, wenn das nichts bringt Kündigung wegen nicht erbrachter Leistung. Parallel kann man Beschwerde bei der Bundesnetzagentur einreichen. Vielleicht auch mal an die Presse wenden, vielleicht schafft man es ja in die "Vorsicht Kunde!"-Rubrik der c't.
Tunnel-Möglichkeiten gibt es viele. Das geht natürlich auch mit SSH, Port-Forwarding und Reverse-Proxys.
Wenn du magst, kann du ja deine Lösung dokumentieren und ich packe sie zu dem Meta-Beitrag dazu.
Der Vorteil, Ports via WG/OpenVPN oder auch SSH zu tunneln besteht darin, dass es flexibler ist und man weniger Ressourcen auf dem VPS benötigt. Zudem entfällt die Konfiguration des Reverse Proxys.
Das sollte auch kein Problem sein, wenn du nativ auf IPv6 unterwegs bist. Dazu muss das natürlich funktionieren.
