Ugyanaz a fájl csatlakozik egy shellből, és megtagadja az importálást az asztali panelen. Ez kizárja a szervert, a hitelesítő adatokat és a profil szintaxisát, mert a parancssori kliens már mindhármat feldolgozta. Ami marad, az maga az asztali útvonal: a szükséges csomagok, az értelmezett direktívák részhalmaza és az objektum, amelyet a lemezre ír. Mindegyik másképp hibázik, és az üzenetek ritkán a megfelelőre mutatnak.

Három dolog, amire a párbeszédnek szüksége van, mielőtt bármit elemez

Az import a felhasználója jogosultságaival fut, ezért a csak root számára elérhető könyvtárban lévő fájlt még a tartalma előtt elutasítja. A panel csak azokat a VPN-típusokat listázza, amelyek NetworkManager-bővítménye telepítve van; az OpenVPN bővítmény nélkül a lehetőség hiányzik, nem pedig hibás. Végül a hálózati eszköznek kezeltnek kell lennie: a nem kezeltként megjelölt interfész elfogadhat egy mentett kapcsolatot, amely soha nem aktiválódik. Mindhármat ellenőrizze a profil szerkesztése előtt.

Két parancs rendezi az első kört: dpkg -l network-manager-openvpn-gnome a bővítményhez és nmcli device status az eszköz állapotához.

Mit dob el csendben az importáló

Az asztali fordítás rögzített tulajdonságkészletet céloz. Az ezen kívül eső sorokat csendben eldobja, ezért az alagút a szándékolt konfiguráció hiányzó részeivel jöhet fel. A up, down és script-security használatával deklarált szkriptek általában eltűnnek, ahogy a kezelőfelület beállításai és a további távoli blokkok is. A vpn_gateway kulcsszóval írt útvonal kivétel: az importáló ott szó szerinti IPv4-átjárót akar, és hibával megszakad a sor eldobása helyett.

Az eldobott útvonalnak felismerhető alakja van. A kapcsolat aktiválódik, az interfész címet kap, és egy adott alhálózat elérhetetlen marad, mert az útvonal soha nem került be a profilba.

A mentett kapcsolatot olvassa, ne a forrásfájlt

Az import mérvadó eredménye a kulcsfájl, nem a kiválasztott .ovpn. A sudo cat /etc/NetworkManager/system-connections/office.nmconnection megmutatja, mit mentett el a panel valójában. Ha van ott útvonal, de hiányzik az élő táblából, az import sikerült, és a problémát az aktiválás okozza. Ha hiányzik a fájlból, az importáló eldobta, és semmilyen újracsatlakozás nem állítja helyre.

Két alternatív útvonal elkerüli a fordítási réteget. A nmcli connection import type openvpn file ./office.ovpn ugyanazt az objektumot írja, és jelenti a panel által elrejtett hibákat.

A régebbi szerkesztő, amelyet a nm-connection-editor indít, olyan útvonalmezőket mutat, amelyek a panelen nincsenek. A szkriptektől vagy nem támogatott direktíváktól függő profilokhoz tartsa meg a parancssori klienst, és inkább egy szolgáltatással felügyelje, miután letiltotta az asztali kapcsolatot, hogy csak egy összetevő birtokolja az alagutat.

Amikor az import működik, az aktiválás nem

A Speciális lap megtartja azt a szállítási módot, amelyet importáltak vagy legutóbb választottak. Az UDP-n figyelő szerver gyorsan elbukik, ha a TCP-t választják, és az üzenet ezt ritkán mondja ki. Az olyan kapcsolatnak, amelynek bejelentkezett felhasználó nélkül kell indulnia, a titkát minden felhasználó számára el kell tárolni, ami más beállítás, mint csak erre a munkamenetre menteni.

Ha nincs semmi hasznos a párbeszédben, a journalctl -u NetworkManager -b megmutatja, miért hiúsult meg az aktiválás. A shell kliens soha nem érinti ezt az útvonalat, ezért működik tovább, miközben az asztali másolat nem.

Végső ellenőrzésként hasonlítsa össze a bővítmény verzióját a disztribúció kiadásával. Egy nem illeszkedő bővítmény tisztán települhet, és mégis megtagadhatja egy olyan profil aktiválását, amelyet a nmcli panasz nélkül importál.

Kapcsolódó cikkek