現在、ルーターで非常に奇妙な問題に直面しています。私は 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キャプチャです 。
そして、以下は私のルーター設定のいくつかです:
インターフェースのスクリーンショット:
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 ;次に構成を適用しました)。残念ながら、それは役に立ちませんでした。
これは、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
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