TLS Handshake wird für einige Websites zurückgesetzt, wenn der OpenWRT-Router verwendet wird

767
Andrey Sapegin

Momentan habe ich ein sehr seltsames Problem mit meinem Router. Ich habe TP-Link TL-WDR4300 rev. 1.7 OpenWRT ausführen 18.06.1.

Das Problem begann ursprünglich vor 1-2 Monaten, als ich OpenWRT 15.05 hatte und die letzte Konfigurationsänderung (vor dem Upgrade auf 18.06.1) am Router vor etwa einem Jahr war.

Vor 1-2 Monaten habe ich festgestellt, dass einige Websites auf ALLEN Geräten (iPhone mit iOS, Android-Handy, Ubuntu-Laptop, Windows-Laptop) in ALLEN Browsern nicht geladen werden. Wenn das Gerät jedoch nicht mit dem WLAN verbunden ist und beispielsweise ein Mobilfunknetz verwendet, wird die Website sofort geladen.

Mein ISP ist die Deutsche Telekom. Ein gutes Beispiel für eine Website, die nicht geladen wird, ist https://telekom.de, die normalerweise erreichbar ist.

Ich habe ein Upgrade auf die neueste stabile OpenWRT-Version durchgeführt und mit der Untersuchung des Problems begonnen. Es gibt keine Pakete in Protokollen oder andere Fehlermeldungen auf dem Router, die sich auf das Problem beziehen. Curl kann den Inhalt einer betroffenen Website (telekom.de) direkt auf dem Router abrufen:

 root@OpenWrt:~# curl --tlsv1.0 -v https://telekom.de > GET / HTTP/1.1 > Host: telekom.de > User-Agent: curl/7.60.0 > Accept: */* >  < HTTP/1.1 301 Moved Permanently < Date: Sat, 01 Sep 2018 20:56:23 GMT < Server: Apache < Location: https://www.telekom.de/start < Content-Length: 236 < Content-Type: text/html; charset=iso-8859-1 <  <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="https://www.telekom.de/start">here</a>.</p> </body></html>

Auf allen Kunden hat es immer noch nicht funktioniert:

$ curl --tlsv1.0 -v https://telekom.de * Rebuilt URL to: https://telekom.de/ * Hostname was NOT found in DNS cache * Trying 46.29.100.76... * Connected to telekom.de (46.29.100.76) port 443 (#0) * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs * SSLv3, TLS handshake, Client hello (1): * Unknown SSL protocol error in connection to telekom.de:443  * Closing connection 0 curl: (35) Unknown SSL protocol error in connection to telekom.de:443

Ich habe versucht, den Windows-Laptop direkt an das PPPoE-Glasfasermodem der Deutschen Telekom anzuschließen, und die Webseiten wurden normal geladen. Ich habe auch einen Windows-Laptop in einen WiFi-Router verwandelt, und alle Clients konnten problematische Websites laden.

Meine ursprüngliche Idee war, dass das Problem möglicherweise mit IPv6 zusammenhängt (ein anderes möglicherweise damit zusammenhängendes Problem ist hier ), und ich habe es konfiguriert (bevor es nicht ordnungsgemäß konfiguriert wurde). Es hat nicht geholfen, und auch das Deaktivieren von IPv6 in den Adaptereinstellungen für den Windows-Client hilft nicht.

Wenn Sie OpenWRT als Router verwenden, versucht der Browser für einige Zeit (1-2 Minuten), einen TLS-Handshake durchzuführen, und zeigt dann die Meldung "Sichere Verbindung fehlgeschlagen" an.

Hier ist das Wireshark-Capture von TLS-Handshake für telekom.de .

Und hier sind einige meiner Router-Einstellungen:

Screenshot der Schnittstellen:

Interfaces

