IPSec のスループット

ネットワークのスループットを測定する環境を整えたので、次いでに IPSec を通してた時のものも測定してみた。

測定の条件は

1. スループット測定ツール nuttcp の計測用データチャンネル 5001/tcp を上り／下りにそれぞれ IPSec に通す。
2. racoon ver.1 でサポートされていない暗号化スイートも測定したいので、鍵を手動で設定する。
3. ESP認証／暗号の組み合わせで計測する。(AHは使わん)
4. 追加で IPComp での圧縮の効果を見たい気がする。

複数の認証/暗号の組み合わせで測定する為にスクリプト(measure_ipsec_throughput.sh)化した。

setkey で、手動で鍵を設定する方法は多々情報(1、2)があるので、そちらを参考にして欲しい。ただ、IPComp を組み合わせる例が乏しいのでこの部分だけ。

IPComp を組み合わせて使う

IPSec設定済みで、ESPのみを使うSPDが次にようになってるだろう。

...
spdadd xx.xx.xx.xx[port] yy.yy.yy.yy tcp -P out ipsec esp/transport//require;
...

このときSPDのルールの順番が重要になる。カプセル化の下の方から、要は IPComp ⇒ ESP ⇒ AH の順に書き下していくことになる。

従ってIPCompを組み合わせるには、次のようにすればよい。

...
add xx.xx.xx.xx[port] yy.yy.yy.yy ipcomp zzzz -C deflate;
spdadd xx.xx.xx.xx[port] yy.yy.yy.yy tcp
	-P out ipsec ipcomp/transport//use esp/transport//require;

ただ、ベンチマークに流れるデータは「0」の羅列なので、いまいち効果が分からん。。。

なので計測は諦めた。

IPSec スループットの計測

前とほぼ同じ環境とmacbook pro を加えたものを用意、全ての計測に MTU 1500 / ロック周波数変更は全て無効にしMAXにした。また、TCP/IP通信に関するパラメータを修正せずにデフォルトにした。

• ref1 - M2NPV-VM / Athlon64X2 2.0GHz / DDR2-667 4GB / Intel Pro/1000PT (外付け)
• ref2 - M4A78-EM / Athlon X2 5050e 2.6GHz / DDR2-800 8GB / RTL8112
• via - VIA-EN12000EG / VIA C7 1.2GHz / DDR2-533 1G / VT6122
• osx - MacBookPro5,1 / Intel Core 2 Duo 2.4 GHz / DDR3-1066 2G x 2 / onboard Gigabit Ethernet
• hub - Gigabit Hub(GS908M)

認証/暗号		ref1⇔ref2			ref1⇔via			ref1⇔osx
		throughput (Mbps)	CPU %		throughput (Mbps)	CPU %		throughput (Mbps)	CPU %
			ref1	ref2		ref1	via		ref1	osx
no ipsec	⇒	941.3580	10	28	785.1857	6	50	936.9429	9	54
	⇐	941.2461	17	24	723.7100	12	99	938.3451	18	77
null/null	⇒	934.6834	99	38	566.8947	13	93	932.0707	31	62
	⇐	787.4495	18	46	520.2880	13	99	879.3127	25	99
null/des-cbc	⇒	229.5461	99	8	72.9094	2	95	136.6533	3	14
	⇐	197.0768	14	26	73.4657	4	99	129.1215	6	99
null/3des-cbc	⇒	110.5173	100	4	30.8918	2	87	59.2064	1	7
	⇐	76.8033	11	1	30.5976	1	99	56.5818	3	98
null/aes-cbc	⇒	466.7989	99	33	392.0739	14	91	475.7789	95	43
	⇐	472.1796	28	36	396.2264	17	99	376.3890	22	99
null/aes-ctr	⇒	495.4163	77	58	218.6071	7	71
	⇐	383.9987	16	7	258.7430	17	99
null/blowfish-cbc	⇒	316.0327	99	11	77.6054	3	74	263.7795	15	31
	⇐	244.9774	11	4	84.1580	4	99	228.4810	13	99
null/twofish-cbc	⇒	372.5317	99	19	100.8360	5	73
	⇐	289.2720	15	9	102.0088	5	99
null/camellia-cbc	⇒	340.9916	100	15	86.7841	3	60
	⇐	267.3560	18	5	84.5675	4	99
hmac-md5/null	⇒	537.2857	99	24	244.7170	7	87	578.8675	99	49
	⇐	453.2448	29	14	230.2019	11	99	572.5809	29	99
hmac-sha1/null	⇒	370.0861	100	15	360.3754	20	86	414.4706	99	41
	⇐	296.1913	11	7	350.0287	20	99	469.5587	57	98
hmac-sha256/null	⇒	307.0078	99	16	302.9315	100	41	278.9001	17	33
	⇐	240.0495	12	4	336.2512	19	96	248.9149	28	99
aes-xcbc-mac/null	⇒	447.6017	99	20	216.0013	6	80
	⇐	347.9881	13	12	271.0801	21	99
hmac-md5/3des-cbc	⇒	101.5172	100	5	29.0609	1	88	57.0069	1	7
	⇐	71.0862	11	1	28.4519	1	100	54.5636	4	98
hmac-md5/aes-cbc	⇒	326.0155	99	17	205.8441	9	79	349.0338	80	27
	⇐	266.2639	18	5	198.6511	12	99	296.4431	27	98
hmac-sha1/3des-cbc	⇒	94.1899	100	5	30.1900	1	85	56.6619	1	5
	⇐	66.1646	12	1	29.8474	2	99	52.0154	4	96
hmac-sha1/aes-cbc	⇒	259.3614	99	15	253.1157	99	56	275.3661	98	25
	⇐	202.5055	12	4	286.0077	20	93	270.1091	26	97
hmac-sha1/aes-ctr	⇒	257.3152	99	14	193.6954	4	97
	⇐	199.9059	12	3	209.8745	16	99
aes-xcbc-mac/aes-cbc	⇒	283.0864	99	15	207.2613	11	62
	⇐	225.1556	13	4	233.3907	26	99
aes-xcbc-mac/aes-ctr	⇒	281.3969	99	15	154.4989	7	70
	⇐	220.3145	12	4	178.5399	13	99

異様にたくさん計測したが、あんまり意味が無い気がしないでもない。

• 暗号化方式の性能は
  aes系 > blowfish/twofish/camellia >> DES > 3DES
  VIA C7 では aes系 >> それ以外
• 認証方式の性能は
  hmac-md5 > aes-xcbc-mac > hmac-sha1/hmac-sha256
  ただ、あまり差異はない。
  VIA C7 では hmac-sha1/hmac-sha256 >> それ以外
• des-cbc/3des-cbc は他の暗号化方法に比べて５～１０倍くらい遅い。もう、見る影が無い。
• aes 系の実装には多くの開発リソースが割かれており、x86 コードでも十分早い。VIA PadLock が圧倒的に有利という訳ではない、不利という訳でもない。
• 個々のNICドライバの個性がある。
  e1000e(Linux) / nvenet(MacOSX) に関しては送信時のCPU負荷が100%になる傾向があり、r8169 に関してはどう考えてもCPU利用率が低くなる。
  これが NIC 自体の性能か、TCPと組み合わせで何らかのビジーウェイトが起きるのかは、いまいち不明。。。nuttcp/netperf で発生するトラフィックパータンに対する適性なのだろうか。
  送信性能が上がるチューニングが必要なのだろうか？
• 普通運用する hmac-sha1/aes-cbc は 約250Mbps のスループットが出る。PadLock を使えば同様の性能が出る。

結論

VIA-EN12000EG 上の Linux で IPSec を使うと約250Mbps程度のスループットの性能があり、Athlon64X2 2.0GHz と同程度の性能である。

Intel Atom はどの程度なのだろうかぁ？

VT6122 の性能(4) - ドライバの強化

元々 via-velocity は、少し古いバージョンの velocityget ソースを整理したものだった。ただ、現在の双方のバージョンを比べると、via-velocity に含まれていない要素がある。

• EnableMRDPL (Memory-Read-Multiple)オプション
• VIA 的には「Adaptive Interrupt」と呼ばれるもの
  (txque_timer/rxque_timer/tx_intsup/rx_intsupオプションとその関連部分)

これは、分岐後にVIAによって追加されたものか、意図的に省かれたのもか、どちらなのかは正直分からない。

EnableMRDPL (Memory-Read-Multiple)オプション

最初の要素は、PCIのバースト転送のモードをなんか指定するものらしいが、ベンチマーク上は効果がなかった。 PCIに詳しくなければいまいち内容が分からないし、デフォルトが無効なので、今回は見送った。

VIA 的には「Adaptive Interrupt」と呼ばれるもの

「適応割り込み」と称しているが、単に割り込みを一定数間引いたり、一定時間遅延を入れるだけのようで、 特に割り込みの頻度に応じて動的に変更はしない。。。なんかなぁ

うんで、機能追加パッチを作ってみた。(velocitygetの処理を流用)

1. via-velocity の adaptive interrupt 関連の機能追加パッチ (debian lenny/kernel-2.6.26用) / via-velocity-adaptive-intr.patch

前出の修正パッチの後に当てればいい

# mkdir via-velocity
# cp Makefile-via-velocity-only via-velocity/Makefile
# cp /usr/src/linux-source-2.6.26/drivers/net/via-velocity.[ch] via-velocity/
# patch -p 3 -d via-velocity < via-velocity-fixed-wol.patch
# patch -p 3 -d via-velocity < via-velocity-fixed-int_works.patch
# patch -p 3 -d via-velocity < via-velocity-adaptive-intr.patch
# cd via-velocity
# make install

スループット性能の比較

