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

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

Я шукаю спосіб змусити всіх господарів спілкуватися між собою, надійно та конфіденційно. Шар 3 тонкий, шар 2 добре (але не обов'язково). Оскільки я не маю доступу до VLAN, він повинен бути певним VPN.

Що для мене важливо:

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

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

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

Я сьогодні натрапив на tcpcrypt . За винятком відсутньої автентичності, це виглядає як те, що я хочу. Реалізація простору користувача пахне повільно, але так само, як і всі інші VPN. І вони говорять про реалізацію ядра. Я ще цього не пробував, і мені цікаво, як він поводиться повторно [1] та [3].

Які ще варіанти є? Що роблять люди, які не на AWS?

Додаткова інформація

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

Остаточне оновлення

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

Чого ви не хочете, це VPN. Те , що ви робите покупку дійсно IPsec, але не в тунельному режимі. Швидше, ви хочете IPsec у транспортному режимі.

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

Так, вам знадобиться строфа підключення IPsec для кожного хоста (якщо тільки ваші хости не згруповані в підмережу; в цьому випадку це можна зробити через блок CIDR), але це може бути легко запрограмовано програмно системою управління конфігурацією.

Ви не питали про деталі конфігурації, але якщо вам потрібні деякі вказівники (там не все так багато надійної інформації про транспортний режим), ви можете звернутися до цієї публікації в блозі, яку я нещодавно написав.