Verbindungsabbruch bei https

Die Anführungszeichen stimmen nicht und setz es ruhig nur auf den DNS-Namen.

Bei mir ist das Problem gerade auch mal aufgetreten.

descilla@des-mb:~$ wget https://twitter.com -O /dev/null --debug
DEBUG output created by Wget 1.17.1 on linux-gnu.

Reading HSTS entries from /home/descilla/.wget-hsts
URI encoding = »UTF-8«
--2016-07-06 23:04:58--  https://twitter.com/
Auflösen des Hostnamens »twitter.com (twitter.com)« … 104.244.42.1
Caching twitter.com => 104.244.42.1
Verbindungsaufbau zu twitter.com (twitter.com)|104.244.42.1|:443 … verbunden.
Created socket 4.
Releasing 0x0000564b62b6ae20 (new refcount 1).
Initiating SSL handshake.
SSL handshake failed.
Closed fd 4
Es ist nicht möglich, eine SSL-Verbindung herzustellen.
Saving HSTS entries to /home/descilla/.wget-hsts

Hier gehts (siehe weiter unten):

descilla@des-mb:~$ wget https://twitter.com -O /dev/null --debug
DEBUG output created by Wget 1.17.1 on linux-gnu.

Reading HSTS entries from /home/descilla/.wget-hsts
URI encoding = »UTF-8«
--2016-07-06 23:07:46--  https://twitter.com/
Auflösen des Hostnamens »twitter.com (twitter.com)« … 104.244.42.1
Caching twitter.com => 104.244.42.1
Verbindungsaufbau zu twitter.com (twitter.com)|104.244.42.1|:443 … verbunden.
Created socket 4.
Releasing 0x000055c54d224db0 (new refcount 1).
Initiating SSL handshake.
Handshake successful; connected socket 4 to SSL handle 0x000055c54d225c30
certificate:
  subject: CN=twitter.com,OU=FRA2 Point of Presence,O=Twitter\\, Inc.,L=San Francisco,ST=California,C=US
  issuer:  CN=Symantec Class 3 Secure Server CA - G4,OU=Symantec Trust Network,O=Symantec Corporation,C=US
X509 certificate successfully verified and matches host twitter.com

---request begin---
GET / HTTP/1.1
User-Agent: Wget/1.17.1 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: twitter.com
Connection: Keep-Alive
...........
descilla@des-mb:~$ nslookup twitter.com 10.43.128.2
Server:		10.43.128.2
Address:	10.43.128.2#53

Non-authoritative answer:
Name:	twitter.com
Address: 104.244.42.65
Name:	twitter.com
Address: 104.244.42.1
descilla@des-mb:~$ nslookup twitter.com 8.8.8.8
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	twitter.com
Address: 199.16.156.230
Name:	twitter.com
Address: 199.16.156.38
Name:	twitter.com
Address: 199.16.156.70
Name:	twitter.com
Address: 199.16.156.102

Kurz gesagt: Mit den 199.16.156.X Adressen gehts, bei den 104.244.42.X Adressen schlägt der Handshake fehl. Aber nur im Freifunk Netz. Denn bei mir privat:

descilla@des-mb:~$ nslookup twitter.com 192.168.0.1
Server:		192.168.0.1
Address:	192.168.0.1#53

Non-authoritative answer:
Name:	twitter.com
Address: 104.244.42.193
Name:	twitter.com
Address: 104.244.42.1

Und dort funktioniert Twitter.

Warum der Handshake genau fehlschlägt und das nur bei Twitter Servern aus einem bestimmten Subnet konnte ich noch nicht herausfinden, muss jetzt leider weiter lernen. :frowning:

1 „Gefällt mir“

Hi,

auch hier gibt es Probleme (Dom13) mit https bzw. kann ich es zur Zeit mit Adressen rund um “Microsoft & Co” nachvollziehen.

Das Problem stellte sich in erster Linie mit dem Arbeiten auf Office356 und auch Bing (Suchmaschine) da.

In erster Linie sind Endgeräte wie z.B. Windows Phones betroffen. Cortana (Sprachassistentin). Diese kann keine Anfragen bearbeiten. Auch Siri (iPhone) ist betroffen. Auch hier wird im Hintergrund z.T. “Bing” benutzt.

Auf beiden Geräten bekommt man als Antwort, das der Dienst momentan nicht zur Verfügung steht. Das stimmt so aber nicht. Über den regulären Internetzugang antworten die Dienste einwandfrei.

