Keyfile eller Netplan: hvor er VPN-profilen egentlig gemt?

At finde den fil, du importerede, er den lette del og ofte den forkerte start. Det afgørende er, hvilken fil NetworkManager i dag læser som den gemte forbindelse, og det afhænger af en forbindelsesidentifikator plus det konfigurations-backend, de installerede pakker faktisk bruger. At redigere importen, før det spørgsmål er besvaret, er måden en fungerende VPN bliver til to halvt korrekte konfigurationer.

Den importerede fil er ikke den gemte profil

Tre navne svæver rundt om ethvert VPN-problem: forbindelsens navn, filnavnet du importerede, og det virtuelle interface, der dukker op, når tunnelen kommer op. Ingen af dem identificerer den gemte konfiguration, og et forbindelsesnavn kan redigeres, mens filen bag det beholder sin oprindelige identifikator.

Begynd med en skrivebeskyttet oversigt og vælg den tilsigtede VPN efter identifikator i stedet for efter etiket:

nmcli -f NAME,UUID,TYPE connection show

Hold endpoint-værtsnavne og identitetsetiketter ude af enhver oversigt, du indsætter i en ticket. Den nyttige del er typen og identifikatoren; resten er kontekst, en fremmed ikke har brug for. Slør resten, før du deler, og sig, at du gjorde det, så ingen undrer sig over, hvad hullerne betyder.

Keyfile-placeringer betyder ikke det samme

Med det indbyggede keyfile-plugin kan forbindelsesfiler optræde i tre mapper, og forskellen mellem dem er varighed, ikke bekvemmelighed.

At redigere runtime-kopien ser vellykket ud indtil næste start, hvor ændringen fordamper og filen ser mystisk tilbagerullet ud. At redigere den pakkeleverede kopi virker, indtil en opgradering erstatter den, hvilket er en langsommere og mere forvirrende version af den samme lektie.

Keyfile-dokumentationen tilføjer en detalje, der er værd at respektere: disse filer kan indeholde private nøgler og adgangsfraser, og NetworkManager ignorerer enhver keyfile, som andre brugere end root kan læse eller skrive. At udvide mappetilladelser for at lede efter en indstilling ødelægger den indlæsningsadfærd, du forsøgte at undersøge.

Når Netplan ejer varigheden

På Ubuntu ændrer den NetworkManager-integration, der er beskrevet i Netplans dokumentation og tilgængelig fra 23.10, hvor den varige kopi ligger. For ikke-midlertidige forbindelser skriver den /etc/netplan/90-NM-<connection UUID>.yaml og genererer en efemær NetworkManager-profil under /run/NetworkManager/system-connections/.

Det er en distributionintegration, ikke en regel for enhver NetworkManager-installation. Bekræft, at de installerede pakker faktisk bruger den, før du går på jagt efter en YAML-fil. Husk også, at en runtime-profil kan være en genereret gengivelse af noget andet snarere end den kilde, der er værd at redigere. To kommandoers kontrol sparer en times redigering af den forkerte fil.

Det dokumenterede eksempel gemmer en OpenVPN-forbindelse gennem Netplan-typen nm-devices med gennemløbsdata fra NetworkManager. At Netplan ikke har nogen særlig fortolkning af et bestemt VPN-felt betyder ikke, at din gemte VPN er gået tabt; det betyder, at feltet rejser som uigennemsigtige data.

Midlertidige interfaces er ikke profiler

Aktivering opretter midlertidige virtuelle forbindelser og interfaces, som aldrig var ment til at vare. Integrationen skriver bevidst ikke en ny YAML-fil for hver af dem, så deres fravær i /etc/netplan siger intet om, hvorvidt den overordnede profil er gemt.

Hvis du jagter en fil, der dukker op og forsvinder, kigger du sandsynligvis på en af disse i stedet for på din konfiguration. Kontroller, om den overlever en genstart, før du drager nogen konklusion ud fra dens indhold. En runtime-fil, der forsvinder ved genstart, fortæller dig, at den aldrig var kilden, og den ene observation omdirigerer hele undersøgelsen. Den forklarer også, hvorfor en ændring så vellykket ud dengang.

Hemmeligheder og ejerskab

En profil kan referere til et certifikat eller en nøgle, der ligger helt andre steder, og en adgangskode kan tilhøre NetworkManager, leveres af en hemmelig agent i brugersessionen, eller bevidst ikke gemmes. At finde én fil afgør derfor meget lidt om, hvad en uovervåget opstart kræver.

Undersøg referencerne og hemmelighedsflagene uden at udskrive hemmelige værdier. Et desktop-login kan gøre en agent tilgængelig, som manglede under boot, og at kopiere en genereret runtime-fil gengiver ikke den agent. Det praktiske symptom er en tunnel, der forbinder, når en person logger ind, og fejler, når maskinen starter alene. Det mønster peger på hemmelighedsejerskab, ikke på routing.

Foretag godkendte ændringer gennem den manager, der ejer forbindelsen, og bekræft derefter både den gemte identifikator og den effektive forbindelse. Hold én varig ejer, fordi redigering af importen, en genereret keyfile og en YAML-kilde uafhængigt efterlader tre konkurrerende forklaringer på, hvad den næste genopkobling bruger. Vælg den, der faktisk varer, rediger kun den, og noter i ticketen, hvilken fil du behandlede som autoritativ. Den næste person vil takke dig for én linje oprindelse.