Werbeblocker Adblock NextDNS und uBlock hängt über IPv6

Bei der Verwendung von Werbeblockern wie NextDNS, uBlock oder Adblock kann es zu langen Ladezeiten kommen, wenn der Netzwerk-Stack des lokalen Rechners Anfragen auf 0.0.0.0 (für IPv4) oder :: (IPv6) falsch interpretiert. Bemerkbar macht es sich z.B. auf der Seite telekom.de, da dort ein Tagger verwendet wird, welcher gerne blockiert wird: https://tags-eu.tiqcdn.com/.... Da dieses Script aber nicht asynchron geladen wird, hängt die gesamte Seite bis die Abhängigkeit aufgelöst werden konnte.

Zur schnellen Analyse können wir zuerst sicherstellen das Netzwerkanfragen korrekt und schnell abgelehnt werden:

$ nc -v 0.0.0.0 80
nc: connect to 0.0.0.0 port 80 (tcp) failed: Connection refused

$ nc -v 0.0.0.0 443
nc: connect to 0.0.0.0 port 443 (tcp) failed: Connection refused

$ nc -6 -v :: 80
nc: connect to :: port 80 (tcp) failed: Connection refused

$ nc -6 -v :: 443
nc: connect to :: port 443 (tcp) failed: Connection refused

Diese Befehle sollten alle schnell die Antwort liefern. Dieser Artikel beschäftigt sich mit dem Fall das einer dieser Befehle nicht direkt eine Ablehnungsantwort bekommt, sondern hängt oder gegen einen unbekannten Timeout läuft.

Bei mir war dies die Abfrage nc -6 -v :: 80 welche einen Timeout nach etwa zwei Minuten produzierte und für den Fehler verantwortlich war.

Erstes Indiz für das Problem war, das mein IPv6-Loopback-Adapter nie eine IPv6-Adresse erhalten hatte:

$ ifconfig lo
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)

Warum? Weil ich keinen Kopf für IPv6 habe und es im Kernel deaktiviert hatte:

$ sysctl net.ipv6.conf.lo.disable_ipv6
net.ipv6.conf.lo.disable_ipv6 = 1

Hier sollte man ggf. manuelle Einstellungen in /etc/sysctl.d/ prüfen, ob dort eine der Regeln aus dem Bereich net.ipv6.conf gesetzt werden und entsprechend wieder zurücksetzen.

Nach einer Anpassung hatte das Loopback-Adapter wieder eine korrekte Adresse:

$ ipconfig lo
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)

und Anfragen ob die entsprechend Hosts wurden wieder korrekt und sofort beantwortet:

$ nc -6 -v :: 80
nc: connect to :: port 80 (tcp) failed: Connection refused

$ ping6 ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.049 ms

Damit konnten Seite mit synchronen Abhängigkeiten wieder zügig aufgerufen werden.