Ingenting händer med en .ovpn-fil förrän något äger den. På ett Pi-skrivbord är de troliga ägarna NetworkManager, som lagrar en importerad anslutning i sin egen nyckelfil, och en fristående serviceenhet som läser en konfiguration från en katalog. Det är två driftsmodeller med olika lagring, olika hantering av inloggningsuppgifter och olika aktiveringsregler. Att välja en av dem medvetet är hela uppgiften; att kopiera filen till båda ställena gör bara valet slumpmässigt.

Båda kan fungera på en maskin, men inte på samma tunnel i samma ögonblick, och konflikten ser ut som ett nätverksfel snarare än ett konfigurationsfel.

Två sätt att äga samma tunnel

NetworkManagers OpenVPN-plugin lägger till en redigerare och en tjänst som hanterar anslutningen åt dig, och att installera OpenVPN-programmet installerar inte den integrationen. En fristående enhet är den omvända ordningen: ingen redigerare, ingen skrivbordsintegration, en konfigurationsfil och de rättigheter enheten ger. Den första håller anslutningstillståndet i sin egen databas, den andra håller det där profilen och enheten säger. Det mesta av förvirringen kommer av antagandet att en importerad profil och en kopierad fil är samma objekt.

De är inte två vyer av en sak. Att redigera den nedladdade filen ändrar varken det NetworkManager sparade eller det enheten läser, och vilken som helst av dem kan vara den som byggde tunneln du just testade.

Följ den anslutning skrivbordet faktiskt använder

Den dokumenterade importoperationen, nmcli connection import type openvpn file office.ovpn, skapar en anslutning genom insticksprogrammet. Anteckna dess UUID och använd den identifieraren efteråt, eftersom namn redigeras och två anslutningar kan dela en etikett. nmcli connection show listar vad som finns, och att läsa anslutningens egna egenskaper berättar vilken fil den kom från och vad den lagrar. Om UUID:t du redigerar inte är det som skrivbordet aktiverar, är dina ändringar dekoration.

Hemligheter bor i ägarens lager. Att tömma varje lagrad hemlighet för att ta reda på vilken profil som är aktiv är långsamt och riskabelt; fråga anslutningsobjektet i stället, och håll privat material där ägaren förväntar sig det.

En importerad anslutning behöver ingen grafisk session för att köras, men den kan fortfarande behöva en källa för inloggningsuppgifter. Om den startar utan tillsyn beror på dess behörigheter och hemligheter, inte på om skrivbordet finns.

Läs enhetsmallen innan du litar på den

Där paketet levererar klientenheten i upstream-stil motsvarar en instans med namnet office %i.conf i enhetens konfigurerade katalog, som för 2.6-mallen är /etc/openvpn/client. Läs den installerade enheten och eventuella tilläggsfiler innan du tror på ett exempel från en guide, eftersom distributioner flyttar sökvägar. En manuell start från en terminal bevisar ingenting om hur tjänsten ser på filer, hemligheter eller behörigheter. Skrivbordets lösenordsdialog är inte heller bevis för att en icke-interaktiv enhet har ett godkänt sätt att få samma lösenord.

Ge enheten bara det den behöver. Att lätta på hela tjänstens sandlåda eftersom en refererad fil inte går att läsa byter en liten behörighetsrättelse mot en stor exponering, och felet namnger oftast filen som behöver uppmärksamhet.

Avveckla dubbletten utan att förlora åtkomst

Om båda ägarna kan starta tunneln vinner en av dem till slut i fel ögonblick och förlorarens rutter och enhet lämnas kvar. Ta bort den oavsiktliga dubbletten via dess egen ägare, håll en återställningsväg öppen och bekräfta att den kvarvarande ägaren fortfarande ansluter efter en omstart. Två medvetet åtskilda VPN:er med olika routingprinciper är en annan designfråga, inte tillstånd för två startvägar att konkurrera om en anslutning.

Skriv sedan ned den livscykel du accepterade: manuell aktivering, inloggning eller uppstart och återanslutning. Kontrollera den sparade slutpunkten, motpartens autentisering och resursen tunneln ska nå, eftersom att installera om skrivbordet inte ersätter vetskapen om vilken konfiguration som kördes.

Relaterade artiklar