Сетевая VPN с высокой пропускной способностью для подключения узлов центров обработки данных

Мы арендуем несколько хостов в общедоступном центре обработки данных. Центр обработки данных не предлагает частные VLAN; все хосты получают один (или несколько) общедоступных адресов IPv4 / IPv6. Хосты поставляются с очень современными процессорами (четырехъядерный процессор Haswell, 3,4 ГГц) и имеют восходящие каналы Gbit. Различные области (комнаты, этажи, здания) центра обработки данных взаимосвязаны - как я могу судить - со ссылками в Гбит или 500 Мбит. Наши хосты работают под управлением Debian Wheezy. В настоящее время у нас работает чуть более 10 хостов с ожиданием роста в ближайшем будущем.

Я ищу способ, чтобы все хосты могли общаться друг с другом, безопасно и конфиденциально. Слой 3 в порядке, слой 2 в порядке (но не обязательно). Поскольку у меня нет доступа к виртуальным локальным сетям, это должен быть своего рода VPN.

Что для меня важно:

1. высокая пропускная способность, идеально близкая к скорости
2. децентрализованная, ячеистая архитектура - это необходимо для того, чтобы пропускная способность не замедлялась центральным элементом (например, концентратором VPN)
3. Загрузка процессора не является чрезмерной (учитывая комплекты шифров AESNI и GCM, я надеюсь, что это не смешное требование)
4. эксплуатационная простота использования; не слишком сложен в настройке; сеть может расти без потери установленных соединений

В настоящее время мы используем тинк . Это отметки [2] и [4], но я достигаю лишь около 600 Мбит / с (симплекс) при скорости передачи 960 Мбит / с, и я полностью теряю одно ядро. Кроме того, tinc 1.1 - в настоящее время в разработке - еще не многопоточный, поэтому я застрял с одноядерной производительностью.

О традиционном IPSec не может быть и речи, поскольку он требует центрального элемента или небольшого количества туннелей для настройки (для достижения [2]). IPsec с оппортунистическим шифрованием будет решением, но я не уверен, что он когда-либо превратился в стабильный производственный код.

Я наткнулся на tcpcrypt сегодня. За исключением отсутствующей аутентификации, похоже, что я хочу. Реализация в пользовательском пространстве пахнет медленно, как и все другие VPN. И они говорят о реализации ядра. Я еще не пробовал, и мне интересно, как он себя ведет re [1] и [3].

Какие еще есть варианты? Что делают люди, которых нет в AWS?

Дополнительная информация

Я заинтересован в GCM, надеясь, что он уменьшит нагрузку на процессор. Смотрите статью Intel на эту тему . Говоря с одним из разработчиков Tinc, он объяснил, что даже используя AESNI для шифрования, HMAC (например, SHA-1) все еще очень дорогой на скорости Gbit.

Окончательное обновление

IPsec в транспортном режиме работает отлично и делает именно то, что я хочу. После большой оценки я выбрал Openswan вместо ipsec-tools, просто потому, что он поддерживает AES-GCM. На процессорах Haswell я измеряю около 910-920 Мбит / с симплексной пропускной способности при нагрузке на процессор около 8-9% kworkerd.

То, что вы не хотите, это VPN. Что вы действительно хотите, так это IPsec, но не в туннельном режиме. Скорее вы хотите IPsec в режиме транспорта .

В этой конфигурации каждый хост связывается напрямую со своим одноранговым узлом, и только полезные данные пакета шифруются, оставляя IP-заголовки на месте. Таким образом, вам не нужно заниматься гимнастикой, чтобы все заработало.

Да, вам понадобится раздел подключения IPsec для каждого хоста (если только ваши хосты не сгруппированы в подсети, в этом случае вы можете сделать это через блок CIDR), но они могут быть легко сгенерированы программно вашей системой управления конфигурацией.

Вы не спрашивали о деталях конфигурации, но если вам нужны некоторые указатели (там не так много солидной информации о транспортном режиме), вы можете обратиться к этому сообщению в блоге, которое я недавно написал.