Wydajność OpenVPN: ilu jednoczesnych klientów jest możliwych?

Oceniam system dla klienta, w którym wielu klientów OpenVPN łączy się z serwerem OpenVPN. „Wiele” oznacza 50000–1000000.

Dlaczego to robię? Klienci są rozproszonymi systemami osadzonymi, każdy siedzi za routerem dsl routera właściciela systemu. Serwer musi mieć możliwość wysyłania poleceń do klientów. Moim pierwszym naiwnym podejściem jest połączenie klientów z serwerem za pośrednictwem sieci openvpn. W ten sposób bezpieczny tunel komunikacyjny może być używany w obu kierunkach.

Oznacza to, że wszyscy klienci są zawsze podłączeni do serwera. Przez lata jest wielu klientów.

Pytanie brzmi: czy serwer OpenVPN eksploduje po dotarciu do określonej liczby klientów? Jestem już świadomy maksymalnego limitu liczby połączeń TCP, dlatego (i z innych powodów) VPN musiałby korzystać z transportu UDP.

Guru OpenVPN, jaka jest twoja opinia?

Wątpię, aby tak duża konfiguracja była kiedykolwiek próbowana, więc prawdopodobnie będziesz przekraczał granice podczas próby. Mogłem znaleźć artykuł o wdrożeniu VPN dla 400 klientów, ale sądząc z tekstu, autor polegał tylko na przybliżonych szacunkach dotyczących liczby klientów, które mogą być uruchomione na procesor i brakowało mu pewnej wiedzy na temat jego konfiguracji.

Trzeba przede wszystkim wziąć pod uwagę te dwa punkty:

1. Przepustowość, z której będą korzystać transfery danych, wymaga szyfrowania / deszyfrowania po stronie serwera VPN, co pochłania zasoby procesora

2. Połączenia klienta OpenVPN zajmują zarówno zasoby pamięci, jak i procesora na serwerze, nawet jeśli dane nie są przesyłane

Każdy przyzwoity sprzęt komputerowy dostępny dzisiaj powinien łatwo nasycić łącze Gigabit za pomocą Blowfish lub AES-128, nawet urządzenia o wartości 100 USD są w stanie osiągnąć prędkości zbliżone do 100 Mb / s , więc wąskie gardła procesora ze względu na intensywność przepustowości nie powinny stanowić żadnego problemu.

Biorąc pod uwagę domyślny interwał ponownego generowania wynoszący 3600 sekund, liczba 1 000 000 klientów oznaczałaby, że serwer musiałby być w stanie wykonać średnio 278 wymian kluczy na sekundę. Podczas gdy wymiana kluczy jest dość intensywnym zadaniem procesora, w razie potrzeby możesz przenieść ją na dedykowany sprzęt - dostępne karty akceleratora kryptograficznego łatwo spełniają i przekraczają tę liczbę uzgadniania TLS. A ograniczenia pamięci nie powinny również zbytnio przeszkadzać - 64-bitowy plik binarny powinien zająć się wszelkimi ograniczeniami pamięci wirtualnej, które w przeciwnym razie prawdopodobnie byś uderzył.

Ale prawdziwą zaletą OpenVPN jest to, że możesz go łatwo skalować - po prostu skonfiguruj dowolną liczbę serwerów OpenVPN i upewnij się, że Twoi klienci z nich korzystają (np. Za pomocą okrągłego robota DNS), skonfiguruj wybrany protokół dynamicznego routingu (zazwyczaj jest to RIP ze względu na jego prostotę), a twoja infrastruktura byłaby w stanie obsłużyć dowolną liczbę klientów, o ile masz wystarczającą ilość sprzętu.

Zrobiłem to, aczkolwiek „tylko” kilkaset zdalnych połączeń podobnie za routerami DSL. Nie mogę komentować zbyt wiele na temat problemów z odtwarzaniem, ale kilka praktycznych rzeczy nauczyłem się po drodze:

1) Wdrażając klientów, upewnij się, że podałeś wiele serwerów VPN w pliku conf klienta, vpn1.example.com, vpn2.example.com, vpn3 ..... Nawet jeśli podasz tylko jeden lub dwa z nich, dajesz nad głową. Odpowiednio skonfigurowani klienci będą próbować je losowo, dopóki nie znajdą takiego, który działa.

2) Używamy niestandardowego obrazu serwera AWS VPN i możemy zwiększać pojemność na żądanie, a Amazon DNS (R53) obsługuje stronę DNS rzeczy. Jest całkowicie oddzielony od reszty naszej infrastruktury.

3) Na końcu serwera (serwerów) ostrożnie korzystaj z maski sieci, aby ograniczyć liczbę potencjalnych klientów. Powinno to zmusić klientów do alternatywnego serwera, łagodząc problemy z procesorem. Myślę, że ograniczamy nasze serwery do około 300 klientów. Ten wybór był z naszej strony nieco arbitralny - jeśli masz ochotę, „czujesz przeczucie”.

