DNS-Schwierigkeiten unter Linux

TotalEclipse

Lt. Junior Grade
Registriert
Juni 2009
Beiträge
473
Hallo zusammen,

habe mal wieder ein seltsames Netzwerkproblem.
Setup: Kabelrouter, daran hängt per LAN ein OpenWRT-Router mit PiHole-Funktionalität - das ist der Hauptrouter, und da funktioniert auch fast alles wie es soll.
Ab und an muss ich mich aber mit dem WLAN des Kabelrouters verbinden, um den DNS-Filter zu umgehen. Seit einigen Tagen habe ich dabei das Problem, dass 1. das Verbinden unter Linux sehr lange dauert (1-2 min), und 2. sehr viele, aber nicht alle Websites nicht funktionieren, weil es offensichtlich ein DNS-Problem gibt (bspw. funktioniert startpage und duckduckgo nicht, aber google). Das Problem besteht NUR unter Linux, auf 2 Windowsrechnern ist alles in Ordnung.

Was mich verwundert ist, dass mir in diesem Netzwerk der Linuxrechner ausschließlich eine IPv6-Adresse anzeigt, und außerdem kann ich den Router tatsächlich auch nicht über seine Standard-IP (192.168.0.1 / bzw IPv6-äquivalent) erreichen. Über das OpenWRT-Netz / unter Windows beides kein Problem. Windows zeigt mir zusätzlich eine IPv4-Adresse an.

In der resolv.conf des Linuxrechners ist ein Vodafone-DNS-Server eingetragen. Habe den manuell mal geändert, das hat keine Veränderung bewirkt.

Ideen?

Edit: Aktueller Stand - Problem anscheinend gelöst:
  • Es ist kein DNS-Problem, sondern die IPv4-Vergabe des Kabelrouters an den Linuxrechner spinnt.
  • Mit dem OpenWRT-Netz funktioniert alles (nach wie vor)
  • Vorher hießen das 2.4 und 5 Ghz-Netz des Kabelrouters identisch, der Linuxrechner wollte sich aber anscheinend immer auf das 5 Ghz-Netz verbinden - da ist der Empfang relativ schlecht, daher langsamer/instabiler Verbindungsaufbau. Wenn die Verbindung erfolgt ist, wurde keine IPv4 vergeben, daher funktionierten die Websites nicht.
  • Workaround: Netze sind verschieden benannt, und nur auf das 2.4 Ghz-Netz wird verbunden, damit gibt es auch eine IPv4 und alles funktioniert.
 
Zuletzt bearbeitet:
TotalEclipse schrieb:
aber nicht alle Websites nicht funktionieren, weil es offensichtlich ein DNS-Problem gibt (bspw. funktioniert startpage und duckduckgo nicht, aber google).
Warum muss es DNS sein ? Das deutet auf ein IPv4/IPv6 Problem hin. Google erreicht man auch mit IPv6 only. DuckDuckGo erreicht man nur per IPv4.

Das kannst du hier testen. https://ipv6-test.com/
 
Gib dem Linuxteil eine IPv4.
Scheinbar brkommt der keine per DHCP von Deinem Router.
 
  • Gefällt mir
Reaktionen: cbtestarossa und Cokocool
TotalEclipse schrieb:
1. das Verbinden unter Linux sehr lange dauert (1-2 min)
Was passiert denn in der Zeit laut Log?

TotalEclipse schrieb:
2. sehr viele, aber nicht alle Websites nicht funktionieren, weil es offensichtlich ein DNS-Problem gibt
Woher weißt du, dass es ein DNS Problem ist?

TotalEclipse schrieb:
Das Problem besteht NUR unter Linux, auf 2 Windowsrechnern ist alles in Ordnung.
Dann vergleiche doch mal die Konfiguration der Geräte.

TotalEclipse schrieb:
Was mich verwundert ist, dass mir in diesem Netzwerk der Linuxrechner ausschließlich eine IPv6-Adresse anzeigt,
Das könnte einiges erklären, z.B. Timeouts, die beim Wechsel von IPv4 -> IPv6 auftreten.

TotalEclipse schrieb:
In der resolv.conf des Linuxrechners ist ein Vodafone-DNS-Server eingetragen.
Wo kommt der her?

Ich hab das Gefühl, du hast bereits Recherchen angestellt, die dich zu gewissen Schlussfolgerungen bringen, die du uns aber nicht mitteilst. Deshalb stochern wir im Nebel und können schwer einschätzen, was du da siehst.