前回と同じ環境で、velocityget と via-velocityの「Adaptive Interrupt」パッチ有／無の３種類の場合を測定した。

	velocityget			via-velocity パッチ無し			via-velocity パッチあり
	スループット (Mbps)	CPU 利用率		スループット (Mbps)	CPU 利用率		スループット (Mbps)	CPU 利用率
		target	ref1		target	ref1		target	ref1
target ⇒ ref1	655.4841	99 %	11 %	646.4036	99 %	12 %	724.7809	99 %	12 %
target ⇐ ref1	741.2755	66 %	4 %	709.2465	80 %	2 %	762.3420	51 %	5 %

mtu 1500 / DMA_length=6 / それ以外のモジュールパラメータはデフォルト値

	velocityget			via-velocity パッチ無し			via-velocity パッチあり
	スループット (Mbps)	CPU 利用率		スループット (Mbps)	CPU 利用率		スループット (Mbps)	CPU 利用率
		target	ref1		target	ref1		target	ref1
target ⇒ ref1	816.0544	32 %	7 %	816.1541	30 %	7 %	814.9007	31 %	7 %
target ⇐ ref1	989.8745	48 %	9 %	944.4813	46 %	8 %	989.8323	46 %	9 %

mtu 9000 / DMA_length=6 / それ以外のモジュールパラメータはデフォルト値

考察

mtu 1500 のとき、送信性能が10%程度上がった。受信性能はほぼ velocityget と同程度になったが、CPU負荷率は低くなった。mtu 9000 のときは、velocityget と同程度になった。

受信時のCPU負荷率低下は面白い。NAPI化すればより軽くなるのかなぁ。e100?系の適応なんとかの動的アルゴリズムを流用すればもっと良くなるのかなぁ。もっと送信性能を上げるにはどうすれば良いのだろう。。。

スループットのベンチマーク上の結果だけなので、レイテンシとかはどうなんだろう。。。

本来 ethtool へのインタフェース経由で設定するものを、モジュールパラメータに載せて、固定値になっているのも気になると言えば気になる。

ちまちまパッチを切るのは面倒だから、どっかにレポジトリ借りて、最新版のバニラソースに作業するのがいいのかなぁ。

ふぅむ。

近年、VIA の NIC のシェアはかなり落ちている。大抵の onboard NIC は RealTek の奴だったりする。また、Windows 64bit系の4G問題とかも敬遠される原因になっている。

廃れつつ、傾きつつ、そんなものの為に作業する奴がいないんだろうなぁ。

VIA EPIA は本当に不憫な奴だ。

今年分の作業は、この辺かなぁ、、、では

VT6122 の性能(3) - ネットワークスループット測定

スループットを計測するツールは何種類かある。

