Keyfile of Netplan: waar word die VPN-profiel werklik gestoor?
’n Gestoor VPN kan in ’n keyfile of in ’n gegenereerde Netplan-lêer woon. Pas die verbinding-UUID by sy regte eienaar voordat jy iets wysig wat herskryf word.
Om die lêer wat jy ingevoer het te vind, is die maklike deel en dikwels die verkeerde begin. Wat saak maak, is watter lêer NetworkManager vandag as die gestoorde verbinding lees, en dit hang af van ’n verbinding-identifiseerder plus watter konfigurasie-agterkant die geïnstalleerde pakkette werklik gebruik. Om die invoer te wysig voordat daardie vraag beantwoord is, is hoe ’n werkende VPN twee halfkorrekte konfigurasies word.
Die ingevoerde lêer is nie die gestoorde profiel nie
Drie name sweef om elke VPN-probleem: die verbindingsnaam, die lêernaam wat jy ingevoer het, en die virtuele koppelvlak wat verskyn wanneer die tonnel opkom. Nie een van hulle identifiseer die gestoorde konfigurasie nie, en ’n verbindingsnaam kan gewysig word terwyl die lêer daaronder sy oorspronklike identifiseerder behou.
Begin met ’n lees-alleen inventaris en kies die beoogde VPN aan die hand van die identifiseerder eerder as die etiket:
nmcli -f NAME,UUID,TYPE connection show
Hou eindpunt-gasheername en identiteitsetikette uit enige inventaris wat jy in ’n kaartjie plak. Die nuttige deel is die tipe en die identifiseerder; die res is konteks wat ’n vreemdeling nie nodig het nie. Verwyder die res voordat jy dit deel, en sê dat jy dit gedoen het, sodat niemand wonder wat die leë plekke beteken nie.
Keyfile-plekke beteken nie dieselfde ding nie
Met die inheemse keyfile-inprop kan verbindingslêers in drie gidsels verskyn, en die verskil tussen hulle is blywendheid, nie gerief nie.
| Location | Role |
|---|---|
/etc/NetworkManager/system-connections/ | Administrator-owned persistence |
/usr/lib/NetworkManager/system-connections/ | Package-supplied defaults, replaced on upgrade |
/run/NetworkManager/system-connections/ | Runtime state, regenerated and not durable |
Om die looptyd-kopie te wysig lyk suksesvol tot die volgende begin, wanneer die verandering verdamp en die lêer geheimsinnig teruggerol lyk. Om die pakket-gelewerde kopie te wysig werk tot ’n opgradering dit vervang, wat ’n stadiger en verwarrender weergawe van dieselfde les is.
Die keyfile-dokumentasie voeg ’n detail by wat die moeite werd is om te respekteer: daardie lêers kan private sleutels en wagfrases bevat, en NetworkManager ignoreer enige keyfile wat gebruikers anders as root kan lees of skryf. Om gidseltoestemmings te verbreed om na ’n instelling te soek, breek die laaggedrag wat jy probeer ondersoek het.
Wanneer Netplan die blywendheid besit
Op Ubuntu verander die NetworkManager-integrasie wat in Netplan se dokumentasie beskryf word, beskikbaar vanaf 23.10, waar die blywende kopie woon. Vir nie-tydelike verbindings skryf dit /etc/netplan/90-NM-<connection UUID>.yaml en genereer ’n vlugtige NetworkManager-profiel onder /run/NetworkManager/system-connections/.
Dit is ’n distribusie-integrasie, nie ’n reël vir elke NetworkManager-installasie nie. Bevestig dat die geïnstalleerde pakkette dit werklik gebruik voordat jy na ’n YAML-lêer gaan soek. Onthou ook dat ’n looptydprofiel ’n gegenereerde voorstelling van iets anders kan wees eerder as die bron wat die moeite werd is om te wysig. Twee opdragte se kontrolering spaar ’n uur se wysiging van die verkeerde lêer.
Die gedokumenteerde voorbeeld stoor ’n OpenVPN-verbinding deur die Netplan-tipe nm-devices met NetworkManager-deurgee-data. Die feit dat Netplan geen toegewyde interpretasie van ’n bepaalde VPN-veld het nie, beteken nie dat jou gestoorde VPN verlore is nie; dit beteken die veld reis as ondeursigtige data.
Vlugtige koppelvlakke is nie profiele nie
Aktivering skep tydelike virtuele verbindings en koppelvlakke wat nooit bedoel was om te bly nie. Die integrasie skryf doelbewus nie ’n nuwe YAML-lêer vir elkeen nie, so hul afwesigheid in /etc/netplan sê niks oor of die ouerprofiel gestoor is nie.
As jy jag maak op ’n lêer wat verskyn en verdwyn, kyk jy waarskynlik na een van hierdie eerder as na jou konfigurasie. Kyk of dit ’n herbegin oorleef voordat jy enige gevolgtrekking uit die inhoud maak. ’n Looptydlêer wat met ’n herbegin verdwyn, sê vir jou dit was nooit die bron nie, en daardie enkele waarneming herlei die hele ondersoek. Dit verduidelik ook waarom ’n wysiging destyds suksesvol gelyk het.
Geheime en eienaarskap
’n Profiel kan verwys na ’n sertifikaat of sleutel wat heeltemal elders gestoor is, en ’n wagwoord kan aan NetworkManager behoort, deur ’n gebruikersessie-geheime agent verskaf word, of doelbewus nie gestoor word nie. Om ’n enkele lêer op te spoor beslis dus baie min oor wat ’n onbeheerde begin sal vereis.
Ondersoek die verwysings en die geheime-vlae sonder om geheime waardes te druk. ’n Lessenaar-aanmelding kan ’n agent beskikbaar maak wat tydens die selflaai afwesig was, en om ’n gegenereerde looptydlêer te kopieer reproduseer nie daardie agent nie. Die praktiese simptoom is ’n tonnel wat verbind wanneer iemand aanmeld en faal wanneer die masjien alleen begin. Daardie patroon wys na geheime-eienaarskap, nie na roetering nie.
Maak goedgekeurde veranderinge deur die bestuurder wat die verbinding besit, en verifieer daarna beide die gestoorde identifiseerder en die effektiewe verbinding. Hou ’n enkele blywende eienaar, want om die invoer, ’n gegenereerde keyfile en ’n YAML-bron onafhanklik te wysig, laat drie mededingende verduidelikings oor wat die volgende herverbinding sal gebruik. Kies die een wat werklik blywend is, wysig net daardie een, en noteer in die kaartjie watter lêer jy as gesaghebbend beskou het. Die volgende persoon sal jou dank vir een reël herkoms.