Erster kühner Verdacht: DHCP scheitert, warum auch immer. Aber das sollte uns das Log verraten, nach dem ich gefragt habe.
 
TotalEclipse schrieb:
Ab und an muss ich mich aber mit dem WLAN des Kabelrouters verbinden, um den DNS-Filter zu umgehen.
Warum so kompliziert, im Webinterface von Pi hole ist doch extra eine Option zum temporären ausschalten, vorgefertigt sind 10 Sek, 30sek, 5min, und costum time, brauche ich auch manchmal für den einen oder anderen Link, funktioniert bestens. 😅
 
  • Gefällt mir
Reaktionen: Raijin
Abgesehen davon, dass man pihole deaktivieren kann, hat man natürlich auch immer die Möglichkeit, am Endgerät den DNS temporär auf zB 8.8.8.8 umzustellen. Lässt sich auch mit einem Skript auf dem Desktop per Doppelklick erledigen.

Grundsätzlich kann man natürlich auch darüber nachdenken ob eine Routerkaskade, nach der es hier ausschaut, so sinnvoll ist. Du hast zwei Netzwerkebenen, das Netzwerk des Kabelrouters, an dem mutmaßlich nur der OpenWRT-Router via WAN-Port angeschlossen ist, sowie das Netzwerk des OpenWRT-Routers selbst. Nur für pihole wäre das aber nicht notwendig, da man den OpenWRT-Router auch als Client in das Kabelrouter-Netzwerk hängen kann und den DHCP-Server im Kabelrouter ausschaltet. Der OpenWRT-Router verteilt dann einfach per DHCP das Internetgateway = Kabelrouter und DNS = OpenWRT.
 
  • Gefällt mir
Reaktionen: Engaged
Erstmal vorweg - mein Netzwerktechnikwissen ist eher rudimentär, mit diesem ganzen Setup bewege ich mich eher auf fremdem Terrain ;-) Danke bis hierher schonmal für die Anregungen.
Cokocool schrieb:
Warum muss es DNS sein ? Das deutet auf ein IPv4/IPv6 Problem hin. Google erreicht man auch mit IPv6 only. DuckDuckGo erreicht man nur per IPv4.

Das kannst du hier testen. https://ipv6-test.com/
Muss es nicht, der Verdacht ist vermutlich meinem Unwissen geschuldet ;-) Hat sich angefühlt wie ein DNS-Problem, dass einige Adressen nicht aufgelöst werden können.
1643889105591.png

So sieht das Ergebnis aus (Address und Hostname oben Links habe ich rausgelöscht!). Mir sind allerdings die Zusammenhänge zwischen einer lokalen Ipv4 oder 6-Adresse und denen im Internet nicht ganz klar, daher kann ich das Ergebnis nicht interpretieren.
riversource schrieb:
Was passiert denn in der Zeit laut Log?


Woher weißt du, dass es ein DNS Problem ist?


Dann vergleiche doch mal die Konfiguration der Geräte.


Das könnte einiges erklären, z.B. Timeouts, die beim Wechsel von IPv4 -> IPv6 auftreten.


Wo kommt der her?
Kannst du mir sagen, welches Log genau du sehen würdest/da hilft? Habe mal dmesg-Output angeguckt, da sehe ich keine Probleme.
Konfigs vergleichen: Bezogen worauf genau, bzw. wie?
Der Vodafone-DNS kommt nach meinem Verständnis vom Kabelrouter, per DHCP verteilt. Ändern kann ich den DNS dort nicht, abschalten glaube ich auch nicht.
Engaged schrieb:
Warum so kompliziert, im Webinterface von Pi hole ist doch extra eine Option zum temporären ausschalten, vorgefertigt sind 10 Sek, 30sek, 5min, und costum time, brauche ich auch manchmal für den einen oder anderen Link, funktioniert bestens. 😅
Erstmal - es ist kein "richtiger" Pi-Hole, sondern das Adblock für OpenWRT-Router, das aber faktisch das gleiche macht (interface ist aber anders). Außerdem mache ich das v.a., um einige andere Geräte im Netz permanent zu DNS-blocken, z.B. einen Chromecast. Da wäre temporäres Abschalten kontraproduktiv, und ich mache das nur auf meiner Maschine.
Raijin schrieb:
Abgesehen davon, dass man pihole deaktivieren kann, hat man natürlich auch immer die Möglichkeit, am Endgerät den DNS temporär auf zB 8.8.8.8 umzustellen. Lässt sich auch mit einem Skript auf dem Desktop per Doppelklick erledigen.
...
Ich habe wegen des Chromecasts alle Anfragen auf Port 53 auf den OpenWRT-Router gebogen, weil der Chromecast sich nicht an vom DHCP vergebene DNS-Server hält, sondern hardgecoded die Google-Server nutzt, und das möchte ich nicht. Dazu kommt, dass ich glaube ich den Standard-DNS-Server im Kabelrouter nicht ändern/abschalten kann, das müsste ich aber nochmal checken. Daher glaube ich, dass dein Vorschlag nicht funktionieren würde, oder?
 
  • Gefällt mir
