• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[GELÖST] Einige https-Seiten Laden nicht unter Leap, aber unter Windows

(Crosspost: https://www.opensuse-forum.de/thread/36566-einige-https-seiten-laden-nicht-unter-leap-aber-unter-windows/ )


Hi zusammen,

ich hab ein seltsames Problem mit openSUSE Leap 42.1. Ich kriege auf einigen Webseiten reproduzierbar Timeouts.
Zwei Beispiele:

https://openshift.redhat.com/app/login
Lädt ordnungsgemäß. Ich kann mich einloggen und und auch auf "Settings" klicken. Danach kann ich aber einen beliebigen Link anklicken und bekomme einen Timeout. Wenn ich dann wieder versuche "https://openshift.redhat.com/app/login" zu laden, geht auch das nicht mehr.
Nach einem Browser-Neustart lädt die Seite wieder, bis zum zweiten Klick nach dem Login.

https://www.mendeley.com/sign-in/
Lädt auch, aber wenn ich meine Login-Daten eingebe und auf "Sign in" klicke bekomme ich auch wieder einen Timeout.

Jetzt das besonders eigenartige:
Das Problem tritt unter openSUSE 42.1 reproduzierbar mit allen Browsern auf, die ich getestet habe (Firefox, Chrome, Midori). Auch eine komplett neue Installation von openSUSE zeigt die gleichen Symptome.
Wenn ich auf dem selben Rechner jedoch Windows 10 starte, funktionieren alle Seiten problemlos. Sowohl mit Chrome, als auch mit Internet Explorer.

Was mir auffällt, ist, dass beide Beispiele, die mir aufgefallen sind, https-Seiten sind. Ob das Problem hierauf beschränkt ist, kann ich jedoch leider nicht sagen.
Ich habe schon drüber nachgedacht, ob es an meinem Internetprovider liegen könnte. Ich bin bei Unitymedia und bekomme vom Provider nur IPv6-Adressen zugewiesen. IPv4-Anfragen werden nach meinem Wissen mit hunderten weiteren Kunden über eine NAT geschleust. Das würde allerdings nicht erklären, warum es mit Windows 10 funktioniert.

Hat jemand eine Idee wo ich noch nach den Ursachen suchen könnte?


EDIT:
Wenn ich die Seiten über einen Webproxy nutze (z.B. https://hide.me/de/proxy ) funktionieren beide Seiten auch unter openSUSE problemlos.

EDIT2:
Netzwerkinfos - collectNWData.txt: http://paste.opensuse.org/48140192
 
OP
W

wichita_c12ca

Member
Leider nicht. Das sind die beiden Beispiele, bei denen mir das Problem aufgefallen ist, weil ich diese regelmäßig nutze.

Achso, dabei fällt mir gerade auf, dass ich folgendes vergessen habe (werde ich oben einfügen):
Wenn ich die Seiten über einen Webproxy nutze (z.B. https://hide.me/de/proxy ) funktionieren beide Seiten auch unter openSUSE problemlos.

EDIT:
Du könntest auf www.bugmenot.com gucken.
Für mendeley.com scheint folgender Login zu gehen:
Username: mend@pfui.ru
Password: 1234567
 
OP
W

wichita_c12ca

Member
In erster Linie Google Chrome (aus den google-repos), aber das Probel tritt wie gesagt mit allen Browsern auf, die ich getestet habe. Das bedeutet:
Firefox, Chrome, Midori
 

spoensche

Moderator
Teammitglied
Es könnte mit den verwendeten Zertifikaten der Webseiten zusammen hängen. Hast du dir diese mal angesehen? Es könnte allerdings auch an der Browserkonfiguration liegen, z.B. eine ältere SSL-Version.

Vergleiche doch mal die Konfigurationen der Browser mit denen die unter Trojaner 10 von M$ verwendest
 
OP
W

wichita_c12ca

Member
Unter Windows hab ich die gleiche Chrome-Konfiguration genutzt wie mit Chrome unter openSUSE. Problem tritt außerdem mit frischer openSUSE Installation mit unveränderten Browser-Konfigurationen auf.

Ich hab mal einen solchen fehlerhaften Ablauf bei openshift mit Wireshark geloggt. An den grünen HTTP-Einträgen sieht man schön, wie der klick auf Settings noch funktioniert, aber der nächste Klick schlägt fehl:
 
OP
W

wichita_c12ca

Member
​Wireshark-log für den fehlschlagenden mendeley.com-login.
Scheinbar versuchen hier also beide Seiten ACKs zu senden, die nicht ankommen. die [FIN, ACK] pakete kommen dann aber direkt an. Hat dafür irgendwer eine mögliche Erklärung?
 
OP
W

wichita_c12ca

Member
Lösung:

Das Problem hängt irgendwie mit der MTU und der DS-Lite Implementierung von Unitymedia zusammen.
http://www.networkworld.com/article/2224654/cisco-subnet/mtu-size-issues.html Dieser Artikel gibt sehr viele gute Infos zu dem Thema her.

Die Lösung bestand darin im NetworkManager die MTU herunterzusetzen. Momentan habe ich sie auf 1200bytes und alles läuft stabil.
 
Oben