Ausgabe von iptables -L -v (Ich verwende keine standardmäßige OpenWRT-Firewall-Konfiguration, da sie viele Ketten enthält und für mich zu kompliziert ist, daher schreibe ich sie beim Booten erneut mit dem Befehl iptables-restore):

Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination  5651 481K ACCEPT all -- lo any anywhere anywhere  137K 17M ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED 184 10370 logdrop all -- any any anywhere anywhere ctstate INVALID 0 0 ACCEPT udp -- pppoe-wan any anywhere anywhere udp dpt:bootpc 0 0 ACCEPT udp -- l2tp-voip any anywhere anywhere udp dpt:bootpc 67318 4219K ACCEPT all -- br-lan any anywhere anywhere  5423 290K logdrop all -- any any anywhere anywhere   Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination  423K 49M ACCEPT all -- br-lan pppoe-wan anywhere anywhere  0 0 ACCEPT all -- br-lan l2tp-voip anywhere anywhere  0 0 ACCEPT all -- br-lan br-lan anywhere anywhere  1324K 1610M ACCEPT all -- pppoe-wan br-lan anywhere anywhere ctstate RELATED,ESTABLISHED 0 0 ACCEPT all -- l2tp-voip br-lan anywhere anywhere ctstate RELATED,ESTABLISHED 0 0 logdrop all -- any any anywhere anywhere   Chain OUTPUT (policy ACCEPT 188K packets, 25M bytes) pkts bytes target prot opt in out source destination   Chain logdrop (3 references) pkts bytes target prot opt in out source destination  5607 300K LOG all -- any any anywhere anywhere LOG level warning prefix "dropped: " 5607 300K DROP all -- any any anywhere anywhere

Ausgabe von iptables -t nat -L -v :

Chain PREROUTING (policy ACCEPT 59800 packets, 4849K bytes) pkts bytes target prot opt in out source destination   Chain INPUT (policy ACCEPT 39692 packets, 2880K bytes) pkts bytes target prot opt in out source destination   Chain OUTPUT (policy ACCEPT 29226 packets, 2171K bytes) pkts bytes target prot opt in out source destination   Chain POSTROUTING (policy ACCEPT 2123 packets, 232K bytes) pkts bytes target prot opt in out source destination  35523 2660K MASQUERADE all -- any pppoe-wan anywhere anywhere  2 1098 MASQUERADE all -- any l2tp-voip anywhere anywhere

Inhalt von / etc / config / network:

cat /etc/config/network  config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0'  config globals 'globals' option ula_prefix 'xxxx:xxxx:xxxx:xxxx::/64'  config interface 'lan' option ifname 'eth0.1' option type 'bridge' option proto 'static' option ipaddr '192.168.x.x' option netmask '255.255.255.0' option ip6addr 'xxxx:xxxx:xxxx:xxxx::1/64'  config interface 'wan' option proto 'pppoe' option password 'yyyyyyyy' option ifname 'eth0.7' option username 'zzzzzzzzzzzzzzzzzzzzzzzzzzz@t-online.de' option ipv6 '1'  config interface 'wan6' option ifname '@wan' option proto 'dhcpv6' option reqprefix 'auto' option reqaddress 'try'  config switch option name 'switch0' option reset '1' option enable_vlan '1'  config switch_vlan option device 'switch0' option vlan '1' option vid '1' option ports '0t 2 3 4 5'  config switch_vlan option device 'switch0' option vlan '3' option vid '7' option ports '0t 1t'  config interface 'voip' option proto 'l2tp' option server 'ooo.ooo.ooo.ooo' option username 'xxxxxxxxxxx' option password 'xxxxxxxxxxx' option defaultroute '0' option peerdns '0' option delegate '0' option ipv6 '0'  config route option interface 'voip' option target 'xxxxxxxxxxxxxxx' option netmask 'xxxxxxxxxxx' option gateway 'xxxxxxxxxx'

Was kann ein Grund für dieses Problem sein?

Update: Nach Anregungen aus einer ähnlichen Frage habe ich versucht, verschiedene MTUs (1400,1476,1480) für pppoe-wan ( ifconfig pppoe-wan mtu xxxx ) einzustellen . Leider hat es nicht geholfen.