Reaktionen: Engaged
TotalEclipse schrieb:
Ich habe wegen des Chromecasts alle Anfragen auf Port 53 auf den OpenWRT-Router gebogen, weil der Chromecast sich nicht an vom DHCP vergebene DNS-Server hält, sondern hardgecoded die Google-Server nutzt, und das möchte ich nicht. Dazu kommt, dass ich glaube ich den Standard-DNS-Server im Kabelrouter nicht ändern/abschalten kann, das müsste ich aber nochmal checken. Daher glaube ich, dass dein Vorschlag nicht funktionieren würde, oder?
Das funktioniert dann aber auch nur solange bis Chromecast DoH oder DoT benutzt, also DNS über https bzw. TLS. Das sind verschlüsselte DNS-Varianten, die zB auch direkt in Browsern genutzt werden und komplett an "Port 53-Umleitungen" vorbeigehen.

Sofern deine Umleitung also tatsächlich greift und Chromecast normales DNS über Port 53 nutzt und dabei fest auf 8.8.8.8 zurückgreift, ist eine Routerkaskade in diesem Fall eine Lösung, aber nicht die einzige. Wenn's aber funktioniert, dann ist das auch ok so.


Abgesehen von der besagten DNS-Umleitung wäre das von mir angesprochene Setup allerdings kein Problem. Der OpenWRT-Router würde ja nach wie vor für deine Endgeräte den DHCP-Server bereitstellen und den kannst du frei konfigurieren wie du möchtest. Der DNS im Kabelrouter ist in diesem Zusammenhang ja irrelevant, weil die Clients den DNS im OpenWRT-Router bekommen und nutzen (sofern nicht hardcoded wie scheinbar im Chromecast).


Dennoch halte ich ein Umloggen des WLANs am PC für unnötig. Wenn du schon DNS in OpenWRT umbiegen konntest, wirst du auch eine Ausnahme für den PC definieren können. Das hieße, dass alle Port 53 Verbindungen auf OpenWRT umgeleitet werden, es sei denn die Source-IP ist die IP des PC*. Somit kannst du am PC nach Belieben auch andere DNS verwenden und im Bedarfsfall am PC eben auf cloudflare, quad9, OpenDNS oder was auch immer umschalten - mit einem Skript schnell erledigt.

* Oder du definierst einen bestimmten public DNS, der an pihole vorbei benutzt werden darf, zB 1.1.1.1
 
Raijin schrieb:
Das funktioniert dann aber auch nur solange bis Chromecast DoH oder DoT benutzt, also DNS über https bzw. TLS. Das sind verschlüsselte DNS-Varianten, die zB auch direkt in Browsern genutzt werden und komplett an "Port 53-Umleitungen" vorbeigehen.
Davon hatte ich auch gelesen, aber verstanden, dass man dann ohnehin machtlos ist - insofern ist das DNS-Blocking aktuell ein "bestmöglicher Versuch" mit klaren Grenzen. Youtube-Werbung und alles was auf der Originaldomain verteilt wird, ist ja ohnehin schon zum Scheitern verurteilt, aber ich fühle mich damit deutlich wohler als ganz ohne (auch den Chromecast betreffend).
Raijin schrieb:
Sofern deine Umleitung also tatsächlich greift und Chromecast normales DNS über Port 53 nutzt und dabei fest auf 8.8.8.8 zurückgreift, ist eine Routerkaskade in diesem Fall eine Lösung, aber nicht die einzige. Wenn's aber funktioniert, dann ist das auch ok so.
Ich hatte, meine ich, zumindest getestet ob Netzanfragen an den google-DNS umgeleitet werden, und das war der Fall. Ob der Chromecast intern aber irgendwelche andere Magic macht, habe ich nicht noch explizit gecheckt dann. Laut Berichten anderer User soll das Vorgehen aber reichen.
Raijin schrieb:
Dennoch halte ich ein Umloggen des WLANs am PC für unnötig. Wenn du schon DNS in OpenWRT umbiegen konntest, wirst du auch eine Ausnahme für den PC definieren können. Das hieße, dass alle Port 53 Verbindungen auf OpenWRT umgeleitet werden, es sei denn die Source-IP ist die IP des PC*. Somit kannst du am PC nach Belieben auch andere DNS verwenden und im Bedarfsfall am PC eben auf cloudflare, quad9, OpenDNS oder was auch immer umschalten - mit einem Skript schnell erledigt.
Da hast du Recht, daran hatte ich bislang nicht gedacht. Das kann ich demnächst mal probieren einzurichten, dennoch würde ich jetzt auch aus akademischem Interesse gern wissen, was beim Kabelrouternetz genau das Problem ist :-)
 