• ttcp / nttcp / nuttcp
  ttcp が古のツールでソースは色んなバージョン(1,2)が散見される、SGI の人が改良したのが nttcp (元サイトは http://www.leo.org/~elmar/nttcp/ だったらしいが、既に無くなっている)。nuttcp は、nttcp をベースに改良が続けられたもの。使うならば nuttcp かなぁ。
• iperf
  Java ベースの GUI 付きがあるので、ベンリかも
• netperf
  スループット以外にもテスト項目の種類が豊富。ただし、man ページが不完全でなので付属の HTML/PDF を参照する必要がある。
• SmartBits
  商用でよく使われている奴ですね。

まぁ、スループットの測定ならば iperf を使えば良いが、CPU の負荷状況を見たいので nuttcp を使ってみた。

VIA-EN を含めて以下の３台とHUBを用意し、３台ともhubに直結した。

• target - VIA-EN12000EG / VIA C7 1.2GHz / DDR2-533 1G / VT6122
• ref1 - M2NPV-VM / Athlon64X2 2.0GHz / DDR2-667 4GB / Intel Pro/1000PT (外付け)
• ref2 - M4A78-EM / Athlon X2 5050e 2.6GHz / DDR2-800 8GB / RTL8112
• hub - Gigabit Hub(GS908M)

また、測定自体は、clock skew を避けるため全て ref1 上で計測した。cpufreq によるクロック周波数変更は全て無効にしMAXにした。 ref2 に関しては ref1 自体の評価にのみ使った。

ref1 ⇔ ref2 間

ref1 / ref2 ともに mtu 1500 に設定して測定した。

# ssh -f ref2 -- "nuttcp -S -1"
# nuttcp -t ref2
 1123.8690 MB /  10.01 sec =  941.3733 Mbps 11 %TX 27 %RX
# ssh -f ref2 -- "nuttcp -S -1"
# nuttcp -r ref2
 1122.3750 MB /  10.00 sec =  941.0966 Mbps 33 %TX 16 %RX

これを表にすると、

	スループット (Mbps)	CPU 利用率
		ref1	ref2
ref1 ⇒ ref2	941.3733	11 %	27 %
ref1 ⇐ ref2	941.0966	16 %	33 %

mtu 1500

まぁ、順当に ref1 は送受信ともに約 940Mbps 程度の性能を持っている事が分かる。

target ⇔ ref1 間

target の ドライバ via-velocity/velocityget のそれぞれに対して、mtu 1500 かつモジュールパラメータを設定せずに(ドライバのデフォルト値で)計測した。

	velocityget			via-velocity
	スループット (Mbps)	CPU 利用率		スループット (Mbps)	CPU 利用率
		target	ref1		target	ref1
target ⇒ ref1	655.2174	99 %	12 %	340.1681	27 %	9 %
target ⇐ ref1	738.7987	68 %	3 %	514.5900	42 %	2 %

mtu 1500 / モジュールパラメータは全てデフォルト値

熟考

結果を見れば、明らかに velocityget の方が性能が高いように思われるが、ソースを見比べるとモジュールパラメータ DMA_length のデフォルト値が、それぞれのドライバで異なる (velocitygetは6/via-velocityは0)。

DMA_length は、チップ内のバッファとメインメモリの間を転送する DMA の処理サイズを指定するらしく、大きなサイズであれば PCI バスの使用効率が上がるので、スループットに影響しそうである。

なので、DMA_length を 0〜7 に振って再度計測し直してみた。

	DMA_length	velocityget			via-velocity			比 (via-velocity /velocityget)
		スループット (Mbps)	CPU 利用率		スループット (Mbps)	CPU 利用率
			target	ref1		target	ref1
target ⇒ ref1	0	369.5053	28 %	11 %	340.1827	27 %	10 %	0.920643
	1	398.9382	39 %	11 %	414.5747	40 %	7 %	1.039195
	2	497.4004	64 %	9 %	494.2757	60 %	8 %	0.993717
	3	539.0356	84 %	9 %	540.7160	80 %	10 %	1.003117
	4	610.5743	99 %	10 %	608.1031	99 %	10 %	0.995952
	5	646.1530	99 %	11 %	640.9711	99 %	10 %	0.991980
	6	655.4841	99 %	11 %	646.4036	99 %	12 %	0.986146
	7	652.1732	99 %	12 %	647.7397	99 %	10 %	0.993201
target ⇐ ref1	0	450.8850	36 %	2 %	502.9532	42 %	2 %	1.115480
	1	490.2150	38 %	2 %	580.6518	56 %	2 %	1.184483
	2	599.5584	48 %	3 %	642.5684	63 %	2 %	1.071736
	3	661.0592	52 %	3 %	685.1753	74 %	3 %	1.036480
	4	719.6965	64 %	3 %	709.9482	83 %	3 %	0.986454
	5	731.3209	69 %	5 %	710.1113	80 %	3 %	0.970998
	6	741.2755	66 %	4 %	709.2465	80 %	3 %	0.956792
	7	738.2975	65 %	3 %	710.1459	82 %	3 %	0.961869

mtu 1500 / モジュールパラメータはDMA_length以外はデフォルト値

DMA_length の値を合わせれば、送受信のスループットに関しては velocityget/via-velocity にほとんと差異は無く、強いて言えば velocityget の方が受信に関して 4〜5% 高く、処理が軽い。送信に関しては双方同じ程度に CPU を使い切って頭打ちになっている。VIA C7 では 1Gbps は吐けないのかぁ。。。

まぁ、DMA_length は velocityget のデフォルト値の 6 が推奨値かなぁ。ちなみに、NetBSDでのドライバ vge だと 4 だった。

ただ、DMA_lengthの値でスループットの差異が出るのは VT6122などのPCIベースの場合だけで、PCIe ベースの VT6130 ではどの値でも違いが無かった。。。多分省かれてしまったのでしょう。

さて、velocityget にだけあるっぽい機能を移植していけば、差異が無くなっていくのかなぁ？

MTU 9000 での測定

そういえば、mtu 9000 のスループットも測定をしたかったで Intel Pro/1000PT を外付けしたんだっけなぁ。なので、測定してみた。

	velocityget			via-velocity
	スループット (Mbps)	CPU 利用率		スループット (Mbps)	CPU 利用率
		target	ref1		target	ref1
target ⇒ ref1	816.0544	32 %	7 %	816.1541	30 %	7 %
target ⇐ ref1	989.8745	48 %	9 %	944.4813	46 %	8 %

mtu 9000 / DMA_length=6 / それ以外のモジュールパラメータはデフォルト値

受信に関しては、ほぼ 1Gbps を使い切っている！凄し！

追記 (2009/10/06)

今回使ったスループット測定用のスクリプトmeasure_net_throughput.shをバックアップとして上げておく。

VT6122 の性能(2) - VIA Velocity の出自

velocitygetのソースを眺めていると VT3119 とか VT3216とか一見全く関係無さそうなチップ名らしき物が出てくる。 VT6122 の Device ID が 0x3119 なのでVIA内部型番になっているのかなぁ。 でも、ドライバ内では Rev ID での区別らしきものがあり、それに従うと VT6122 = VT3216 (?)っぽい。

正直のところ VIA に聞かないと分からないし、検索でもホンの僅かの情報しか引っ掛からないので、 憶測程度にしかならないが、ちょっとだけ書き残しておこう。

VT6110

ここら辺の事情は、ほんとに雲をつかむような感じだ。。。

ZyXEL社の Gigabit NIC (GN650-T/GN670-T) が最初の製品っぽい。そいつが VIA 内部では Device ID と関連づけて、多分 VT3119 と呼ばれていたんだろう。コイツにはまだ PHY が内蔵されておらず、ZyXEL の製品には PHY が載っている。それが CICADA製SimpliPHY のもの。

ZyXEL へのOEM供給?でチップの型番はZX1701Z/X1702になっているが、VIA が外販する時に VT6110 と付けたんだろうと推測できる。

参照

1. BSD系のドライバ vgeには、ZyXEL 製のNICとVT3119 の記述がある。
2. ZyXELのサイトには情報は殆どないが、Download Search で検索するととドライバ(rhineget 1.10/velocityget 1.18)が見つかる。
3. ロシアでは結構流通した製品らしく、検索（"Zyxel Omni LAN PCI G1"）に出てくる。カード全体の鮮明な画像も出てくる。SimpliPHYのマークのチップが見てとれる。
4. rhineget/velocityget 内の chip_info_table には、CHIP_TYPE_VT6110 のマクロがある。
5. Gentooのフォーラムの記事に、GN650-T の lspciの出力があり、Rev 01 となっており、ソース内では REV_ID_VT3119_A1 に相当する。REV_ID_VT3119_A0 というのは開発版なのかなぁ。。。

VT6120/VT6121/VT6122

VT6110 に SimpliPHYを内蔵して１チップ化したものが、良く知っている VIA Velocity と呼ばれてる製品群で、 PCIのバスサイズが32bit/64bitのものがそれぞれがVT6120/VT6121で、VT6120 のパッケージを小型したのが VT6122 である。

内部的には VT3216 の型番が付いてると思われるが、ドライバが流用できるほど上位互換なので、Device ID が 0x3119 のままになったようである。

以後、Rev ID の範囲で区別する方針になったのか、0x00〜0x0F が ZX1701Z/X1702/VT6110 であり、0x10 〜 0x1F　が VT6120/VT6121/VT6122 のどれかにあたる。ちなみに EPIA-EN12000EG に載っているのは 0x11 になっている。

性能アップのための機能で Tx/RX キューに関するなんかのタイマーが追加されている。

Rev ID が 0x20〜0x7fのもの

該当する製品が見つけられなかった。。。内部的には VT3284 の型番が付いていると思われる。

velocityget を読む限り、PCI のバースト転送に Memory-Read-Multiple が使えるようになったっぽい。なんのコッチャ、、、

Rev ID が 0x80 〜

PCIe に対応した VT6130/VT6132 が該当する。内部的には、VT3286 の型番が付いてると思われる。

どうも PCIe 化と同時に省かれた機能があるっぽいが、ドライバでは何も対処してないっぽい気がする。

まとめ

Device ID 0x3119 のデバイスは、Rev ID の範囲でチップを区別してるらしい（もしかしたら、特定の Rev ID リストが作れるかも）。

Rev ID	内部型番	チップ名
0x00 ～ 0x0f	VT3119	ZX1701Z/X1702/VT6110
0x10 ～ 0x1f	VT3216	VT6120/VT6121/VT6122
0x20 ～ 0x7f	VT3284	不明
0x80 ～	VT3286	VT6130/VT6132

但し書き

元になるデータが凄く不確かであり、かなりの憶測が含んでいる(ほとんどが要出典)。あまり信用できる情報ではありませんのであしからず。

VT6122 の性能(1) - Linux のドライバの準備

VIA EPIA は不憫な奴だ。

去年から消費電力が低い Intel Atom ボードが出荷され、当初性能がわずかに上かなぁ〜と思われた後で、Dual-Core だとか Hyper-Threading とかが追加され、もう比べるのも可哀想なぐらい、次いでに Mini-ITX のボードの市場も荒らされまくり、踏んだり蹴ったりのボコボコにされてますなぁ、、、なんか違うかも。

何の気の迷いか EPIA-EN12000EG を買ってしまって以来、 不憫な奴が故に捨てられずに、年に１回くらいは思い出したように手を入れて使っている。。。はぁ〜

今回は NIC の性能について愚痴ってみよう。

EPIA-EN12000EG には VT6122 (Gigabit Ethernet) が搭載されている。Datasheet(pdf) を見る限り、South Bridge / VT8237R+ の下のPCIバス(32bit/33MHz)にぶら下がっている。PCIバス(32bit/33MHz) の上限 133MByte/s がボトルネックになるので期待は出来ない。PCIe 接続の VT6130/VT6132 でないなければ Gigabit の限界には迫れないが、どれくらい迫れるかが興味の有るところ。

二種類のドライバ

VT6122のLinux ドライバは二種類で、どっちも些細なバグが有る。

1. via-velocity / kernel 本家に取り込まれているもの。性能が低いのがもっぱらの噂。WOL が動かない。
2. velocityget / VIA 本家作成のドライバ。VIA AREA で公開されているが、ダウンロードページに辿り着くまでが迷路というか、ほんとに無理。現在(2009/09/23)の時点で、1.36 が安定版らしい。 rmmod/insmod を繰り返すと dmesg に 不審な oops を残す不具合あり。

で、修正パッチを作ってみた。

1. via-velocity の WOL 対応パッチ (debian lenny/kernel-2.6.26用) / via-velocity-fixed-wol.patch
2. velocityget の procエントリのリークフィックパッチ / velocityget-fixed-proc.patch

via-velocity単体で再構築

via-velocity 単体だけでも再構築できるようにしてみよう。ターゲットは、Debian lenny の 2.6.26-2-686 向けだが、他のディストロでも応用可能かなぁ。

# apt-get install linux-headers-2.6.26-2-686
# apt-get install linux-source-2.6.26

構築用ソースのかき集め

1. 適当にでっち上げた Makefile / Makefile-via-velocity-only
2. linux-source-2.6.26 パッケージからvia-velocity.[hc]

# mkdir via-velocity
# cp Makefile-via-velocity-only via-velocity/Makefile
# cp /usr/src/linux-source-2.6.26/drivers/net/via-velocity.[ch] via-velocity/
# patch -p 3 -d via-velocity < via-velocity-fixed-wol.patch

あとは再構築してモジュールをインストール。

# cd via-velocity
# make install
make -C /lib/modules/2.6.26-2-686/build SUBDIRS=/usr/src/via-velocity modules
make[1]: ディレクトリ `/usr/src/linux-headers-2.6.26-2-686' に入ります
  CC [M]  /usr/src/via-velocity/via-velocity.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /usr/src/via-velocity/via-velocity.mod.o
  LD [M]  /usr/src/via-velocity/via-velocity.ko
make[1]: ディレクトリ `/usr/src/linux-headers-2.6.26-2-686' から出ます
mkdir -p /lib/modules/2.6.26-2-686/kernel/drivers/net
*****  Move current driver via-velocity.ko to via-velocity.ko.2009-09-24-1253781710 file
mv /lib/modules/2.6.26-2-686/kernel/drivers/net/via-velocity.ko /lib/modules/2.6.26-2-686/kernel/drivers/net/via-velocity.ko.2009-09-24-1253781710

install -m 644 -o root via-velocity.ko /lib/modules/2.6.26-2-686/kernel/drivers/net
/sbin/depmod -a || true

最後に rmmod/modprobe してモジュールを更新して完了。

これで機能的には同程度になったので、性能比較でもしますかぁ。

追記 (2009/09/26)

どうも via-velocity には、ネットワーク負荷が高いときにシステムが黙りをする症状(1,2 等々)？が報告されている。velocityget を使えば症状が出ないので、velocitygetを使うべしとなってるらしい。。。

ソースを見比べると、割り込みハンドラ内の処理が問題のようだ。それぞれは、大まかに次のようになっている。

• via-velocity
  1. 未処理の割り込み要因がなくなるまでループする
  2. ループの一単位は、受信/送信ディスクリプタをそれぞれ最大15ディスクリプタ分を処理する
  3. 処理したディスクリプタ数が int_works を超えたらメッセージを出力する
• velocityget
  1. 受信/送信ディスクリプタをそれぞれ最大int_worksディスクリプタ分を処理する
  2. 上記の処理を２回繰り返す

要するに via-velocity では int_works の取り扱いが杜撰で、かつネットワーク負荷が高いと割り込みハンドラ内に捕われてしまう。なので、割り込みを共有してるデバイスの処理が滞る症状が現れる。

他のネットワークチップのドライバーを見る限り、割り込みハンドラ内で全部のディスクリプタを処理せずに抜ける実装は多々有るので、バグなんだろうなぁ。

うんで、修正パッチを作ってみた

1. via-velocity の int_works 関連の修正パッチ (debian lenny/kernel-2.6.26用) / via-velocity-fixed-int_works.patch

上のWOL対応パッチの後に当てればいい

# tar xfz via-velocity-buildpack-nosrc.tgz
# cp /usr/src/linux-source-2.6.26/drivers/net/via-velocity.[ch] via-velocity/
# patch -p 3 -d via-velocity < via-velocity-fixed-wol.patch
# patch -p 3 -d via-velocity < via-velocity-fixed-int_works.patch
# cd via-velocity
# make install

これで、本当に不具合が無い状態？になったので、性能比較でもしますかぁ。

追記 (2009/09/29)

どうも via-velocity-fixed-int_works.patch の velocity_tx_srv の修正部分がバグってたみたいだ。なので、修正版に差し替えました。申し訳ない。

Time Machine を iSCSI 経由で使う (3) - 性能比較

ボリュームをiSCSIの載せたときの性能と、IPSecで保護した場合やWiFi経由にした場合の性能劣化を測定してみた。

設定条件

接続の経路に結構余分な機器が挟まっているが、 測定用に別環境は用意していないためである。 実環境ベースと考えて勘弁してもらいたい。

Linux ターゲット側

• ASUS M2NPV-VM / Athlon64X2 3800+ (2GHz) / DDR2-533 1G x 4
• onboard Gigabit Ethernet (nVidia MCP51)を利用。

Mac OSX のイニシエータ側

• MacBookPro5,1 / Intel Core 2 Duo / 2.4 GHz / DDR3-1066 2G x 2
• onboard Gigabit Ethernet / AirMac(WiFi) を利用。
• Wifi経由では 802.11n/WPA2でアクセスポイントに接続

接続形態

• ローカルHDD
  MacBookPro
  ⇔ ExpressCard(GH-EXC-ESA2/eSATA接続) ⇔ HDDケース(LHR-DS02SAU2BU) ⇔ HDD
• 有線ネットワークでは
  MacBookPro
  ⇔ Gigabit Hub(LSW-GT-8NSR)
  ⇔ Gigabit Hub(GS908M) ⇔ Gigabit Hub(GS908M)
  ⇔ Linux マシン(SATA接続) ⇔ HDD
• Wifi経由では
  MacBookPro
  ⇔ AirMac Extreme (2007モデル？有線100Baseの奴)
  ⇔ Gigabit Hub(GS908M) ⇔ Gigabit Hub(GS908M)
  ⇔ Linux マシン(SATA接続) ⇔ HDD

測定したHDD

• SATA 320G HDD(ST3320620AS)
• 3.0Gbps が有効になる用にジャンパー設定
• iSCSI／ローカル接続でも同じモデルを利用

測定結果

		ローカルHDD	GigaEther	Wifi経由	GigaEther	Wifi経由
			IPSec 無		IPSec 有
Sequential	Uncached Write [4K blocks]	58.19	60.51	5.34	13.15	5.48
	Uncached Write [256K blocks]	47.58	50.82	7.33	12.65	4.72
	Uncached Read [4K blocks]	16.16	6.02	1.46	4.75	1.38
	Uncached Read [256K blocks]	75.55	28.86	3.39	15.86	4.90
Random	Uncached Write [4K blocks]	1.25	1.36	1.32	1.35	1.26
	Uncached Write [256K blocks]	26.19	24.37	6.19	13.10	6.93
	Uncached Read [4K blocks]	0.64	0.61	0.45	0.58	0.43
	Uncached Read [256K blocks]	26.68	23.66	3.21	11.17	4.63

測定単位は全て MByte/sec

ゴタク

iSCSI を有線／noIPSec で通す場合、シーケンシャル読込み以外はほとんど劣化が無い。 シーケンシャル読込みはキャッシュがほとんど効かない為か、iSCSIターゲット実装の良し悪しが出ていると思う。 また、チューニングを実施せずにデフォルト設定にしているので、それも影響しているのかも。

IPSec で保護すると、約120Mbps (15Mbyte/sec) 程度で頭打ちになっている。IPSec の実効帯域と思われる。Gigabit Ethernet なのに帯域が一割程度とはちょっと情けない。IPSec 固有の問題か、Linux の実装の問題か、iSCSI との組み合わせか、判然としない。何処に文句を言っていいのか分からない。

iSCSI を無線にした場合は、大きな問題は経路の帯域である。iSCSIとか、IPSec の有無とかは、もはや問題ではない。周囲の電波状況によって影響を受けるが、WPA2で50Mbpsくらいは流れるので良いのかなぁ。

結論

iSCSIをIPSecで保護することは、 無線を使って Time Machine でバックアップすることには殆ど影響しないと言えそうだ。 また、差分は一時間に一度であり、有線であっても約 120Mbps 程度の帯域を確保できることを考えると、 目くじらを立てるものではないのかなぁ。

Time Machine を iSCSI 経由で使う (2) - IPSecで保護

iSCSI はブロックデータが Network 上に流れるので気を付けなくはいけない。 専用のネットワークかVLANとかを組むのが定石らしいが、そうでない場合 IPSec が使うのが望ましいらしい。

設定が面倒で、大抵ノーガードですなぁ。

MacOSX でも普通にIPSecが使えるので、iSCSI のデータのみを保護する設定をしてみよう。

IPSec の設定内容

1. Linux と Mac OSX の相互にIPSec接続をする。
2. 既に iSCSI の設定が済んでおり、Linux側のiSCSIターゲットボリュームをMacOSX側のiSCSIイニシエータからマウントできる。
3. IPSec はトランスポートモードで使い、iSCSI のデータ(3260/tcp)に限定する。
4. IKE デーモンは racoon (IKEv1) を使う。
5. 認証は事前共有秘密鍵／aggressive mode を使う。
6. 暗号はAES/SHA1をなるべく使う。

	役割	IPアドレス	ホスト名
Linux 側	iSCSIターゲット	192.168.0.10/24 (固定)	server1
MacOSX 側	iSCSIイニシエータ	192.168.0.20/24	client1

SADの設定

基本的に、上りと下りのそれぞれで、サーバ側のIPアドレスとポート番号を指定すれば、iSCSI通信のみに限定できる。クライアント側は、DHCP等で振れる事を考えて範囲指定にする。

BSDの実装では PF tag なるものがあり「spdadd tagged」と組み合わせてフィルタルールに溶け込ませる事ができるそうなのだが、Linux側では同等の機能が実装されていないようなので残念ですなぁ。。。

Linux ターゲット側

# apt-get install ipsec-tools

/etc/ipsec-tools.conf

...
flush;
spdflush;

spdadd 192.168.0.10[3260] 192.168.0.0/24 tcp -P out ipsec esp/transport//require;
spdadd 192.168.0.0/24 192.168.0.10[3260] tcp -P in ipsec esp/transport//require;

Mac OSX のイニシエータ側

MacOSXでは、setkey 用の設定ファルの置き場がデフォルトでは用意されていないので、適当な場所に保存して、起動時に setkey コマンドで読み込み必要がある。

/etc/racoon/setkey.conf

flush;
spdflush;

spdadd 192.168.0.0/24 192.168.0.10[3260] tcp -P out ipsec esp/transport//require;
spdadd 192.168.0.10[3260] 192.168.0.0/24 tcp -P in  ipsec esp/transport//require;

racoonの設定

Linux/MacOSX ともに、racoon を使うので設定ファイル racoon.conf の内容はほぼ同じになる。ただし、事前共有秘密鍵ファイル psk.txt は、同じ鍵をそれぞれの相手側のものとして書く必要があり、ちょっと注意が必要。

Linux ターゲット側

/etc/racoon/racoon.conf

...
remote anonymous {
	exchange_mode aggressive,main;
	my_identifier fqdn "server1";	# サーバの認識情報
	dpd_delay 20;

	proposal {
		encryption_algorithm 3des;
		lifetime time 2 hour;
		hash_algorithm sha1;
		authentication_method pre_shared_key;
		dh_group 2;
	}
	generate_policy off;
}

sainfo anonymous {
	pfs_group 2;
	lifetime time 1 hour;
	encryption_algorithm aes, 3des;
	authentication_algorithm hmac_sha1;
	compression_algorithm deflate;
}

/etc/racoon/psk.txt

...
client1	secret1

Mac OSX のイニシエータ側

他にVPNなど IPSec を使うものと衝突する可能性がある気がしないでも無い。。。anonymous の部分をアドレス指定しれば、行けそうな気がするが。。。未検証。

/etc/racoon/racoon.conf

...
remote anonymous {
	exchange_mode aggressive,main;
	my_identifier fqdn "client1";	# クライアントの認識情報
	dpd_delay 20;

	proposal {
		encryption_algorithm 3des;
		lifetime time 2 hour;
		hash_algorithm sha1;
		authentication_method pre_shared_key;
		dh_group 2;
	}
	generate_policy off;
}

sainfo anonymous {
	pfs_group 2;
	lifetime time 1 hour;
	encryption_algorithm aes, 3des;
	authentication_algorithm hmac_sha1;
	compression_algorithm deflate;
}

/etc/racoon/psk.txt

...
server1	secret1

racoonは自動に起動しないので、適当名タイミングで起動する必要はある。

% sudo setkey -f /etc/racoon/setkey.conf
% sudo racoon

自動起動するには、「マスタリングIPsec 第2版」に記述の方法が簡単である。

確認

IPSec はアプリケーション側の修正の必要の無い物なので、、、普通にボリュームをマウントすると普通に使える。

まぁ気休めに、IPSec_SAをチェックすれば、

# setkey -D
192.168.0.20 192.168.0.10 
	esp mode=transport spi=131341201(0x07d41b91) reqid=0(0x00000000)
	E: aes-cbc  8250b455 59cc8799 c0d0b0b0 71b570a8
	A: hmac-sha1  6ff81843 b28130ed a5722694 32b134ee a0fc5b96
	seq=0x00000000 replay=4 flags=0x00000000 state=dying 
	created: Sep  8 14:51:43 2009	current: Sep  8 15:40:54 2009
	diff: 2951(s)	hard: 3600(s)	soft: 2880(s)
	last: Sep  8 14:51:45 2009	hard: 0(s)	soft: 0(s)
	current: 50750612(bytes)	hard: 0(bytes)	soft: 0(bytes)
	allocated: 49393	hard: 0	soft: 0
	sadb_seq=1 pid=1233 refcnt=0
192.168.0.10 192.168.0.20 
	esp mode=transport spi=17664308(0x010d8934) reqid=0(0x00000000)
	E: aes-cbc  5d2d422b fe916f6d 501fedce e3d9650d
	A: hmac-sha1  6cfbf657 2eb74cb3 b64b5074 e34148b9 7bcaf934
	seq=0x00000000 replay=4 flags=0x00000000 state=dying 
	created: Sep  8 14:51:43 2009	current: Sep  8 15:40:54 2009
	diff: 2951(s)	hard: 3600(s)	soft: 2880(s)
	last: Sep  8 14:51:45 2009	hard: 0(s)	soft: 0(s)
	current: 2142076(bytes)	hard: 0(bytes)	soft: 0(bytes)
	allocated: 26881	hard: 0	soft: 0
	sadb_seq=2 pid=1233 refcnt=0

ついでに tcpdump でサーバ側のパケットの流れを見れば、ESPパケットが飛び交ってるのが見える。。。

# tcpdump -i eth0 not port 22
...
15:38:24.183860 IP client1 > server1: ESP(spi=0x07d41b91,seq=0xc0ba), length 116
15:38:24.184162 IP server1 > client1: ESP(spi=0x010d8934,seq=0x68e6), length 116
15:38:24.184625 IP client1 > server1: ESP(spi=0x07d41b91,seq=0xc0bb), length 68
15:38:27.186886 IP client1 > server1: ESP(spi=0x07d41b91,seq=0xc0bc), length 116
...

まとめ

SADの設定をちまちま行えば、他の通信もIPSecで保護が出来そうである。気になるのは、パフォーマンスがどこまで劣化するかなのだが。。。あまり期待は出来ないのかなぁ。。。

Time Machine を iSCSI 経由で使う (1) - 設定

Leopard から実装された Time Machine は非常に使い易い。 ただ、常にノートブックに外付けのHDDをぶら下げるのは、可搬性が損なわれる。 Time Capsule を使えば良いのだが、約10M Byte/s 位しか出ないらしい。

どうも iSCSI 経由で外部ストレージを繋げてバックアップ先に指定すれば、いい感じになれるらしい。

最近 Linux でよく使われているターゲットは「iSCSI Enterprise Target」であり、Debian lenny からカーネルモジュールもパッケージ化されており、apt 一発で使える。また、ストレージ層は Linux に依存しており、フォーマット縛りが無い。そのため、HDD単体をiSCSI経由で接続して使っていた場合、そのHDDをUSB等の変換アダプタで直に接続しても、そのままで使える利点がある。

Mac OSX のイニシエータは標準では用意されていないが、サードベンダー製の「globalSAN iSCSI Initiator for OS X」が無料で制限なしで利用できる。

コイツらを組み合わせると、Time Machine の初期化やリカバリ時だけマシンに直付けして、差分バックアップ運用時はiSCSI経由で行う事が出来る。

Linux で iSCSI target 設定

設定の内容は、

1. お手軽な単方向CHAP認証を使い、ユーザ名 iscsiadmin ／パスワードは12～16文字の適当な文字列にする。
2. IQN(ISCSI Qualified Name)は iqn.YYYY-MM.domainなんたらをユニークになるように適当に付ける。
3. デバイスの名前に関しては、固定される用に /dev/sd? ではなく /dev/disk/by-id/? を使う。
4. イニシエータ制限をサブネット範囲でかけておく。

Debian lenny にバイナリパッケージが用意されている。

# apt-get install iscsitarget iscsitarget-modules-2.6-amd64

/etc/default/iscsitarget

ISCSITARGET_ENABLE=true

/etc/ietd.conf

IncomingUser iscsiadmin 123456789012

Target iqn.2009-09.com.example:stroage.fileserver.timemachine
	IncomingUser iscsiadmin 123456789012
	Lun 0 Path=/dev/disk/by-id/scsi-XXXXXX,Type=blockio

/etc/initiators.allow

ALL xx.xx.xx.xx/24

うんで、/etc/init.d/iscsitargt start で、iSCSI ターゲットのサービスを有効化する。

Linux の Open-ISCSIを使って確認

適当な iSCSI イニシエータが必要なので、Open-iSCSI を設定して確認する。

# apt-get install open-iscsi

/etc/iscsi/iscsid.conf

...
node.session.auth.authmethod = CHAP
node.session.auth.username = iscsiadmin
node.session.auth.password = 123456789012
...
discovery.sendtargets.auth.authmethod = CHAP
discovery.sendtargets.auth.username = iscsiadmin
discovery.sendtargets.auth.password = 123456789012
...

うんで、/etc/init.d/open-iscsi start で、iSCSI イニシエータのサービスを有効化する。

取り敢えず、検索すると

# iscsi_discovery xx.xx.xx.xx
iscsiadm: No active sessions.
Set target iqn.2009-09.com.example:stroage.fileserver.timemachine to automatic login over tcp to portal xx.xx.xx.xx:3260
Logging out of session [sid: 5, target: iqn.2009-09.com.example:stroage.fileserver.timemachine, portal: xx.xx.xx.xx,3260]
Logout of [sid: 5, target: iqn.2009-09.com.example:stroage.fileserver.timemachine, portal: xx.xx.xx.xx,3260]: successful
discovered 1 targets at xx.xx.xx.xx

何となく、ターゲットが発見できる。

ついでに、ノードに接続して確認すると

# iscsiadm -m node -p xx.xx.xx.xx -l
Logging in to [iface: default, target: iqn.2009-09.com.example:stroage.fileserver.timemachine, portal: xx.xx.xx.xx,3260]
Login to [iface: default, target: iqn.2009-09.com.example:stroage.fileserver.timemachine, portal: xx.xx.xx.xx,3260]: successful
# cat /proc/scsi/scsi
...
Host: scsi27 Channel: 00 Id: 00 Lun: 00
  Vendor: IET      Model: VIRTUAL-DISK     Rev: 0   
  Type:   Direct-Access                    ANSI  SCSI revision: 04
...
# iscsiadm -m node -p xx.xx.xx.xx -u
Logging out of session [sid: 7, target: iqn.2009-09.com.example:stroage.fileserver.timemachine, portal: xx.xx.xx.xx,3260]
Logout of [sid: 7, target: iqn.2009-09.com.example:stroage.fileserver.timemachine, portal: xx.xx.xx.xx,3260]: successful

まぁ、ディスクが見える！

Mac OSX 上での設定

globalSAN iSCSI Initiator for OS Xから、パッケージをインストールして再起動し、GUIに従って設定すれば良い。

1. 「システム環境設定」から「globalSAN iSCSI」を選択
2. 「Portals」タブで、ターゲットマシンのIPを追加する。このとき、「Advanced Settings」で、CHAP認証を有効にして、User Name/Target Secret をISCSIターゲットで設定したものにする。
3. 「Targets」タブにISCSIターゲットのIQNが見えるようになる。
4. ISCSIターゲットのIQNを選択して「Log On」をする。
5. 後の扱いはローカル接続のHDDと同じで、必要に応じて「ディスクユーティリティ」で初期化する。

Time Machine の設定は、ローカル接続のHDDと同じような扱いで、HFS+のボリュームを作って指定すれば普通に使える。。。快適じゃぁ。。。

NFS サーバ側でUTF8 NFD ⇔ UTF8 NFC の変換はできるのか？

MacOSX で Unicode が全面的にサポートされている。その中で一番分からないのは、ファイル名が UTF8 NFD (Normalization Form Decomposition) で正規化されていることである。詳しく言えば NFD をベースにした微妙に異なるルールらしい(1, 2)。その結果なのか知れないが UTF-8-MAC と呼ばれることが多い。

Linux 界隈でサポートされる UTF8 は NFC で正規化されると言われている。ただし、正規化処理が為された結果ではなく、専ら合成済みの文字のみを扱っている結果として、UTF-8 NFC なんだと思う。 Windows とおんなじ理由と思う。

根拠は全くない。

Linux というより上位のフレームワーク／アプリケーション(Gnome,KDE 等)の扱いの問題なんだと思う。

UTF8 の正規化の問題は、Samba や netatalk では対応が進んでおり、運用上問題が出ないレベルまで押さえ込むことができるそうなぁ。

NFS に関しては、どっかで議論されている?だろうが、一般的な運用まで下りてきていない。

現状は、

1. MacOSX はファイル名を UTF-8-MAC にして、NFSサーバに送っている。
2. 一般的な NFS サーバは、ファイル名の変換を行わずに、ローカルなファイルシステムに送る。
3. ローカルなファイルシステムも、ファイル名の変換を行わず、ディスクに記録される。
4. MacOSX が作成したファイル名は UTF-8-MAC (NFD) で正規化されており、UTF8 NFC と異なるバイト列だった場合、Linux のNFSクライアントで不整合が発生する。

ローカルな記録をUTF-8-MAC に変えたり、NFS は諦めたり、MacOSX の対応が進まないか祈ってみたり、四苦八苦である。

NFSの実験

どうしたもんかなぁと思いつつ、ちょっとだけ実験することにした。

NFSサーバに以下の機能があればいいのかなぁ

1. クライアントからのファイル名をUTF8 NFC に正規化する。
2. クライアントに応じて、正規化方法を選択して、ファイル名をその正規化をして返す。

NFS のファイル名は変換しても大丈夫なんだろうか？とか疑問だが、一番最低限の実装を作ってみた。

1. 検証するNFSサーバの実装は unfs3 を使う。従って、NFSv3 が対象。
2. NFS プロトコールのみで、NFS の MOUNT プロトコールは手をつけない。
3. NFD <=> NFC の変換は、かなの濁音・半濁音に限定する。
4. クライアントの区別をせずに常に変換する。
5. NFD => NFC の変換が行われるのは、LOOKUP / CREATE / MKDIR / SYMLINK / MKNOD / REMOVE / RMDIR / RENAME / LINKの引数内のファイル名とSYMLINKの引数内のシンボリックデータ。
6. NFC => NFD の変換が行われるのは、READDIRの返答内のファイル名。

unfs3-0.9.20.utf8mac-20080305.patch.txt

検証方法

Linuxでは カーネルベースのNFSを使いつつ検証が出来するのが通なんだろうなぁ。

サーバ側(fserver)でパッチを当てた unfs3 のバイナリを作っておく。

# UNFSD=/usr/src/unfs3-0.9.20.utf8mac/unfsd   <-- パッチ済みバイナリ
# EXPORTS=/etc/exports_test                   <-- テスト用の exportsファイル
# ${UNFSD} -d -u -p -n 44000 -m 44100 -e ${EXPORTS}

/etc/exports_test

/export/share 192.168.0.23(rw,no_root_squash)

MacOSX 側(192.168.0.23)でマウント

# mkdir /Volumes/unfs
# sudo mount -omountport=44100,port=44000 fserver:/export/share /Volumes/unfs

結び

濁点・半濁音だけだが変換が行われて、MacOSX から普通に扱える。。。

まぁ、いろいろ試したいことが思い浮かぶので、ちまちま実験していくかなぁ。

FreeBSD でコケる。でも立ち上がる。

向学のために VMware 上に FreeBSDをインストールしてみていたが、amd の設定で不明なエラーが出て詰まっていた。

# /etc/rc.d/amd start
# amq
amq: localhost: RPC: Port mapper failure - RPC: Unable to send
# dmesg
...
nfs send error 49 for server pid473@freebsd:/home
nfs server pid473@freebsd:/home: not responding
...

Google先生に聞くと、そんな例が出てくるが、結局うやむやに解消されている、、、。

ふと気付いた。

ホスト名を指定すると、amqがマトモな返事を返してくれる！

# amq -h freebsd
/      root    "root"         freebsd:(pid473)
/home  toplvl  /etc/amd.home  /home

熟考の結果、ループバックインタフェースにIPv4のアドレス127.0.0.1が付いていなかった。。。

# ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
    inet6 ::1 prefixlen 128

原因はインストール直後のネットワーク設定をテキトウに書いたため。

/etc/rc.conf

...
network_interfaces="lo0 lnc0"
...

設定を変更して、再起動。。。ちゃんと動く。。。ばかぁ

Leopard の ssh の Kerberos認証の不具合？

ssh の公開鍵認証はいい。

ただ、ホームディレクトリを automount で Kerberos化した NFS をマウントする場合は利用できない。 そんなあなたのために ssh+GSSAPI+Kerberos を使うといい。

sshd_config と.ssh/config に下記設定をする。

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

あら不思議、チケットを持っていたら、認可され、チケットが転送されて、証明書キャッシュに保存され、Kerberos化されたNFSサービスがよろしくアクセスできる。

サーバ側がLeopard だと、認可され、チケットが転送され、何故か証明書キャッシュには保存されない。なので、Kerberos化されたNFSサービスは使えない。。。

で、再度チケットを取得するとKerberos化されたNFSが使えるようになる。

なんか設定が足らんのか、そのうち直るかなぁ。。。

これが振る舞いが無ければ automountMap を Solarisと共存できるのに、、、。

でも、MacOSXで sec=krb5/krb5i/krb5p が使えるようになったのって凄いっすね。UNIX認定を受けた恩恵か！？

NFSv4とKerberosを組み合わせる

どうもNFSはパケットだだ漏れ、認証もへったくれもない、スピード狂のネットワークファイルシステムのイメージは拭えない。ただ、Linux のNFSv3では AUTH_SYSぐらいしか使えなかった(使わなかった？)のも大きいかも。

NFSv3 から NFSv4 への移行に合わせて、まともなKerberos認証を組み合わせてみた。 丁度、OpenDirectory にはもれなく、即運用可能なKerberosサーバ群がついてくるので、、、。

前提として

• NFS サーバ／クライアントは、Fedora2以上／CentOS4以上である。
• NFS サーバ／クライアントになるマシンのKerberos のクライアント設定(/etc/krb5.conf)が完了してる。
• NFS サーバ／クライアントにはユーザアカウント情報がある。
  • /etc/passwd ファイル内であれ、LDAPサーバ上であれ、あればいい。

参考

• Using NFSv4
• Kerberos 5 setup for NFSv4
• Kerberos/LDAP/NFSv4 HOWTO
• NFSv4 Testing for Linux
• NFSv4

NFSv4 のドメイン設定

NFSサーバ／クライアントの両方で、下記ファイルを編集してrpcidmapdを再起動

/etc/idmapd.conf

...
Domain = example.com
...

nfs用のサービスプリンシパルの登録

KDCにNFSサーバ／クライアントのサービスプリンシパルの登録し、それぞれをkeytabに保存。暗号化／ソルトをdes-cbc-crc:normal に限定するのがミソらしい。

# kadmin -p diradmin
Authenticating as principal diradmin with password.
Password for diradmin@EXAMPLE.COM:
kadmin: add_principal -randkey nfs/server1.example.com@EXAMPLE.COM
...
kadmin: add_principal -randkey nfs/client1.example.com@EXAMPLE.COM
...
kadmin: ktadd -k /tmp/server1.keytab -e des-cbc-crc:normal nfs/server1.example.com@EXAMPLE.COM
...
kadmin: ktadd -k /tmp/client1.keytab -e des-cbc-crc:normal nfs/client1.example.com@EXAMPLE.COM

できた keytab をそれぞれのマシンの /etc/krb5.keytab にコピーする

rpc.gssd を有効化

/etc/sysconfig/nfs

...
SECURE_NFS=yes
...

で起動。

# /etc/init.d/rpcgssd start
...
# ps `pidof rpc.gssd`
  PID TTY      STAT   TIME COMMAND
 2644 ?        Ss     0:16 rpc.gssd
#  lsmod | grep rpc
rpcsec_gss_krb5        12873  7
auth_rpcgss            42465  4 rpcsec_gss_krb5
sunrpc                142973  10 nfs,lockd,nfs_acl,rpcsec_gss_krb5,auth_rpcgss

ただし、Fedora2だけは事前に rpcsec_gss_krb5 をロードしておく必要がある。。。どうでもいいけど。

NFSv4 のサーバの設定

/etc/exports

/srv/nfs4       gss/krb5(rw,sync,fsid=0,crossmnt,insecure,no_subtree_check)
/srv/nfs4       gss/krb5i(rw,sync,fsid=0,crossmnt,insecure,no_subtree_check)
/srv/nfs4       gss/krb5p(rw,sync,fsid=0,crossmnt,insecure,no_subtree_check)

/srv/nfs4/home       gss/krb5(rw,sync,insecure,no_subtree_check)
/srv/nfs4/home       gss/krb5i(rw,sync,insecure,no_subtree_check)
/srv/nfs4/home       gss/krb5p(rw,sync,insecure,no_subtree_check)

適当にディレクトリを作成して、nfsを起動

# mkdir -p /srv/nfs4/home
# mount --bind /path/to/home /srv/nfs4/home
# /etc/init.d/nfs restart
...
# exportfs
/srv/nfs4/home  gss/krb5
/srv/nfs4/home  gss/krb5i
/srv/nfs4/home  gss/krb5p
/srv/nfs4       gss/krb5
/srv/nfs4       gss/krb5i
/srv/nfs4       gss/krb5p

クライアントでNFSv4のマウント

これで最後で root 権限で

# mount -t nfs4 -o sec=krb5 server1:/home /mnt
# mount | grep home
server1:/home on /mnt type nfs4 (rw,sec=krb5,addr=XX.XX.XX.XX)

一般ユーザでKerberosレルムに認証されている状態であれば、NFS上のファイルが触れる。。。

# su - user1
% klist -5
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_5002)
% ls /mnt
ls: cannot access /mnt: Permission denied
% kinit
Password for user1@EXAMPLE.COM:
% klist -5
Ticket cache: FILE:/tmp/krb5cc_5002
Default principal: user1@EXAMPLE.COM

