Keyfile aŭ Netplan: kie la VPN-profila dosiero vere konserviĝas?

Trovi la dosieron, kiun vi importis, estas la facila parto kaj ofte la malĝusta komenco. Gravas, kiun dosieron NetworkManager hodiaŭ legas kiel la konservitan konekton, kaj tio dependas de konekta identigilo kaj de tiu agorda fono, kiun la instalitaj pakoj efektive uzas. Redakti la importaĵon antaŭ ol respondi tiun demandon estas kiel funkcianta VPN fariĝas du duone ĝustaj agordoj.

La importita dosiero ne estas la konservita profilo

Tri nomoj ŝvebas ĉirkaŭ ĉiu VPN-problemo: la nomo de la konekto, la dosiernomo, kiun vi importis, kaj la virtuala interfaco, kiu aperas, kiam la tunelo leviĝas. Neniu el ili identigas la konservitan agordon, kaj konekta nomo povas esti redaktita dum la dosiero malantaŭ ĝi konservas sian originalan identigilon.

Komencu per nurlega inventaro kaj elektu la celatan VPN per identigilo anstataŭ per etikedo:

nmcli -f NAME,UUID,TYPE connection show

Tenu finpunktaĵajn gastigantnomojn kaj identecajn etikedojn ekster ajna inventaro, kiun vi algluos en bileton. La utila parto estas la tipo kaj la identigilo; la resto estas kunteksto, kiun fremdulo ne bezonas. Redaktu la reston antaŭ dividi, kaj diru, ke vi tion faris, por ke neniu demandu, kion signifas la spacoj.

Keyfile-lokoj ne signifas la saman aferon

Ĉe la denaska keyfile-kromaĵo, konektaj dosieroj povas aperi en tri dosierujoj, kaj la diferenco inter ili estas daŭreco, ne komforto.

Redakti la rultempan kopion aspektas sukcesa ĝis la sekva starto, kiam la ŝanĝo vaporiĝas kaj la dosiero aspektas mistere restarigita. Redakti la pako-provizitan kopion funkcias ĝis ĝisdatigo anstataŭigos ĝin, kio estas pli malrapida kaj pli konfuza versio de la sama leciono.

La keyfile-dokumentaro aldonas detalon indan je respekto: tiuj dosieroj povas enhavi privatajn ŝlosilojn kaj pasfrazilojn, kaj NetworkManager ignoras ajnan keyfile-dosieron, kiun uzantoj krom root povas legi aŭ skribi. Larĝigi dosierujajn permesojn por serĉi agordon rompas la ŝargan konduton, kiun vi provis ekzameni.

Kiam Netplan posedas la daŭrecon

En Ubuntu, la NetworkManager-integriĝo priskribita en la dokumentaro de Netplan, disponebla ekde 23.10, ŝanĝas, kie loĝas la daŭra kopio. Por ne-tempaj konektoj ĝi skribas /etc/netplan/90-NM-<connection UUID>.yaml kaj generas efemeran NetworkManager-profilo sub /run/NetworkManager/system-connections/.

Tio estas distribua integriĝo, ne regulo por ĉiu NetworkManager-instalaĵo. Konfirmu, ke la instalitaj pakoj efektive uzas ĝin, antaŭ ol serĉi YAML-dosieron. Memoru ankaŭ, ke rultempa profilo povas esti generita reprezento de io alia, anstataŭ la fonto inda je redakto. Du komandoj da kontrolado ŝparas horon da redaktado de la malĝusta dosiero.

La dokumentita ekzemplo konservas OpenVPN-konekton per la Netplan-tipo nm-devices kun NetworkManager-transdonaj datumoj. La fakto, ke Netplan ne havas specialan interpreton de aparta VPN-kampo, ne signifas, ke via konservita VPN perdiĝis; ĝi signifas, ke la kampo vojaĝas kiel netravideblaj datumoj.

Transiraj interfacoj ne estas profiloj

Aktivigo kreas tempajn virtualajn konektojn kaj interfacojn, kiuj neniam estis destinitaj daŭri. La integriĝo intence ne skribas novan YAML-dosieron por ĉiu el ili, do ilia foresto el /etc/netplan diras nenion pri tio, ĉu la patra profilo estas konservita.

Se vi ĉasas dosieron, kiu aperas kaj malaperas, vi verŝajne rigardas unu el ĉi tiuj anstataŭ vian agordon. Kontrolu, ĉu ĝi postvivas restarton, antaŭ ol fari ajnan konkludon el ĝia enhavo. Rultempa dosiero, kiu malaperas dum restarto, diras al vi, ke ĝi neniam estis la fonto, kaj tiu unu observo redirektas la tutan esploron. Ĝi ankaŭ klarigas, kial redakto tiam aspektis sukcesa.

Sekretoj kaj posedado

Profilo povas referenci atestilon aŭ ŝlosilon konservitan tute aliloke, kaj pasvorto povas aparteni al NetworkManager, esti provizita de sekreta agento de uzanta sesio, aŭ esti intence nekonservita. Trovado de unu dosiero do malmulte solvas pri tio, kion postulos nerigardata starto.

Ekzamenu la referencojn kaj la sekretajn flagojn sen presi sekretajn valorojn. Labortabla ensaluto povas igi disponebla agenton, kiu mankis dum la ŝargo, kaj kopii generitan rultempan dosieron ne reproduktas tiun agenton. La praktika simptomo estas tunelo, kiu konektiĝas kiam persono ensalutas kaj malsukcesas kiam la maŝino startas sola. Tiu ŝablono montras al sekreta posedado, ne al enkursigado.

Faru aprobitajn ŝanĝojn per la administrilo, kiu posedas la konekton, kaj poste kontrolu kaj la konservitan identigilon kaj la efektivan konekton. Tenu unu daŭran posedanton, ĉar sendependa redaktado de la importaĵo, generita keyfile kaj YAML-fonto lasas tri konkurantajn klarigojn pri tio, kion uzos la sekva rekonekto. Elektu tiun, kiu efektive daŭras, redaktu nur ĝin, kaj notu en la bileto, kiun dosieron vi traktis kiel aŭtoritatan. La sekva persono dankos al vi pro unu linio da deveno.