web-dev-qa-db-ja.com

OpenWRTルーターを使用すると、一部のWebサイトでTLSハンドシェイクがリセットされます

現在、ルーターで非常に奇妙な問題に直面しています。私は TP-Link TL-WDR43 revを持っています。 1.7 OpenWRT18.06.1の実行。

この問題は、OpenWRT 15.05を使用していた1〜2か月前に最初に発生し、ルーターの最後の構成変更（18.06.1にアップグレードする前）は約1年前でした。

そのため、1〜2か月前に、一部のWebサイトがすべてのブラウザのすべてのデバイス（iOS搭載のiPhone、Android電話、Ubuntuラップトップ、Windowsラップトップ））に読み込まれないことに気付きました。デバイスはWiFiから切断され、たとえばセルラーネットワークを使用すると、Webサイトがすぐに読み込まれます。

私のISPはDeutscheTelekomであり、ロードされていないWebサイトの良い例は https://telekom.de であり、通常は到達可能であると予想されます。

最新の安定したOpenWRTリリースへのアップグレードを実行し、問題の調査を開始しました。この問題に関連するログやその他のエラーメッセージには、ルーターにドロップされたパケットはありません。 Curlは、影響を受ける1つのWebサイト（telekom.de）のコンテンツをルーターで直接取得できます。

 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>

すべてのクライアントで、それはまだ機能しませんでした：

$ 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

WindowsラップトップをドイツテレコムのPPPoE光ファイバーモデムに直接接続しようとすると、Webサイトが正常にロードされ始めました。また、WindowsラップトップをWiFiルーターに変えて、すべてのクライアントがロードできました。問題のあるWebサイト。

私の当初の考えは、問題 IPv6に関連している可能性があります （別の関連する可能性のある問題は ここ ）であり、（適切に構成されていない前に）構成しました。それは役に立ちませんでした。また、Windowsクライアントのアダプター設定でIPv6を無効にしても役に立ちません。

OpenWRTをルーターとして使用している場合、ブラウザーはしばらくの間（1〜2分）TLSハンドシェイクを実行しようとし、その後「セキュア接続に失敗しました」というメッセージを表示します。

telekom.deのTLSハンドシェイクのWiresharkキャプチャです 。

そして、以下は私のルーター設定のいくつかです：

インターフェースのスクリーンショット：

Interfaces

iptables -L -vの出力（標準のOpenWRTファイアウォール構成は含まれているため使用しませんチェーンがたくさんあり、私には複雑すぎるので、起動時に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

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

/ 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 '[email protected]'
 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'

この問題の理由は何でしょうか？

更新：同様の質問 からの提案に従って、pppoe-wanに異なるMTU（1400,1476,1480）を設定しようとしました（ifconfig pppoe-wan mtu xxxx）。残念ながら、それは役に立ちませんでした。

アップデート2：buntuforums.org 、Ubuntuを再インストールすることで同様の問題が修正されました。 OpenWRTを再フラッシュしようとしました（次の https://openwrt.org/toh/tp-link/tl-wdr4300#flash_overwrite ;次に構成を適用しました）。残念ながら、それは役に立ちませんでした。

networkingrouteriptablessslopenwrt
5
Andrey Sapegin

これは、MTUとフラグメンテーションの問題のようです。イーサネットMTUは1500ですが、PPPoE MTUは（1500-8）= 1492です。

ルーターにMTUを設定するだけでは役に立ちません。発信パケットのMSSサイズの設定を減らします。

ppp0があなたのPPPoEインターフェースであると仮定して、このルールをiptablesに追加します：

-転送-oppp0 -p tcp -m tcp --tcp-flags SYN、RST SYN -j TCPMSS --clamp-mss-to-pmtu

別の方法は固定サイズです。

-A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN、RST SYN -j TCPMSS --set-mss 1400

3
RalfFriedl

RalfFriedlがすでに書いたように、それは確かにMTUの問題です。ただし、MTUの単純な変更は役に立ちません。 PPPoEイーサネットのMTUは常に少なくなります（例：イーサネットMTU 1488-> PPPoverEthernet MTU1480）。どういうわけか、ルーターがPPPoEに適切なMTUを知っていても、接続がルーター自体から開始された場合でも、すべてのクライアントマシンはMTU 1500でパケットを送信し、iptablesは、パケットの転送中にMTU調整が必要であることを認識する必要があります。

問題の詳細な説明は次のとおりです。 2017年-なぜまだMTUを気にする必要があるのですか？

デフォルトでは、OpenWRTにはこの問題を軽減するための特別なオプションがあります。

ただし、非標準のiptablesルールを使用しても、これは簡単に修正できます iptablesの--set-mssオプションを使用

重要な点は、このmssクランプルール FORWARDルールの先頭にある必要があります 、以前に他のルール（conntrackルールなど）によってパケットがキャプチャされないようにすることです。

私の場合、これが最初のルールです。

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