Przy każdym uruchomieniu tunel pojawia się, zanim ktokolwiek zdecydował się go użyć, a pole wyboru, które wygląda na odpowiedzialne, po odznaczeniu nic nie robi. To nie błąd interfejsu. NetworkManager nie łączy profili VPN samodzielnie; VPN startuje, bo połączenie bazowe wymienia go z nazwy. Poprawka jest w drugim profilu i to jedna właściwość.

Flaga, którą odznaczasz, nie jest brana pod uwagę

Profil VPN ma własną właściwość automatycznego łączenia, a dla połączeń VPN menedżer nie używa jej do uruchamiania czegokolwiek. Odznaczenie jej sprawia, że profil czyta się spójnie, i nie zmienia zachowania, i właśnie dlatego niespodzianka przeżywa edycję.

Udokumentowanym mechanizmem jest lista połączeń wtórnych w profilu bazowym. Gdy połączenie Wi-Fi lub Ethernet zostaje aktywowane, menedżer aktywuje także UUID-y VPN tam wymienione. Dziś w tej liście obsługiwane są tylko połączenia VPN, a jeśli zawiera kilka wpisów, jedna edycja dotyczy ich wszystkich.

Priorytet automatycznego łączenia szereguje kandydatów; to też nie jest wyłącznik.

Przeczytaj oba profile przed edycją

Najpierw zapisz nazwy, UUID-y i typy, bo wyświetlane nazwy się powtarzają, a połączenie bazowe łatwo pomylić z VPN-em. Potem odczytaj właściwości, które mają znaczenie po każdej stronie.

nmcli -f NAME,UUID,TYPE connection show
nmcli -f connection.secondaries connection show "Wired connection 1"
nmcli -f connection.autoconnect,connection.autoconnect-priority connection show "Work VPN"

W edytorze graficznym te same wartości pojawiają się pod innymi etykietami. Zakładka General połączenia bazowego zawiera ustawienie automatycznego łączenia, a gdy wtyczka jest zainstalowana, opcję podniesienia wraz z nim VPN-u. Przetłumaczony pulpit może opisać pole priorytetu jako automatyczne połączenie z priorytetem, co nie jest przełącznikiem włączania. Pomylenie obu daje odznaczone pole i niezmieniony start.

Usuń jeden wpis, nie całą listę

Właściwość jest listą, więc przypisanie nowej wartości zastępuje wszystko w niej. Użyj wiodącego minusa, aby usunąć jeden UUID i pozostawić resztę listy nietkniętą.

nmcli connection modify uuid BASE_UUID -connection.secondaries VPN_UUID
nmcli -f connection.secondaries connection show "Wired connection 1"

Sprawdź listę przed i po, zwłaszcza na maszynie zależnej od drugiego VPN-u.

Profile można ograniczyć do określonych użytkowników. Gdy tak jest, konto, z którego edytujesz, musi pojawić się na tej liście; inaczej polecenie może zostać odrzucone albo menedżer zapisze osobny profil dla użytkownika, którego pierwotny właściciel nigdy nie widzi. Sprawdź właściciela, zanim uznasz, że edycja nic nie dała, bo cicha kopia dla użytkownika wyjaśnia wiele mylących wyników.

Testuj prawdziwe przejście, nie ręczny restart

Ponowne połączenie profilu bazowego jest sensownym testem. Wyłącz go i włącz albo uruchom ponownie, a potem sprawdź listę aktywnych, listę interfejsów i wyszukanie trasy do adresu wewnętrznego.

nmcli connection show --active
ip -brief address
ip route get 10.8.0.1

Jeśli tunel nadal się pojawia, pozostałym właścicielem jest zwykle skrypt. Dziennik menedżera pokazuje, który profil i kiedy został aktywowany, a katalog dispatcher to miejsce, w którym mieszkałby hook wywołujący nmcli connection up przy zdarzeniu interfejsu. Hook jest niewidoczny w edytorze profili, dlatego przeżywa każdy eksperyment z polem wyboru.

Utrzymuj ręczną ścieżkę w działaniu, bo to jest rzeczywiste wymaganie.

Jak wygląda dobry wynik

Profil pozostaje zainstalowany wraz z bramą, certyfikatem i poświadczeniami. Nie aktywuje się przy starcie i podnosi się, gdy o to poprosisz. Te trzy zdania to test akceptacyjny.

Zapisz UUID połączenia bazowego w runbooku, bo to profil, który będziesz edytować następnym razem.

VPN dostępny, ale nie automatyczny, to wybór konfiguracji, a nie brakująca funkcja, i dzieli go jedna właściwość.

Powiązane artykuły