Z plikiem .ovpn nic się nie dzieje, dopóki coś go nie posiada. Na pulpicie Pi prawdopodobnymi właścicielami są NetworkManager, który przechowuje zaimportowane połączenie we własnym pliku klucza, oraz samodzielna jednostka usługi, która czyta konfigurację z katalogu. To dwa modele działania z innym przechowywaniem, innym obchodzeniem się z poświadczeniami i innymi regułami aktywacji. Świadome wybranie jednego z nich to całe zadanie; skopiowanie pliku w oba miejsca czyni wybór przypadkowym.

Oba mogą działać na jednej maszynie, ale nie na tym samym tunelu w tej samej chwili, a konflikt wygląda jak awaria sieci, nie jak awaria konfiguracji.

Dwa sposoby posiadania tego samego tunelu

Wtyczka OpenVPN NetworkManagera dodaje edytor i usługę, które zarządzają połączeniem za ciebie, a instalacja programu OpenVPN nie instaluje tej integracji. Samodzielna jednostka to odwrotny układ: brak edytora, brak integracji z pulpitem, jeden plik konfiguracji i uprawnienia, które daje jednostka. Pierwszy trzyma stan połączenia we własnej bazie danych, drugi trzyma go tam, gdzie mówią profil i jednostka. Większość zamieszania bierze się z założenia, że zaimportowany profil i skopiowany plik to ten sam obiekt.

To nie są dwa widoki jednej rzeczy. Edycja pobranego pliku nie zmienia ani tego, co zapisał NetworkManager, ani tego, co czyta jednostka, i każde z nich może być tym, które zbudowało tunel, który właśnie sprawdziłeś.

Podążaj za połączeniem, którego pulpit naprawdę używa

Udokumentowana operacja importu, nmcli connection import type openvpn file office.ovpn, tworzy połączenie przez wtyczkę. Zapisz jego UUID i używaj tego identyfikatora później, bo nazwy są edytowane, a dwa połączenia mogą dzielić jedną etykietę. nmcli connection show wylicza, co istnieje, a odczyt własnych właściwości połączenia mówi, z którego pliku pochodzi i co przechowuje. Jeśli UUID, który edytujesz, nie jest tym, które aktywuje pulpit, twoje zmiany są dekoracją.

Sekrety mieszkają w magazynie właściciela. Wysypanie każdego zapisanego sekretu, aby ustalić, który profil jest aktywny, jest wolne i ryzykowne; zapytaj zamiast tego obiekt połączenia i trzymaj prywatny materiał tam, gdzie właściciel go oczekuje.

Zaimportowane połączenie nie potrzebuje sesji graficznej, aby działać, ale nadal może potrzebować źródła poświadczeń. To, czy uruchomi się bez nadzoru, zależy od jego uprawnień i sekretów, a nie od obecności pulpitu.

Przeczytaj szablon jednostki, zanim na nim polegniesz

Gdy pakiet dostarcza jednostkę klienta w stylu upstream, instancja o nazwie office odpowiada %i.conf w skonfigurowanym katalogu jednostki, który dla szablonu 2.6 to /etc/openvpn/client. Przeczytaj zainstalowaną jednostkę i wszelkie pliki dodatkowe, zanim zaufasz przykładowi z poradnika, bo dystrybucje przenoszą ścieżki. Ręczne uruchomienie z terminala niczego nie dowodzi o tym, jak usługa widzi pliki, sekrety czy uprawnienia. Okno hasła na pulpicie też nie jest dowodem, że nieinteraktywna jednostka ma zatwierdzony sposób uzyskania tego samego hasła.

Daj jednostce tylko to, czego potrzebuje. Poluzowanie całego sandboxa usługi, bo jeden wskazany plik jest nieczytelny, wymienia małą poprawkę uprawnień na duże narażenie, a błąd zwykle nazywa plik, który wymaga uwagi.

Wycofaj duplikat bez utraty dostępu

Jeśli obaj właściciele mogą uruchomić tunel, jeden w końcu wygra w złym momencie, a trasy i urządzenie przegranego zostaną z tyłu. Usuń przypadkowy duplikat przez jego własnego właściciela, zostaw otwartą ścieżkę odzyskiwania i potwierdź, że pozostały właściciel nadal się łączy po restarcie. Dwa świadomie oddzielone VPN-y z różnymi politykami routingu to inne pytanie projektowe, a nie zgoda na to, by dwie ścieżki uruchamiania rywalizowały o jedno połączenie.

Następnie zapisz cykl życia, który przyjąłeś: ręczna aktywacja, logowanie albo uruchamianie i ponowne łączenie. Sprawdź zapisany punkt końcowy, uwierzytelnianie drugiej strony i zasób, do którego tunel ma dotrzeć, bo ponowna instalacja pulpitu nie zastępuje wiedzy, która konfiguracja działała.

Powiązane artykuły