web-dev-qa-db-ja.com

GREを介したIPsecのパフォーマンスが低い

リモートホストとのIPsecover GRE接続を設定しました。どちらもNetBSD6.1ベースです。 「クライアント」は、400Mbpsのファイバー接続を介してインターネットに接続されています。 「サーバー」は10Gbpsネットワーク上にあります。どちらのマシンにも1GbpsのNICがあり、完全に動作します。つまり、IPsecトンネルの外部にデータを転送すると、どちらもリンク速度の制限に達します。トンネルを介して転送を行う場合、速度は5〜10倍低下します。

直接接続：/dev/null 27%[====> ] 503.19M 45.3MB/s eta 83s IPsec接続：/dev/null 2%[ ] 47.76M 6.05MB/s eta 5m 3s

トンネルは次のように設定されます。

サーバー上で、debian/AMD64 dom0で実行されているNetBSD domU -）：

 $ cat /etc/ifconfig.xennet0
# server interface 
 up 
 inet 192.168.1.2 netmask 255.255.255.0 
 inet 172.16.1.1 netmask 0xfffffffcエイリアス
 $ cat/etc/ifconfig.gre0
create
tunnel172.16.1.1 172.16.1.2 up 
 inet 172.16.1.5172.16.1.6ネットマスク255.255.255.252

IPsecトラフィックは、dom0のパブリックIPからdomUのxennet0インターフェイスにiptables NATルール：

-APREROUTING -i eth0 -p udp -m udp --dport 500 -j DNAT --to-destination192.168.1.2:500
-APREROUTING-i eth0 -p esp -j DNAT --to-destination 192.168.1.2 
-事前設定-ieth0 -p ah -j DNAT --to-destination 192.168.1.2

クライアントの場合：

 $ cat /etc/ifconfig.vlan8 
＃client public interface 
 create 
 vlan 8 vlanif re0 
！dhcpcd -i $ int 
 inet 172.16.1.2 netmask 0xfffffffc alias 
 $ cat/etc/ifconfig.gre1
create
tunnel172.16.1.2 172.16.1.1 up 
 inet172.16。 1.6172.16.1.5ネットマスク255.255.255.252

racoon側では、enc_nullでさえ、さまざまなハッシュ/暗号化アルゴリズムの組み合わせを試しましたが、実際には何も変わりません。転送は最大6MB /秒で止まります。

 remote node.public.ip {
 exchange_mode main; 
ライフタイム時間28800秒; 
提案{
 encryption_algorithm blowfish; 
 hash_algorithm sha1; 
 authentication_method pre_shared_key; 
 dh_group 2; 
} 
 generate_policy off; 
} 
 
 sainfoアドレス172.16.1.1/30任意のアドレス172.16.1.2/30任意の{
 pfs_group 2; 
 encryption_algorithm blowfish; 
 authentication_algorithm hmac_sha1; 
 compression_algorithm deflate; 
ライフタイム時間3600秒; 
}

クライアントの場合：

 remote office.public.ip {
 exchange_mode main; 
ライフタイム時間28800秒; 
提案{
 encryption_algorithmblowfish; 
 hash_algorithm sha1; 
 authentication_method pre_shared_key; 
 dh_group 2; 
} 
 generate_policy off; 
} 
 
 sainfoアドレス172.16.1.2/30任意のアドレス172.16.1.1/30任意の{
 pfs_group 2; 
 encryption_algorithmblowfish; 
 authentication_algorithm hmac_sha1; 
 compression_algorithm deflate; 
ライフタイム時間3600秒; 
}

トンネルは問題なく確立されます。ここでの唯一の問題は転送ドロップです。繰り返しますが、トンネルなしで/からサーバーへ/からクライアントへ転送する場合、速度は最適であり、ドロップが発生しますのみ IPsecを介して。

どちらのマシンも、2 + GHzで動作するIntelベースのCPUであり、十分なメモリがあり、転送/ NAT以外で消費されるCPU時間はごくわずかです。

誰かがそのような行動を目撃したことがありますか？さらにどこを見ればよいかについて何か考えはありますか？

ありがとう、

ipsecgreracoonnetbsd
3
iMil

MTUを微調整しなかった場合は、断片化後の問題（暗号化後に断片化が発生する）が発生する可能性があります。これについては、次のドキュメントで詳しく説明しています。 http://www.Cisco.com/c/en/us/td /docs/interfaces_modules/services_modules/vspa/configuration/guide/ivmsw_book/ivmvpnb.html#wp2047965

トンネル内のMTUを82バイト（GRE + IPSecヘッダー）削減するようにしてください。

2
Fanu