Livingdeadの日記： vpnc 2
/etc/vpnc/vpnc-script ではトンネルデバイスのMTUを1390としている。
/sbin/ifconfig "$TUNDEV" inet "$INTERNAL_IP4_ADDRESS" $ifconfig_syntax_ptp "$INTERNAL_IP4_ADDRESS" netmask ${INTERNAL_IP4_NETMASK:-255.255.255.255} mtu 1390 up
TCPがよく切れてしまうのだけど、もう少し小さいほうがいいのだろうか。
[メモ]
vpnc --dpd-idle 0 で Dead Peer Detection を切るべし。
[追記 MTU]
まずはtun0のMTUが1390でいいのか。vpncを実行しているマシンからNTT西日本のフレッツ光プレミアムを経由した先にCiscoのVPNサーバがある。VPNサーバはインターネットに露出しており、そこまでのPMTUは1410である。vpncが作成するtun0のMTUは/etc/vpnc/vpnc-scriptにハードコードされておりデフォルトでは1390である。CiscoのVPN サーバの先にある Ubuntu マシンのマシン名を epson とすると、
ping -s 1362 -M do epson
でぎりぎりpingが通るので、1362+8(ICMP)+20(IP)でMTUは確かに1390である。それより大きいパケットだとtun0に割り当てたアドレスから、Frag neededが返ってくる。 needed/etc/vpnc/vpnc-scriptを修正してtun0のMTUを1500にしてみる。わけで、その中でさらにIPSecを通すのだからこのMTUは明らかに過大だ。案の定pingでしらべるとPMTU=1418+8+20=1446でぎりぎり通過できる。PMTUが1410である経路で張ったVPNのPMTUが1446というのは過大だ。1446バイトより大きいパケットだとepsonからは何も返ってこない。このときフラグメント化が起こっているはずなのだが、RTTの変化点は見つからなかった。ｋの状況でnetperfによりUDPのやり取りをしてみる。
netperf -t UDP_RR -H epson -- -r 1354
でぎりぎりUDPが通る。このときのレートは毎秒37.20回であった。これから推測されるPMTUは1354+8(UDP)+20(IP)=1382バイトである。あれ？ICMPで測ったPMTUと違うぞ？小さいほうを取るのが安全か。ということはtun0のMTUは1382としておくのがよさそうだ。
[追記 MSS]
tun0のMTUを1500のままで、netperfによりTCPのストリームを流してみる。
netperf -t TCP_STREAM -H epson -- -m 1m -S 1m -s 1m
tcpdumpでハンドシェイクを眺めるとepsonへはMSS=1460を提案し、epsonからはMSS=1380が提案されている。前者はtun0のMTUを1500としているから1500-20(IP)-20(TCP)=1460を提案している。epsonのeth0のMTUは1500なのだがこれからはMSS=1380が提案されている。netperfのTCP_STREAMテストでは計測の際にTCPのオプションが3つ（nop,nop,timestamp）付加されるので結果的にTCP_STREAMテストのパケットをtcpdumpで眺めると各TCPパケットのペイロードサイズは1380-4*3=1368となっている。このときスループットは20.30Mbpsであった。
[追記 mii-tool]
スループットが20Mbps程度あれば十分なのだが、vpncを動かしているLinuxマシン自体で何かしたいわけで無くて、それをルータとして動かしたい。ルータとして動かすよう設定することには問題がないのだが、そうしてルータとして動いているLinuxマシンを経由してVPNの先（上の例のepson）につなぐとTCPがぶちぶち切れる。全二重・半二重のネゴシエーションがうまくいっていないときにこのような症状が出ることを経験していたのでmii-toolでチェックしてみたのだが、「eth1: negotiated 100baseTx-FD, link ok」らしい。
[追記 パケットスケジューラ]
qdisc sfq 8002: dev eth1 root limit 127p quantum 1514b
qdisc tbf 800b: dev tun0 root rate 2000Kbit burst 1Mb lat 50.0ms
[追記 SACKとRSTフラグ]
TCPでSACKが働くとそのあと連続的にRSTフラグのたったパケットが飛ぶのはなぜだろう。しかもNAPTをしているLinuxが自発的に出しているみたい。だからNAPTの下にある機器からはそんなことが行われているとは見えない。
retransmission の個数と RTT の変動を調べると良い (スコア:1)
15秒間隔とかでデータを取るといい。5分だと荒すぎてわからない。
まれに、RTTがとんでもない変動の仕方をしていて、そのせいで tcp window サイズが爆発的に増減を繰り返している場合がある。( Window size は RTT * 手元の送信速度 * 送信率 ) で出した数字と、手動で設定している tcp window size の最大値、のどちらか数字の小さい方だからだ。
ちなみに送信率は、tcp session 単位で流量制御をする場合なんぞに使われる。たとえば 1Gbps の回線で 300Mbps ぐらいしか出したくない場合、流量最大値を 300Mbps とかに設定すると思うのだが、そうすると「手元の送信速度 * 送信率」の結果が 300Mbps になる、とそういうわけだ。
.
tcp window サイズがいきなり増大すると、その分のパケットが全力でPCから送出される。多分1Gbpsとかそれぐらいで。
ところが、WAN経由だったりすると、WANの部分がこの急激な増大に耐えられない。で、パケットを落とす。膨大な量を落としまくる。あとは再送のタイミングとウィンドウサイズの増減とのタイミングが合ってしまうと、再送も落ち、再再送も駄目…となってセッションが切れてしまう。
.
対策としては、tcp window size の最大値を手動で強引に小さな値にするか、WANの部分の管理をしている会社に
「ふざけるな、てめぇっ!! RTT が安定してないってのはどういうこったっ!!!
てめーらのせいで TCP session が切れまくるじゃねーかっ!!!!」
と文句を言う。
どうも WAN 会社の超大手所とかが、WAN内部でのパケットロスト率を下げるために、それ自身が再送機構を持っているらしいのだ。で、そいつの輻輳制御が RTT に露骨に反映されているらしい。なので、大声で文句を言うと、突如として性能が改善されたりする。
fjの教祖様
netperfなどで調整中 (スコア:1)
RTTの変動についてはまだ調べてないんですが、それ以前に vpnc のバージョンが古くてブチブチ切れるみたいです。vpnc の Dead Peer Detection で勝手に IPSec のトンネルが切られてしまう。そちらが解決したら netperfでパフォーマンス測定しつつそのトラフィックをtcpdumpで取り、統計処理してみようと思います。どの程度の時間間隔でRTTの変動があるのかもわからないんで、とりあえず全部取ってやれ、と。
自分の土日の在宅作業の手間を軽減するためだけにやってることであって業務に係るところじゃないんで、気長に。Ciscoから正規に配布されているクライアントを使えばいいわけですが、Linuxからつながらないとなんか悔しい。
屍体メモ [windy.cx]