La agordoj ne importas la .ovpn, kiun la CLI akceptas

La sama dosiero konektiĝas el ŝelo kaj rifuzas importiĝi en la tabula panelo. Tio ekskludas la servilon, la akreditaĵojn kaj la profil-sintakson, ĉar la komandlinia kliento jam analizis ĉiujn tri. Restas la tabula vojo mem: la pakaĵoj, kiujn ĝi bezonas, la subaro de direktivoj, kiujn ĝi komprenas, kaj la objekto, kiun ĝi skribas al la disko. Ĉiu el ili malsukcesas malsame, kaj la mesaĝoj malofte montras la ĝustan.

Tri aferoj, kiujn la dialogo bezonas antaŭ ol analizi ion ajn

La importado ruliĝas kun la permesoj de via uzanto, do dosiero en dosierujo alirebla nur de root estas malakceptita antaŭ ol ĝia enhavo gravas. La panelo ankaŭ listigas nur VPN-tipojn, kies NetworkManager-kromaĵo estas instalita; sen la kromaĵo OpenVPN, la opcio mankas anstataŭ esti rompita. Fine, la reta aparato devas esti administrata: interfaco markita kiel neadministrata povas akcepti konservitan konekton, kiu neniam aktivigos. Kontrolu ĉiujn tri antaŭ ol redakti la profilon.

Du komandoj solvas la unuan raŭndon: dpkg -l network-manager-openvpn-gnome por la kromaĵo kaj nmcli device status por la aparata stato.

Kion la importantilo kviete forĵetas

La tabula traduko celas fiksan aron de ecoj. Linioj ekster tiu aro estas kviete forĵetataj, tial la tunelo povas ekfunkcii kun mankantaj partoj de la intencita agordo. Skriptoj deklaritaj per up, down kaj script-security kutime malaperas, same kiel la opcioj de la administra interfaco kaj pliaj malproksimaj blokoj. Itinero skribita per la ŝlosilvorto vpn_gateway estas la escepto: la importantilo volas tie laŭvortan IPv4-enirejon kaj ĉesas kun eraro anstataŭ forĵeti la linion.

Forĵetita itinero havas rekoneblan formon. La konekto aktiviĝas, la interfaco ricevas adreson, kaj unu specifa subreto estas neatingebla ĉar la itinero neniam eniris la profilon.

Legu la konservitan konekton, ne la fontdosieron

La aŭtoritata rezulto de importado estas la ŝlosildosiero, ne la .ovpn, kiun vi elektis. sudo cat /etc/NetworkManager/system-connections/office.nmconnection montras, kion la panelo efektive konservis. Se itinero ĉeestas tie sed mankas en la viva tabelo, la importado sukcesis kaj la aktivigo estas la problemo. Se ĝi mankas en la dosiero, la importantilo forĵetis ĝin kaj neniu kvanto da rekonektado restarigos ĝin.

Du alternativaj vojoj evitas la tradukan tavolon. nmcli connection import type openvpn file ./office.ovpn skribas la saman objekton kaj raportas erarojn, kiujn la panelo kaŝas.

La pli malnova redaktilo, lanĉita per nm-connection-editor, montras itinerajn kampojn, kiujn la panelo ne havas. Por profiloj, kiuj dependas de skriptoj aŭ nesubtenataj direktivoj, tenu la komandlinian klienton kaj prizorgu ĝin per servo anstataŭe, post malŝalto de la tabula konekto, por ke nur unu komponanto posedu la tunnelon.

Kiam la importado funkcias sed la aktivigo ne

La langeto por spertuloj retenas tiun transporton, kiu estis importita aŭ laste elektita. Servilo aŭskultanta sur UDP rapide malsukcesas, kiam TCP estas elektita, kaj la mesaĝo malofte diras tion. Konekto, kiu devas starti sen ensalutinta uzanto, bezonas sian sekreton konservitan por ĉiuj uzantoj, kio estas malsama agordo ol konservi ĝin nur por ĉi tiu seanco.

Kiam la dialogo montras nenion utilan, journalctl -u NetworkManager -b montras, kial la aktivigo malsukcesis. La ŝela kliento neniam tuŝas tiun vojon, tial ĝi daŭre funkcias, dum la tabula kopio ne.

Kiel finan kontrolon, komparu la kroman version kun la eldono de la distribuo. Nekongrua kromaĵo povas instaliĝi pure kaj tamen rifuzi aktivigi profilon, kiun nmcli importas sen plendo.