Flyt en VPN-profil i NetworkManager til en anden computer

To maskiner kan vise samme VPN-navn i menuen og ikke have andet til fælles. Indstillingssiden er den del, der rejser dårligst, fordi profilens egentlige indhold er spredt over en nøglefil, en nøglering, et plugin og en håndfuld absolutte filstier. Tre spørgsmål afgør, om du bør eksportere, kopiere eller registrere igen. Stil dem, før du kopierer noget.

Begynd med den profil, der faktisk virker

List forbindelserne, og læs UUID i stedet for navnet. nmcli connection show udskriver begge, og UUID er det eneste felt, der skelner den fungerende post fra en ældre import med samme etiket. Omdøb eller slet dubletten fra før på kildemaskinen, før du begynder, så det, du kopierer, er entydigt. Noter derefter plugin og forbindelsestype, fordi de to bestemmer, hvad eksport overhovedet betyder. En profil, du ikke kan identificere præcist, er en, du ikke bør migrere.

Dette trin koster et minut. Det forhindrer den mest almindelige fejl, nemlig at flytte den forkerte profil og derefter fejlfinde destinationen.

Eksport eller kopiering af nøglefilen?

NetworkManager kan eksportere nogle VPN-profiler til en fil, når det installerede plugin understøtter eksport, og for OpenVPN ligner resultatet en selvstændig konfiguration. Kopiering af den oprindelige nøglefil er den anden vej: den bevarer hver indstilling, men forventer samme plugin og en tilladt ejer på destinationen. Ingen af dem er universelt bedre, og ingen af dem er en backup. Vælg ved at spørge, hvad der skal forblive identisk.

Eksport passer til en flytning til en maskine, der skal køre samme plugin, især når du vil have ét artefakt, du kan inspicere. Nøglefilen passer til en gendannelse på en identisk distribution, hvor rettigheder og stier kan gengives præcist.

Hvad profilen stadig peger på

En profil er ikke selvforsynende, blot fordi den blev eksporteret rent. CA'en, klientcertifikatet, den private nøgle og ethvert ekstra TLS-materiale er normalt separate filer, der refereres via sti, og disse stier findes på den maskine, du forlader. List hver refereret fil, før du overfører noget.

Beslut derefter, om samme legitimationsoplysning overhovedet bør bruges. En fil med samme navn på en anden maskine er ikke samme identitet, og nogle udrulninger forventer i stedet en ny registrering.

Hemmelighederne er ikke i filen

Adgangskoder og kodefraser kan ligge i nøglefilen, i en brugernøglering eller slet ingen steder, fordi brugeren bliver spurgt hver gang. Kun det første af disse følger med en filkopi.

Kontroller adgangskodeflagene på kilde-profilen, før du antager, at flytningen ikke kræver opmærksomhed. En profil, der er konfigureret til at spørge eller til at gemme hemmeligheden hos en session-agent, ankommer til den nye maskine uden legitimationsoplysninger og med et forbindelsesforsøg, der mislykkes uden at forklare hvorfor. Gengiv den godkendte hemmelighedsarbejdsgang der i stedet for at eksportere en adgangskode i klartekst til en fil for at gøre flytningen lettere. Den genvej gør en migrering til en afsløring.

Udfas den gamle kopi ordentligt

Accepter den nye opsætning ved at bruge det tilsigtede program gennem den, og hold den gamle sti tilgængelig indtil da. Importér, læs slutpunkt, godkendelse, ruter og DNS tilbage, og opret derefter forbindelse og bekræft den private ressource. En import, der giver et grønt ikon, er ikke en accept.

Sletning af en lokal profil tilbagekalder intet. Certifikatet og legitimationsoplysningerne forbliver gyldige, indtil operatøren trækker dem tilbage, så udfasning er en separat anmodning til den, der udstedte dem. Fjern de gamle filer, fjern nøgleringenposten, og notér, hvilken identitet der blev trukket tilbage, og hvornår. Hvis den gamle maskine gives videre, betyder den registrering mere end sletningen.