Valid starting     Expires            Service principal
11/16/07 03:34:16  11/16/07 13:34:16  krbtgt/EXAMPLE.COM@EXAMPLE.COM
    renew until 11/17/07 03:34:17
11/16/07 03:34:20  11/16/07 13:34:16  nfs/server1.example.com@EXAMPLE.COM
    renew until 11/17/07 03:34:17
% ls /mnt
lost+found user1 user2 user3
% touch /mnt/user1/a
% ls -l /mnt/user1/a
-rw-r--r-- 1 user1 users 0 Nov 16 03:34 /mnt/user1/a

以上。

あぁ忘れていた。

とりあえずSELinux が有効になってる場合、いろんなアクセスが阻止されるので、Disabled か Permissive にした方がよい。。。SELinux めぇ！

追記

Open Directory の設定のまとめ 2008Q1

netatalk で Kerberos 認証

だいぶ前に設定できたのだが備忘として書いておこう。

Debian/etch 環境の netatalk は DHX認証のプラグインが含まれていないので、GSSAPI 経由で Kerberos v5 を使う。

前提として、

• netatalkサーバはクリアテキスト認証でのファイル共有が可能
• Kerberos のクライアント設定(/etc/krb5.conf)が完了してる。
  • ユーザは既に特定のレルムからKerberos のチケットが入手できる。
  • netatalk サーバが動いてるマシンのデフォルトのレルムが上と同じ。でもサービスプリンシパルの登録はしていない。

