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


16

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.


SO, sprzęt niskiej klasy? Jakiej wydajności oczekujesz po szyfrowaniu na poziomie gigabitowym? Nie ma mowy - sugeruję, abyś szukał bardziej profesjonalnego hosta lub zabił część szyfrującą.
TomTom

2
@tomtom zgodnie z dokumentem firmy Cryptoperformance firmy Intel wydajność szyfrowania dla AES-128-CBC wynosi 4,52 cykli na bajt, co oznacza, że ​​100 MB / s pochłonie ~ 450 MHz jednego rdzenia. Deszyfrowanie jest znacznie mniej kosztowne. Tak więc, chyba że problemy związane z implementacją zmniejszają wydajność, powinno to działać w przypadku obciążeń, które nie wymagają maksymalnej wydajności procesora i maksymalnej wydajności sieci w tym samym czasie .
the-wabbit

dlaczego chcesz GCM? IPSEC nie jest podatny na ataki TLS, więc rozważenie użycia GCM do obejścia słabości TLS w trybach CBC jest kwestią sporną.
the-wabbit

Odpowiedzi:


15

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.


Po drugie, używam do tego trybu transportu IPSEC. Używanie PSK z OpenSWAN może jednak nie być najlepszym ze wszystkich ustawień. Linux jest już dostarczany z natywną implementacją IPSEC i demonem kluczowania (racoon), trzymałbym się tego, chyba że istnieje szczególny wymóg nie objęty przez KAME / racoon.
the-wabbit

1
Dzięki wielkie! Łącząc twoje porady, użyłem natywnej implementacji IPsec z racoon. Najpierw przetestowałem na małych maszynach jednordzeniowych, a już przepustowość wzrosła o 50%, a opóźnienie spadło do około 60%. Potwierdzę to w węzłach Haswell w przyszłym tygodniu i wtedy zaakceptuję odpowiedź. Muszę jednak dowiedzieć się, czy w jądrze obsługiwana jest funkcja AES-GCM i jak zasygnalizować to IPsec.
Hank

@ syneticon-dj - po prostu ciekawy ... dlaczego nie openswan? Nadal używa bitów xfrm IP jądra dla IPsec, ale używa plutonu jako demona IKE w przestrzeni użytkownika zamiast racoon. Nie opowiadam się za tym, że openswan jest najlepszy - to wszystko, z czego korzystałem, a jeśli są lepsze opcje, chcę iść w tym kierunku.
EEAA

1
Prawdopodobnie sprowadza się to do osobistych preferencji, ale zawsze miałem problem z nieelegancją plików konfiguracyjnych Free- / OpenSWAN i całkowicie brzydką implementacją routingu. Bardzo podoba mi się część dynamiczna, racoonctlktóra bardzo przypomina to, na co pozwalają komercyjne routery w swoich kontrolkach IPSEC. KAME jest bardziej dogłębnie zaprojektowany, podczas gdy OpenSWAN jest raczej połączony.
the-wabbit

@ syneticon-dj, czy chciałbyś rozwinąć tę kwestię? Czy masz na myśli, że możesz trasować kilka sieci za pośrednictwem łącza IPSec bez potrzeby kilku konfiguracji SA, tak jak ma to miejsce w przypadku otwarcia w Openwan?
rsuarez
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.