TotalEclipse schrieb:
Muss es nicht, der Verdacht ist vermutlich meinem Unwissen geschuldet ;-) Hat sich angefühlt wie ein DNS-Problem, dass einige Adressen nicht aufgelöst werden können.
Werden sie wirklich nicht aufgelöst oder einfach nur nicht erreicht ? Das ist hier ein himmelweiter Unterschied

Was sagt denn nslookup/dig für duckduckgo.com ?
 
  • Gefällt mir
Reaktionen: Raijin
TotalEclipse schrieb:
Kannst du mir sagen, welches Log genau du sehen würdest/da hilft? Habe mal dmesg-Output angeguckt, da sehe ich keine Probleme.
Die Logs, die dein Linux zur Verfügung stellt. Das ist ja von Distribution zu Distribution unterschiedlich. Vielleicht was in /var/log, oder das Journal vom systemd. Das musst du selber herausfinden.

TotalEclipse schrieb:
Konfigs vergleichen: Bezogen worauf genau, bzw. wie?
Auf IP-Adressen und Netzwerkeinstellungen, also u.a. DNS etc.

TotalEclipse schrieb:
Der Vodafone-DNS kommt nach meinem Verständnis vom Kabelrouter, per DHCP verteilt.
Sicher? Verteilt der sich nicht selber als DNS Server?
Besteht das Problem mit der fehlenden IPv4 Adresse noch? Mit welcher Konfiguration hast du oben den ipv6-test Screenshot gemacht? Am OpenWRT oder am Kabelmodem?
 
Cokocool schrieb:
Werden sie wirklich nicht aufgelöst oder einfach nur nicht erreicht ? Das ist hier ein himmelweiter Unterschied

Was sagt denn nslookup/dig für duckduckgo.com ?
Code:
$ dig duckduckgo.com

; <<>> DiG 9.11.5-P4-5.1+deb10u6-Debian <<>> duckduckgo.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44799
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;duckduckgo.com.            IN    A

;; ANSWER SECTION:
duckduckgo.com.        101    IN    A    40.114.177.156

;; Query time: 17 msec
;; SERVER: 2a02:8108:45bf:fd6c:5667:51ff:fe57:223a#53(2a02:8108:45bf:fd6c:5667:51ff:fe57:223a)
;; WHEN: Do Feb 03 14:59:35 CET 2022
;; MSG SIZE  rcvd: 59

Sieht mir eigentlich sogar erfolgreich aus... Ich bin der Meinung (aber da kann ich mich auch vertun), dass der Output vor 2 Tagen anders aussah, da hatte ich das schonmal getestet), aber jetzt ist er wie er ist...

riversource schrieb:
Die Logs, die dein Linux zur Verfügung stellt. Das ist ja von Distribution zu Distribution unterschiedlich. Vielleicht was in /var/log, oder das Journal vom systemd. Das musst du selber herausfinden.Sicher? Verteilt der sich nicht selber als DNS Server?
Ok, ich hatte danach schon gegoogelt, aber nicht das richtige gefunden. Werde nochmal weiterschauen. MXLinux ist es, Debian-basiert.
riversource schrieb:
Besteht das Problem mit der fehlenden IPv4 Adresse noch? Mit welcher Konfiguration hast du oben den ipv6-test Screenshot gemacht? Am OpenWRT oder am Kabelmodem?
Nicht sicher, aber meine Vermutung war immer, dass Vodafone seine Router mit ihren eigenen DNS-Servern vorkonfiguriert...
Ja, das IPv4-Problem besteht noch, habe mich da noch nicht rangesetzt. Der Screenshot ist am Kabelmodem, am OpenWRT war der Score deutlich höher und fast alles funktionierte.
Edit: Mein Fehler, der Score ist nur unter Windows am Kabelrouter höher, ansonsten kommt immer die obige 4/20 raus.
 
