wget Fehler oder sehr langsam (IPv6 Problem?)

    Hi,


    auf einem der Debian-Server funktioniert wget entweder nicht oder nur extrem langsam. Scheint so, als würde dies nur passieren, wenn IPv6 aufgelöst werden soll. Denn bei IPv6 kommt "failed", wonach die IPv4-Adresse erfolgreich aufgelöst und die Datei heruntergeladen wird.



    Das passiert übrigens seit dem letzten großen Upgrade von Debian.


    Welche Logs oder Configs bräuchtet ihr, um zu helfen?


    Vielen Dank.

    Ich bitte Euch, Kunden-Seiten nicht direkt zu erwähnen, damit nicht unnötig Traffic hierher geleitet wird, wenn jemand bspw. nach xymeinkunde.de googlet. :)

    Stimmt Deine Default-Route fuer IPv6 ?


    ip -6 route show


    sollte so eine Zeile enthalten:


    default via fe80::1 dev ens3 metric 1024 onlink pref medium


    "metric" und "pref" sind nicht wichtig, der Rest schon.

    Code
    root@myserver:~# ip -6 route show
::1 dev lo proto kernel metric 256 pref medium
2a03:4000:2:f093::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::1 dev eth0 metric 1024 onlink pref medium


    Code
    root@myserver:~# ping -6 google.com
PING google.com(fra24s06-in-x0e.1e100.net (2a00:1450:4001:829::200e)) 56 data bytes
--- google.com ping statistics ---
63 packets transmitted, 0 received, 100% packet loss, time 63473ms

    Nach der ersten Zeile kommt lange nichts. Muss dann abbrechen, wonach dann die restlichen Infos (ping statistics) kommen.


    cUrl funktioniert einwandfrei.




    /root/.wget-hsts:

    Code
    # HSTS 1.0 Known Hosts database for GNU Wget.
