Instellings voer nie die .ovpn in wat die CLI aanvaar nie

Dieselfde lêer verbind vanaf 'n shell en weier om in die lessenaarpaneel ingevoer te word. Dit sluit die bediener, die geloofsbriewe en die profielsintaksis uit, want die opdraglynkliënt het al drie reeds verwerk. Wat oorbly, is die lessenaarpaad self: die pakkette wat dit nodig het, die subset opdragte wat dit verstaan, en die objek wat dit op skyf skryf. Elkeen van dié misluk anders, en die boodskappe wys selde na die regte een.

Drie dinge wat die dialoog nodig het voordat dit enigiets verwerk

Die invoer loop met jou gebruiker se regte, so 'n lêer onder 'n gids wat net vir root toeganklik is, word verwerp voordat die inhoud saak maak. Die paneel lys ook net VPN-tipes waarvan die NetworkManager-inprop geïnstalleer is; sonder die OpenVPN-inprop is die opsie afwesig eerder as stukkend. Laastens moet die netwerktoestel bestuur word: 'n koppelvlak wat as onbestuur gemerk is, kan 'n gestoorde verbinding aanvaar wat nooit sal aktiveer nie. Kontroleer al drie voordat jy die profiel wysig.

Twee opdragte besleg die eerste rondte: dpkg -l network-manager-openvpn-gnome vir die inprop en nmcli device status vir die toesteltoestand.

Wat die invoerder stilweg weggooi

Die lessenaarvertaling teiken 'n vaste stel eienskappe. Reëls buite dié stel word stilweg verwerp, en daarom kan die tonnel opkom met dele van die beoogde konfigurasie wat ontbreek. Skripte wat met up, down en script-security verklaar word, verdwyn gewoonlik, net soos bestuurskoppelvlak-opsies en bykomende remote-blokke. 'n Roete wat met die vpn_gateway-sleutelwoord geskryf is, is die uitsondering: die invoerder wil 'n letterlike IPv4-gateway daar hê en staak met 'n fout eerder as om die reël te laat val.

'n Weggelate roete het 'n herkenbare vorm. Die verbinding aktiveer, die koppelvlak kry 'n adres, en een spesifieke subnet is onbereikbaar omdat die roete nooit in die profiel beland het nie.

Lees die gestoorde verbinding, nie die bronlêer nie

Die gesaghebbende resultaat van 'n invoer is die sleutellêer, nie die .ovpn wat jy gekies het nie. sudo cat /etc/NetworkManager/system-connections/office.nmconnection wys wat die paneel werklik gestoor het. As 'n roete daar teenwoordig is maar in die lewende tabel ontbreek, het die invoer geslaag en is aktivering die probleem. As dit in die lêer ontbreek, het die invoerder dit laat val en geen hoeveelheid herverbinding sal dit herstel nie.

Twee alternatiewe paaie vermy die vertaallaag. nmcli connection import type openvpn file ./office.ovpn skryf dieselfde objek en rapporteer foute wat die paneel wegsteek.

Die ouer redigeerder, wat met nm-connection-editor begin word, wys roetevelde wat die paneel nie het nie. Vir profiele wat van skripte of onondersteunde opdragte afhanklik is, hou die opdraglynkliënt en bestuur dit eerder met 'n diens, nadat jy die lessenaarverbinding gedeaktiveer het sodat net een komponent die tonnel besit.

Wanneer die invoer werk maar aktivering nie

Die gevorderde oortjie behou watter vervoer ook al ingevoer of laas gekies is. 'n Bediener wat op UDP luister, misluk vinnig wanneer TCP gekies word, en die boodskap sê dit selde. 'n Verbinding wat sonder 'n aangemelde gebruiker moet begin, het sy geheim vir alle gebruikers gestoor nodig, wat 'n ander instelling is as om dit net vir hierdie sessie te stoor.

Met niks nuttigs in die dialoog nie, wys journalctl -u NetworkManager -b waarom aktivering misluk het. Die shell-kliënt raak nooit daardie pad aan nie, en daarom bly dit werk terwyl die lessenaarkopie dit nie doen nie.

As 'n finale kontrole, vergelyk die inpropweergawe met die verspreidingsvrystelling. 'n Inprop wat nie ooreenstem nie, kan skoon installeer en steeds weier om 'n profiel te aktiveer wat nmcli sonder klagte invoer.