Google Code Prettify

ラベル IPSec の投稿を表示しています。 すべての投稿を表示
ラベル IPSec の投稿を表示しています。 すべての投稿を表示

2009年10月15日

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 %
ref1ref2 ref1via ref1osx
no ipsec⇒ 941.35801028 785.1857650 936.9429954
⇐ 941.24611724 723.71001299 938.34511877
null/null⇒ 934.68349938 566.89471393 932.07073162
⇐ 787.44951846 520.28801399 879.31272599
null/des-cbc⇒ 229.5461998 72.9094295 136.6533314
⇐ 197.07681426 73.4657499 129.1215699
null/3des-cbc⇒ 110.51731004 30.8918287 59.206417
⇐ 76.8033111 30.5976199 56.5818398
null/aes-cbc⇒ 466.79899933 392.07391491 475.77899543
⇐ 472.17962836 396.22641799 376.38902299
null/aes-ctr⇒ 495.41637758 218.6071771
⇐ 383.9987167 258.74301799
null/blowfish-cbc⇒ 316.03279911 77.6054374 263.77951531
⇐ 244.9774114 84.1580499 228.48101399
null/twofish-cbc⇒ 372.53179919 100.8360573
⇐ 289.2720159 102.0088599
null/camellia-cbc⇒ 340.991610015 86.7841360
⇐ 267.3560185 84.5675499
hmac-md5/null⇒ 537.28579924 244.7170787 578.86759949
⇐ 453.24482914 230.20191199 572.58092999
hmac-sha1/null⇒ 370.086110015 360.37542086 414.47069941
⇐ 296.1913117 350.02872099 469.55875798
hmac-sha256/null⇒ 307.00789916 302.931510041 278.90011733
⇐ 240.0495124 336.25121996 248.91492899
aes-xcbc-mac/null⇒ 447.60179920 216.0013680
⇐ 347.98811312 271.08012199
hmac-md5/3des-cbc⇒ 101.51721005 29.0609188 57.006917
⇐ 71.0862111 28.45191100 54.5636498
hmac-md5/aes-cbc⇒ 326.01559917 205.8441979 349.03388027
⇐ 266.2639185 198.65111299 296.44312798
hmac-sha1/3des-cbc⇒ 94.18991005 30.1900185 56.661915
⇐ 66.1646121 29.8474299 52.0154496
hmac-sha1/aes-cbc⇒ 259.36149915 253.11579956 275.36619825
⇐ 202.5055124 286.00772093 270.10912697
hmac-sha1/aes-ctr⇒ 257.31529914 193.6954497
⇐ 199.9059123 209.87451699
aes-xcbc-mac/aes-cbc⇒ 283.08649915 207.26131162
⇐ 225.1556134 233.39072699
aes-xcbc-mac/aes-ctr⇒ 281.39699915 154.4989770
⇐ 220.3145124 178.53991399

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

  • 暗号化方式の性能は
    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 はどの程度なのだろうかぁ？

- 0 件のコメント:
ラベル: , , , , ,

2009年9月10日

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／ローカル接続でも同じモデルを利用

測定結果

ローカルHDDGigaEtherWifi経由GigaEtherWifi経由
IPSec 無IPSec 有
SequentialUncached Write [4K blocks]58.1960.515.3413.155.48
Uncached Write [256K blocks]47.5850.827.3312.654.72
Uncached Read [4K blocks]16.166.021.464.751.38
Uncached Read [256K blocks]75.5528.863.3915.864.90
RandomUncached Write [4K blocks]1.251.361.321.351.26
Uncached Write [256K blocks]26.1924.376.1913.106.93
Uncached Read [4K blocks]0.640.610.450.580.43
Uncached Read [256K blocks]26.6823.663.2111.174.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 程度の帯域を確保できることを考えると、 目くじらを立てるものではないのかなぁ。

- 0 件のコメント:
ラベル: , , , ,

2009年9月8日

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/24client1

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で保護が出来そうである。気になるのは、パフォーマンスがどこまで劣化するかなのだが。。。あまり期待は出来ないのかなぁ。。。

- 0 件のコメント:
ラベル: , , , ,

2007年3月7日

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 のできあがり。

- 3 件のコメント:
ラベル: , ,

2007年3月5日

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 はルータ上で適当なフィルターを切ってある。

blog20070305-network-diagram

で、お外の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にもなっており、クライアントソフトの設定でも回避できるそうなぁ。

- 0 件のコメント:
ラベル: ,
登録: 投稿 (Atom)

久しぶりの投稿

かなり期間が空いてしまったが、ブログを再開してみようと思う。 2013年3月が直前の投稿だったが、頻繁に更新していた時期が 2011年11月までなので、8年間ぶりとなる。 8年間なにをしていたのかと言えば、2回転職して未だにIT技術者の職を得ている。 その...

  • X68k用の5inch フロッピーを読むには？
    最初に購入したComputerは、かのツタンカーメンCMで有名なX68000無印でした。付属のグラデウスを１周もできずにズルしてクリアーしたのもよい思い出です。先日、実家に預けてある荷物の整理をしたところ、X68000で使っていた5inchフロッピーディスクが大量に出てきました。...
  • libvirt 経由で日本語キーボードを扱う
    libvirt の管理下の仮想化ドメインから、virt-manager を使って、仮想グラフィック画面をVNC経由でアクセスすると、正しくキー入力ができない場合がある。 kvm/qemu のエミュレータに対してキーボードのレイアウトを指定するオプションを付ければ、対応が可能で...
  • Cocoa Emacs 24.3 構築 (2013/03版)
    暫く使っている Cocoa Emacs を更新していなかったので、24.3 に上げてみた。 当てるパッチは inline patch と ポップアップフリーズ対応パッチ くらい。 24.3 には既にフルスクリーン実装が入っているので、よく使われているフルスクリーンパッチは外し...