# Edit at your own risk.
# <hostname>    <port>  <incl. subdomains>      <created>       <max-age>
www.servercontrolpanel.de       0       1       1649764702      31536000
en.wikipedia.org        0       1       1661474718      106384710
github.com      0       1       1658690700      31536000
myserver.de 0       1       1658573118      63072000
codeload.github.com     0       0       1658690700      31536000

    Ich bitte Euch, Kunden-Seiten nicht direkt zu erwähnen, damit nicht unnötig Traffic hierher geleitet wird, wenn jemand bspw. nach xymeinkunde.de googlet. :)

    Ich bitte Euch, Kunden-Seiten nicht direkt zu erwähnen, damit nicht unnötig Traffic hierher geleitet wird, wenn jemand bspw. nach xymeinkunde.de googlet. :)

    Fortsetzung letzter Output


    Ich bitte Euch, Kunden-Seiten nicht direkt zu erwähnen, damit nicht unnötig Traffic hierher geleitet wird, wenn jemand bspw. nach xymeinkunde.de googlet. :)

    Fortsetzung letzter Output



    Alles ziemlich kryptisch.

    Ich bitte Euch, Kunden-Seiten nicht direkt zu erwähnen, damit nicht unnötig Traffic hierher geleitet wird, wenn jemand bspw. nach xymeinkunde.de googlet. :)

    Wenn der simple Ping nicht geht, muss das ja schon irgendwas grundlegendes sein? Komisch nur, dass curl gehen soll.


    Wie sieht denn deine /etc/network/interfaces aus? Passt die noch seit dem Update?

    Heißt dein Interface wirklich eth0 und nicht ens3 oder ähnlich?

    Irgendeine Firewall aktiv, die vielleicht gar kein IPv6 Traffic raus oder rein lässt?




    Bei cUrl kam bisher immer sofort was. Habe aber nicht drauf geachtet. Vielleicht nutzt cUrl einfach direkt IPv4.

    Ich bitte Euch, Kunden-Seiten nicht direkt zu erwähnen, damit nicht unnötig Traffic hierher geleitet wird, wenn jemand bspw. nach xymeinkunde.de googlet. :)

    Einmal editiert, zuletzt von Akay ()

    Du hast kein funktionierendes IPv6. Wenn der Download ueberhaupt klappt, dann weil er auf IPv4 zurueckgefallen ist,


    Fragen:


    Warum heisst Dein Interface "eth0" ? Normalerweise heisst das primaere Interface bei VMs von NC "ens3".

    Hat Dein Interface eine IPv6-Adresse aus dem Praefix, den NC Deiner VM zugeteilt hat?

    Funktioniert "ping fe80::1%eth0" ?

    Mein anderer Ubuntu-Server hat auch eth0. Sind beides root server.



    Im SCP:

    Ob die Schnittstelle eth0 oder ens33 heißt, ist ja nur eine Frage der Kernel Parameter, die man beim Booten mit auf den Weg gibt. Wichtig ist, dass der Rest der Konfiguration dazu passt.


    Oben die ufw Ausgabe verwirrt mich. Du hast nicht wirklich tausende IP-Adressen als direkte Regel im ufw Framework, oder? =O Das ist nicht empfehlenswert, weil sehr ineffizient. Wenn man solche Blacklisten pflegen will, dann lieber auf ipset setzen.


    Braucht man bei ufw nichts in Richtung RELATED/ESTABLISHED?

    Im ersten Post hiess es Debian, nicht Ubuntu. Daher meine Frage nach eth0 vs. ens3. Ist aber ok so.


    Da das Ping auf fe80::1 funktioniert, wuerde ich die Firewall ausschliessen.


    "traceroute -6 google.de" kommt vermutlich nicht mal bis zum ersten Hop, oder?


    Du kannst noch "ping 2a03:4000:10::3" probieren.Das ist der erste Hop, den ich beim Traceroute sehe.


    Deine Konfiguration sieht sonst gut aus. Mir fallsen dann nur noch die ueblichen Verzweiflungsmassnahmen ein. (Reboot, Test mit dem Rettungssystem, Support)


    Edit: Wie verhindere ich, dass mir die Forensoftware automtisch aus einem Hostnamen einen Link macht ? Mit "www" vor dem "google" wurde mir immer ein Link erzeugt.

    Zitat von heppel

    Da das Ping auf fe80::1 funktioniert, wuerde ich die Firewall ausschliessen.

    Ähh, Nein. Das Ziel der Ping-Antworten von fe80::1 ist voraussichtlich die eigene link-lokale Adresse. Der Inhalt von Firewall-Regeln ist üblicherweise die eigene Public Adresse. Das eine kann wunderbar funktionieren, während das andere komplett geblockt wird.


    Gerade die Schwankungen im Ping Result auf fe80::1 zeigen mir, dass da was faul ist. Ich vermute, diese tausenden Zeilen spielen da eine Rolle. Ob die auch ursächlich für das Gesamtproblem sind, kann ich noch nicht sagen.


    Ist 50-cloud-init.cfg die einzige Datei in /etc/network/interfaces.d/?

    Zitat von heppel

    Wie verhindere ich, dass mir die Forensoftware automtisch aus einem Hostnamen einen Link macht ? Mit "www" vor dem "google" wurde mir immer ein Link erzeugt.

    Mit dem [code] oder [tt] BBCode :)


    Letzteres ist der sogenannte Inline-Code. Dafür gibt es im Editor eigene Schaltflächen.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Einmal editiert, zuletzt von KB19 ()

    Zitat von frank_m

    Ähh, Nein. Das Ziel der Ping-Antworten von fe80::1 ist voraussichtlich die eigene link-lokale Adresse. Der Inhalt von Firewall-Regeln ist üblicherweise die eigene Public Adresse. Das eine kann wunderbar funktionieren, während das andere komplett geblockt wird.


    NEIN. fe80::1 ist die Adresse des Default-Gateways. Definitiv keine eigene Adresse. Ausserdem haette das "tcpdump" die Antwortpakete vom Webserver gezeigt. Tcpdump greift die Pakete vor der Firewall ab.

    Zitat von heppel

    fe80::1 ist die Adresse des Default-Gateways. Definitiv keine eigene Adresse.

    Richtig, aber offenbar hast du meine Intention nicht verstanden.


    Wenn du fe80::1 anpingst, dann wird die Absender-Adresse in diesem Ping Paket die link-lokale Adresse des entsprechenden Interfaces sein. Das ist ebenso die Adresse, an die die Ping-Antworten von fe80::1 zurückgesendet werden.


    Wenn du aber ein Paket an einen öffentlichen Webserver sendest, dann wird die Absenderadresse die primäre öffentliche Adresse des entsprechenden Interfaces sein. Das Defaultgateway kann ja trotzdem fe80::1 sein, es geht ja nur darum, zu wissen, an welche MAC Adresse das Paket im ersten Hop geleitet wird. Die Antworten des Webservers werden an diese öffentliche Adresse zurückgesendet (wenn sie den Server erreicht haben, was wir nicht wissen) und landen damit in völlig anderen Firewall Regeln, als vorher die Ping Pakete.


    Fazit: Ein Ping auf eine link-lokale Gateway Adresse eignet sich nicht, um die generelle IPv6 Funktionalität eines Servers oder die Firewall zu testen. Auf keinen Fall ist der Schluss zulässig "Der Ping auf fe80::1 geht, also blockt die Firewall keine eingehenden IPv6 Pakete".


    Zitat von heppel

    Ausserdem haette das "tcpdump" die Antwortpakete vom Webserver gezeigt. Tcpdump greift die Pakete vor der Firewall ab.

    Auch richtig. Aber da sieht man halt auch, dass nur 30 von 41 Paketen gecaptured wurden. Außerdem wissen wir nicht, was von den ausgehenden Paketen den Server erreicht hat.


    Mich würde immer noch interessieren, ob da wirklich tausende ufw Regeln als Blacklist verwendet werden. So oder so halte ich das für eine schlechte Idee. Wie gesagt, ob es ursächlich ist, müsste man herausfinden, aber bei der Ineffizienz, die das erzeugt, halte ich es für denkbar, dass es nachhaltig Einfluss auf die gesamte Kommunikation des Servers nimmt.


    Darüber hinaus muss man Tests mit IPv6 Gegenstellen machen, auf denen man vergleichbare Messungen machen kann, um zu analysieren, was konkret da ankommt. Nicht zuletzt muss man dann auch Pakete von außen an den Server senden, um auch da zu sehen, was ankommt.

    Ich habe tatsächlich aber tausende UFW-Regeln. Seit Jahren nutze ich dieses selbst geschriebene Script, welches TOR-IPs zieht und alle einzeln blockt. Dieses Script steht natürlich noch auf meiner To Do. IPset schaue ich mir noch an.


    Bei diesem Server geht es um Debian. Aber da es einen allgemeinen Statement zu allen NC-Servern gab, wollte ich damit sagen, dass auch mein zweiter Server eth0 hat (der aber Ubuntu ist).


    Code
    root@myserver:~/scripts# ping 2a03:4000:10::3
