Lista VPN w nmcli: zapisane profile a aktywne tunele

Uruchamiasz nmcli connection show, oczekując listy VPN, a dostajesz każde połączenie, jakie maszyna kiedykolwiek zapisała, w tym most i hotspot. Szukanego VPN może tam być, może być innego typu niż vpn albo wcale nie być połączeniem NetworkManager. Aby wiedzieć, który z tych trzech przypadków zachodzi, potrzeba dwóch poleceń.

Dwie listy, dwa pytania

connection show odpowiada, co zapisał NetworkManager, a connection show --active odpowiada, co jest obecnie podłączone do urządzenia. Pierwsza lista obejmuje nieaktywne profile i to jest zamierzone: zapisany VPN, który leży, nadal jest profilem, który możesz musieć naprawić. Pomylenie obu daje wrażenie, że tunel działa, gdy istnieje tylko jego konfiguracja.

Wybieraj pola zamiast czytać domyślną tabelę, ponieważ domyślne wyjście ukrywa typ na wąskich terminalach i zawija długie nazwy.

NAME, UUID i TYPE to zwykle wszystko, czego trzeba na pierwszy rzut oka, a potem sprawdzasz jedyny interesujący wpis po UUID.

TYPE to miejsce, w którym są niespodzianki

OpenVPN połączenia zarządzane przez wtyczkę pojawiają się jako typ vpn, ponieważ wtyczka jest usługą wewnątrz ogólnych ram VPN. Rodzime wsparcie WireGuard jest osobnym pełnoprawnym typem połączenia, więc filtrowanie po vpn go nie znajdzie. Wyszukiwanie tunelu WireGuard, które nic nie zwraca, to zwykle problem filtra, a nie brakujący profil. To różnica architektoniczna, a nie dziwactwo nazewnictwa.

To samo dotyczy innych typów tuneli, których NetworkManager z czasem nauczył się obsługiwać rodzimie, więc przeczytaj kolumnę TYPE, zanim uznasz, że czegoś brakuje.

Wypisz wszystko i odfiltruj później, a profil się pojawi.

Czytaj UUID, nie tylko nazwę

Nazwy to etykiety, które ludzie edytują, a dwa profile mogą dzielić jedną po nieuważnym imporcie. UUID to tożsamość, do której odwołują się polecenia i pliki. Gdy wpis wygląda na duplikat, porównaj UUID i ustawienia bazowe, zanim cokolwiek usuniesz.

Polecenia aktywacji przyjmują oba, i właśnie dlatego nawyk oparty na nazwie prędzej czy później zmienia niewłaściwy profil.

Skopiuj UUID do notatek, gdy zmieniasz coś, co być może będziesz musiał cofnąć.

Czego zapisany profil ci nie powie

Zapisany profil nic nie mówi o tym, czy jego tunel jest podniesiony, a aktywne połączenie nic nie mówi o tym, czy ruch w nim działa. Tunel uruchomiony przez wg-quick lub jednostkę usługi wcale nie jest połączeniem NetworkManager, więc brakuje go na obu listach, choć interfejs wyraźnie przepuszcza ruch. Sprawdź interfejs i tablicę routingu, zanim uznasz, że profilu brak. Pusta lista dowodzi tylko, że NetworkManager nie jest właścicielem.

Dwaj menedżerowie dla tego samego interfejsu to druga wersja tego problemu, i daje listę, która wygląda poprawnie, gdy stan jądra należy do czegoś innego.

Jeden właściciel na interfejs utrzymuje listę uczciwą, a odnośnik nmcli dokumentuje, które pola każdy widok faktycznie raportuje.

Zgłaszaj bez wyciekania sekretów

connection show z nazwą wypisuje ustawienia, a dodanie --show-secrets wypisuje klucze prywatne i hasła razem z nimi. Do wklejenia diagnozy w zgłoszeniu nie są potrzebne. Zamiast tego zgłoś typ, UUID, stan i odpowiednie trasy, a wszystko, co przyszło z magazynu sekretów, zamaż.

Interaktywna aktywacja z --ask to wspierany sposób podania brakujących danych logowania, a automatyzacja bez nadzoru wymaga innego zatwierdzonego rozwiązania zamiast zapisanego hasła w czystym tekście.

Krótki, zamazany raport jest łatwiejszy do przejrzenia niż pełny zrzut.