Dlaczego /24 OpenVPN kończy się klientami szybciej, niż się spodziewasz

Pule zbudowane na /24, które przestają przyjmować klientów w okolicach sześćdziesięciu, zachowują się zgodnie z projektem, a nie uderzają w limit licencji. Przy net30 każdy klient otrzymuje wirtualne łącze punkt-punkt, które zużywa cztery adresy, więc podsieć z 256 adresami obsługuje około jednej czwartej tego, co sugeruje prefiks. Liczą się przydziały, nie adresy. Czytanie prefiksu jako liczby klientów to błąd, który prowadzi do szukania ukrytego limitu użytkowników.

Dwie topologie, dwa modele arytmetyczne, i tylko jeden z nich pasuje do prefiksu, który ludzie zakładają.

net30 zużywa cztery adresy na klienta

net30 przydziela blok /30 na klienta, ponieważ każda sesja jest modelowana jako łącze punkt-punkt z adresem na każdym końcu. W ten blok wchodzą cztery adresy, a dwa są użyteczne, dlatego efektywna liczba klientów to jedna czwarta podsieci. Na /24 zostaje 64 bloków, zanim wyjdą własny blok serwera i wszelkie stałe przydziały. Raportowany sufit w okolicach 63 to arytmetyka, która wychodzi na jaw, a nie skonfigurowane maksimum.

Serwer też potrzebuje własnego przydziału, a statyczne wpisy klientów zużywają bloki niezależnie od tego, czy ci klienci się łączą. Oba zmniejszają zakres dynamiczny bez zmiany prefiksu, od którego zaczęliście.

Granice puli są ważniejsze niż prefiks

Dyrektywa serwera może zdefiniować pulę węższą niż podsieć, którą nazywa, a skrypt pomocniczy może rozwinąć się w dodatkowe ustawienia, których nie widać w otwartym profilu. Stałe adresy z katalogu client-config leżą w tym zakresie i nie mogą być wydane dwa razy. Prefiks opisuje maksymalną możliwą przestrzeń; efektywna pula to to, co faktycznie oferuje działająca konfiguracja.

Porównaj oba, zanim wyciągniesz jakikolwiek wniosek o pojemności, bo mniejszy skonfigurowany zakres wyjaśnia sufit równie dobrze jak topologia.

Znajdź limit, który naprawdę odmówił klientowi

Najpierw przeczytaj topologię i efektywną pulę, potem uwzględnij stałe przydziały i adresy zarezerwowane. Zanim obwinisz przestrzeń adresową, sprawdź max-clients i wszelką kontrolę przyjęć poza OpenVPN. Na koniec zestaw własny komunikat serwera w chwili odmowy z tymi kandydatami. Komunikat nazywa ograniczenie; liczba tylko zawęża pole.

Odmowa, która przychodzi z błędem współbieżności, i odmowa, która przychodzi z błędem przydziału, mają różne poprawki, a zgadywanie między nimi marnuje okno serwisowe.

Zmiana topologii zmienia plan adresów

Przejście na topologię podsieci daje każdemu klientowi jeden adres zamiast bloku, co jest właściwym krokiem, gdy prefiks jest naprawdę za mały. Zmienia też znaczenie parametrów adresu klienta, więc każdy przypięty przydział i każdy plik specyficzny dla klienta trzeba wyprowadzić od nowa, a nie przenumerować ręcznie. Zaplanuj nowy zakres, przenieś wpisy statyczne i zaktualizuj trasy, które się do nich odwołują.

Przejście nie jest synonimem starej konfiguracji. Traktuj je jako zmianę planu adresów z własnym przeglądem i oczekuj, że co najmniej jeden klient zachowa adres z poprzedniego schematu.

Ustal rozmiar puli z planu, nie z maski

Wybierz rozmiar na podstawie liczby równoczesnych klientów plus zapasu na ponowne połączenia i testy, a potem wybierz najmniejszy prefiks, który to obejmuje w wybranej topologii. Rozszerzenie do /16, aby rozwiązać sufit sześćdziesięciu klientów, zamienia problem pojemności na problem routingu i nakładania się, bo większy zakres prywatny łatwiej koliduje z czymś, do czego klient już dociera.

Udokumentuj razem topologię, pulę, stałe przydziały i wynikający z nich sufit klientów. Wtedy następne pytanie o pojemność staje się arytmetyką, a nie śledztwem.