先に結論。
VyOS で MSS 制限設定入れる場合、そのトラフィックが出入りする全インタフェースに set policy route しないといけない。(VyOS 1.1.7時点)
※2019-03-21 PPPoEインタフェースのみでMSS制限する方法書きました → https://naga-sawa.hatenablog.com/entry/2019/03/21/152748
naga-sawa.hatenadiary.org
よくあるのが Flets の PPPoE の MTU 1454 byte 環境用に MSS 1414 byte と制限したい場合はこんなルールを作って、
policy {
route PPPOE-IN {
rule 10 {
destination {
address 0.0.0.0/0
}
protocol tcp
set {
tcp-mss 1414
}
tcp {
flags SYN
}
}
}
}PPPoEインタフェースと LAN インタフェースの両方に指定するのが正解です。
set interfaces ethernet eth0 pppoe 0 policy route PPPOE-IN
set interfaces ethernet eth1 policy route PPPOE-IN
いまいちスマートさに欠けるので、別のスマートな設定方法あるか将来バージョンで
set interface ethernet eth0 pppoe 0 mss-limit 1414
みたいなことができればいいなぁとか思いつつ。
以下のサイトは、自身が過去にも参考にさせてもらったりしてるのですが、どれも LAN 側のみに設定しているだけなので、上手くいかない場合があります。
海外だと同じ問題にぶつかって「双方向で指定しないと」って話があるようなんだけれども、国内じゃさっぱり見かけないので。
なんで？というお話
TCP において、MSS のネゴシエーションはコネクション確立時に行われ、SYNパケットに付けられる MSS オプションを使って双方の MSS を送りあった後、より小さい MSS をコネクションの MSS として採用するという形で実現されています。
PC1 が MSS1200、 PC2 が MSS1400 の場合、通常時は以下のように MSS 情報の交換が行われます。
1. PC1 --(SYN : MSS1200)-> PC2
2. PC1 <-(SYN+ACK: MSS1400)-- PC2
3. PC1 --------(ACK)--------> PC2
1. の時点で、 PC2 は PC1 の MSS を知り、自身の MSS より小さいため MSS = 1200 を採用します。
2. の時点で、 PC1 は PC2 の MSS を知ることになりますが、自身の MSS のほうが小さいため、そちらを採用します。
以降このコネクションでは MSS = 1200 として無難に通信が進むことになります。
問題になるのは以下のように、途中のルータで MSS 制限を加える場合。
PC1, PC2 とも途中経路に制限があるとも知らず、 MSS1460 で通信をしようとしています。
ルータ - PC2 間が PPPoE を挟むので、ルータで MSS1414 に制限しようとします。
このとき、ルータが片方向でしか MSS を変えてくれない場合に問題が生じます。
1. PC1 --(SYN : MSS1460)-> ルータ --(SYN : MSS1414)-> PC2
2. PC1 <-(SYN+ACK: MSS1460)-- ルータ <-(SYN+ACK: MSS1460)-- PC2
3. PC1 --------(ACK)--------> ルータ --------(ACK)--------> PC2
1. ではルータが MSSを1414を変更して PC2 に伝えるので、 PC2 は MSS=1414 を採用します。
しかしながら、 2. において、ルータが戻りパケットの MSS オプションを変更しないので、そのパケットを見て PC1 は MSS=1460 で大丈夫だと判断してしまいます。
そうすると、パケットサイズによって PC1 -> PC2 のパケットが落ちたりして不安定な状態になってしまいます。
set interfaces policy で片方のインタフェースにしか指定しないと、まさにこの状態になってしまいます。
実際の所、どうなってるの？ということで、 PPPoE インタフェースと LAN インタフェースを通る 3way ハンドシェイクをモニタ(tcpdump)した結果を見てみましょう。
LAN内の PC から 59.106.194.36 (d.hatena.ne.jp) に接続してみたときの結果です。
まず、LAN側のみ PPPOE-IN を適用している場合。
LAN 側 IF (eth1) を通る 3way ハンドシェイク は次の通り。
$ monitor interfaces ethernet eth1 traffic filter "host 59.106.194.36"
0.000000 192.168.0.17 -> 59.106.194.36 TCP 58563 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2
0.014629 59.106.194.36 -> 192.168.0.17 TCP 80 > 58563 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 WS=9
0.015777 192.168.0.17 -> 59.106.194.36 TCP 58563 > 80 [ACK] Seq=1 Ack=1 Win=65700 Len=0
次に PPPoE インタフェースをモニタした結果。
$ monitor interfaces pppoe pppoe0 traffic filter "host 59.106.194.36"
0.000000 218.211.81.60 -> 59.106.194.36 TCP 58548 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1414 WS=2
0.014321 59.106.194.36 -> 218.211.81.60 TCP 80 > 58548 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 WS=9
0.015360 218.211.81.60 -> 59.106.194.36 TCP 58548 > 80 [ACK] Seq=1 Ack=1 Win=65700 Len=0
PC -> 59.106.194.36 への MSS は PPPoE に出て行く時点で MSS=1414 に変更されているものの、 59.106.194.36 の応答 SYN パケットのそれは MSS=1460 のまま、変更されていません。
そして、LAN側、PPPoE側の双方に PPPOE-IN を適用した場合では、
$ monitor interfaces ethernet eth1 vif 5 traffic filter "host 59.106.194.36"
Capturing traffic on eth1.5 ...
0.000000 192.168.0.17 -> 59.106.194.36 TCP 58688 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2
0.013817 59.106.194.36 -> 192.168.0.17 TCP 80 > 58688 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1414 WS=9
0.014805 192.168.0.17 -> 59.106.194.36 TCP 58688 > 80 [ACK] Seq=1 Ack=1 Win=66456 Len=0
$ monitor interfaces pppoe pppoe0 traffic filter "host 59.106.194.36"
Capturing traffic on pppoe0 ...
0.000000 218.211.81.60 -> 59.106.194.36 TCP 58678 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1414 WS=2
0.013987 59.106.194.36 -> 218.211.81.60 TCP 80 > 58678 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 WS=9
0.015217 218.211.81.60 -> 59.106.194.36 TCP 58678 > 80 [ACK] Seq=1 Ack=1 Win=66456 Len=0
PC -> 59.106.194.36 への SYN パケットと、 59.106.194.36 -> PC の応答SYNパケットの双方で MSS=1414 に変更できていることがわかると思います。
なんでなんでー？というお話
詳細は調べてないのでわからないのですが、 policy route で指定する tcp-mss は iptables の mangle テーブルの PREROUTING チェインに入るようです。
各インタフェースの受信パケットは → PREROUTING チェインで MSS 変更 → ルーティング → ルーティング先インタフェースから出力、という流れで処理されるため、 LAN 側インタフェースに指定しただけでは、 PPPoE インタフェースで受信されたパケットに対して MSS 変更処理がされず、上に書いたような状況に遭遇してしまうと考えられます。
(Linux の受信パケットの流れは 画像検索"iptables prerouting" 参照)
以下、LAN 側インタフェースのみに指定したときの iptables の状態。
$ sudo /sbin/iptables -L -n -v -t mangle
Chain PREROUTING (policy ACCEPT 4263 packets, 753K bytes)
pkts bytes target prot opt in out source destination
342K 142M VYATTA_FW_IN_HOOK all -- * * 0.0.0.0/0 0.0.0.0/0
Chain INPUT (policy ACCEPT 1074 packets, 82127 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 2841 packets, 628K bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 680 packets, 66835 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 3521 packets, 695K bytes)
pkts bytes target prot opt in out source destination
306K 138M VYATTA_FW_OUT_HOOK all -- * * 0.0.0.0/0 0.0.0.0/0
Chain PPPOE-IN (5 references)
pkts bytes target prot opt in out source destination
8559 444K TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 /* PPPOE-IN-10 */ tcp flags:0x02/0x02 TCPMSS set 1414
175K 18M RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 /* PPPOE-IN-10000 default-action accept */
Chain VYATTA_FW_IN_HOOK (1 references)
pkts bytes target prot opt in out source destination
1072 166K PPPOE-IN all -- eth1 * 0.0.0.0/0 0.0.0.0/0
Chain VYATTA_FW_OUT_HOOK (1 references)
pkts bytes target prot opt in out source destination
続いて、 PPPoE 側、LAN 側の双方に指定した場合の iptables の状態。
$ sudo /sbin/iptables -L -n -v -t mangle
Chain PREROUTING (policy ACCEPT 172 packets, 23721 bytes)
pkts bytes target prot opt in out source destination
343K 142M VYATTA_FW_IN_HOOK all -- * * 0.0.0.0/0 0.0.0.0/0
Chain INPUT (policy ACCEPT 60 packets, 5003 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 99 packets, 18075 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 45 packets, 4652 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 144 packets, 22727 bytes)
pkts bytes target prot opt in out source destination
307K 138M VYATTA_FW_OUT_HOOK all -- * * 0.0.0.0/0 0.0.0.0/0
Chain PPPOE-IN (6 references)
pkts bytes target prot opt in out source destination
8594 446K TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 /* PPPOE-IN-10 */ tcp flags:0x02/0x02 TCPMSS set 1414
175K 18M RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 /* PPPOE-IN-10000 default-action accept */
Chain VYATTA_FW_IN_HOOK (1 references)
pkts bytes target prot opt in out source destination
48 11695 PPPOE-IN all -- pppoe0 * 0.0.0.0/0 0.0.0.0/0
1075 166K PPPOE-IN all -- eth1 * 0.0.0.0/0 0.0.0.0/0
Chain VYATTA_FW_OUT_HOOK (1 references)
pkts bytes target prot opt in out source destination
経緯
新しく買ったタブレットからのWiFi通信が通らず、あかんやーんとしばらく放ってたところ、古いタブレットでも同じ現象が出ることに気づき、 LTE 経由だとちゃんと通信が通ったので、まず WiFi AP の不具合を疑い、ファーム更新したり再起動したりでも改善せず、MTU 絡みの可能性を疑って、 MSS がちゃんと変更されてるかパケットキャプチャしてみたところ、戻りパケットで MSS が変更されてないことに気付き、元設定じゃダメじゃんとなった次第。
PPPoE インタフェースにも set policy route の設定を入れたら、新タブでも通信できるようになったので、ようやく新タブが使えるようになったorz
PCからの通信も妙に遅かったのもこれのせいだったぽい。
これについて書かれたものが見あたらないので、国内だとあまり問題になってない地雷を踏み抜いたんだろうか…（or VyOSユーザがレアなのか）
VyOSっぽいOSが動くルーター EdgeRouter Lite では機能として MSS clamp が載ってる模様。
17,000円で買えるVyOSっぽいOSが動くルーター EdgeRouter Lite(ERLite-3)を使ってみる — どこか遠くでのんびり怠惰に暮らしたい
iptables を触って PPPoE インタフェースの POSTROUTING チェインに無理矢理 TCPMSS を書けばコンフィグ上はシンプルに収まりそうだけど、裏技臭がひどくて運用的に問題がでそうだし。