使っている Open Directory だと MIT Kerberos なので、kadminはそれようなのを使うべし。

kadmin で管理者でログインして、サービスプリンシパルを登録して、そのサービスプリンシパルが入った keytab を作成する。

# kadmin -p diradmin
Authenticating as principal diradmin with password.
Password for diradmin@EXAMPLE.COM:
kadmin:  addprinc -randkey afpserver/machine.example.com@EXAMPLE.COM
...
kadmin: ktadd -k /tmp/krb5.keytab afpserver/machine.example.com@EXAMPLE.COM

できた keytab をマシンの /etc/krb5.keytab にコピーする。別のサービスプリンシパルがあれば、ktuil とかで追加すると吉。

認証方法の指定を /etc/default/netatalk では行わず、afpd.conf から行うようにする。

/etc/default/netatalk

...
AFPD_UAMLIST=""
...

/etc/netatalk/afpd.conf

...
- -tcp -uamlist uams_gss.so -k5service afpserver -k5keytab /etc/krb5.keytab -k5realm EXAMPLE.COM -fqdn machine.example.com:548
...

Linux でもローカルKDC?とでのKerberos認証が提供されるのだろうかねぇ。

追記

Open Directory の設定のまとめ 2008Q1

Leopard が netatalk サーバを自動的に見つられる設定

