ifconfig-push: adres peera w net30 czy maska podsieci w subnet?

Drugi argument ifconfig-push to adres peera w net30, a w topology subnet maska podsieci. Porównaj działającą topologię, zanim edytujesz plik CCD.

Klienci dynamiczni łączą się i trasują poprawnie, ale jedyny klient ze stałym adresem w ogóle nie dociera do serwera. W zaporze nic się nie zmieniło, a linia CCD wygląda wiarygodnie. Zwykłą przyczyną jest drugi argument napisany dla innej topologii TUN niż ta, którą uruchamia serwer. Awaria jest cicha: klient wstaje z adresem i serwer akceptuje połączenie, ale żaden ruch nie przechodzi.

W net30 to pole jest adresem peera; w subnet jest maską podsieci. Oba warianty są alternatywami, nigdy sekwencją.

Oba warianty obok siebie

W tradycyjnym wdrożeniu net30 każdy klient ma blok /30: adres sieci, dwa użyteczne adresy i adres rozgłoszeniowy. ifconfig-push przyjmuje adres klienta i adres peera, a peer to drugi użyteczny adres w tym samym bloku, używany przez stronę serwera łącza punkt-punkt.

# net30: client address and its peer
ifconfig-push 10.99.0.6 10.99.0.5
# topology subnet: client address and the pool netmask
ifconfig-push 10.99.0.20 255.255.255.0

W topology subnet klient dzieli jedną podsieć z serwerem, a ta sama dyrektywa przyjmuje adres i maskę podsieci. Własny adres serwera pochodzi z dyrektywy server, a nie z drugiego pola. Mieszanie wariantów daje klienta, który uważa, że jest na łączu punkt-punkt, podczas gdy serwer trasuje go jako hosta podsieci, albo odwrotnie. Dlatego maski podsieci nigdy nie wolno łączyć z net30.

Obie linie w bloku są pojedynczymi liniami pliku CCD. Jeden klient dostaje dokładnie jedną z nich.

Odczytaj topologię, którą serwer naprawdę uruchamia

Czytaj działającą konfigurację, a nie domyślną z pakietu, bo topologia mogła zostać ustawiona lata temu i skopiowana dalej. Poszukaj topology subnet lub jego braku, a następnie sprawdź, jak linia server przydziela adresy. Konfiguracja, która nigdy nie wspomina o topologii, nie jest tym samym co ta ustawiająca subnet.

Następnie odczytaj ustawienia otrzymane przez klienta. Adres, maska i peer, które raportuje, mówią, którą interpretację zastosował serwer.

Trzymaj stały adres poza pulą dynamiczną

Stały adres musi leżeć poza pulą dynamiczną, inaczej dwóch klientów może dostać ten sam adres. W topologii subnet nopool w linii server wyłącza automatyczną pulę, a jawny zakres ifconfig-pool określa, co otrzymują klienci dynamiczni.

dev tun
topology subnet
server 10.99.0.0 255.255.255.0 nopool
ifconfig-pool 10.99.0.100 10.99.0.210 255.255.255.0
client-config-dir /etc/openvpn/ccd

Serwer bierze dla siebie 10.99.0.1, a stały adres klienta leży poza zakresem puli. Plik CCD nazywa się od efektywnej tożsamości klienta, a nie od nazwy pliku profilu, i nie ma dodatkowego rozszerzenia. Jeśli username-as-common-name jest aktywne, uwierzytelniona nazwa użytkownika jest tożsamością do dopasowania. Dwa urządzenia dzielące jedną tożsamość będą też dzielić stały adres, co jest problemem polityki, a nie routingu.

Sprawdź przypisanie, które klient faktycznie otrzymał

Połącz ponownie zamierzonego klienta i potwierdź, który plik CCD został wybrany, zanim sprawdzisz cokolwiek innego. Następnie sprawdź adres, maskę lub peera oraz trasę powrotną do serwera. Klient pokazujący adres peera we wdrożeniu subnet nadal używa niewłaściwego wariantu.

Zmiana topologii dotyczy każdego klienta i każdego nadpisania, więc traktuj ją jako migrację, a nie naprawę jednego klienta. Poprawienie linii statycznej tak, by pasowała do używanej już topologii, jest zwykle mniejszą zmianą. Dokumentacja server-options opisuje helper i nadpisania dla poszczególnych klientów.

Powiązane artykuły