Zuletzt bearbeitet:
Wie vermutet - DNS funktioniert. Warum sollte der DNS Server dir Google.de auflösen können aber nicht duckduckgo.com ? Sowas passiert eher selten.

Das ist eine IPv4/IPv6 Geschichte. Duckduckgo erreicht man nur per IPv4
 
Cokocool schrieb:
Wie vermutet - DNS funktioniert. Warum sollte der DNS Server dir Google.de auflösen können aber nicht duckduckgo.com ? Sowas passiert eher selten.

Das ist eine IPv4/IPv6 Geschichte. Duckduckgo erreicht man nur per IPv4
Ich habe mir mal testweise für das Kabelrouter-Netz eine feste IPv4-Adresse eingetragen - ich verbinde mit dem Netz, es geht relativ fix, die IP ist gesetzt - aber nichts geht, gar keine Verbindung mehr. Habe auch mehrere ausprobiert, um Kollisionen auszuschließen. Wie sonst sollte ich mir eine IPv4-Adresse geben?
 
Du schaffst es echt, mich zu verwirren.

TotalEclipse schrieb:
Nicht sicher, aber meine Vermutung war immer, dass Vodafone seine Router mit ihren eigenen DNS-Servern vorkonfiguriert...
Ja, das heißt aber nicht, dass sie ihn auch per DHCP an ihre Clients weiterreichen. Im DHCP geben Heimrouter üblicherweise sich selber als DNS Server an.

TotalEclipse schrieb:
Ja, das IPv4-Problem besteht noch, habe mich da noch nicht rangesetzt.
Über welches Problem reden wir denn dann hier? Es geht doch darum, wenn du dich per Linux direkt mit dem Kabelmodem verbindest. Da fehlt die IPv4 Adresse und du kannst Webseiten nicht aufrufen. Gibt es noch ein anderes Problem? Weil für die beschriebenen Effekte wird die fehlende IPv4 Adresse garantiert eine Rolle spielen.

TotalEclipse schrieb:
Der Screenshot ist am Kabelmodem, am OpenWRT war der Score deutlich höher und fast alles funktionierte.
Ok, nun ist das Chaos komplett.

Du schreibst, am Kabelmodem hast du keine IPv4, aber eine IPv6 Adresse. Der Screenshot von ipv6-test zeigt das genaue Gegenteil. Außerdem sieht man in deinem dig Aufruf, dass der von einem IPv6 Server beantwortet wurde. Wie hast du denn den angefertigt?
Und wie schaffst du es, am Kabelrouter kein IPv6 zu haben, am OpenWRT aber schon, wenn der OpenWRT hinter dem Kabelrouter hängt?

Grundsätzlich: Wenn du ein problematisches Environment hast, und eins, was funktioniert, und wir fragen nach Diagnose Informationen, dann solltest du die auch im problematischen Environment erzeugen. Es hilft nicht, Screenshots von etwas Funktionierendem zu posten und dort nach Fehlern zu suchen, die eigentlich woanders auftreten.
 
riversource schrieb:
Du schaffst es echt, mich zu verwirren.
Sorry, dafür, ich bin es selbst. Ich versuche mal zu entwirren.

riversource schrieb:
Ja, das heißt aber nicht, dass sie ihn auch per DHCP an ihre Clients weiterreichen. Im DHCP geben Heimrouter üblicherweise sich selber als DNS Server an.
Macht Sinn, habe ich auch schon gesehen, aber in dieser resolv.conf waren (je nach Netz, in dem ich war), verschiedene Einträge - daraus habe ich gefolgert, dass der DHCP des Routers diese Adressen jeweils mitteilt. Mag aber falsch sein - aber gerade vermutlich auch nicht entscheiden.

