Indstillingerne importerer ikke den .ovpn, som CLI'en accepterer
En profil, der forbinder fra en terminal, kan stadig fejle i desktop-importen. Kontroller pluginnet, de direktiver det smider væk, og hvad der faktisk blev gemt.
Den samme fil forbinder fra en shell og nægter at blive importeret i desktoppanelet. Det udelukker serveren, legitimationsoplysningerne og profilens syntaks, fordi kommandolinjeklienten allerede har parset alle tre. Det, der er tilbage, er desktopstien selv: de pakker, den kræver, den delmængde af direktiver, den forstår, og det objekt, den skriver til disken. Hver af dem fejler forskelligt, og meddelelserne peger sjældent på den rigtige.
Tre ting, dialogen skal have, før den parser noget
Importen kører med din brugers rettigheder, så en fil i en mappe, som kun root har adgang til, afvises, før indholdet betyder noget. Panelet viser også kun VPN-typer, hvis NetworkManager-plugin er installeret; uden OpenVPN-pluginnet mangler indstillingen, i stedet for at være i stykker. Endelig skal netværksenheden være administreret: en grænseflade markeret som ikke-administreret kan acceptere en gemt forbindelse, der aldrig aktiveres. Kontroller alle tre, før du redigerer profilen.
To kommandoer afgør den første runde: dpkg -l network-manager-openvpn-gnome for pluginnet og nmcli device status for enhedens tilstand.
Hvad importeren i stilhed smider væk
Desktopoversættelsen sigter mod et fast sæt egenskaber. Linjer uden for dette sæt kasseres i stilhed, og derfor kan tunnelen komme op med dele af den tilsigtede konfiguration manglende. Scripts, der er erklæret med up, down og script-security, forsvinder normalt, ligesom indstillinger for administrationsgrænsefladen og ekstra remote-blokke. En rute skrevet med nøgleordet vpn_gateway er undtagelsen: importeren vil have en bogstavelig IPv4-gateway der og afbryder med en fejl i stedet for at droppe linjen.
En droppet rute har en genkendelig form. Forbindelsen aktiveres, grænsefladen får en adresse, og et bestemt undernet er utilgængeligt, fordi ruten aldrig nåede ind i profilen.
Læs den gemte forbindelse, ikke kildefilen
Det autoritative resultat af en import er nøglefilen, ikke den .ovpn, du valgte. sudo cat /etc/NetworkManager/system-connections/office.nmconnection viser, hvad panelet faktisk gemte. Hvis en rute findes der, men mangler i den levende tabel, lykkedes importen, og aktiveringen er problemet. Hvis den mangler i filen, droppede importeren den, og ingen mængde genopkobling vil gendanne den.
To alternative veje undgår oversættelseslaget. nmcli connection import type openvpn file ./office.ovpn skriver det samme objekt og rapporterer fejl, som panelet skjuler.
Den ældre editor, startet med nm-connection-editor, afslører rutefelter, som panelet ikke har. For profiler, der afhænger af scripts eller ikke-understøttede direktiver, skal du beholde kommandolinjeklienten og overvåge den med en tjeneste i stedet, efter at have deaktiveret desktopforbindelsen, så kun én komponent ejer tunnelen.
Når importen virker, men aktiveringen ikke gør
Fanen Avanceret beholder den transport, der blev importeret eller sidst valgt. En server, der lytter på UDP, fejler hurtigt, når TCP vælges, og meddelelsen siger det sjældent. En forbindelse, der skal starte uden en logget ind bruger, kræver sin hemmelighed gemt for alle brugere, hvilket er en anden indstilling end at gemme den kun for denne session.
Når der ikke er noget brugbart i dialogen, viser journalctl -u NetworkManager -b, hvorfor aktiveringen mislykkedes. Shellklienten rører aldrig den sti, og derfor bliver den ved med at virke, mens desktopkopien ikke gør.
Som en sidste kontrol skal du sammenligne pluginversionen med distributionens udgivelse. Et plugin, der ikke passer, kan installeres rent og stadig nægte at aktivere en profil, som nmcli importerer uden klager.