Keyfile czy Netplan: gdzie naprawdę jest przechowywany profil VPN?

Znalezienie zaimportowanego pliku to łatwa część i często zły początek. Liczy się to, który plik NetworkManager czyta dziś jako zapisane połączenie, a to zależy od identyfikatora połączenia oraz backendu konfiguracji, którego zainstalowane pakiety naprawdę używają. Edytowanie importu przed odpowiedzią na to pytanie to sposób, w jaki działający VPN staje się dwiema na wpół poprawnymi konfiguracjami.

Zaimportowany plik nie jest zapisanym profilem

Wokół każdego problemu z VPN krążą trzy nazwy: nazwa połączenia, nazwa zaimportowanego pliku i interfejs wirtualny, który pojawia się, gdy tunel wstaje. Żadna z nich nie identyfikuje zapisanej konfiguracji, a nazwę połączenia można edytować, podczas gdy plik za nią zachowuje swój pierwotny identyfikator.

Zacznij od inwentarza tylko do odczytu i wybierz docelowy VPN po identyfikatorze, a nie po etykiecie:

nmcli -f NAME,UUID,TYPE connection show

Trzymaj nazwy hostów punktów końcowych i etykiety tożsamości poza każdym inwentarzem wklejanym do zgłoszenia. Przydatna część to typ i identyfikator; reszta to kontekst, którego obcy nie potrzebuje. Zredaguj resztę przed udostępnieniem i powiedz, że to zrobiłeś, żeby nikt się nie zastanawiał, co oznaczają luki.

Lokalizacje keyfile nie znaczą tego samego

Z natywną wtyczką keyfile pliki połączeń mogą pojawiać się w trzech katalogach, a różnica między nimi to trwałość, nie wygoda.

Edycja kopii środowiska uruchomieniowego wygląda na udaną do następnego startu, kiedy zmiana wyparowuje, a plik wygląda na tajemniczo przywrócony. Edycja kopii dostarczanej przez pakiet działa do chwili, gdy aktualizacja ją zastąpi, co jest wolniejszą i bardziej mylącą wersją tej samej lekcji.

Dokumentacja keyfile dodaje szczegół, który warto szanować: te pliki mogą zawierać klucze prywatne i hasła, a NetworkManager ignoruje każdy keyfile, który użytkownicy inni niż root mogą czytać lub zapisywać. Rozszerzanie uprawnień katalogu, by szukać ustawienia, psuje zachowanie ładowania, które próbowałeś zbadać.

Gdy Netplan posiada trwałość

W Ubuntu integracja NetworkManager opisana w dokumentacji Netplan, dostępna od 23.10, zmienia miejsce, w którym mieszka trwała kopia. Dla połączeń nietymczasowych zapisuje /etc/netplan/90-NM-<connection UUID>.yaml i generuje efemeryczny profil NetworkManager pod /run/NetworkManager/system-connections/.

To integracja dystrybucji, a nie reguła dla każdej instalacji NetworkManager. Zanim zaczniesz szukać pliku YAML, potwierdź, że zainstalowane pakiety naprawdę jej używają. Pamiętaj też, że profil środowiska uruchomieniowego może być wygenerowanym przedstawieniem czegoś innego, a nie źródłem wartym edycji. Dwie komendy sprawdzenia oszczędzają godzinę edycji złego pliku.

Udokumentowany przykład przechowuje połączenie OpenVPN przez typ Netplan nm-devices z danymi przekazywania NetworkManager. To, że Netplan nie ma własnej interpretacji konkretnego pola VPN, nie oznacza, że zapisany VPN przepadł; oznacza, że pole podróżuje jako nieprzezroczyste dane.

Interfejsy przejściowe nie są profilami

Aktywacja tworzy tymczasowe połączenia i interfejsy wirtualne, które nigdy nie miały trwać. Integracja celowo nie zapisuje nowego pliku YAML dla każdego z nich, więc ich brak w /etc/netplan nic nie mówi o tym, czy profil nadrzędny jest zapisany.

Jeśli tropisz plik, który pojawia się i znika, prawdopodobnie patrzysz na jeden z tych, a nie na swoją konfigurację. Sprawdź, czy przetrwa restart, zanim wyciągniesz jakikolwiek wniosek z jego zawartości. Plik środowiska uruchomieniowego, który znika przy restarcie, mówi ci, że nigdy nie był źródłem, i ta jedna obserwacja przekierowuje całe śledztwo. Wyjaśnia też, dlaczego edycja wtedy wyglądała na udaną.

Sekrety i własność

Profil może wskazywać certyfikat lub klucz przechowywany zupełnie gdzie indziej, a hasło może należeć do NetworkManager, być dostarczane przez tajnego agenta sesji użytkownika, albo celowo nie być zapisywane. Znalezienie jednego pliku rozstrzyga więc bardzo niewiele o tym, czego będzie wymagał start bez nadzoru.

Sprawdź odwołania i flagi sekretów bez drukowania tajnych wartości. Logowanie do pulpitu może udostępnić agenta, którego nie było podczas rozruchu, a skopiowanie wygenerowanego pliku środowiska uruchomieniowego nie odtwarza tego agenta. Praktycznym objawem jest tunel, który łączy się, gdy ktoś się zaloguje, a zawodzi, gdy maszyna startuje sama. Ten wzorzec wskazuje na własność sekretów, nie na routing.

Wprowadzaj zatwierdzone zmiany przez menedżera, który posiada połączenie, a następnie zweryfikuj zarówno zapisany identyfikator, jak i efektywne połączenie. Utrzymuj jednego trwałego właściciela, bo niezależna edycja importu, wygenerowanego keyfile i źródła YAML zostawia trzy konkurencyjne wyjaśnienia tego, czego użyje następne ponowne połączenie. Wybierz to, co naprawdę się utrzymuje, edytuj tylko to i zanotuj w zgłoszeniu, który plik uznałeś za autorytatywny. Następna osoba podziękuje ci za jedną linię pochodzenia.