Innstillingene importerer ikke .ovpn-filen som CLI godtar
En profil som kobler til fra en terminal kan likevel feile i skrivebordsimporten. Sjekk programtillegget, direktivene det forkaster, og hva som faktisk ble lagret.
Samme fil kobler til fra en shell og nekter å bli importert i skrivebordspanelet. Det utelukker serveren, påloggingsdetaljene og profilsyntaksen, fordi kommandolinjeklienten allerede har tolket alle tre. Det som gjenstår, er skrivebordsbanen selv: pakkene den trenger, delmengden av direktiver den forstår, og objektet den skriver til disken. Hver av dem feiler ulikt, og meldingene peker sjelden på den riktige.
Tre ting dialogen trenger før den tolker noe
Importen kjører med brukerens tillatelser, så en fil i en mappe som bare root har tilgang til, avvises før innholdet betyr noe. Panelet viser også bare VPN-typer der NetworkManager-programtillegget er installert; uten OpenVPN-tillegget mangler alternativet i stedet for å være ødelagt. Til slutt må nettverksenheten være administrert: et grensesnitt merket som ikke administrert kan godta en lagret tilkobling som aldri vil aktiveres. Sjekk alle tre før du redigerer profilen.
To kommandoer avgjør den første runden: dpkg -l network-manager-openvpn-gnome for tillegget og nmcli device status for enhetens tilstand.
Hva importøren stille kaster bort
Skrivebordsoversettelsen retter seg mot et fast sett egenskaper. Linjer utenfor dette settet forkastes stille, og derfor kan tunnelen komme opp med deler av den tiltenkte konfigurasjonen manglende. Skript som er deklarert med up, down og script-security forsvinner vanligvis, det samme gjør alternativer for administrasjonsgrensesnittet og ekstra eksterne blokker. En rute skrevet med nøkkelordet vpn_gateway er unntaket: importøren vil ha en bokstavelig IPv4-gateway der og avbryter med en feil i stedet for å forkaste linjen.
En forkastet rute har en gjenkjennelig form. Tilkoblingen aktiveres, grensesnittet får en adresse, og ett bestemt subnett er utilgjengelig fordi ruten aldri kom inn i profilen.
Les den lagrede tilkoblingen, ikke kildefilen
Det autoritative resultatet av en import er nøkkelfilen, ikke .ovpn-filen du valgte. sudo cat /etc/NetworkManager/system-connections/office.nmconnection viser hva panelet faktisk lagret. Hvis en rute finnes der, men mangler i den levende tabellen, lyktes importen, og aktiveringen er problemet. Hvis den mangler i filen, forkastet importøren den, og ingen mengde gjenoppkobling vil gjenopprette den.
To alternative veier unngår oversettelseslaget. nmcli connection import type openvpn file ./office.ovpn skriver det samme objektet og rapporterer feil panelet skjuler.
Den eldre editoren, startet med nm-connection-editor, viser rutefelt panelet ikke har. For profiler som avhenger av skript eller direktiver som ikke støttes, behold kommandolinjeklienten og overvåk den med en tjeneste i stedet, etter å ha deaktivert skrivebordstilkoblingen slik at bare én komponent eier tunnelen.
Når importen virker, men aktiveringen ikke
Fanen Avansert beholder den transporten som ble importert eller valgt sist. En server som lytter på UDP feiler raskt når TCP velges, og meldingen sier det sjelden. En tilkobling som må starte uten en innlogget bruker, trenger hemmeligheten lagret for alle brukere, noe som er en annen innstilling enn å lagre den bare for denne økten.
Når det ikke står noe nyttig i dialogen, viser journalctl -u NetworkManager -b hvorfor aktiveringen feilet. Shellklienten berører aldri den banen, og derfor fortsetter den å virke mens skrivebordskopien ikke gjør det.
Som en siste kontroll sammenlign programtilleggets versjon med distribusjonens utgivelse. Et programtillegg som ikke passer, kan installeres rent og likevel nekte å aktivere en profil som nmcli importerer uten klage.