Wi-Fi łączy się sam; VPN potrzebuje skojarzenia wtórnego

Laptop łączy się z Wi-Fi, zanim usiądziesz, a VPN wciąż czeka na kliknięcie. Ustawienie automatycznego łączenia w profilu VPN niczego nie zmienia, bo ten przełącznik rządzi aktywacją samego profilu, a NetworkManager traktuje VPN jako towarzysza połączenia bazowego. Udokumentowanym mechanizmem jest lista połączeń wtórnych połączenia bazowego i to jest inna właściwość w innym miejscu.

Automatyczne łączenie to nie przełącznik VPN

Profil Wi-Fi lub Ethernet może aktywować się sam, ponieważ posiada urządzenie. Profil wtyczki VPN nie posiada urządzenia w tym samym sensie; jest uruchamiany obok połączenia, które je posiada. Dlatego flaga automatycznego łączenia w VPN wygląda poprawnie, zapisuje się prawidłowo i nie tworzy tunelu. Flaga odpowiada na pytanie o profil, a nie o sieć, której potrzebuje.

Takie czytanie modelu wyjaśnia też tryb awarii. Baza się łączy, nic nie prosi VPN o start, a pulpit pokazuje rozłączony VPN obok połączonej sieci. Nic nie jest zepsute; skojarzenie nigdy nie zostało utworzone.

Zidentyfikuj oba profile po UUID

nmcli -f NAME,UUID,TYPE connection show

Wybierz profil Wi-Fi lub Ethernet, który ma wyzwolić tunel, a następnie zamierzony profil VPN. Używaj UUID zamiast nazw, bo nazwa to etykieta, którą można zduplikować lub edytować, a UUID to coś, co ścieżka aktywacji naprawdę rozwiązuje.

Nie mieszaj nazwy profilu z nazwą interfejsu ani adresem, który maszyna ma w tej chwili. To trzy różne identyfikatory, które przypadkiem wyglądają podobnie w terminalu, a ich zmieszanie daje modyfikację wymierzoną w nic.

Dodaj VPN do połączenia bazowego

nmcli connection modify uuid "PRIMARY_UUID" +connection.secondaries "VPN_UUID"

Forma z plusem dopisuje do istniejącej listy; pominięcie jej zastępuje listę, co po cichu usuwa każde inne już skonfigurowane połączenie wtórne. Najpierw sprawdź bieżącą wartość i zapisz ją, zanim cokolwiek zmienisz.

Ustawienia połączeń NetworkManagera opisują połączenia wtórne jako połączenia VPN uruchamiane razem z połączeniem bazowym. To, czy natywny profil WireGuard jest tym samym rodzajem obiektu, zależy od tego, jak zarządza nim NetworkManager, więc to samo polecenie może być złym narzędziem dla tunelu, który pojawia się jako interfejs, a nie jako wtyczka VPN.

To zmiana polityki połączeń, a nie przełącznik w czasie działania. Zastosuj ją przez dowolny proces ponownego łączenia, który zatwierdza wdrożenie, i oczekuj, że pierwsza aktywacja po zmianie zachowa się inaczej niż sesja, w której teraz siedzisz.

Tajemnice nie są częścią skojarzenia

Wpis wtórny mówi «uruchom to z tamtym». Nic w nim nie przekazuje hasła, nie odblokowuje pęku kluczy ani nie odpowiada na pytanie. Profil, który po zalogowaniu do pulpitu bez problemu się uwierzytelnia, nadal może zawieść, gdy zostanie aktywowany w kontekście, w którym agent tajemnic jest niedostępny.

Użyj wspieranego układu systemowego lub agenta tajemnic w rzeczywistym wdrożeniu. Przechowywanie wszystkich haseł w skrypcie, aby tunel mógł startować bez nadzoru, zamienia projekt uwierzytelniania w plik, który przeżyje zatrudnienie jego właściciela.

Przeczytaj oba zdarzenia, a potem sprawdź zasób

Obserwuj połączenie bazowe i aktywację VPN podczas jednej próby. Brak zdarzenia VPN oznacza, że wyzwalacz nigdy nie został skonfigurowany albo UUID jest błędny. Zdarzenie VPN, po którym następuje błąd uwierzytelniania, oznacza, że wyzwalacz zadziałał, a pozostałym problemem są dane logowania, co jest inną poprawką.

Po aktywacji poproś o zasób, który uzasadnił konfigurację, zamiast ufać ikonie. Następnie rozłącz się celowo i obserwuj, co dzieje się dalej, bo skojarzenie automatycznego startu nie jest wyłącznikiem bezpieczeństwa i nie obiecuje nieskończonych ponowień. Jeśli wymaganiem jest «żaden ruch bez tunelu», to odrębna polityka wymagająca własnej konfiguracji i własnego testu. Mylenie obu to sposób, w jaki maszyna wpada w pętlę ponownego łączenia, podczas gdy użytkownik wierzy, że jest chroniony.