Jaki adres pula przydzieli przy następnym połączeniu?

Reguła, która pasowała wczoraj, przestaje pasować dziś, bo klient wrócił z innym adresem tunelu. Alokator nie jest jednak losowy, a znajomość jego kolejności zamienia tę niespodziankę w przewidywalne zdarzenie. Preferuje adres, który ten sam klient miał wcześniej, sięga po wolny adres najdłużej nieużywany i zapomina wszystko, jeśli nie dasz mu miejsca na pamięć. Reguły zakładające dzierżawę pasują dalej, aż do dnia, w którym po cichu przestają.

Kolejność, której trzyma się alokator

Przy jednej sesji na common name alokator najpierw szuka adresu, którego ten sam klient używał wcześniej i który jest teraz wolny. Jeśli tego adresu nie ma, bierze wolny adres, który najdłużej był bezczynny. Gdy dla tej samej nazwy włączono sesje równoległe, preferencja wcześniejszego adresu nie obowiązuje i zamiast tego używany jest pierwszy wolny adres, bo sesje traktowane są jako odrębni równorzędni uczestnicy.

Wynikają z tego od razu dwa skutki. Klient, który szybko się łączy ponownie, zwykle zachowuje swój adres, dlatego nikt nie zauważa mechanizmu, dopóki się nie zmieni. A inne urządzenie, które połączy się w tym małym oknie, może zająć adres, gdy jest przez chwilę wolny, po czym pierwszy klient dostaje coś innego i każda reguła oparta na starym numerze jest błędna. Żadne z tych dwóch zdarzeń nie tworzy wpisu w logu, który wygląda jak awaria.

Dlaczego dzierżawa wygląda stabilnie, a potem się przesuwa

Stabilność jest tu właściwością emergentną ponownych połączeń przychodzących, zanim ktokolwiek inny zajmie adres. To nie obietnica i nie jest wymuszana, gdy klient jest rozłączony. Planuj zmianę adresu, zamiast dać się jej zaskoczyć. Pula ledwo większa od liczby urządzeń czyni kolizje codziennością, bo wariant zastępczy z najdłużej nieużywanym adresem prawie nie ma z czego wybierać.

Szczytowa współbieżność to liczba, do której trzeba wymiarować, a nie liczba użytkowników. Ktoś testujący z dwóch urządzeń naraz albo klient łączący się ponownie przed wygaśnięciem starej sesji zajmuje przez jakiś czas dwie dzierżawy. Pula wymierzona tylko na liczbę osób wywoła dokładnie tę rotację, którą ludzie zrzucają na serwer.

Plik trwałości pamięta, nie rezerwuje

Adres, który przetrwa restart usługi, potrzebuje pliku trwałości. Zapisuje on nazwę klienta i adres przy zamykaniu i odczytuje je przy starcie usługi, dlatego zaplanowany restart nie miesza już wszystkich reguł, które napisałeś.

ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0

Czego nie robi, to nie trzyma adresu, gdy klient jest nieobecny. W tej luce alokator może oddać numer komuś innemu, a plik zapisuje wtedy nieaktualną preferencję, której następne połączenie nie może dotrzymać. Traktuj go jako wskazówkę poprawiającą zachowanie przy restarcie, a nie jako adresowanie statyczne.

Sprawdź pulę wobec każdej trasowanej podsieci, gdy jesteś w pliku. Nakładający się zakres rozdaje adresy, do których serwer nie potrafi trasować, a objawem jest klient, który się łączy, dostaje adres i nic nie osiąga.

Przypinanie adresu we właściwy sposób

Gdy reguła zapory albo rekord DNS naprawdę potrzebuje stałego adresu, przydziel go, zamiast mieć nadzieję. Wpis konfiguracji dla poszczególnego klienta może bezpośrednio wypchnąć adres i maskę, a ten wpis jest kluczowany efektywną nazwą klienta.

# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0

Trzymaj stałe adresy poza dynamiczną pulą, żeby alokator nigdy nie oddał tego samego numeru innej sesji. Potem sprawdź topologię tunelu, bo zmienia ona, ile adresów puli zużywa każdy klient: starszy układ punkt-punkt zużywa mały blok na klienta, podczas gdy układ podsieci zużywa po jednym adresie. Pula, która wygląda hojnie w jednej topologii, może się wyczerpać w drugiej.

Potwierdź wynik na kliencie, zamiast ufać księgowości serwera. Gdy sesja wróci, spójrz na adres interfejsu i wypchniętą trasę, bo log na serwerze może podawać żądany adres, podczas gdy interfejs ma inny.

Adres zdalny to osobne pytanie

Adres w wierszu zdalnym klienta musi być osiągalny, zanim powstanie jakikolwiek tunel. Wpisanie tam adresu puli, na przykład własnego punktu końcowego tunelu serwera, sprawia, że klient próbuje dotrzeć do punktu końcowego przez tunel, którego jeszcze nie zbudował, a wynikiem jest pętla albo ciche przekroczenie czasu zamiast skrótu.

Użyj publicznego punktu końcowego, który podał operator, i zachowaj pulę do tego, do czego została pomyślana: adresów wewnątrz tunelu. Zapisanie zakresu puli, stałych przydziałów i ścieżki trwałości w jednym miejscu oszczędza następnej osobie traktowania każdej dzierżawy jako dowolnej.