VPN o wysokiej przepustowości do łączenia hostów centrum danych

Wynajmujemy szereg hostów w publicznym centrum danych. Centrum danych nie oferuje prywatnych sieci VLAN; wszystkie hosty otrzymują jeden (lub więcej) publiczny adres IPv4 / IPv6. Hosty są wyposażone w bardzo nowoczesne procesory (czterordzeniowy Haswell, 3,4 GHz) i mają łącza w górę Gbit. Różne obszary (pokoje? Piętra? Budynki?) Centrum danych są połączone - z tego co mogę powiedzieć - z łączami Gbit lub 500Mbit. Nasi gospodarze obsługują debian wheezy. Obecnie prowadzimy nieco ponad 10 hostów, a spodziewamy się wzrostu w najbliższej przyszłości.

Szukam sposobu, aby wszystkie hosty komunikowały się ze sobą w sposób bezpieczny i poufny. Warstwa 3 jest w porządku, warstwa 2 ok (ale nie jest to konieczne). Ponieważ nie mam dostępu do sieci VLAN, musi to być jakaś sieć VPN.

Co jest dla mnie ważne:

1. wysoka przepustowość, idealnie zbliżona do wirespeed
2. zdecentralizowana, siatkowa architektura - ma to zapewnić, że przepustowość nie zostanie spowolniona przez centralny element (np. koncentrator VPN)
3. Obciążenie procesora nie jest nadmierne (biorąc pod uwagę pakiety szyfrów AESNI i GCM, mam nadzieję, że nie jest to śmieszne wymaganie)
4. łatwość obsługi; niezbyt skomplikowane w konfiguracji; sieć może się rozwijać bez utraty ustanowionych połączeń

Obecnie używamy cynku . Zaznacza [2] i [4], ale osiągam tylko około 600 Mb / s (simpleks) przy prędkości 960 Mb / s i całkowicie tracę jeden rdzeń. Ponadto, tinc 1.1 - obecnie w fazie rozwoju - nie jest jeszcze wielowątkowy, więc utknąłem z wydajnością jednego singla.

Tradycyjne IPSec nie wchodzi w rachubę, ponieważ wymaga skonfigurowania centralnego elementu lub sh * tload tuneli (aby osiągnąć [2]). Rozwiązaniem byłoby IPsec z szyfrowaniem oportunistycznym, ale nie jestem pewien, czy kiedykolwiek stał się stabilnym kodem produkcyjnym.

Natknąłem się dziś na tcpcrypt . Oprócz braku uwierzytelnienia wygląda to tak, jak chcę. Implementacja przestrzeni użytkownika pachnie wolno, ale podobnie jak wszystkie inne sieci VPN. I mówią o implementacji jądra. Jeszcze tego nie próbowałem i interesuje mnie, jak się zachowuje, ponownie [1] i [3].

Jakie są inne opcje? Co robią ludzie, którzy nie korzystają z AWS?

Dodatkowe informacje

Interesuje mnie GCM, mam nadzieję, że zmniejszy to obciążenie procesora. Zobacz artykuł Intela na ten temat . Podczas rozmowy z jednym z twórców tinc wyjaśnił, że nawet przy użyciu AESNI do szyfrowania, HMAC (np. SHA-1) jest wciąż bardzo drogi przy prędkości Gbit.

Ostatnia aktualizacja

IPsec w trybie transportu działa idealnie i robi dokładnie to, co chcę. Po wielu ocenach wybrałem openswan zamiast ipsec-tools, po prostu dlatego, że obsługuje AES-GCM. W procesorach Haswell mierzę przepustowość jednostronną około 910–920 Mb / s przy obciążeniu procesora około 8–9% kworkerd.

To, czego nie chcesz, to VPN. To, czego potrzebujesz, to rzeczywiście IPsec, ale nie w trybie tunelowym. Raczej chcesz IPsec w trybie transportu .

W tej konfiguracji, każdy komunikuje się bezpośrednio do swojego gospodarza Peer, a tylko pakietów ładunków są szyfrowane, pozostawiając nagłówków IP w miejscu. W ten sposób nie musisz wykonywać żadnej gimnastyki routingu, aby wszystko działało.

Tak, potrzebujesz sekcji połączenia IPsec dla każdego hosta (chyba że hosty są zgrupowane w podsieci, w którym to przypadku możesz to zrobić za pomocą bloku CIDR), ale można je łatwo wygenerować programowo przez system zarządzania konfiguracją.

Nie pytałeś o szczegóły konfiguracji, ale jeśli potrzebujesz wskazówek (nie ma tak wielu solidnych informacji na temat trybu transportu), możesz odnieść się do tego wpisu na blogu , który niedawno napisałem.