NetworkManager importerar inte din OpenVPN-profil? Läs det här
Importfelet är lokalt. Kontrollera insticksprogrammet och redigeraren, importera med nmcli för att få ett riktigt meddelande, och låt inbäddade certifikat vara där de är.
Profiler som ansluter fint i en annan OpenVPN klient kan vägra att importeras i NetworkManager, och dialogen skyller på insticksprogrammets importförmåga. Den meningen handlar om din maskin, inte om filen eller servern. Import är en lokal åtgärd som utförs av hanterarens VPN-insticksprogram, och i stunden då den misslyckas har ingenting skickats någonstans. Behandla det först som en fråga om paketering och sedan som en fråga om tolkning.
Läs meddelandet som ett lokalt påstående
Frasen beskriver insticksprogrammets funktionsuppsättning. Antingen saknas insticksprogrammet som ger OpenVPN-stöd, eller så är komponenten som erbjuder importåtgärden äldre än det format du ger den. Båda fallen är lokala för maskinen framför dig.
Lägg märke till vad meddelandet inte säger. Det säger inte att certifikatet är fel, att lösenordet har gått ut eller att servern ligger nere, så en omstart eller ett byte av inloggningsuppgifter löser det inte. Läs det som ett påstående om installerad programvara.
Den distinktionen sparar mest tid i hela artikeln, eftersom reflexen är att titta utåt mot gatewayen när felet ligger helt på skrivbordet.
Steg 1: bekräfta insticksprogrammet och redigeraren
Två paket spelar roll och de gör olika arbete. Det ena levererar VPN-insticksprogrammet för NetworkManager som äger anslutningen; det andra levererar redigerings- och importgränssnittet på skrivbordet. Installerar du bara körmiljön eller bara redigeraren får du halva funktionen.
nmcli --version
nmcli connection show
rpm -q NetworkManager-openvpn NetworkManager-openvpn-gnome 2>/dev/null
dpkg -l | grep -i network-manager-openvpn
Använd det paketeringskommando som din distribution faktiskt har; de två raderna ovan är alternativ, inte en sekvens. Bekräfta också att du överhuvudtaget är i NetworkManager-flödet, för en annan OpenVPN-klient med egen importör svarar inte på något av dessa råd.
Att installera insticksprogrammet startar vanligtvis om eller laddar om NetworkManager, vilket kort bryter befintliga anslutningar. Gör det medvetet och inte mitt i ett supportärende.
Steg 2: importera med nmcli och få ett riktigt meddelande
Den grafiska dialogen tenderar att pressa ihop flera fel till en enda mening. Importören på kommandoraden är mer specifik, och det är samma åtgärd:
nmcli connection import type openvpn file /path/to/client.ovpn
nmcli connection show --active
Läs svaret noga. Ett klagomål på ett saknat insticksprogram är ett paketeringsproblem. Ett klagomål på ett visst direktiv är ett tolkarproblem. Ett klagomål på en refererad fil är ett sökvägsproblem, och de tre har inget gemensamt utöver ordet import.
Kom ihåg att framgång här skapar en sparad profil. Den ansluter inte, och den bevisar inte att profilen behöll alla funktioner från originalet.
Steg 3: låt inbäddade certifikat vara där de är
Äldre råd säger att du ska ta bort varje inbäddat certifikat- och nyckelblock före import. Det rådet är föråldrat. Den nuvarande importören hanterar inbäddade objekt, och att radera dem tar bort den identitet som anslutningen behöver och skapar samtidigt en profil som importeras och sedan misslyckas med autentiseringen.
Om du verkligen behöver avskilja material av en särskild anledning, behåll originalfilen och notera vilket block som gick vart. En profil som tre personer har redigerat tre gånger är inte en konfiguration du kan resonera kring senare.
Samma försiktighet gäller leverantörens direktiv. Ett klientspecifikt alternativ kan ligga utanför funktionsuppsättningen för en version av insticksprogrammet utan att vara ogiltig OpenVPN-syntax, och att ta bort det bara för att dialogen ska stängas kan ändra beteendet i tysthet.
Steg 4: kontrollera vad profilen betyder nu
Efter en lyckad import, granska slutpunkten, autentiseringsupplägget, filreferenserna och var hemligheter lagras innan du aktiverar något. Det är i dessa fyra som import och avsikt oftast går isär.
Kontrollera sedan det beteende du faktiskt bryr dig om: rutter, DNS och om den ursprungliga profilens funktioner överlevde. Det är de tre ställena där en lyckad import fortfarande kan göra personen som bad om den besviken. En lyckad import och en anslutning som beter sig korrekt är två olika resultat, och bara det andra spelar roll för användaren.
Om den importerade profilen beter sig annorlunda än den ursprungliga klienten, jämför de två konfigurationerna i stället för att bygga upp dem igen ur minnet, eftersom skillnaden oftast är en rad.
Steg 5: låt en enda hanterare äga tunneln
När profilen väl bor i NetworkManager, låt den äga anslutningen. Att starta en separat OpenVPN-process som en omväg skapar en andra administrationsväg med eget resolverbeteende, egna inloggningsuppgifter och egen livscykel.
Två tunnlar som båda menar sig äga standardvägen ger symtom som ser ut som en trasig leverantör, och lösningen är att ta bort en av dem i stället för att justera någon av dem.