nmcli-listigo de VPN: konservitaj profiloj kontraŭ aktivaj tuneloj

Vi rulas nmcli connection show atendante liston de VPN-oj kaj ricevas ĉiun konekton, kiun la maŝino iam konservis, inkluzive ponton kaj hotspot-on. La VPN, kiun vi serĉas, eble estas tie, eble estas tipigita kiel io alia ol vpn, aŭ eble tute ne estas NetworkManager-konekto. Por scii, en kiu el tiuj tri kazoj vi troviĝas, necesas du komandoj.

Du listoj, du demandoj

connection show respondas, kion NetworkManager konservis, kaj connection show --active respondas, kio nun estas alkroĉita al aparato. La unua listo inkluzivas neaktivajn profilojn, kaj tio estas intenca: konservita VPN, kiu estas malŝaltita, restas profilo, kiun vi eble devos ripari. Konfuzi la du kreas la impreson, ke tunelo funkcias, dum ekzistas nur ĝia agordo.

Elektu kampojn anstataŭ legi la defaŭltan tabelon, ĉar la defaŭlta eligo kaŝas la tipon sur mallarĝaj terminaloj kaj faldas longajn nomojn.

NAME, UUID kaj TYPE kutime sufiĉas por unua trarigardo, kaj poste vi inspektas la solan rikordon, kiu interesas vin, laŭ UUID.

TYPE estas la loko, kie estas la surprizoj

OpenVPN konektoj administrataj per la kromprogramo aperas kiel tipo vpn, ĉar la kromprogramo estas servo ene de la ĝenerala VPN-kadro. Denaska subteno por WireGuard estas propra unuaklasa konekta tipo, do filtrado laŭ vpn ne trovos ĝin. Serĉo pri WireGuard-tunelo, kiu redonas nenion, kutime estas filtra problemo, ne mankanta profilo. Tio estas arkitektura diferenco, ne kaprico de nomado.

La sama validas por aliaj tunelaj tipoj, kiujn NetworkManager laŭtempe lernis trakti denaske, do legu la kolumnon TYPE antaŭ ol konkludi, ke io mankas.

Listigu ĉion kaj filtru poste, kaj la profilo aperos.

Legu la UUID, ne nur la nomon

Nomoj estas etikedoj, kiujn homoj redaktas, kaj du profiloj povas kunhavi unu post senzorga importo. La UUID estas la identeco, al kiu komandoj kaj dosieroj referencas. Kiam rikordo aspektas duobla, komparu la UUID kaj la subajn agordojn antaŭ ol forigi ion.

Aktivigaj komandoj akceptas ambaŭ, kaj ĝuste tial nom-bazita kutimo eventuale modifas la malĝustan profilon.

Kopiu la UUID en viajn notojn, kiam vi ŝanĝas ion, kion vi eble devos malfari.

Kion konservita profilo ne diras al vi

Konservita profilo diras nenion pri tio, ĉu ĝia tunelo estas supren, kaj aktiva konekto diras nenion pri tio, ĉu la trafiko ene de ĝi funkcias. Tunelo lanĉita de wg-quick aŭ de serva unuo tute ne estas NetworkManager-konekto, do ĝi mankas en ambaŭ listoj dum la interfaco klare pasigas trafikon. Kontrolu la interfacon kaj la enkursigan tabelon antaŭ ol supozi, ke la profilo mankas. Malplena listo pruvas nur, ke NetworkManager ne estas la posedanto.

Du administriloj por la sama interfaco estas la alia versio de ĉi tiu problemo, kaj ĝi produktas liston, kiu aspektas ĝusta, dum la kernostato estas posedata de io alia.

Unu posedanto por interfaco tenas la liston honesta, kaj la nmcli-referenco dokumentas, kiujn kampojn ĉiu vido efektive raportas.

Raportu sen liki sekretojn

connection show kun nomo presas agordojn, kaj aldono de --show-secrets presas la privatajn ŝlosilojn kaj pasvortojn kune kun ili. Por problemtrakta aliigo en bileton tiuj ne necesas. Anstataŭe raportu la tipon, la UUID, la staton kaj la koncernajn itinerojn, kaj kaŝu ĉion, kio venis el sekreta konservejo.

Interaga aktivigo per --ask estas la subtenata maniero liveri mankantan legitimilon, kaj senprizorga aŭtomatigo bezonas alian aprobitan aranĝon anstataŭ konservitan pasvorton en klara teksto.

Mallonga, kaŝita raporto estas pli facile revidebla ol plena elĵeto.