Statyczny IP OpenVPN dla każdego klienta: ifconfig-push, nie ipp.txt

Edytowanie wiersza w ipp.txt wygląda jak rezerwowanie adresu, ale nim nie jest. Ten plik, nazwany przez ifconfig-pool-persist, zapisuje, jaki adres wspólna nazwa miała ostatnio, aby pula mogła zwrócić ten sam, gdy to wygodne. Nic w nim nie wiąże następnego połączenia z tym numerem.

Wykonaj poniższe kontrole po kolei. Każda albo potwierdza mechanizm, albo każe się zatrzymać i naprawić dane wejściowe.

Do czego służy plik trwałości

Plik istnieje po to, by adresy pozostawały stabilne między restartami, co czyni ponowne połączenia wygodniejszymi, a logi łatwiejszymi do czytania. Jest czytany jako historia i zapisywany jako historia, a ścieżka przydziału pozostaje wolna, by wybrać inny adres, gdy podpowiedź nie pasuje: inna pula, kolidujący przydział albo klient, który przyszedł po zapełnieniu puli. Dlatego ręczna zmiana może wyglądać w pliku idealnie i niczego nie zmienić w połączeniu. Traktuj go jako pamięć podręczną dawnych decyzji, a nie źródło polityki.

Jeśli potrzebujesz konkretnego adresu dla konkretnego klienta, udokumentowanym mechanizmem jest ifconfig-push i należy on do konfiguracji, która posiada tego klienta.

Sprawdź, czy wybrano właściwego klienta

Przydział jawny jest wyszukiwany po wspólnej nazwie klienta, więc plik nazwany dla złej tożsamości po prostu nigdy nie jest czytany. Potwierdź, co serwer uważa za nazwę tego klienta, zwłaszcza tam, gdzie username-as-common-name zmienia ją po uwierzytelnieniu. Następnie potwierdź, że nazwa pliku dokładnie odpowiada tej wartości, wraz z wielkością liter.

Pomyśl o współbieżności, póki tu jesteś. Jeśli duplicate-cn jest dozwolone, kilka urządzeń może przedstawić tę samą tożsamość, a jeden stały adres nie może być unikalny dla wszystkich. Zdecyduj, czy stały adres jest wart odmowy współbieżnych sesji dla tej tożsamości, ponieważ tych dwóch wymagań nie można spełnić jednocześnie.

Sprawdź, czy liczby pasują do topologii

Znaczenie argumentów zależy od topologii tunelu i właśnie tutaj skopiowany przykład wyrządza najwięcej szkody. W starszym układzie net30 każdy klient zajmuje blok czterech adresów, więc push dostarcza parę adresów. W topologii podsieci klient otrzymuje jeden adres plus maskę puli, a forma pary jest błędna. Przeczytaj topologię z działającej konfiguracji, zanim napiszesz wiersz.

# /etc/openvpn/ccd/partner-a   (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0

Sprawdź adres wobec wszystkiego innego, co mogłoby go posiadać: innego jawnego przydziału, zakresu puli dynamicznej i każdej trasy statycznej, która zakłada stałego hosta. Adres nakładający się na pulę będzie działał, dopóki pula nie da go komuś innemu, a ta awaria będzie wyglądać losowo.

Sprawdź wynik na nowym połączeniu

Istniejąca sesja zachowuje przydzielony adres, więc jedynym sensownym testem jest nowe połączenie. Rozłącz klienta, połącz ponownie i odczytaj adres, który faktycznie otrzymał, wraz z trasami, które z nim przyszły. Jeśli adres nadal jest dynamiczny, przydział nie został zastosowany, a następnym krokiem jest sprawdzenie konfiguracji, a nie kolejna zmiana w pliku historii.

Trzymaj dowody razem: nazwę klienta, pasujący plik, przydzielony adres i pulę, z której pochodzi.

Na koniec, stały adres tunelu nie jest poświadczeniem urządzenia. Wskazuje miejsce w planie adresów, podczas gdy uwierzytelnianie nadal opiera się na certyfikacie i koncie. Mylenie obu zamienia konflikt adresów w założenie bezpieczeństwa, którego nikt nie zapisał.