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

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

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

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

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

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

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

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

Я наткнулся на tcpcrypt Cегодня. За исключением отсутствующей аутентификации, похоже, что я хочу. Реализация пользовательского пространства кажется медленной, как и все другие VPN. И они говорят о реализации ядра. Я еще не пробовал, и мне интересно, как он себя ведет в [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), но они могут быть легко сгенерированы программно с помощью вашей системы управления конфигурацией.

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