Én profil, to eiere: NetworkManager eller systemd

Det skjer ingenting med en .ovpn-fil før noe eier den. På en Pi-skrivebord er de sannsynlige eierne NetworkManager, som lagrer en importert tilkobling i sin egen nøkkelfil, og en frittstående tjenesteenhet som leser en konfigurasjon fra en mappe. Det er to driftsmodeller med ulik lagring, ulik håndtering av påloggingsinformasjon og ulike aktiveringsregler. Å velge én av dem med vilje er hele oppgaven; å kopiere filen til begge steder gjør bare valget tilfeldig.

Begge kan fungere på én maskin, men ikke på samme tunnel i samme øyeblikk, og konflikten ser ut som en nettverksfeil snarere enn en konfigurasjonsfeil.

To måter å eie samme tunnel på

NetworkManagers OpenVPN-plugin legger til et redigeringsprogram og en tjeneste som administrerer tilkoblingen for deg, og å installere OpenVPN-programmet installerer ikke den integrasjonen. En frittstående enhet er den motsatte ordningen: ingen redigering, ingen skrivebordsintegrasjon, én konfigurasjonsfil og de rettighetene enheten gir. Den første holder tilkoblingstilstanden i sin egen database, den andre holder den der profilen og enheten sier. Det meste av forvirringen kommer av å anta at en importert profil og en kopiert fil er samme objekt.

De er ikke to visninger av én ting. Å redigere den nedlastede filen endrer verken det NetworkManager lagret eller det enheten leser, og hvilken som helst av dem kan være den som bygde tunnelen du nettopp testet.

Følg tilkoblingen skrivebordet faktisk bruker

Den dokumenterte importoperasjonen, nmcli connection import type openvpn file office.ovpn, oppretter en tilkobling gjennom programtillegget. Noter UUID-en og bruk den identifikatoren etterpå, fordi navn redigeres og to tilkoblinger kan dele en etikett. nmcli connection show viser hva som finnes, og å lese tilkoblingens egne egenskaper forteller deg hvilken fil den kom fra og hva den lagrer. Hvis UUID-en du redigerer ikke er den skrivebordet aktiverer, er endringene dine dekorasjon.

Hemmeligheter bor i eierens lager. Å tømme hver lagrede hemmelighet for å finne ut hvilken profil som er aktiv er langsomt og risikabelt; spør tilkoblingsobjektet i stedet, og hold privat materiale der eieren forventer det.

En importert tilkobling trenger ingen grafisk økt for å kjøre, men den kan fortsatt trenge en kilde for påloggingsinformasjon. Om den starter uten tilsyn avhenger av rettighetene og hemmelighetene dens, ikke av om skrivebordet er til stede.

Les enhetsmalen før du stoler på den

Der pakken leverer klientenheten i upstream-stil, svarer en instans med navnet office til %i.conf inne i enhetens konfigurerte mappe, som for 2.6-malen er /etc/openvpn/client. Les den installerte enheten og eventuelle tilleggsfiler før du tror på et eksempel fra en veiledning, fordi distribusjoner flytter stier. En manuell start fra en terminal beviser ingenting om tjenestens syn på filer, hemmeligheter eller rettigheter. Skrivebordets passorddialog er heller ikke bevis for at en ikke-interaktiv enhet har en godkjent måte å få samme passord på.

Gi enheten bare det den trenger. Å lempe på hele tjenestens sandkasse fordi én referert fil ikke kan leses, bytter en liten rettelsesfiks mot en stor eksponering, og feilen navngir vanligvis filen som trenger oppmerksomhet.

Avvikle duplikatet uten å miste tilgang

Hvis begge eierne kan starte tunnelen, vinner en av dem til slutt på feil tidspunkt, og taperens ruter og enhet blir liggende igjen. Fjern det utilsiktede duplikatet gjennom sin egen eier, hold en gjenopprettingsvei åpen, og bekreft at den gjenværende eieren fortsatt kobler til etter en omstart. To bevisst atskilte VPN-er med ulike rutingspolicyer er et annet designspørsmål, ikke tillatelse til at to startveier konkurrerer om én tilkobling.

Skriv så ned livssyklusen du aksepterte: manuell aktivering, innlogging eller oppstart og gjenoppkobling. Kontroller endepunktet som er lagret, autentiseringen av motparten og ressursen tunnelen skal nå, fordi å installere skrivebordet på nytt ikke erstatter kunnskapen om hvilken konfigurasjon som kjørte.