IPv6 Probleme mit best. Web-Seiten an einzelnem Client

Hallo,

ich habe Probleme beim Aufruf bestimmter Web-Seiten (z.B. https://www.elektronik-kompendium.de/), die über IPv6 und SSL angesprochen werden. In der Kombination IPv4 und SSL gibt es keine Probleme.

Ich bin folgende Möglichkeiten schon durchgegangen:

  • Betriebssysteme Linux, Windows 7 und Windows 10
  • Wechsel der Community (z.B. FF-Essen, FF-EN und FF-Düsseldorf)
  • Überprüfung der IPv6 Verbindung mit http://test-ipv6.com/ und Connection test erfolgreich
  • IPv6 Adresse, IPv6 Netmask, IPv6 Gateway und IPv6 DNS in Ordnung
  • Problem tritt sowohl auf Command Line als auch mit verschiedenen Browsern (Firefox, Chrome, IE) auf
  • SSL Handshake kommt nicht zu Stande

HTTP → OK

wget -d -O /dev/null http://www.elektronik-kompendium.de/
Setting --output-document (outputdocument) to /dev/null
DEBUG output created by Wget 1.17.1 on linux-gnu.

Reading HSTS entries from /home/user/.wget-hsts
URI encoding = »UTF-8«
--2018-02-21 19:15:04--  http://www.elektronik-kompendium.de/
Auflösen des Hostnamen »www.elektronik-kompendium.de (www.elektronik-kompendium.de)«... 2001:8d8:100f:f000::2b7, 217.160.0.96
Caching www.elektronik-kompendium.de => 2001:8d8:100f:f000::2b7 217.160.0.96
Verbindungsaufbau zu www.elektronik-kompendium.de (www.elektronik-kompendium.de)|2001:8d8:100f:f000::2b7|:80... verbunden.
Created socket 4.
Releasing 0x000055b61421db10 (new refcount 1).

---request begin---
GET / HTTP/1.1
User-Agent: Wget/1.17.1 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: www.elektronik-kompendium.de
Connection: Keep-Alive

---request end---
HTTP-Anforderung gesendet, warte auf Antwort... 

HTTPS- > Fehler

wget -d -O /dev/null https://www.elektronik-kompendium.de/
Setting --output-document (outputdocument) to /dev/null
DEBUG output created by Wget 1.17.1 on linux-gnu.

Reading HSTS entries from /home/user/.wget-hsts
URI encoding = »UTF-8«
--2018-02-21 19:17:38--  https://www.elektronik-kompendium.de/
Auflösen des Hostnamen »www.elektronik-kompendium.de (www.elektronik-kompendium.de)«... 2001:8d8:100f:f000::2b7, 217.160.0.96
Caching www.elektronik-kompendium.de => 2001:8d8:100f:f000::2b7 217.160.0.96
Verbindungsaufbau zu www.elektronik-kompendium.de (www.elektronik-kompendium.de)|2001:8d8:100f:f000::2b7|:443... verbunden.
Created socket 4.
Releasing 0x0000558106816050 (new refcount 1).
Initiating SSL handshake.

Äh, was kommt denn nach „Initiating SSL handshake“ über v6? Generelles Problem sollte es nicht sein:

root@discourse:~# wget -6 -d -O /dev/null https://www.elektronik-kompendium.de/
Setting --output-document (outputdocument) to /dev/null
DEBUG output created by Wget 1.17.1 on linux-gnu.

Reading HSTS entries from /root/.wget-hsts
URI encoding = ‘UTF-8’
--2018-02-22 14:14:48--  https://www.elektronik-kompendium.de/
Resolving www.elektronik-kompendium.de (www.elektronik-kompendium.de)... 2001:8d8:100f:f000::2b7
Caching www.elektronik-kompendium.de => 2001:8d8:100f:f000::2b7
Connecting to www.elektronik-kompendium.de (www.elektronik-kompendium.de)|2001:8d8:100f:f000::2b7|:443... connected.
Created socket 4.
Releasing 0x000055d9974756e0 (new refcount 1).
Initiating SSL handshake.
Handshake successful; connected socket 4 to SSL handle 0x000055d997475ea0
certificate:
[…]
018-02-22 14:14:48 (1,71 MB/s) - ‘/dev/null’ saved [27357]

Saving HSTS entries to /root/.wget-hsts

Irgendwann kommt ein Timemout ohne eine weitere Fehlermeldung.

Ist deine Systemzeit korrekt?
Weiß nicht ob Wget dafür ne Fehlermeldung werfen würde.
Aber falsche Uhrzeit sorgt teilweise für nervige Probleme.

Ah, dann ist traceroute Dein Freund — und das Mittel der Wahl, das Problem einzugrenzen:

 root@discourse:~# traceroute -T -6 -m 10 www.elektronik-kompendium.de
 traceroute to www.elektronik-kompendium.de (2001:8d8:100f:f000::2b7), 30 hops max, 80 byte packets
  1  bgp-ber01.4830.org (2a06:e881:1706:1::1)  0.285 ms  0.133 ms  0.154 ms
  2  strato.a36.community-ix.de (2001:7f8:a5::6724:1)  0.260 ms  0.351 ms  0.288 ms
  3  ae2.0.morla.as6724.net (2a01:238:0:30ad::2)  14.472 ms  14.467 ms  14.414 ms
  4  vl-88.bb-c.act.fra.de.oneandone.net (2001:8d8:0:3::6d)  14.543 ms  14.599 ms  14.655 ms
  5  ae-11.bb-c.bs.kae.de.oneandone.net (2001:8d8:0:2::101)  17.641 ms  17.596 ms  17.558 ms
  6  2001-08d8-100f-f000-0000-0000-0000-02b7.elastic-ssl.ui-r.com (2001:8d8:100f:f000::2b7)  16.861 ms  16.971 ms  16.900 ms

Interessant wäre auch noch Deine Quell-IP (genauer: die ersten 4 Blöcke der v6-Adresse, also z. B. 2a06:e881:1706:1 in meinem Fall); wenn’s nur zu einigen Zielen Probleme gibt, fehlt wahrscheinlich teilweise der Rückweg (ungefähr ab da, wo * auftreten im traceroute).

kannst Du strace/ltrace nachinstallieren ? Wenn da irgendwas runtime-maessig krank ist, sieht man das am besten so.

Irgendwo übereifrig ICMPv6 blockiert und damit die MTU-Discovery kaputt gemacht?

2 „Gefällt mir“

traceroute und ping sind sauber.

Es gibt keine Firewall. Freifunk :slight_smile: .

Aber die Idee ist nicht schlecht. Ich bin gerade mit tracepath6 auf der Suche.

Bei dem Anschluss handelt es sich übrigens um einen FTTH der Telekom.

Also aus einer von Dir oben gelisteten Community funktioniert es einwandfrei,
vielleicht sind die Probleme anderer Natur?

Traceroute

mattes@enkreis-3:~$ sudo traceroute6 -I www.elektronik-kompendium.de
traceroute to www.elektronik-kompendium.de (2001:8d8:100f:f000::2b7), 30 hops max, 80 byte packets
 1  2a03:2260:300f:bb06::a (2a03:2260:300f:bb06::a)  0.111 ms  0.127 ms  0.135 ms
 2  2a03:2260::2 (2a03:2260::2)  10.836 ms  10.851 ms  10.853 ms
 3  2a03:2260::1 (2a03:2260::1)  11.008 ms  11.027 ms  11.011 ms
 4  decix.bb-a.fra3.fra.de.oneandone.net (2001:7f8::2170:0:1)  25.722 ms  25.726 ms  25.728 ms
 5  ae-10-0.bb-a.bap.rhr.de.oneandone.net (2001:8d8:0:2::f2)  32.035 ms  32.034 ms  32.141 ms
 6  2001-08d8-100f-f000-0000-0000-0000-02b7.elastic-ssl.ui-r.com (2001:8d8:100f:f000::2b7)  31.864 ms  31.556 ms  31.609 ms

Wget

mattes@enkreis-3:~$ wget -6 -d -O /dev/null https://www.elektronik-kompendium.de/
Setting --output-document (outputdocument) to /dev/null
DEBUG output created by Wget 1.17.1 on linux-gnu.

Reading HSTS entries from /home/mattes/.wget-hsts
URI encoding = »UTF-8«
--2018-02-22 21:58:40--  https://www.elektronik-kompendium.de/
Auflösen des Hostnamen »www.elektronik-kompendium.de (www.elektronik-kompendium.de)«... 2001:8d8:100f:f000::2b7
Caching www.elektronik-kompendium.de => 2001:8d8:100f:f000::2b7
Verbindungsaufbau zu www.elektronik-kompendium.de (www.elektronik-kompendium.de)|2001:8d8:100f:f000::2b7|:443... verbunden.
Created socket 4.
Releasing 0x000055c4564b95a0 (new refcount 1).
Initiating SSL handshake.
Handshake successful; connected socket 4 to SSL handle 0x000055c4564b9a30
certificate:
  subject: CN=www.elektronik-kompendium.de
  issuer:  CN=GeoTrust DV SSL CA - G3,OU=Domain Validated SSL,O=GeoTrust Inc.,C=US
X509 certificate successfully verified and matches host www.elektronik-kompendium.de

---request begin---
GET / HTTP/1.1
User-Agent: Wget/1.17.1 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: www.elektronik-kompendium.de
Connection: Keep-Alive

---request end---
HTTP-Anforderung gesendet, warte auf Antwort...
---response begin---
HTTP/1.1 200 OK
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=15
Date: Thu, 22 Feb 2018 20:58:40 GMT
Server: Apache
Accept-Ranges: bytes
Cache-Control: max-age=0
Expires: Thu, 22 Feb 2018 20:58:40 GMT

---response end---
200 OK
Registered socket 4 for persistent reuse.
Länge: nicht spezifiziert [text/html]
In »»/dev/null«« speichern.

/dev/null                                               [ <=>                                                                                                               ]  26,72K  --.-KB/s    in 0,03s

2018-02-22 21:58:40 (887 KB/s) - »/dev/null« gespeichert [27357]

Saving HSTS entries to /home/mattes/.wget-hsts
mattes@enkreis-3:~$

Es liegt tatsächlich ein MTU Problem an dem Telekom FTTH Anschluss vor.

Der gleiche freifunk-Router läuft an einem Standard VDSL-Anschluss mit den o.g. Web-Seiten einwandfrei.

hmm, das ist aber doch gar kein pmtu/mss-clamping-fressendes NAT64…
d.h. irgendein Mechanismus funktioniert da nicht an diesem speziellen Client. Denn der sollte das selbst erkennen und korrigieren.
(vgl. Probleme mit MTU(?) im Netz )