4) Również po stronie serwera powinieneś ostrożnie korzystać z zapór ogniowych. Mówiąc najprościej, mamy skonfigurowane tak, aby klienci mogli się łączyć VPN, ale serwery surowo zabraniają przychodzących połączeń ssh z wyjątkiem znanego adresu IP. Możemy SSH do klientów, jeśli czasami musimy, nie mogą nam SSH do nas.

5) Nie polegaj na tym, że OpenVPN wykona dla ciebie ponowne połączenie po stronie klienta. 9 razy na 10 tak będzie, ale czasem się zacina. Oddzielny proces regularnego resetowania / restartowania openVPN po stronie klienta.

6) Potrzebujesz sposobu generowania unikatowych kluczy dla klientów, aby móc je czasem zrzec. Generujemy je wewnętrznie w procesie kompilacji serwera (PXEboot). Nigdy nam się nie zdarzyło, ale wiemy, że możemy to zrobić.

7) Potrzebujesz skutecznych narzędzi do zarządzania, skryptów do skutecznego monitorowania połączeń z serwerem VPN.

Niestety nie ma zbyt wiele materiałów na temat tego, jak to zrobić, ale jest to możliwe przy ostrożnej konfiguracji.

Aktualizacja 2018

Nie jestem pewien, co się zmieniło od 2012 roku. Chciałem tylko zaktualizować moje doświadczenie w 2018 roku. Wdrożyliśmy sieć openvpn bardzo podobną do konfiguracji OP. Nasze punkty końcowe to w pełni wydane komputery z systemem Linux zamiast urządzeń osadzonych. Każdy punkt końcowy ma monitor służący do wyświetlania informacji i alarmu dla tej witryny, a nasz serwer pozwala nam na zdalny dostęp do wszystkich punktów końcowych za pomocą jednego punktu. Sieć nie jest zbyt aktywna, ale czasami ma jednocześnie 5-10 sesji zdalnych.

Korzystając z aktualnej wersji openvpn na około 100 klientach na lazurowym obrazie z pojedynczym rdzeniem i 2 GB pamięci RAM, zużywamy średnio około 0,7% pamięci, a użycie procesora wynosi prawie zawsze około 0%. Na podstawie tego, co znalazłem w tym mniejszym teście, uważam, że pojedynczy serwer z przyzwoitą specyfikacją z łatwością poradziłby sobie z 50000 współbieżnymi, gdyby miał ram do obsługi. Gdyby użycie pamięci RAM było skalowane liniowo, 16 GB byłoby w stanie obsłużyć 50000 użytkowników z wystarczającą ilością dodatkowych na dedykowanej maszynie openvpn.

Nie jesteśmy na wystarczająco dużą skalę, aby powiedzieć to ze znaczną pewnością, ale chciałem tylko dać ostatnią aktualizację, ponieważ podczas początkowego wdrażania naszej sieci znalazłem to i spodziewałem się znacznie większego zużycia zasobów w tej skali. Teraz wierzę, że procesor, który to uruchamia, ma szyfrowanie sprzętowe i nie jestem pewien, w którym momencie byłoby to przeciążone z punktu widzenia ruchu, ale dla punktów końcowych, które nie komunikują się dużo, nie powinno to stanowić problemu.

Przy 1000000 potrzebowałbyś 200 GB pamięci RAM na jednej maszynie (jeśli skalowane liniowo z dodatkowym), podczas gdy jest to możliwe. Sądzę, że w tym momencie chciałbyś mieć 5 maszyn z 64 GB pamięci RAM, więc nie masz ani jednego punktu o błędzie. Powinno to umożliwić konserwację, ponowne uruchomienie i wymianę 1 lub nawet 2 maszyn bez istotnych problemów.

Moje oszacowania pamięci RAM są prawdopodobnie zbyt przesadne, ponieważ dzielę całe użycie OpenVPN przez liczbę klientów, gdzie tylko część tego RAM jest spowodowana przez klientów.

Dodaliśmy 74 punkty końcowe w ciągu roku od początkowego wdrożenia. Mam nadzieję, że nadal znacznie zwiększę tę liczbę i dokonam dalszej aktualizacji, jeśli osiągniemy przyzwoitą skalę.

Zastanawiam się nad podobnym problemem, chociaż liczba klientów może wynosić setki, a może kilka tysięcy.

Uznałem, że nie mogę utrzymywać wszystkich klientów w kontakcie przez cały czas.

Zastanawiam się nad uruchomieniem demona OpenVPN na klientach w losowych odstępach czasu, aby mogli sprawdzić, czy zostali odpytywani. Jeśli tak, to wyślą e-mail lub coś, co są online i wyślą pakiety przez pewien czas, abym mógł się z nimi połączyć.

Jeśli przez pewien czas nie ma ruchu, demon zostałby zatrzymany.

Problem, z którym się teraz spotykam, polega na tym, że uzyskanie listy aktualnie połączonych klientów VPN wydaje się niemożliwe ...