Update 2: Auf ubuntuforums.org wurde ein ähnliches Problem durch die Neuinstallation von Ubuntu behoben. Ich habe gerade versucht, OpenWRT erneut zu flashen (im Anschluss an https://openwrt.org/toh/tp-link/tl-wdr4300#flash_overwrite ; dann habe ich meine Konfiguration angewendet). Leider hat es nicht geholfen.

5
"Ich verwende keine OpenWRT-Standardkonfiguration" und was passiert, wenn Sie Ihre Konfiguration sichern, auf die Werkseinstellungen zurücksetzen und die Standardregeln von Luci iptables verwenden? Tim_Stewart vor 6 Jahren 2
In Ihrem Auszug versucht curl, SSLv3 zu verwenden. SSLv3 ist tot. Es ist höchstwahrscheinlich völlig unabhängig von Ihrem Router. Daniel B vor 6 Jahren 0
@Daniel B, danke, ich habe die Frage aktualisiert und dort die Ausgabe von curl mit TLS 1.0 gestellt Andrey Sapegin vor 6 Jahren 0
"--tlsv1.0" ist jetzt veraltet. Bitte ersetzen Sie in Ihrem Post die Ausgabe von curl auf einem Client und das Wireshark-Capture durch eine mit --tlsv1.2 oder zumindest --tlsv1.1. harrymc vor 6 Jahren 0
Die Wireshark-Aufnahme wurde für Firefox unter Windows durchgeführt. Wenn ich mit --tlsv1.2 oder --tlsv1.1 curl versuche, ist die Ausgabe absolut gleich. Andrey Sapegin vor 6 Jahren 0
Schönes Detail !!!!!! Pimp Juice IT vor 6 Jahren 0
Funktioniert die Standardkonfiguration? SILENT vor 6 Jahren 0

2 Antworten auf die Frage

2
RalfFriedl

Dies scheint ein Problem bei der MTU und der Fragmentierung zu sein. Ethernet-MTU ist 1500, während PPPoE-MTU (1500-8) = 1492 ist.

Das Einstellen der MTU auf dem Router allein hilft nicht. Sie reduzieren die MSS-Größe in ausgehenden Paketen.

Fügen Sie diese Regel hinzu iptables, vorausgesetzt, ppp0Ihre PPPoE-Schnittstelle ist:

-A VORWÄHLEN -o ppp0 -p tcp -m tcp --tcp-Flags SYN, RST SYN -j TCPMSS --clamp-mss-to-pmtu

Eine Alternative ist eine feste Größe:

-A VORWÄHLEN -o ppp0 -p tcp -m tcp -tcp-Flags SYN, RST SYN -j TCPMSS --set-mss 1400

Ja, du hast recht! Ich habe es gerade selbst gefunden und werde eine weitere Antwort mit weiteren Details zur Angelegenheit geben. Sie erhalten immer noch die akzeptierte Antwort und alle Kopfgeldpunkte, vielen Dank! Andrey Sapegin vor 6 Jahren 0
2
Andrey Sapegin

Wie RalfFriedl bereits schrieb, handelt es sich tatsächlich um das MTU-Problem. Die einfache Änderung der MTU hilft jedoch nicht. PPPoE hat immer weniger MTU als Ethernet, z. B. Ethernet MTU 1488 -> PPPoverEthernet MTU 1480. Selbst wenn der Router die richtige MTU für PPPoE kennt, funktioniert er irgendwie, und die Verbindung wird vom Router selbst, allen Client-Maschinen, hergestellt sendet weiterhin Pakete mit der MTU 1500 und iptables muss wissen, dass eine MTU-Anpassung beim Weiterleiten der Pakete erforderlich ist.

Hier ist die detaillierte Beschreibung des Problems: Es ist 2017 - Warum muss ich mich immer noch um MTU kümmern?

Standardmäßig verfügt OpenWRT über eine spezielle Option, um dieses Problem zu beheben:

Dies kann jedoch auch mit iptables-Regeln, die nicht Standard sind, mit der Option --set-mss in iptables behoben werden

Der wichtige Punkt ist, dass diese mss- Klemmregel am Anfang der FORWARD-Regeln stehen sollte, um zu verhindern, dass Pakete von anderen Regeln erfasst werden (z. B. Conntrack-Regeln usw.).

In meinem Fall ist dies die erste Regel dort:

-A FORWARD -i br-lan -o pppoe-wan -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Verwandte Probleme