Leopard は、いい意味でも悪い意味でも、過去の遺産をばっさり切り捨てたツンなOSである。

SLP によるサービス検索機能がなくなってしまったらしく、 netatalk は AFPサーバ機能を SLP 通知しているので見つけられなくなってしまったらしい。

そんな人は、avahi を使えとか言われるが、設定方法があまり載っていない。。。

Debian/etch だと avahi-daemon は設定が何もなく？困るし。。。

avahi でサービスを通知する方法

ドキュメントを読めばよく、sshサービスのサンプルもついてくる。

/etc/avahi/services/ssh.services

<?xml version="1.0" standalone='no'?>
<service-group>
<name replace-wildcards="yes">Remote Terminal on %h</name>
    <service>
        <type>_ssh._tcp</type>
        <port>22</port>
    </service>
</service-group>

avahi-daemon を再起動させると、Leopard の「ターミナル」の「新規リモート接続」のリストに自動的に追加される。

netatalk を通知するには、AFPのサービスタイプ（http://www.dns-sd.org/ServiceTypes.html を参考）を指定して、

/etc/avahi/services/afp.services

<?xml version="1.0" standalone='no'?>
<service-group>
<name replace-wildcards="yes">%h</name>
    <service>
        <type>_afpovertcp._tcp</type>
        <port>548</port>
    </service>
