Keyfile eller Netplan: var lagras VPN-profilen egentligen?

Att hitta filen du importerade är den lätta delen och ofta den felaktiga starten. Det som spelar roll är vilken fil NetworkManager läser i dag som den sparade anslutningen, och det beror på en anslutningsidentifierare plus vilken konfigurationsbackend de installerade paketen faktiskt använder. Att redigera importen innan den frågan är besvarad är hur en fungerande VPN blir två halvkorrekta konfigurationer.

Den importerade filen är inte den sparade profilen

Tre namn svävar runt varje VPN-problem: anslutningens namn, filnamnet du importerade och det virtuella gränssnitt som dyker upp när tunneln kommer upp. Ingen av dem identifierar den sparade konfigurationen, och ett anslutningsnamn kan redigeras medan filen bakom behåller sin ursprungliga identifierare.

Börja med en skrivskyddad inventering och välj den avsedda VPN:en efter identifierare i stället för etikett:

nmcli -f NAME,UUID,TYPE connection show

Håll slutpunktsvärdnamn och identitetsetiketter utanför varje inventering du klistrar in i ett ärende. Den användbara delen är typen och identifieraren; resten är kontext som en främling inte behöver. Redigera resten innan du delar och säg att du gjorde det, så att ingen undrar vad luckorna betyder.

Keyfile-platser betyder inte samma sak

Med det inbyggda keyfile-pluginprogrammet kan anslutningsfiler dyka upp i tre kataloger, och skillnaden mellan dem är varaktighet, inte bekvämlighet.

Att redigera körtidskopian verkar lyckas fram till nästa start, då ändringen avdunstar och filen ser mystiskt återställd ut. Att redigera kopian som paketet levererar fungerar tills en uppgradering ersätter den, vilket är en långsammare och mer förvirrande version av samma lektion.

Keyfile-dokumentationen lägger till en detalj som förtjänar respekt: dessa filer kan innehålla privata nycklar och lösenfraser, och NetworkManager ignorerar varje keyfile som andra användare än root kan läsa eller skriva. Att vidga katalogbehörigheter för att leta efter en inställning bryter det inläsningsbeteende du försökte undersöka.

När Netplan äger varaktigheten

På Ubuntu ändrar NetworkManager-integrationen som beskrivs i Netplans dokumentation, tillgänglig från 23.10, var den varaktiga kopian ligger. För icke-tillfälliga anslutningar skriver den /etc/netplan/90-NM-<connection UUID>.yaml och genererar en efemär NetworkManager-profil under /run/NetworkManager/system-connections/.

Det är en distributionsintegration, inte en regel för varje NetworkManager-installation. Bekräfta att de installerade paketen faktiskt använder den innan du ger dig ut för att leta efter en YAML-fil. Kom också ihåg att en körtidsprofil kan vara en genererad representation av något annat snarare än källan som är värd att redigera. Två kommandon av kontroll sparar en timmes redigering av fel fil.

Det dokumenterade exemplet lagrar en OpenVPN-anslutning genom Netplan-typen nm-devices med genomströmningsdata från NetworkManager. Att Netplan inte har någon egen tolkning av ett visst VPN-fält betyder inte att din sparade VPN har gått förlorad; det betyder att fältet reser som ogenomskinliga data.

Tillfälliga gränssnitt är inte profiler

Aktivering skapar tillfälliga virtuella anslutningar och gränssnitt som aldrig var avsedda att bestå. Integrationen skriver medvetet inte en ny YAML-fil för var och en av dem, så deras frånvaro i /etc/netplan säger inget om huruvida den överordnade profilen är sparad.

Om du jagar en fil som dyker upp och försvinner tittar du förmodligen på en av dessa och inte på din konfiguration. Kontrollera om den överlever en omstart innan du drar någon slutsats av innehållet. En körtidsfil som försvinner vid omstart berättar att den aldrig var källan, och den enda observationen ändrar inriktning på hela undersökningen. Det förklarar också varför en ändring såg framgångsrik ut då.

Hemligheter och ägarskap

En profil kan referera till ett certifikat eller en nyckel som ligger helt någon annanstans, och ett lösenord kan tillhöra NetworkManager, levereras av en hemlig agent i användarsessionen, eller medvetet inte sparas. Att hitta en enda fil avgör därför väldigt lite om vad en obevakad start kräver.

Granska referenserna och hemlighetsflaggorna utan att skriva ut hemliga värden. En skrivbordsinloggning kan göra en agent tillgänglig som saknades vid uppstarten, och att kopiera en genererad körtidsfil återskapar inte den agenten. Det praktiska symptomet är en tunnel som ansluter när en person loggar in och misslyckas när maskinen startar ensam. Det mönstret pekar på hemlighetsägarskap, inte på routing.

Gör godkända ändringar genom hanteraren som äger anslutningen och verifiera sedan både den sparade identifieraren och den effektiva anslutningen. Håll en enda varaktig ägare, eftersom redigering av importen, en genererad keyfile och en YAML-källa separat lämnar tre konkurrerande förklaringar till vad nästa återanslutning använder. Välj den som faktiskt består, redigera bara den och notera i ärendet vilken fil du behandlade som auktoritativ. Nästa person kommer att tacka dig för en rad proveniens.