Keyfile of Netplan: waar wordt het VPN-profiel echt opgeslagen?
Een opgeslagen VPN kan in een keyfile of in een gegenereerd Netplan-bestand staan. Koppel de UUID van de verbinding aan de echte eigenaar voordat u iets bewerkt dat opnieuw wordt geschreven.
Het bestand vinden dat u hebt geïmporteerd is het makkelijke deel en vaak het verkeerde begin. Wat telt is welk bestand NetworkManager vandaag als de opgeslagen verbinding leest, en dat hangt af van een verbindingsidentificatie plus de configuratiebackend die de geïnstalleerde pakketten echt gebruiken. De import bewerken voordat die vraag is beantwoord, is hoe een werkende VPN twee half juiste configuraties wordt.
Het geïmporteerde bestand is niet het opgeslagen profiel
Drie namen zweven rond elk VPN-probleem: de naam van de verbinding, de bestandsnaam die u hebt geïmporteerd en de virtuele interface die verschijnt wanneer de tunnel omhoog komt. Geen ervan identificeert de opgeslagen configuratie, en een verbindingsnaam kan worden bewerkt terwijl het bestand erachter zijn oorspronkelijke identificatie behoudt.
Begin met een alleen-lezen inventaris en kies de bedoelde VPN op identificatie in plaats van op label:
nmcli -f NAME,UUID,TYPE connection show
Houd hostnamen van eindpunten en identiteitslabels buiten elke inventaris die u in een ticket plakt. Het nuttige deel is het type en de identificatie; de rest is context die een vreemde niet nodig heeft. Redigeer de rest voordat u deelt, en zeg dat u dat hebt gedaan, zodat niemand zich afvraagt wat de lege plekken betekenen.
Keyfile-locaties betekenen niet hetzelfde
Met de native keyfile-plugin kunnen verbindingsbestanden in drie mappen verschijnen, en het verschil ertussen is duurzaamheid, niet gemak.
| Location | Role |
|---|---|
/etc/NetworkManager/system-connections/ | Administrator-owned persistence |
/usr/lib/NetworkManager/system-connections/ | Package-supplied defaults, replaced on upgrade |
/run/NetworkManager/system-connections/ | Runtime state, regenerated and not durable |
De runtime-kopie bewerken lijkt te lukken tot de volgende start, wanneer de wijziging verdampt en het bestand er mysterieus teruggedraaid uitziet. De door het pakket geleverde kopie bewerken werkt tot een upgrade die vervangt, wat een tragere en verwarrendere versie van dezelfde les is.
De keyfile-documentatie voegt een detail toe dat respect verdient: die bestanden kunnen privésleutels en wachtwoordzinnen bevatten, en NetworkManager negeert elk keyfile dat gebruikers anders dan root kunnen lezen of schrijven. Maprechten verruimen om een instelling te zoeken breekt het laadgedrag dat u probeerde te onderzoeken.
Wanneer Netplan de duurzaamheid bezit
Op Ubuntu verandert de NetworkManager-integratie die in de Netplan-documentatie wordt beschreven, beschikbaar vanaf 23.10, waar de duurzame kopie staat. Voor niet-tijdelijke verbindingen schrijft hij /etc/netplan/90-NM-<connection UUID>.yaml en genereert een efemeer NetworkManager-profiel onder /run/NetworkManager/system-connections/.
Dat is een distributie-integratie, geen regel voor elke NetworkManager-installatie. Bevestig dat de geïnstalleerde pakketten die echt gebruiken voordat u op zoek gaat naar een YAML-bestand. Onthoud ook dat een runtime-profiel een gegenereerde weergave van iets anders kan zijn in plaats van de bron die het bewerken waard is. Twee commando’s controleren bespaart een uur het verkeerde bestand bewerken.
Het gedocumenteerde voorbeeld slaat een OpenVPN-verbinding op via het Netplan-type nm-devices met NetworkManager-doorgiftegegevens. Dat Netplan geen eigen interpretatie van een bepaald VPN-veld heeft, betekent niet dat uw opgeslagen VPN verloren is; het betekent dat het veld als ondoorzichtige gegevens reist.
Tijdelijke interfaces zijn geen profielen
Activering maakt tijdelijke virtuele verbindingen en interfaces die nooit bedoeld waren te blijven. De integratie schrijft bewust geen nieuw YAML-bestand voor elk ervan, dus hun afwezigheid in /etc/netplan zegt niets over of het bovenliggende profiel is opgeslagen.
Als u jaagt op een bestand dat verschijnt en verdwijnt, kijkt u waarschijnlijk naar een van deze in plaats van naar uw configuratie. Controleer of het een herstart overleeft voordat u conclusies uit de inhoud trekt. Een runtime-bestand dat bij een herstart verdwijnt, vertelt u dat het nooit de bron was, en die ene observatie stuurt het hele onderzoek een andere kant op. Het verklaart ook waarom een bewerking toen geslaagd leek.
Geheimen en eigendom
Een profiel kan verwijzen naar een certificaat of sleutel die heel ergens anders is opgeslagen, en een wachtwoord kan van NetworkManager zijn, geleverd worden door een geheime agent van de gebruikerssessie, of bewust niet worden opgeslagen. Eén bestand vinden beslist daarom heel weinig over wat een onbeheerde start vereist.
Inspecteer de verwijzingen en de geheimvlaggen zonder geheime waarden af te drukken. Een desktop-login kan een agent beschikbaar maken die tijdens het opstarten ontbrak, en een gegenereerd runtime-bestand kopiëren reproduceert die agent niet. Het praktische symptoom is een tunnel die verbinding maakt wanneer iemand inlogt en faalt wanneer de machine alleen start. Dat patroon wijst op geheimeneigendom, niet op routing.
Voer goedgekeurde wijzigingen uit via de beheerder die de verbinding bezit, en verifieer daarna zowel de opgeslagen identificatie als de effectieve verbinding. Houd één duurzame eigenaar, want de import, een gegenereerd keyfile en een YAML-bron afzonderlijk bewerken laat drie concurrerende verklaringen achter over wat de volgende herverbinding gebruikt. Kies degene die echt blijft, bewerk alleen die, en noteer in het ticket welk bestand u als gezaghebbend hebt behandeld. De volgende persoon zal u danken voor één regel herkomst.