</service-group>

ついでに Samba と区別ができなくなるので、

/etc/avahi/services/smb.services

<?xml version="1.0" standalone='no'?>
<service-group>
<name replace-wildcards="yes">Samba on %h</name>
    <service>
        <type>_smb._tcp</type>
        <port>139</port>
    </service>
</service-group>

Finder のサイドバーの共有のリストに、samba/netatalk のエントリが追加され、ちょっといい感じになります。

追記

Open Directory の設定のまとめ 2008Q1

OpenDirectory で Feodra/CentOSを 認証

Open Directory を立ち上げるのは非常に簡単である。 例えば、インストールするとき標準構成とかを選べば、勝手に OpenDirectory のマスターが出来上がるし、それ以外の構成でもGUIのツールを使い、LDAPの基本DNやKerberosのrealm名を指定して数クリックで完了する。

これだけで、LDAPサーバとKerberosサーバ群が直に使える状態になるのは、なんというか、、、楽だ。

CentOS5/Fedora7 の認証

authconfig を使えば、簡単にできる。同様なGUIの管理ツールauthconfig-gtk があるのでこっちを使ってよいかも。

• ユーザ情報には、LDAPサポートを有効にして、LDAPの設定情報に OpenDirectory の検索ベースとIPアドレスを指定する。
• 認証には、Kerberosサポートを有効にして、Realm /KDC/管理サーバに、OpenDirectoryのKerberos領域とIPアドレスとポート番号(KDCは88/管理サーバ749)を指定する。

上記に設定で書き換わるのは、次のファイル群なので面倒な問題が起きた場合これらのファイルを眺めればいい。

• /etc/nsswitch.conf
• /etc/krb5.conf
• /etc/pam.d/system-auth
• /etc/ldap.conf

大体、RedHat7くらいから同様な設定で行けたみたいだ。。。知らんかった。。。(RedHat6.2とかだともう一捻りが必要だ、、、多分知らんでもいいと思う。)

２つ問題点

Open Directory から提供されるうち基本的な部類の情報に プラットホーム依存なものがある。

• ログインシェル
• ホームディレクトリ

どのプラットホームに共通してあるシェルは、/bin/sh と /bin/csh くらいだが、bash がなければ別途パッケージをいれ、/bin/bash にシンボリックリンクを張れば、/bin/bash を指定できるので、大した問題では無い。

残るのは、ホームディレクトリをどうするねん。。。 ネットワークファイルシステムはどれにするとか、 オートマウントを使うか使わないかとか、、、それはプラットホーム依存ばりばりなんだなぁ。。。

で、Leopard で実装された autofs がLDAPからマップ情報をとれるので、これは面白いことになってきたって話。。。。(続く)

追記

Open Directory の設定のまとめ 2008Q1

Linux クライアントからIPSec Tunnel接続をする

昨日からの続きで、IPSec-VPNにLinuxクライアントで繋いでみる。

まぁ、Linuxでもやりたいことは、

Develop Domain:192.168.1.0/24
<---->
192.168.1.1:ルータ:XX.XX.XX.XX
<==[IPSec Tunnel]==>
YY.YY.YY.YY:クライアントPC:192.168.150.201/32

な感じだけども、、、 参考なるそうなページを検索すれど、IPSec トランスポートモードだったり、ルータ間のIPSecトンネルだったり、PPTP使っていたりと、イマイチよさげな情報は無し。

基本から組み立てて行かねばなんないのかぁ。

IPSecとは AH + ESP + IPcomp + IKE だそうだが、使う側が理解すべきなのはもっとある。難解なのはウサギとカメの陰謀だと思う。

• IPSec を利用する通信はどれかを Security Policy Database (SPD)で指定する。このとき transport/tunnel モード等も指定する。
• IPsec を利用する通信のセキュリティパラメータをSecurity Association Database(SAD)で指定する。暗号化方法や鍵等が含まれる。
• SPD は setkey ツールで指定する。
• SAD は setkey ツールを使って手動で指定していできるが、大抵はIKEを利用する。racoonやisakmpd とかのIKEデーモンを使って自動的に指定する。
• IKEを利用する場合は、事前共有鍵、PKI、Kerberosとかの認証とSAの種別を指定する。

順番に設定すれば良いのだが一番悩むのはIPSecを利用する通信をどう作るのか？

何？禅問答みたいなこと言っているのだろう？

俺もそう思う。

ルータ間の接続では、

Develop Domain:192.168.1.0/24
<---->
192.168.1.1:ルータA:XX.XX.XX.XX
<==[IPSec Tunnel]==>
YY.YY.YY.YY:ルータB:192.168.2.1
<---->
Outer Domain:192.168.2.0/24

になっているので、ルータB 上を通過する通信 192.168.1.0/24 <=> 192.168.2.0/24 が発生させることはそんなに難しいことではない。ルータBがOuter Domainのデフォルトゲートウェイであれば良く、大抵そんなもんだ。

もう一つ心に留める必要があるIPSec Tunnelの挙動として、SPD にマッチした通信は勝手に横取りされて、トンネルで指定された端点間のIPSecのパケットとして流されてしまいます。そう！何処を流れるハズだったには関係なく！！

クライアントPCの場合を同様に考えると、通信を192.168.1.0/24 <=> 192.168.150.201/32 をいかに発生させるかが鍵だと思う(だれもそんなこと言っていないので間違ってるかも)。

ルータAにはRTX1100を使っているので、tunnel デバイスへのルーティングとかは設定してある。

ip route 192.168.150.201 gateway tunnel 1

クライアントPCで、考えられる設定は３種類です(もっとあるかも)。

• iptunnel を使う方法
• 疑似デバイス dummy を使う方法
• ip alias を使う方法

iptunnel を使う方法

iptunnel add ipsec0 mode ipip remote 1.1.1.1
ifconfig ipsec0 192.168.150.201 netmask 255.255.255.255
route add -net 192.168.1.0/24 dev ipsec0

実際にはIPSecに横取りされるので、特に ipip 以外でも良く、対向の端点アドレスもなんでも良い。

こいつは良く例に上げられている。FreeBSD/NetBSDの場合 gif0 とか使っている。

疑似デバイス dummy を使う方法

modrpobe dummy
ip link set dummy0 name ipsec0
ifconfig ipsec0 192.168.150.201 netmask 255.255.255.255
route add -net 192.168.1.0/24 dev ipsec0

dummyは来るパケットを全部破棄する疑似デバイスで、昔SLIPとかで使っていたみたい。好き者が、ネットワーク検証とかで使っているのしか見たこと無いなぁ。

こいつを使っている例は見たことが無い。偶然出来ただけなのかも。

ip alias を使う方法

ifconfig eth0:1 192.168.150.201 netmask 255.255.255.255
route add -net 192.168.1.0/24 gw 192.168.150.201

こいつを使っている例は見たことが無い。どこかに落とし穴があるかも。

上のどれでも良いと思う。というか推奨とか何処にも書いていない、、、、多分陰謀だ。

本当は、iptunnel の mode にipsec-tunnel とかがあって、SPDにtunnelモードの設定が追加された時点で自動的に追加されるのが親切な気がする。。。

そう言えば RTX1100から、VPN通信用のIPアドレスを動的に割り振れないので、固定して考えていたので３つ上げたが、正当な方法が別にありそうである。。。絶対陰謀だ。

取り敢えず、どれかの方法を決めたあとは簡単

/etc/ipsec-tools.conf で、SPDを作成

#!/usr/sbin/setkey -f
flush;
spdflush;

spdadd 192.168.150.201 192.168.1.0/24 any -P out ipsec
            esp/tunnel/YY.YY.YY.YY-XX.XX.XX.XX/require;

spdadd 192.168.1.0/24 192.168.150.201 any -P in ipsec
            esp/tunnel/XX.XX.XX.XX-YY.YY.YY.YY/require;

/etc/racoon/psk.txt に事前共有鍵を

XX.XX.XX.XX * (RTX1100と同じ文字列)

