Keyfile o Netplan: saan ba talaga naka-store ang profile ng VPN?

Ang paghahanap ng file na in-import mo ang madaling bahagi at kadalasan ang maling simula. Ang mahalaga ay kung aling file ang binabasa ng NetworkManager ngayon bilang naka-save na koneksyon, at iyon ay nakadepende sa identifier ng koneksyon at sa backend ng configuration na aktwal na ginagamit ng mga naka-install na package. Ang pag-edit ng import bago sagutin ang tanong na iyon ay kung paano ang gumaganang VPN ay nagiging dalawang kalahating-tamang configuration.

Ang na-import na file ay hindi ang naka-save na profile

Tatlong pangalan ang lumulutang sa paligid ng bawat problema sa VPN: ang pangalan ng koneksyon, ang pangalan ng file na in-import mo, at ang virtual interface na lumalabas kapag umangat ang tunnel. Wala sa kanila ang tumutukoy sa naka-save na configuration, at ang pangalan ng koneksyon ay maaaring i-edit habang ang file sa likod nito ay nagpapanatili ng orihinal nitong identifier.

Magsimula sa read-only na imbentaryo at piliin ang nais na VPN sa pamamagitan ng identifier kaysa label:

nmcli -f NAME,UUID,TYPE connection show

Ilayo ang mga hostname ng endpoint at label ng pagkakakilanlan mula sa anumang imbentaryong idinidikit mo sa isang ticket. Ang kapaki-pakinabang na bahagi ay ang uri at identifier; ang natitira ay kontekstong hindi kailangan ng estranghero. I-redact ang natitira bago ibahagi at sabihin na ginawa mo iyon, para walang magtaka kung ano ang ibig sabihin ng mga patlang.

Ang mga lokasyon ng keyfile ay hindi parehong ibig sabihin

Sa native na keyfile plugin, ang mga file ng koneksyon ay maaaring lumitaw sa tatlong direktoryo, at ang pagkakaiba sa pagitan ng mga ito ay pagtitiyaga, hindi kaginhawahan.

Ang pag-edit sa runtime copy ay mukhang matagumpay hanggang sa susunod na pagsisimula, kung kailan naglalaho ang pagbabago at ang file ay mukhang misteryosong naibalik. Ang pag-edit sa copy na ibinibigay ng package ay gumagana hanggang palitan ito ng isang upgrade, na isang mas mabagal at mas nakakalitong bersyon ng parehong aral.

Ang dokumentasyon ng keyfile ay nagdaragdag ng detalyeng dapat igalang: ang mga file na iyon ay maaaring maglaman ng mga pribadong key at passphrase, at binabalewala ng NetworkManager ang anumang keyfile na mababasa o maisusulat ng mga user na hindi root. Ang pagpapalawak ng mga pahintulot ng direktoryo para maghanap ng setting ay sumisira sa pag-uugali ng pag-load na sinusubukan mong siyasatin.

Kapag ang Netplan ang may-ari ng pagtitiyaga

Sa Ubuntu, binabago ng integrasyon ng NetworkManager na inilarawan sa dokumentasyon ng Netplan, na available mula 23.10, kung saan naninirahan ang matibay na kopya. Para sa mga hindi pansamantalang koneksyon nagsusulat ito ng /etc/netplan/90-NM-<connection UUID>.yaml at bumubuo ng ephemeral na NetworkManager profile sa ilalim ng /run/NetworkManager/system-connections/.

Iyon ay integrasyon ng distribusyon, hindi isang tuntunin para sa bawat pag-install ng NetworkManager. Kumpirmahin na aktwal na ginagamit ito ng mga naka-install na package bago ka maghanap ng YAML file. Tandaan din na ang runtime profile ay maaaring isang generated na representasyon ng ibang bagay kaysa sa source na sulit i-edit. Dalawang utos ng pagsuri ang nagse-save ng isang oras sa pag-edit ng maling file.

Ang dokumentadong halimbawa ay nag-iimbak ng OpenVPN na koneksyon sa pamamagitan ng uri ng Netplan nm-devices na may passthrough data ng NetworkManager. Ang katotohanang walang dedikadong interpretasyon ang Netplan sa isang partikular na field ng VPN ay hindi nangangahulugang nawala ang naka-save mong VPN; nangangahulugan itong naglalakbay ang field bilang opaque na data.

Ang mga transient na interface ay hindi profile

Ang pag-activate ay lumilikha ng pansamantalang virtual na koneksyon at interface na hindi kailanman nilayong tumagal. Sadyang hindi nagsusulat ang integrasyon ng bagong YAML file para sa bawat isa sa kanila, kaya ang kanilang kawalan sa /etc/netplan ay walang sinasabi tungkol sa kung naka-save ang parent profile.

Kung hinahabol mo ang isang file na lumilitaw at nawawala, malamang na tinitingnan mo ang isa sa mga ito at hindi ang iyong configuration. Suriin kung nakakaligtas ito sa restart bago magbigay ng anumang konklusyon mula sa nilalaman nito. Ang runtime file na nawawala sa reboot ay nagsasabi sa iyo na hindi kailanman ito ang source, at ang nag-iisang obserbasyong iyon ay nagbabago ng direksyon ng buong imbestigasyon. Ipinapaliwanag din nito kung bakit ang isang pag-edit ay mukhang matagumpay noon.

Mga sikreto at pagmamay-ari

Ang isang profile ay maaaring sumangguni sa isang sertipiko o key na naka-store sa ibang lugar, at ang password ay maaaring pag-aari ng NetworkManager, ibinigay ng secret agent ng session ng user, o sadyang hindi naka-save. Kaya ang paghahanap ng isang file ay napakakaunting nireresolba tungkol sa kung ano ang kakailanganin ng startup na walang pagsubaybay.

Siyasatin ang mga reference at secret flag nang hindi nagpi-print ng mga lihim na halaga. Ang pag-login sa desktop ay maaaring gawing available ang agent na wala noong boot, at ang pagkopya ng generated na runtime file ay hindi nagre-reproduce ng agent na iyon. Ang praktikal na sintomas ay isang tunnel na kumokonekta kapag may pumapasok at nabigo kapag ang makina ay nagsimula nang mag-isa. Ang pattern na iyon ay tumuturo sa pagmamay-ari ng mga sikreto, hindi sa routing.

Gawin ang mga aprubadong pagbabago sa pamamagitan ng manager na may-ari ng koneksyon, pagkatapos ay i-verify ang parehong naka-save na identifier at ang epektibong koneksyon. Panatilihin ang isang matibay na may-ari, dahil ang pag-edit ng import, generated na keyfile at source ng YAML nang hiwalay ay nag-iiwan ng tatlong magkakumpitensyang paliwanag kung ano ang gagamitin ng susunod na muling pagkonekta. Piliin ang aktwal na tumatagal, i-edit lamang iyon, at itala sa ticket kung aling file ang itinuring mong awtoridad. Pasasalamatan ka ng susunod na tao para sa isang linya ng pinagmulan.