Stabilne adresy OpenVPN powinny podążać za tożsamością, nie źródłowym IP

Plany adresów, które mówią „ten laptop dostaje 10.90.0.10”, są w rzeczywistości stwierdzeniami o tożsamości: które uwierzytelnione urządzenie może mieć ten adres. Obecny publiczny IP tego urządzenia prawie nie ma z tym nic wspólnego, ponieważ NAT i roaming zmieniają go bez zmiany tego, kim jest użytkownik. Budowanie planu na adresie źródłowym daje reguły, które łamią się w pierwszej sieci hotelowej. Budowanie go na uwierzytelnionej tożsamości daje plan, który przetrwa podróże.

Zacznij od tego, co serwer może zweryfikować, a potem zdecyduj, do czego służy adres.

Wybierz klucz tożsamości przed adresem

Osobny certyfikat klienta dla każdego urządzenia daje serwerowi stabilny, weryfikowalny klucz dla każdego członka, co jest najczystszą podstawą statycznego przypisania. Wdrożenie z uwierzytelnianiem na użytkownika może zamiast tego opierać się na nazwie użytkownika, o ile wybór konfiguracji podąża za tym samym polem. Mieszanie obu modeli daje przypisania, które pasują do certyfikatu u jednego klienta i do nazwy użytkownika u innego, i nikt nie potrafi przewidzieć, który wygra. Zdecyduj, którego klucza używa plan, zanim napiszesz choćby jedną rezerwację.

Z duplicate-cn kilka jednoczesnych sesji może przedstawić tę samą nazwę wspólną, więc jeden przypięty adres nie może ich zidentyfikować pojedynczo. To właściwość modelu tożsamości, a nie coś, co lepszy plan adresów może naprawić.

Rezerwuj adresy poza zakresem dynamicznym

W sieci z topologią podsieci, takiej jak 10.90.0.0/24, zachowaj niskie adresy dla nazwanych członków, a pulę dynamiczną umieść w osobnym zakresie. Przypisanie dla przypiętego członka wygląda tak ifconfig-push 10.90.0.10 255.255.255.0 w pliku, który serwer wybiera dla tej tożsamości. Drugi argument oznacza coś innego w net30, więc przykład nie jest neutralny względem topologii. Przeczytaj topologię, zanim go skopiujesz.

Trwałość puli zapisuje ostatnie dzierżawy i ma skłonność do zwracania tego samego adresu, co jest wygodą, a nie rezerwacją. Nie pozwól, aby plik trwałości stał się rejestrem własności, ponieważ zmienia się wraz z historią połączeń, a nie z polityką.

Pierwszeństwo przypisania decyduje, kto wygrywa

Podręcznik dokumentuje kolejność: jawne przypisanie wygenerowane podczas client-connect może wejść w życie przed wpisem client-config-dir, który z kolei wyprzedza zwykłe przydzielanie z puli. Ta kolejność wyjaśnia większość raportów „przypięty adres nie został zastosowany”. Oznacza to również, że dynamiczny alokator zapisujący konfigurację dla każdej sesji może po cichu nadpisać plik statyczny, który uważałeś za autorytatywny.

Wybierz jedną warstwę, która posiada przypisania, a pozostałe uczyń tylko do odczytu. Dwie warstwy, które obie twierdzą, że decydują, dają przypisania zależne od czasu.

Dynamiczny alokator potrzebuje tego samego modelu

Integracja client-connect, która rozdaje adresy na sesję, to mały alokator ze zwykłymi problemami alokatora. Musi zweryfikować tożsamość żądającego, atomowo zarezerwować adres, emitować tylko obsługiwane wyjście dla połączenia i zwalniać rezerwację przy rozłączeniu lub błędzie. Równoczesne żądania wymagają blokady lub ograniczenia bazy danych, a nie sekwencji odczyt-a-potem-zapis. Bez czyszczenia pula traci adresy do restartu.

Trzymaj stan alokatora tam, gdzie następny operator może go odczytać, i rejestruj decyzję tożsamość-do-adresu, a nie tylko adres.

Zdecyduj, czy adres jest polityką czy wygodą

Jeśli reguła firewalla lub trasa pozwala na ruch z jednego adresu tunelu, to adres uczestniczy w polityce dostępu, a ponowne przypisanie dziedziczy to uprawnienie. Skoordynuj cykl życia tożsamości, adresu i firewalla albo powiąż regułę z czymś, czego nie można przypisać ponownie. Stabilne adresowanie czyni konfigurację czytelną; nie zastępuje uwierzytelniania.

Napisz plan jako inwentarz z właścicielem przy każdym wpisie, a potem przejrzyj go, gdy urządzenie zostanie wycofane. Nieużywana rezerwacja to ta, która zostaje przypadkowo użyta ponownie.