Aufruf von “http://www.bing.com/?cc=de” --> keine Probleme
Aufruf von “https://www.bing.com/?cc=de” --> Fehler: Gesicherte Verbindung fehlgeschlagen. Verbindung zurückgesetzt.

Es waren in diesem Test Verbindungen mit Diensten in Richtung Microsoft betroffen.
Netapp, IBM, VMware mit https sind kein Probleme ersichtlich.

Bing:

> wget https://bing.com -O /dev/null --debug
> DEBUG output created by Wget 1.17.1 on linux-gnu.

> URI encoding = »UTF-8«
> --2016-07-06 23:43:55--  https://bing.de/
> Auflösen des Hostnamen »bing.de (bing.de)«... 204.79.197.219
> Caching bing.de => 204.79.197.219
> Verbindungsaufbau zu bing.de (bing.de)|204.79.197.219|:443... verbunden.
> Created socket 4.
> Releasing 0x000055a506038ff0 (new refcount 1).
> Initiating SSL handshake.
> SSL handshake failed.
> Closed fd 4
> Es ist nicht möglich, eine SSL-Verbindung herzustellen.


> nslookup -debug bing.com 8.8.4.4
> Server:         8.8.4.4
> Address:        8.8.4.4#53

> ------------
>     QUESTIONS:
>         bing.com, type = A, class = IN
>     ANSWERS:
>     ->  bing.com
>         internet address = 204.79.197.200
>         ttl = 1795
>     AUTHORITY RECORDS:
>     ADDITIONAL RECORDS:
> ------------
> Non-authoritative answer:
> Name:   bing.com
> Address: 204.79.197.200

mtr -t -4 -n -r -c 50 bing.de
Loss% Snt Last Avg Best Wrst StDev
1.|-- 10.43.104.2 0.0% 50 114.5 103.9 30.3 346.9 47.0
2.|-- ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
3.|-- 31.209.91.17 0.0% 50 114.1 106.9 47.6 212.7 26.4
4.|-- 77.109.128.195 0.0% 50 118.8 108.0 59.9 226.1 27.0
5.|-- 198.200.130.202 0.0% 50 114.3 116.7 53.3 225.4 35.8
6.|-- 131.253.6.95 0.0% 50 119.8 108.4 55.8 223.3 26.9
7.|-- 62.69.146.70 54.0% 50 68.6 123.1 63.7 244.3 49.5
8.|-- 104.44.80.145 0.0% 50 118.7 121.0 63.6 238.3 34.0
9.|-- 204.79.197.219 58.0% 50 99.1 106.4 66.0 119.6 17.2

Netapp:

wget https://www.netapp.com -O /dev/null --debug

> DEBUG output created by Wget 1.17.1 on linux-gnu.
> URI encoding = »UTF-8«
> --2016-07-07 00:12:36--  https://www.netapp.com/
> Auflösen des Hostnamen »www.netapp.com (www.netapp.com)«... 184.25.158.59
> Caching www.netapp.com => 184.25.158.59
> Verbindungsaufbau zu www.netapp.com (www.netapp.com)|184.25.158.59|:443... verbunden.
> Created socket 4.
> Releasing 0x000055a863492fb0 (new refcount 1).
> Initiating SSL handshake.
> Handshake successful; connected socket 4 to SSL handle 0x000055a863493f10
> certificate:
>   subject: CN=*.netapp.com,OU=Marketing,O=NetApp Inc.,L=Sunnyvale,ST=CA,C=US
>   issuer:  CN=Verizon Akamai SureServer CA G14-SHA2,OU=Cybertrust,O=Verizon Enterprise Solutions,L=Amsterdam,C=NL
> X509 certificate successfully verified and matches host www.netapp.com

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

> ---request end---
> HTTP-Anforderung gesendet, warte auf Antwort... 
> ---response begin---
> HTTP/1.1 301 Moved Permanently
> Content-Type: text/html; charset=utf-8
> Location: http://www.netapp.com/us/
> Server: Microsoft-IIS/8.5
> X-AspNet-Version: 4.0.30319
> X-Powered-By: ASP.NET
> X-UA-Compatible: IE=edge
> Content-Length: 142
> Cache-Control: public, max-age=900
> Expires: Wed, 06 Jul 2016 22:27:37 GMT
> Date: Wed, 06 Jul 2016 22:12:37 GMT
> Connection: keep-alive

