Keyfile vai Netplan: kur VPN profils patiešām tiek glabāts?
Saglabāts VPN var dzīvot keyfile vai ģenerētā Netplan failā. Pirms rediģējat kaut ko, kas tiek pārrakstīts, saskaņojiet savienojuma UUID ar tā īsto īpašnieku.
Atrast importēto failu ir vieglā daļa un bieži vien nepareizais sākums. Svarīgi ir tas, kuru failu NetworkManager šodien lasa kā saglabāto savienojumu, un tas ir atkarīgs no savienojuma identifikatora un konfigurācijas aizmugures, ko instalētās pakotnes patiešām izmanto. Importa rediģēšana pirms atbildes uz šo jautājumu ir ceļš, kā strādājošs VPN kļūst par divām daļēji pareizām konfigurācijām.
Importētais fails nav saglabātais profils
Ap katru VPN problēmu riņķo trīs vārdi: savienojuma nosaukums, importētā faila nosaukums un virtuālā saskarne, kas parādās, kad tunelis paceļas. Neviens no tiem neidentificē saglabāto konfigurāciju, un savienojuma nosaukumu var rediģēt, kamēr fails aiz tā saglabā savu sākotnējo identifikatoru.
Sāciet ar tikai lasāmu inventarizāciju un izvēlieties vajadzīgo VPN pēc identifikatora, nevis etiķetes:
nmcli -f NAME,UUID,TYPE connection show
Turiet galapunktu resursdatoru nosaukumus un identitātes etiķetes ārpus jebkuras inventarizācijas, ko ielīmējat biļetē. Noderīgā daļa ir tips un identifikators; pārējais ir konteksts, kas svešiniekam nav vajadzīgs. Pirms kopīgošanas aizsedziet pārējo un pasakiet, ka to izdarījāt, lai neviens nebrīnās, ko nozīmē tukšās vietas.
keyfile atrašanās vietas nenozīmē vienu un to pašu
Ar vietējo keyfile spraudni savienojumu faili var parādīties trīs mapēs, un atšķirība starp tām ir noturība, nevis ērtība.
| 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 |
Izpildlaika kopijas rediģēšana šķiet veiksmīga līdz nākamajai palaišanai, kad izmaiņas iztvaiko un fails izskatās noslēpumaini atgriezts. Pakotnes piegādātās kopijas rediģēšana darbojas, līdz atjauninājums to aizstāj, un tā ir lēnāka un mulsinošāka tās pašas mācības versija.
keyfile dokumentācija pievieno detaļu, ko ir vērts respektēt: šajos failos var būt privātās atslēgas un paroles frāzes, un NetworkManager ignorē jebkuru keyfile, ko var lasīt vai rakstīt lietotāji, kas nav root. Mapes atļauju paplašināšana iestatījuma meklēšanai salauž ielādes uzvedību, ko mēģinājāt pārbaudīt.
Kad Netplan pārvalda noturību
Ubuntu Netplan dokumentācijā aprakstītā NetworkManager integrācija, kas pieejama no 23.10, maina vietu, kur dzīvo noturīgā kopija. Ne-pagaidu savienojumiem tā raksta /etc/netplan/90-NM-<connection UUID>.yaml un ģenerē īslaicīgu NetworkManager profilu zem /run/NetworkManager/system-connections/.
Tā ir distribūcijas integrācija, nevis noteikums katrai NetworkManager instalācijai. Pirms doties meklēt YAML failu, pārliecinieties, ka instalētās pakotnes to patiešām izmanto. Atcerieties arī, ka izpildlaika profils var būt kaut kā cita ģenerēts attēlojums, nevis avots, ko ir vērts rediģēt. Divas komandas pārbaudes ietaupa stundu, rediģējot nepareizo failu.
Dokumentētais piemērs saglabā OpenVPN savienojumu caur Netplan nm-devices tipu ar NetworkManager caurlaides datiem. Tas, ka Netplan nav īpašas interpretācijas konkrētam VPN laukam, nenozīmē, ka jūsu saglabātais VPN ir pazaudēts; tas nozīmē, ka lauks ceļo kā necaurredzami dati.
Pārejošas saskarnes nav profili
Aktivizācija rada pagaidu virtuālos savienojumus un saskarnes, kas nekad nebija paredzēti palikšanai. Integrācija apzināti neraksta jaunu YAML failu katram no tiem, tāpēc to neesamība /etc/netplan mapē neko nepasaka par to, vai vecākprofils ir saglabāts.
Ja vajājat failu, kas parādās un pazūd, jūs, iespējams, skatāties uz vienu no šiem, nevis savu konfigurāciju. Pārbaudiet, vai tas pārdzīvo restartu, pirms izdarāt jebkādu secinājumu no tā satura. Izpildlaika fails, kas pazūd pārstartēšanas laikā, pasaka, ka tas nekad nav bijis avots, un šis vienīgais novērojums novirza visu izmeklēšanu citur. Tas arī izskaidro, kāpēc rediģēšana toreiz šķita veiksmīga.
Noslēpumi un īpašumtiesības
Profils var atsaukties uz citur glabātu sertifikātu vai atslēgu, un parole var piederēt NetworkManager, to var nodrošināt lietotāja sesijas slepens aģents, vai arī tā var apzināti netikt saglabāta. Tāpēc viena faila atrašana ļoti maz izšķir par to, kas būs vajadzīgs uzraudzībai nepakļautai palaišanai.
Pārbaudiet atsauces un slepenos karodziņus, neizdrukājot slepenas vērtības. Darbvirsmas pieteikšanās var padarīt pieejamu aģentu, kas starta laikā nebija, un ģenerēta izpildlaika faila kopēšana šo aģentu neatveido. Praktiskais simptoms ir tunelis, kas savienojas, kad cilvēks piesakās, un neizdodas, kad iekārta startē viena. Šis modelis norāda uz noslēpumu īpašumtiesībām, nevis maršrutēšanu.
Veiciet apstiprinātās izmaiņas caur pārvaldnieku, kuram pieder savienojums, un pēc tam pārbaudiet gan saglabāto identifikatoru, gan faktisko savienojumu. Turiet vienu noturīgu īpašnieku, jo importa, ģenerēta keyfile un YAML avota neatkarīga rediģēšana atstāj trīs konkurējošus skaidrojumus par to, ko izmantos nākamā atkārtotā savienošanās. Izvēlieties to, kas patiešām saglabājas, rediģējiet tikai to un biļetē atzīmējiet, kuru failu uzskatījāt par autoritatīvu. Nākamais cilvēks pateiksies par vienu izcelsmes rindu.