PING 2a03:4000:10::3(2a03:4000:10::3) 56 data bytes
^C
--- 2a03:4000:10::3 ping statistics ---
14 packets transmitted, 0 received, 100% packet loss, time 13304ms


    Server wurde seither zigfach neu gestartet.



    Die Domain lässt sich hierüber über IPv6 anpingen: http://www.ipv6now.com.au/pingme.php



    Hat es gereicht, ufw zu disablen? Weil es ja nur ein Framework für iptables ist. Muss man iptables selbst auch noch leeren?

    Ich bitte Euch, Kunden-Seiten nicht direkt zu erwähnen, damit nicht unnötig Traffic hierher geleitet wird, wenn jemand bspw. nach xymeinkunde.de googlet. :)

    Zitat von Akay

    Die Domain lässt sich hierüber über IPv6 anpingen: http://www.ipv6now.com.au/pingme.php

    Und was passiert dann im tcpdump?

    Die IP-Adresse, die man oben sieht, lässt sich nicht anpingen, und das ist offenbar die einzige auf deinem Server. Welche Adresse verbirgt sich hinter der Domain?

    Zitat von Akay

    Weil es ja nur ein Framework für iptables ist.

    Bist du sicher, dass du iptables nutzt? Es könnte ja auch nftables sein.


    Ich bekomme den Eindruck, dass die IPv6 Pakete den Server gar nicht verlassen. Das musst du auf einem anderen IPv6 tauglichen Host verifizieren.