Wi-Fi ansluter sig självt; VPN behöver en sekundär koppling

Den bärbara datorn ansluter till Wi-Fi innan du sätter dig, och VPN väntar fortfarande på ett klick. Att ställa in automatisk anslutning på VPN-profilen ändrar ingenting, eftersom den brytaren styr profilens egen aktivering och NetworkManager behandlar en VPN som en följeslagare till en basanslutning. Den dokumenterade mekanismen är basanslutningens sekundärlista, och det är en annan egenskap på en annan plats.

Automatisk anslutning är inte VPN-brytaren

En Wi-Fi- eller Ethernet-profil kan aktivera sig själv eftersom den äger en enhet. En VPN-pluginprofil äger inte en enhet i samma mening; den startas vid sidan av en anslutning som gör det. Därför ser flaggan för automatisk anslutning på VPN:en korrekt ut, sparas korrekt och ger ingen tunnel. Flaggan svarar på en fråga om profilen, inte om nätverket den behöver.

Att läsa modellen så förklarar också felläget. Basen ansluter, ingenting ber VPN:en att starta, och skrivbordet visar en frånkopplad VPN bredvid ett anslutet nätverk. Ingenting är trasigt; kopplingen skapades aldrig.

Identifiera båda profilerna med UUID

nmcli -f NAME,UUID,TYPE connection show

Välj den Wi-Fi- eller Ethernet-profil som ska utlösa tunneln, sedan den avsedda VPN-profilen. Använd UUID i stället för namn, eftersom ett namn är en etikett som kan dupliceras eller redigeras, och UUID är det som aktiveringsvägen faktiskt löser upp.

Blanda inte ihop ett profilnamn med ett gränssnittsnamn eller en adress som maskinen har just nu. Det är tre olika identifierare som råkar se likadana ut i en terminal, och att blanda dem ger en ändring som inte riktas mot något.

Lägg till VPN:en i basanslutningen

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

Plusformen lägger till i den befintliga listan; utelämnar du den ersätts listan, vilket tyst tar bort varje annan sekundär anslutning som redan var konfigurerad. Titta på det aktuella värdet först och anteckna det innan du ändrar något.

NetworkManagers anslutningsinställningar beskriver sekundärer som VPN-anslutningar som startas tillsammans med basanslutningen. Om en inbyggd WireGuard-profil är samma sorts objekt beror på hur NetworkManager hanterar den, så samma kommando kan vara fel verktyg för en tunnel som visas som ett gränssnitt i stället för som en VPN-plugin.

Det här är en ändring av anslutningspolicy, inte en brytare under körning. Använd den via vilken återanslutningsprocess som helst som driftsättningen godkänner, och räkna med att den första aktiveringen efter ändringen beter sig annorlunda än sessionen du sitter i nu.

Hemligheter är inte en del av kopplingen

En sekundär post säger «starta det här med det där». Ingenting i den lämnar över ett lösenord, låser upp en nyckelring eller svarar på en förfrågan. En profil som autentiserar fint efter en skrivbordsinloggning kan ändå misslyckas när den aktiveras i en kontext där hemlighetsagenten inte är tillgänglig.

Använd den stödda system- eller hemlighetsagentordningen för den faktiska driftsättningen. Att lagra allas lösenord i ett skript så att tunneln kan starta obevakat gör en autentiseringsdesign till en fil som överlever ägarens anställning.

Läs båda händelserna och kontrollera sedan resursen

Följ basanslutningen och VPN-aktiveringen under ett försök. En saknad VPN-händelse betyder att utlösaren aldrig konfigurerades eller att UUID:t är fel. En VPN-händelse följd av ett autentiseringsfel betyder att utlösaren kördes och att det kvarvarande problemet är inloggningsuppgifterna, vilket är en annan åtgärd.

Efter aktiveringen, begär resursen som motiverade uppsättningen i stället för att lita på ikonen. Koppla sedan från med avsikt och observera vad som händer härnäst, eftersom en koppling för autostart inte är en nödstopp och inte lovar ändlösa försök. Om kravet är «ingen trafik utan tunneln» är det en separat policy som behöver sin egen konfiguration och sitt eget test. Att förväxla de två är hur en maskin hamnar i att återansluta i en loop medan användaren tror att den är skyddad.