/etc/racoon/racoon.conf に、IKEデーモンの設定

path pre_shared_key "/etc/racoon/psk.txt"

remote XX.XX.XX.XX {
   exchange_mode aggressive;
   my_identifier fqdn "PCNAME"
   proposal {
       encryption_algorithm aes;
       hash_algorithm md5;
       authentication_method pre_shared_key;
      dh_group modp1024;
   }
}

sainfo anonymous {
    pfs_group modp1024;
    encryption_algorithm aes;
    authentication_algorithm hmac_md5;
}

てな具合で、クライアントPC から Develop Domain に ping を打つと、クライアントPCのログに、

racoon: INFO: initiate new phase 1 negotiation: YY.YY.YY.YY[500]<=>XX.XX.XX.XX[500]
racoon: INFO: begin Aggressive mode.
racoon: NOTIFY: couldn't find the proper pskey, try to get one by the peer's address.
racoon: INFO: ISAKMP-SA established YY.YY.YY.YY[500]-XX.XX.XX.XX[500] spi:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
racoon: INFO: initiate new phase 2 negotiation: YY.YY.YY.YY[500]<=>XX.XX.XX.XX[500]
racoon: INFO: IPsec-SA established: ESP/Tunnel XX.XX.XX.XX[0]->YY.YY.YY.YY[0] spi=xxxxxxxx(0xXXXXXXX)
racoon: INFO: IPsec-SA established: ESP/Tunnel YY.YY.YY.YY[0]->XX.XX.XX.XX[0] spi=xxxxxxxx(0xXXXXXXX)

が出れば、IPSec Tunnel のできあがり。

RTX1100 でIPSec-VPNを構築する

IPSecを使ってVPNを構築をしようとRTX1100を購入したのだが、買った満足感でそんな事をすっかり忘れて放置していた。だが、勿体ないお化けが出てきたので、RTシリーズの設定事例集を参考にIPSec-VPNを設定してみた。

VPNを構築する方法が多々あるようだが、

• IPSec トランスポートモード
• IPSec トンネルモード
• L2TP over IPSec
• PPTP
• IP-IP
• GRE
• etc

で、今回構築してたのは IPSec トンネルモードっす。

現在のネットワーク構成は、次の通り。

• ルータはPPPoEによりInternet に接続されている。
• ルータの配下にはHome/Developのドメインがある。
• ルータのWAN側には固定のIPアドレスが割り振られている。
• Home ドメインには192.168.0.0/24 が、Develop ドメインには192.168.1.0/24 が割り振られている。
• Home, Develop => Internet はルータ上のNAT変換により通信できる。
• Home, Develop はルータ上で適当なフィルターを切ってある。

で、お外のPCからIPSecでDevelopドメインと疎通できれば良いのだが、 Home ドメインからからIPSec接続でDevelopドメインと疎通しても、 一応目的を達成できる。

クライアントに関しては、Windows とLinuxを考えている。 ついでに言うならば、Windows 用のものはNET-G Secure VPN Clientを既に購入している。ヤマハのVPNクライアントソフトは、こいつのOEM版らしいので、今ならばこいつを使うのも可だと思う。Windows 標準のIPSec では、IKE の mainモードしか対応してないっぽいので、動的IPを持つ場合はうまくいかないそうな。

やりたいことは、端点のクライアントPCに仮想IPアドレスとして192.168.150.201 を付与して、

Develop Domain:192.168.1.0/24
<---->
192.168.1.1:ルータ:XX.XX.XX.XX
<==[IPSec Tunnel]==>
YY.YY.YY.YY:クライアントPC:192.168.150.201/32

な感じかなぁ。

ヤマハの設定例を参考にしてRTX側での設定は、

# インタフェースの設定
ip lan1 address 192.168.0.1/24
ip lan2 address 192.168.1.1/24

# PPPoEの設定
pp select 1
pppoe use lan3
... (ISPに応じた設定、固定IP XX.XX.XX.XX をもらう)
ip pp nat descriptor 1
pp enable 1

# NAT設定
nat descriptor type 1 masquerade
nat descriptor address inner 1 192.168.0.1-192.168.0.254 192.168.1.1-192.168.1.254 192.168.150.201
nat descriptor masquerade static 1 1 192.168.1.1 udp 500
nat descriptor masquerade static 1 2 192.168.1.1 esp

# IKE
ipsec auto refresh on
ipsec ike encryption 1 aes-cbc
ipsec ike group 1 modp1024
ipsec ike pre-shared-key 1 text *    (事前共有鍵)
ipsec ike remote address 1 any
ipsec ike remote name 1 PCNAME      (クライアントの名前)
ipsec sa policy 101 1 esp aes-cbc md5-hmac

# Tunnel 設定
tunnel select 1
ipsec tunnel 101
ip route 192.168.150.201 gateway tunnel 1
tunnel enable 1

ここでは、クライアントの名前を PCNAME で、仮想IPは 192.168.150.201 と考えている。 複数クライアントの同時接続を考えているならば、tunnel 設定を増やしていけば良い。

設定例を参考にパラメータを合わせれば、問題なくVPN接続は疎通する。 はまりポイントとしては、ルータ側のNAT処理の内側アドレスに対向アドレスを追加していないと、インターネットとの疎通が取れなくなる。これは、FAQにもなっており、クライアントソフトの設定でも回避できるそうなぁ。

今更ながらIPv6のアドレス付けとは？

IPv6がぼちぼちコンシューマのサービスレベルまで落ちて来始めたので、再度勉強して見ようかと、ローカルマシン間(A,B)で ping を打ってみました。

A:~# ping6 fe80::222:XXXX:XXXX:XXXX
connect: Invalid argument

あれ、対向のPCのアドレスで間違いないのになぁ

B:~# ifconfig eth0 | grep inet6
inet6 addr: fe80::222:XXXX:XXXX:XXXX/64 Scope:Link

って、エラーだぁ、、、何故だろう。

色々な所で宣伝されているようにIPv6 アドレスは 128 bit であり、全ての機器に一意に割り振ってもまだ余るハズではなかったのか〜〜〜！

実は上の例ではAが複数NICを持ち、Linux の iputils のping6を使っている場合にエラーになる。ただ、inetutils の ping6 では普通に疎通する。実装によりけりである。

IPv6のリンクローカルアドレスと疎通する場合、送受信するインタフェースを指定しなければ一意に通信経路を指定することが出来ないので、追加でスコープ番号(インターフェース番号)を指定するらしい(1)。

分かっている人はチャンと理解して、こっそりほくそ笑んでいることなんだろう。ワシは今までほんと知らなかった。

# ping6 -I eth0 fe80::222:XXXX:XXXX:XXXX
or
# ping6 fe80::222:XXXX:XXXX:XXXX%eth0

実装によってはエラーになったりする、、、なんじゃい。

えっと、サイトローカルは廃止されたんかい、何処へ行けばいいの？

ssh アクセスの制限する

専用サーバを借りている当初からパラパラと brute force attack を受けていたので、気になっていたので対策を立ててみた。

iptables を使う場合、ipt_recent/ipt_hashlimitの２種類の方法があるらしい(他にもあるかも)。 ipt_recentは CentOS 4 のカーネルに標準に入っているので、こいつを使ってみる。

ただ巷では、ipt_recent はバグ#415(1,2)があったらしく、その不具合の修正が 2.6.18 取り込まれたそうである。 ただ、CAN-2005-2872,CAN-2005-2873 という名前が付いている結構深刻そうな不具合らしいので、現在のサーバ環境にも当てはまるか注意する必要がありそうだ。

で、CentOS 4は 2.6.9 のままでパッチがやたら当たっているので、問題ないのかなぁ？ RHELの changelog を見る限り #167703(CAN-2005-2872)/#189127 の fix としてkernel-2.6.9-42.ELまでに修正は入っているようだ。で、CAN-2005-2873 はどうかと言えば、パッチを見る限りどうも一緒に対応したようである。取り敢えず、yum update で最新版にしていれば安心なようである。

でもって、SSH接続を６０秒に５回以上行うホストは10分間拒絶する感じにすると下記のようになる。 あまりにもしつこいホストはdenyhost とに登録しおく感じ。

iptables -N attacked
iptables -A attacked -m recent --name evilhost --set \
         -j LOG --log-level INFO --log-prefix "brute force attack: "
iptables -A attacked -j REJECT
 
iptables -N check_ssh
iptables -A check_ssh -m recent --name tcpssh --set
iptables -A check_ssh -m recent --name tcpssh --rcheck \
         --seconds 60 --hitcount 5 -j attacked
 
iptables -N safehost
iptables -A safehost -s 127.0.0.1 -j ACCEPT
 
iptables -N safeonly
iptables -A safeonly -j safehost
iptables -A safeonly -j REJECT
 
iptables -N denyhost
iptables -A denyhost -s xx.xx.xx.xx -j REJECT
 
iptables -A INPUT -j safehost
iptables -A INPUT -j denyhost
iptables -A INPUT -m recent --name evilhost --rcheck \
         --seconds 600 -j REJECT
iptables -A INPUT -p tcp --syn --dport 22 -j check_ssh
iptables -A INPUT -p tcp --dport xxx -j safeonly

余計なサービスを一切立ち上げていないので、いいのかなぁ。 何か頑張ってない感じが出ているなぁ〜。

さて、evilhostなのど名前を付けたリストには何個のIPアドレスを覚えており、登録したIPアドレスのタイムスタンプ履歴はいくつまで覚えているのでしょうか？

無限？、、、まさか

モジュールの引数に最大値を引き渡せて、デフォルトでは履歴は20個、リストあたり100 IPアドレスまで記録できるそうなぁ。リストがあふれた場合は、古い履歴を持つリストから削除されると思う(ipt_recent.cのソースはちょっと分かりづらいので詰めていないけど)