riversource schrieb:
Über welches Problem reden wir denn dann hier? Es geht doch darum, wenn du dich per Linux direkt mit dem Kabelmodem verbindest. Da fehlt die IPv4 Adresse und du kannst Webseiten nicht aufrufen. Gibt es noch ein anderes Problem? Weil für die beschriebenen Effekte wird die fehlende IPv4 Adresse garantiert eine Rolle spielen.
Vermutlich ist die Ursache die fehlende IPv4-Adresse, das war aber bis ich gerade das dig-Ergebnis gepostet habe glaube ich nicht 100% klar. Mein Verdacht, dass es ein DNS-Problem war, ist damit aber ja anscheinend eindeutig widerlegt. Zum Versuch, mir eine Adresse zu geben s. mein letzter Post.
Wie oben geschrieben ist mir aber nach wie vor überhaupt nicht klar, wieso eine bestimmte IP-Adressvergabe im (W)LAN eine Rolle für die Erreichbarkeit von Internetadressen hat, gerne mal einen Infolink dazu posten.
riversource schrieb:
Ok, nun ist das Chaos komplett.

Du schreibst, am Kabelmodem hast du keine IPv4, aber eine IPv6 Adresse. Der Screenshot von ipv6-test zeigt das genaue Gegenteil. Außerdem sieht man in deinem dig Aufruf, dass der von einem IPv6 Server beantwortet wurde. Wie hast du denn den angefertigt?
Und wie schaffst du es, am Kabelrouter kein IPv6 zu haben, am OpenWRT aber schon, wenn der OpenWRT hinter dem Kabelrouter hängt?
Sorry, da bin ich tatsächlich durcheinander gekommen. Der Screenshot von oben war Linuxrechner am Kabelrouter - also im problematischen Setting, wie angefragt. Am Linuxrechner am OpenWRT sieht das Ergebnis GENAUSO aus.
An einem WINDOWS-Rechner im Kabelrouternetz ist alles außer ICMP und Hostname bei IPv6 grün und ich bekomme einen Score von 17/20. Unter Windows am OpenWRT ist es genau wie unter Linux die 4/20 von oben.
Hoffe das klärt die Verwirrung?
 
TotalEclipse schrieb:
Der Screenshot von oben war Linuxrechner am Kabelrouter - also im problematischen Setting, wie angefragt.
Ok. Da funktioniert IPv4 aber offensichtlich.

TotalEclipse schrieb:
Am Linuxrechner am OpenWRT sieht das Ergebnis GENAUSO aus.
Gut. IPv4 geht, IPv6 nicht.

TotalEclipse schrieb:
An einem WINDOWS-Rechner im Kabelrouternetz ist alles außer ICMP und Hostname bei IPv6 grün und ich bekomme einen Score von 17/20.
Ok, also Windows hat am Kabelrouter IPv4 und IPv6. Gut. Linux nur IPv4. Das kann natürlich eine Einstellung im Linux sein.

TotalEclipse schrieb:
Unter Windows am OpenWRT ist es genau wie unter Linux die 4/20 von oben.
Ok. Der OpenWRT macht vermutlich im LAN kein IPv6. Damit das vernünftig funktioniert, müsste der Kabelrouter auch Prefix Delegation machen. Ich glaube nicht, dass das so einfach geht. Es ist aber auch nebensächlich im Moment.

Zusammenfassend:
  • Am Kabelrouter funktioniert IPv4 und IPv6, wobei Linux sich keine IPv6 holt
  • Am OpenWRT funktioniert IPv4, was auch bei Linux und Windows zur Anwendung kommt.

Das sagen jedenfalls die Ausgaben von ipv6-test. Der Aufruf von dig oben war also unter Windows am Kabelrouter? Das ist die einzige Möglichkeit, denn die Antwort kommt von einem IPv6 Server.

Bleibt das Problem unter Linux am Kabelrouter. Warum glaubst du, hast du unter Linux am Kabelrouter keine IPv4? Poste doch mal Ausgaben von "ifconfig" oder "ip a" unter Linux am Kabelrouter. Ein Ping auf eine nicht funktionierende Webseite wäre auch interessant.
 
Edit:
Ich weiß nicht, was jetzt passiert ist. Im gefühlt 100. Versuch, mit dem Kabelrouter zu verbinden hat der auf einmal eine IPv4-Adresse verteilt, und dann funktionieren die Seiten. In den Linux-Netzwerkeinstellungen habe ich die IPv4-Adressvergabe auf "DHCP (nur Adressen)" gestellt, aber den Wert hatte es zu Beginn auch schon.
Es dauert allerdings wirklich lange/schlägt immer wieder fehl, überhaupt zu verbinden.

