Назад | Перейти на главную страницу

Плохая производительность IPsec по GRE

Я установил соединение IPsec через GRE с удаленным хостом, оба NetBSD 6.1 на основе. «Клиент» подключен к Интернету через оптоволоконное соединение со скоростью 400 Мбит / с. «Сервер» находится в сети 10 Гбит / с. Обе машины имеют сетевые адаптеры 1 Гбит / с, которые работают идеально, что означает, что они обе достигают предельной скорости канала при передаче данных за пределы туннеля 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

Туннель настроен так:

На сервере, который является NetBSD domU работает на debian / amd64 dom0:

$ cat /etc/ifconfig.xennet0
# server interface
up
inet 192.168.1.2 netmask 255.255.255.0
inet 172.16.1.1 netmask 0xfffffffc alias
$ cat /etc/ifconfig.gre0 
create
tunnel 172.16.1.1 172.16.1.2 up
inet 172.16.1.5 172.16.1.6 netmask 255.255.255.252

Трафик IPsec перенаправляется с публичного IP-адреса dom0 на domU xennet0 интерфейс iptables Правила NAT:

-A PREROUTING -i eth0 -p udp -m udp --dport 500 -j DNAT --to-destination 192.168.1.2:500 
-A PREROUTING -i eth0 -p esp -j DNAT --to-destination 192.168.1.2 
-A PREROUTING -i eth0 -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
tunnel 172.16.1.2 172.16.1.1 up
inet 172.16.1.6 172.16.1.5 netmask 255.255.255.252

На racoonсо стороны, я пробовал различные комбинации алгоритмов хеширования / шифрования, даже enc_null, но на самом деле ничего не меняется, скорость передачи по-прежнему остается на максимальной скорости 6 МБ / с.

remote node.public.ip {
     exchange_mode main;
     lifetime time 28800 seconds;
     proposal {
         encryption_algorithm blowfish;
         hash_algorithm sha1;
         authentication_method pre_shared_key;
         dh_group 2;
     }
     generate_policy off;
}

sainfo address 172.16.1.1/30 any address 172.16.1.2/30 any {
     pfs_group 2;
     encryption_algorithm blowfish;
     authentication_algorithm hmac_sha1;
     compression_algorithm deflate;
     lifetime time 3600 seconds;
}

На клиенте:

remote office.public.ip {
     exchange_mode main;
     lifetime time 28800 seconds;
     proposal {
         encryption_algorithm blowfish;
         hash_algorithm sha1;
         authentication_method pre_shared_key;
         dh_group 2;
     }
     generate_policy off;
}

sainfo address 172.16.1.2/30 any address 172.16.1.1/30 any {
     pfs_group 2;
     encryption_algorithm blowfish;
     authentication_algorithm hmac_sha1;
     compression_algorithm deflate;
     lifetime time 3600 seconds;
}

Туннель устанавливается без проблем, единственная проблема - обрыв передачи. Опять же при передаче с / на сервер от / к клиенту без туннеля скорость оптимальная, происходит дроп только через IPsec.

Обе машины представляют собой процессоры на базе Intel, работающие на частоте 2+ ГГц, много памяти и очень мало процессорного времени, потребляемого чем-либо, кроме пересылки / NAT.

Кто-нибудь видел такое поведение? Есть идеи, где искать дальше?

Спасибо,

Если вы не настраивали 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).