Wi-Fi kobler seg til selv; VPN trenger en sekundær tilknytning

Bærbaren kobler seg til Wi-Fi før du setter deg, og VPN venter fortsatt på et klikk. Å sette automatisk tilkobling på VPN-profilen endrer ingenting, fordi den bryteren styrer profilens egen aktivering, og NetworkManager behandler en VPN som en følgesvenn til en basisforbindelse. Den dokumenterte mekanismen er basisforbindelsens sekundærliste, og det er en annen egenskap på et annet sted.

Automatisk tilkobling er ikke VPN-bryteren

En Wi-Fi- eller Ethernet-profil kan aktivere seg selv fordi den eier en enhet. En VPN-pluginprofil eier ikke en enhet i samme forstand; den startes sammen med en forbindelse som gjør det. Derfor ser flagget for automatisk tilkobling på VPN-en riktig ut, lagres korrekt og gir ingen tunnel. Flagget svarer på et spørsmål om profilen, ikke om nettverket den trenger.

Å lese modellen slik forklarer også feilmodusen. Basisforbindelsen kobles opp, ingenting ber VPN-en starte, og skrivebordet viser en frakoblet VPN ved siden av et tilkoblet nettverk. Ingenting er ødelagt; tilknytningen ble aldri laget.

Identifiser begge profilene med UUID

nmcli -f NAME,UUID,TYPE connection show

Velg Wi-Fi- eller Ethernet-profilen som skal utløse tunnelen, deretter den tiltenkte VPN-profilen. Bruk UUID-er i stedet for navn, fordi et navn er en etikett som kan dupliseres eller redigeres, og UUID-en er det aktiveringsveien faktisk løser opp.

Ikke forveksle et profilnavn med et grensesnittnavn eller en adresse maskinen har akkurat nå. Det er tre forskjellige identifikatorer som tilfeldigvis ser like ut i en terminal, og å blande dem gir en endring som ikke retter seg mot noe.

Føy VPN-en til basisforbindelsen

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

Plussformen legger til i den eksisterende listen; utelater du den, erstattes listen, noe som stille fjerner enhver annen sekundær forbindelse som allerede var konfigurert. Se på gjeldende verdi først og noter den før du endrer noe.

NetworkManagers forbindelsesinnstillinger beskriver sekundære som VPN-forbindelser som startes sammen med basisforbindelsen. Om en innebygd WireGuard-profil er samme slags objekt avhenger av hvordan NetworkManager håndterer den, så samme kommando kan være feil verktøy for en tunnel som vises som et grensesnitt i stedet for som en VPN-plugin.

Dette er en endring av forbindelsespolicy, ikke en bryter under kjøring. Bruk den via hvilken som helst gjenoppkoblingsprosess utrullingen godkjenner, og forvent at den første aktiveringen etter endringen oppfører seg annerledes enn økten du sitter i nå.

Hemmeligheter er ikke en del av tilknytningen

En sekundær oppføring sier «start dette med det». Ingenting i den overleverer et passord, låser opp en nøkkelring eller svarer på en forespørsel. En profil som autentiserer fint etter en skrivebordsinnlogging, kan fortsatt feile når den aktiveres i en sammenheng der hemmelighetsagenten ikke er tilgjengelig.

Bruk den støttede system- eller hemmelighetsagentordningen for den faktiske utrullingen. Å lagre alles passord i et skript slik at tunnelen kan starte uten tilsyn, gjør et autentiseringsdesign om til en fil som overlever eierens ansettelse.

Les begge hendelsene, og kontroller deretter ressursen

Følg med på basisforbindelsen og VPN-aktiveringen under ett forsøk. En manglende VPN-hendelse betyr at utløseren aldri ble konfigurert, eller at UUID-en er feil. En VPN-hendelse etterfulgt av en autentiseringsfeil betyr at utløseren kjørte, og at det gjenværende problemet er påloggingsinformasjonen, som er en annen retting.

Etter aktivering, be om ressursen som motiverte oppsettet i stedet for å stole på ikonet. Koble deretter fra med vilje og se hva som skjer videre, fordi en tilknytning for automatisk start ikke er en nødstopp og ikke lover endeløse forsøk. Hvis kravet er «ingen trafikk uten tunnelen», er det en egen policy som trenger sin egen konfigurasjon og sin egen test. Å forveksle de to er hvordan en maskin ender med å koble til på nytt i en løkke mens brukeren tror den er beskyttet.