riversource schrieb:
Das sagen jedenfalls die Ausgaben von ipv6-test. Der Aufruf von dig oben war also unter Windows am Kabelrouter? Das ist die einzige Möglichkeit, denn die Antwort kommt von einem IPv6 Server.
Leider nein, die dig-Ausgabe war unter Linux am Kabelrouter. Hier nochmal:
Code:
$ dig duckduckgo.com

; <<>> DiG 9.11.5-P4-5.1+deb10u6-Debian <<>> duckduckgo.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62901
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;duckduckgo.com.            IN    A

;; ANSWER SECTION:
duckduckgo.com.        140    IN    A    40.114.177.156

;; Query time: 4 msec
;; SERVER: 2a02:8108:45bf:fd6c:5667:51ff:fe57:223a#53(2a02:8108:45bf:fd6c:5667:51ff:fe57:223a)
;; WHEN: Do Feb 03 16:10:40 CET 2022
;; MSG SIZE  rcvd: 59

Code:
$ dig duckduckgo.com

; <<>> DiG 9.11.5-P4-5.1+deb10u6-Debian <<>> duckduckgo.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54372
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;duckduckgo.com.            IN    A

;; ANSWER SECTION:
duckduckgo.com.        51    IN    A    40.114.177.156

;; Query time: 3 msec
;; SERVER: fd64:5051:7fd6::1#53(fd64:5051:7fd6::1)
;; WHEN: Do Feb 03 15:59:02 CET 2022
;; MSG SIZE  rcvd: 59
riversource schrieb:
Bleibt das Problem unter Linux am Kabelrouter. Warum glaubst du, hast du unter Linux am Kabelrouter keine IPv4? Poste doch mal Ausgaben von "ifconfig" oder "ip a" unter Linux am Kabelrouter. Ein Ping auf eine nicht funktionierende Webseite wäre auch interessant.
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::7b49:bd32:97e6:cf6c prefixlen 64 scopeid 0x20<link>
inet6 2a02:8108:45bf:fd6c:1ad9:4f3c:6fed:bd85 prefixlen 64 scopeid 0x0<global>
ether 34:31:c4:db:6a:e3 txqueuelen 1000 (Ethernet)
RX packets 448 bytes 440662 (430.3 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 410 bytes 75686 (73.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
(später gemacht als ifconfig)
9: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 34:31:c4:db:6a:e3 brd ff:ff:ff:ff:ff:ff
inet6 2a02:8108:45bf:fd6c:1ad9:4f3c:6fed:bd85/64 scope global dynamic noprefixroute
valid_lft 66350sec preferred_lft 23150sec
inet6 fe80::7b49:bd32:97e6:cf6c/64 scope link noprefixroute
valid_lft forever preferred_lft forever
Warum? Keine Ahnung leider...
 
Zuletzt bearbeitet:
Das ist in der Tat bemerkenswert. Und der Verbindungsaufbau dauert immer noch so lange unter Linux? Der Screenshot von oben ist bei so einer Netzwerkkonfiguration entstanden?

Gibt es da noch ein anderes Interface mit einer IPv4 Adresse? Ein Tunnel oder so? Nutzt der Browser einen Proxy?
 
riversource schrieb:
Das ist in der Tat bemerkenswert. Und der Verbindungsaufbau dauert immer noch so lange unter Linux? Der Screenshot von oben ist bei so einer Netzwerkkonfiguration entstanden?
Ja, immernoch langsam (natürlich nur zum Kabelrouter), und Aufbau der Verbindung klappt auch gerade nur in 30-40% der Fälle. War erst nicht sicher, ob das vllt. mit der größeren Entfernung zum Router zu tun hat, aber wenn ich meinen Windowslaptop mit Mini-WLAN-Stick danebenstelle kann der sofort verbinden. Langsamer Verbindungsaufbau ist also ein Linuxproblem.
Der Screenshot oben entstand bei Linux+Kabelrouter ohne IPv4-Adresse, mit selber Linux-Netzwerkkonfig initiiert wie die, die jetzt funktioniert und eine IPv4-Adresse bekommen hat.
riversource schrieb:
Gibt es da noch ein anderes Interface mit einer IPv4 Adresse? Ein Tunnel oder so? Nutzt der Browser einen Proxy?
Nein, keinen Tunnel, keinen Proxy, in 2 Browsern reproduziert.
 
Zurück
Oben