Das längste Thema

Zitat von whoami0501

Browser läuft in nen Timeout

Hier nicht (lokaler Provider: Vodafone):

pasted-from-clipboard.png

[2022-01-19T21:42:32+0100] ueberall_l@desktop01:/tmp% time curl -6 -v https://forum.netcup.de
*   Trying 2a03:4000:35:8e2::95:443...
* Connected to forum.netcup.de (2a03:4000:35:8e2::95) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=forum.netcup.de
*  start date: Jan 19 09:39:18 2022 GMT
*  expire date: Apr 19 09:39:17 2022 GMT
*  subjectAltName: host "forum.netcup.de" matched cert's "forum.netcup.de"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55c8613859e0)
> GET / HTTP/2
> Host: forum.netcup.de
> user-agent: curl/7.81.0
> accept: */*
[…]
</body>
* Connection #0 to host forum.netcup.de left intact
</html>curl -6 -v https://forum.netcup.de  0,01s user 0,01s system 5% cpu 0,549 total
[2022-01-19T21:42:37+0100] ueberall_l@desktop01:/tmp% 

oh

pasted-from-clipboard.png

Zitat von whoami0501

Wohingegen ein mtr nicht geht, der Traffic geht nicht aus dem DTAG Netz raus.

Ein Traceroute (ICMP/UDP) endet bei mir allerdings auch schon bei bgp1.ix.as51184.net (2a02:1748::100:126:0:245), außerhalb meines Providernetzes also keine Antwort mehr.

m_ueberall bei mir ist es auch so wie es whoami0501 geschildert hat; ich hatte die Schuld dem SSL-Interception in die Schuhe geschoben;

stelle ich hingegen bei meinem lokalen Proxy ein, er soll den Host forum.netcup.de über den nachgeordneten Squid hier in einem RS abwickeln, geht es;

mein lokaler Proxy, der es bisher direkt machte, läuft ebenfalls in ein Timeout;

wobei merkwürdiges Detail: mein Router hat ebenfalls einen Squid laufen, verwende ich diesen, dann klappt das;

(kann es damit zusammen hängen, dass es f. den lokalen Proxy keinen rDNS Namen gibt?)

Zitat von KB19

Ein Traceroute (ICMP/UDP) endet bei mir allerdings auch schon bei bgp1.ix.as51184.net (2a02:1748::100:126:0:245), außerhalb meines Providernetzes also keine Antwort mehr.

Kann ich so über AS58057 tunnelbroker.ch (Endpoint Düsseldorf) auch noch bestätigen. Selbiges wenn ich aus AS48314 (IPP) und AS24940 (weißes H auf roten Grund) komme - aber wie gesagt nur die IPv6 des Forums.

Wobei besagter Tunnelbroker Endpoint bei anderen IPv6 auch interessant ist, der routet Düsseldorf Nürnberg über Amsterdam.

Was auch Interessant ist - der v4 Traffic aus AS199284 (Encoline/TNK) wird über AS8220 (Colt) und ein Stück unbekannt über Anexia Wien geroutet. Ich bin mir ziemlich sicher, dass Wien nicht zwischen Thüringen und Nürnberg liegt lol

Zitat von whoami0501

[…] aber wie gesagt nur die IPv6 des Forums.

Dito.

Und dennoch funktioniert HTTP(S) bei mir zu besagter IPv6-Adresse einwandfrei.

Komische Sache.

Zitat von mainziman

am schönsten sieht dieses Schriftbild aus ..., gezeigt an Hand des Look&Feel von WinXP

WinXP - Look&Feel

screenHEBR.png

Das erinnert mich doch glatt wieder mal an: https://winxp.vercel.app/

Schafft es jemand von euch hier einen Request abzusenden? https://lg.netcup.net

Oder „are you a robot“?

Zitat von Virinum

Schafft es jemand von euch hier einen Request abzusenden? https://lg.netcup.net

Oder „are you a robot“?

Bei mir geht es auch nicht. Es kommt oben eine rote Fehlermeldung wegen dem Captcha.

Offenbar bin ich ein Robot. Ich kann das zwar anklicken und es erscheint dann auch der grüne Haken. Aber egal was ich als Parameter eingebe, es gibt immer nur Fehler, wie z.B. das der Parameter fehlt.

Zitat von aRaphael

无论如何，这个论坛很快就会被中国人接管。

Die sind doch längst da

Zitat von Virinum

Schafft es jemand von euch hier einen Request abzusenden? https://lg.netcup.net

Oder „are you a robot“?

Jetzt, wo Du mich daran erinnerst…

Das ist wahrscheinlich schon einige Wochen so. Ich habe damals aber ganz darauf vergessen, das in einem Ticket zu erwähnen.

/ping [netcup] Christina R. – euer Looking Glass ist hin

was soll mir das sagen? [netcup] Claudia H.

pasted-from-clipboard.png

bzw.

pasted-from-clipboard.png

beim IPv6 hats auch was; wobei das ist irgendwie komplett Strange;

ich betreibe meinen eigenen 6in4-Tunnel: mein Router hat auf der LAN-Seite prefix::1 und von dort gehts,

und jedem anderen Host im LAN gehts nicht; alles andere geht mit IPv6 ohne Probleme;

Ich komme immer noch nicht per IPv6 aufs Forum, mit meiner DTAG Leitung. Wenn ich aber übers VPN beim weißen H auf roten Grund gehe, geht alles. Mega strange. Ich verstehe das nicht.

Vor Allem funktioniert der TCP Connect an sich ja. Da klappt ja bei vereinzelten IPv6 Adressen etwas mit dem TLS Handshake mit dem Forum nicht.

Interessant, bei mir klappt der Aufruf via IPv6 ohne Probleme aus dem DTAG Netz.

edit: auch das Zertifikat scheint OK zu sein. Weiß nicht wieso es bei mainziman anders aussieht.

$ dig +short forum.netcup.de AAAA
2a03:4000:35:8e2::95

$ openssl s_client -6 -connect forum.netcup.de:443 </dev/null | openssl x509 -noout -dates
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = forum.netcup.de
verify return:1
notBefore=Jan 19 09:39:18 2022 GMT
notAfter=Apr 19 09:39:17 2022 GMT
DONE

DerRené keine Ahnung, wieso wget hier meint, dass des Zertifikat abgelaufen ist, wobei es sollte

auch forum.netcup.net in den SANs haben;

# openssl s_client -connect forum.netcup.de:443 </dev/null | openssl x509 -noout -dates
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
DONE
notBefore=Jan 19 09:39:18 2022 GMT
notAfter=Apr 19 09:39:17 2022 GMT

das liegt daran, dass da in der Zertifikatskette was mitgeschickt wird, was man üblicherweise nicht mitschicken sollte - den Root-Token;

der Verursacher vom Problem mit dem TLS Handshake, den whoami0501 meint;

Ich habe meinen Anschluss bei AS8881 und wohne etwa 20 km östlich von Köln.
Ist es da normal, dass die Pakete zu netcup einen Umweg über Amsterdam machen?

Rückweg und IPv6 sehen sehr ähnlich aus.

 1. 172.28.8.1
 2. wup1101aihr001.versatel.de
 3. 62.214.38.169
 4. 62.214.38.178
 5. ae3-1337.bbr02.anx63.ams.nl.anexia-it.net
 6. ae1-10.bbr01.anx63.ams.nl.anexia-it.net
 7. ae10-0.bbr01.anx25.fra.de.anexia-it.net
 8. ae0-0.bbr02.anx25.fra.de.anexia-it.net
 9. ae1-0.bbr01.anx84.nue.de.anexia-it.net
10. netcup-gw.bbr01.anx84.nue.de.anexia-it.net
11. server1.XXXXX.de

Lohnt es sich dafür ein Ticket aufzumachen?

Virinum das liegt aber mehr an deinem Anbieter, welcher scheinbar die Route über AMS-IX nimmt.

nicht an Anexia/Netcup

Zitat von Gunah

Virinum das liegt aber mehr an deinem Anbieter, welcher scheinbar die Route über AMS-IX nimmt.

nicht an Anexia/Netcup

Woran erkennt man an welcher Partei das liegt? Wie gesagt, von netcup zu mir geht der Weg auch über Amsterdam.

Wir haben den Thread an unsere Entwickler weitergegeben und sie vermuten, dass es höchstwahrscheinlich am Cache liegt.

Zitat von KB19

Jetzt, wo Du mich daran erinnerst…

Das ist wahrscheinlich schon einige Wochen so. Ich habe damals aber ganz darauf vergessen, das in einem Ticket zu erwähnen.

/ping [netcup] Christina R. – euer Looking Glass ist hin

Danke für den Hinweis! Magst du dazu bitte ein Support-Ticket eröffnen. Danke!