> ---response end---
> 301 Moved Permanently
> Registered socket 4 for persistent reuse.
> URI content encoding = »utf-8«
> Platz: http://www.netapp.com/us/ [folge]
> Skipping 142 bytes of body: [Object moved
> Object moved to <a href="http://www.netapp.com/us/">here</a>.
> </body>
> ] done.
> URI content encoding = None
> --2016-07-07 00:12:37--  http://www.netapp.com/us/
> Found www.netapp.com in host_name_addresses_map (0x55a863492fb0)
> Verbindungsaufbau zu www.netapp.com (www.netapp.com)|184.25.158.59|:80... verbunden.
> Created socket 5.
> Releasing 0x000055a863492fb0 (new refcount 1).

> ---request begin---
> GET /us/ HTTP/1.1
> User-Agent: Wget/1.17.1 (linux-gnu)
> Accept: */*
> Accept-Encoding: identity
> Host: www.netapp.com
> Connection: Keep-Alive

> ---request end---
> HTTP-Anforderung gesendet, warte auf Antwort... 
> ---response begin---
> HTTP/1.1 200 OK
> Content-Type: text/html; charset=utf-8
> Server: Microsoft-IIS/8.5
> X-AspNet-Version: 4.0.30319
> X-Powered-By: ASP.NET
> X-UA-Compatible: IE=edge
> Content-Length: 93632
> Cache-Control: public, max-age=900
> Expires: Wed, 06 Jul 2016 22:27:37 GMT
> Date: Wed, 06 Jul 2016 22:12:37 GMT
> Connection: keep-alive

> ---response end---
> 200 OK
> Disabling further reuse of socket 4.
> Closed 4/SSL 0x000055a863493f10
> Registered socket 5 for persistent reuse.
> URI content encoding = »utf-8«
> Länge: 93632 (91K) [text/html]
> In »»/dev/null«« speichern.

> /dev/null           100%[===================>]  91,44K   206KB/s    in 0,4s    

> 2016-07-07 00:12:38 (206 KB/s) - »/dev/null« gespeichert [93632/93632]

nslookup -debug netapp.com 8.8.4.4

> Server:         8.8.4.4
> Address:        8.8.4.4#53

> ------------
>     QUESTIONS:
>         netapp.com, type = A, class = IN
>     ANSWERS:
>     ->  netapp.com
>         internet address = 104.208.162.27
>         ttl = 957
>     ->  netapp.com
>         internet address = 104.208.166.236
>         ttl = 957
>     ->  netapp.com
>         internet address = 40.78.66.78
>         ttl = 957
>     ->  netapp.com
>         internet address = 40.78.29.32
>         ttl = 957
>     ->  netapp.com
>         internet address = 138.91.147.191
>         ttl = 957
>     ->  netapp.com
>         internet address = 104.209.186.225
>         ttl = 957
>     AUTHORITY RECORDS:
>     ADDITIONAL RECORDS:
> ------------
> Non-authoritative answer:
> Name:   netapp.com
> Address: 104.208.162.27
> Name:   netapp.com
> Address: 104.208.166.236
> Name:   netapp.com
> Address: 40.78.66.78
> Name:   netapp.com
> Address: 40.78.29.32
> Name:   netapp.com
> Address: 138.91.147.191
> Name:   netapp.com
> Address: 104.209.186.225

mtr -t -4 -n -r -c 50 netapp.com

Loss% Snt Last Avg Best Wrst StDev
1.|-- 10.43.104.2 0.0% 50 46.6 49.5 40.9 102.0 8.2
2.|-- ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
3.|-- 31.209.91.17 0.0% 50 46.9 58.3 45.8 135.3 18.3
4.|-- 77.109.128.195 0.0% 50 53.3 67.9 53.3 186.9 21.5
5.|-- 198.200.130.202 0.0% 50 60.3 67.4 51.9 265.9 35.2
6.|-- 185.76.190.166 0.0% 50 60.9 70.2 54.7 222.4 31.0
7.|-- 104.44.5.28 0.0% 50 190.2 136.7 61.9 440.3 79.8
8.|-- 104.44.5.16 0.0% 50 189.8 212.2 188.2 546.9 56.7
9.|-- 104.44.4.215 0.0% 50 201.9 209.3 188.7 503.6 49.0
10.|-- 104.44.8.191 0.0% 50 199.2 211.9 187.9 460.2 44.7
11.|-- 104.44.4.233 36.0% 50 199.4 213.4 199.4 276.6 15.7
12.|-- 104.44.9.151 54.0% 50 65.2 72.7 62.6 160.7 20.8
13.|-- 104.44.225.174 58.0% 50 68.3 69.5 63.1 117.7 13.0
14.|-- 104.44.5.28 52.0% 50 198.5 205.3 197.9 240.1 12.1
15.|-- 104.44.4.28 48.0% 50 199.9 208.2 198.3 308.9 22.7
16.|-- 104.44.4.203 46.0% 50 199.5 205.1 198.2 227.1 9.5
17.|-- 104.44.8.189 34.0% 50 198.4 211.2 196.9 356.8 28.5
18.|-- ??? 100.0 50 0.0 0.0 0.0 0.0 0.0

Gruß
Nicklas

webmailer bei 1&1 und twitter gehen hier gerade wieder nicht. Gibt es das Problem nur bei uns, oder gibt es entsprechenden Meldungen auch im großen Forum. So langsam muss man das mal angehen.

Geht es nur auf einem Gateway nicht oder auf beiden?

falin: kaputt, barristan: heile.

Habe schlicht auf dem Laptop ein anderes default-gateway eingetragen.

Wir könnten mal die NAT-IPs tauschen. Dann wissen wir, ob es an der Konfiguration oder schlicht der IP liegt.

Scheint so, als betrifft dass Problem nicht nur uns

Ich glaube, dass das was anderes ist. ruhrwetter.de hat nichtsmals richtiges https, also nur ein selbstsigniertes Zertifikat.

Aber twitter taucht da auch auf

In 43 bei Twitter gerade wieder tcp Reset.

Ebenso in Domäne 50: twitter Verbinungsabbruch. 1und1-Webmiler funzt.

Ergänzung und Frage. Auf meinem router aktuell:
tunneldigger.@broker[0].address=‘163.172.211.238::20050’ ‘ausrufer.servers.freifunk-muensterland.de:20050’ ‘176.9.88.123:20050’ ‘c1024.servers.freifunk-muensterland.de:20050’ ‘domaene50.servers.freifunk-muensterland.de:20050

Der Eintrag domaene50.servers.freifunk-muensterland.de ist im Gegensatz zu den beiden anderen ohne IP. Kann auch nicht, da
host domaene50.servers.freifunk-muensterland.de
Host domaene50.servers.freifunk-muensterland.de not found: 3(NXDOMAIN)

Wieso steht domaene50.servers.freifunk-muensterland.de in der broker-Liste?

Das ist nur eine Vorkehrung, falls wir mal spontan ein weiteres Gateway schalten wollen, damit wir dann keine neue Firmware ausrollen müssen. Der DNS-Eintrag hat auch derzeit keine IP hinterlegt.

Die Diskussion dahinter gab es hier: Generische Gateway-DNS-Einträge in der Firmware?

OK, danke für die Info.

Wollte ursprünglich “nur” deinem Hinweis folgen, und meinen router dazu bringen nur einen der aktiven GW zu nutzen, um dem Problem näher zu komen. Mit uci hatte ich dann aber Probleme eine Liste richtig zu setzen.
Daher würde ich gerne paulinsches Ansatz verfolgen:

“Habe schlicht auf dem Laptop ein anderes default-gateway eingetragen.”.
In Dom50 dann also z.B.
route add default gateway 163.172.211.238
richtig?

Dadurch wechselst du die Nat-IP. Es besteht der Verdacht, dass der Anbieter ein Problem mit der einen Nat-IP hat.

8 posts were split to a new topic: Tunnel und Layer

Ne. Das default Gateway ist sicherlich was mit 10.xxx … Suche mit “ip r” das aktuelle raus und versuch dann eine IP drüber oder drunter.

1 „Gefällt mir“

Paulinsche hat recht, hab nicht richtig gelesen. Du kannst die externe IP nicht als Gateway anbieten.

twitter.com per https via FF-router und
10.48.144.3 als internes gw
geht nicht.
Mit 10.48.144.2 als internes gw geht es.

Update, 03.08.16, 18 Uhr
twitter.com und webmailer von 1und1 per https via FF-router und 10.48.144.3 als internes gw
geht nicht.
Und wieder nach ip route del default via 10.48.144.3; ip route add default via 10.48.144.2
geht es.

Entweder 10.48.144.3 hat ein internes Problem oder twitter und 1und1 haben ihn bzw. die entsprechende öffentliche ip auf einer Blacklist?

Wie geht es weiter?

Bei mir in Dom50: 10.48.144.2 als gw heile und
10.48.144.3 als gw kaputt an verschiedenen Tagen

Laut

könnte es ein MTU-Problem sein (letzter Eintrag).