Vilket program äger den där config.json i din OpenVPN-konfiguration?

Du hittar en fil som heter config.json, den nämner en VPN-server och antagandet kommer direkt: det här måste vara OpenVPN-anslutningen. Ofta är det inte det. En JSON-fil med det namnet kan tillhöra ett skrivbordsgränssnitt som startar klienten, en daemon som sparar sina egna inställningar eller ett produkts exportformat, och var och en av dem har sitt eget schema.

Filnamnet är den minst användbara ledtråden. Börja med processen som läser filen, kontrollera sedan om formatet den förväntar sig ens är JSON, och avgör först därefter om redigering av filen är det stödda sättet att ändra något.

Börja med processen, inte filnamnet

Titta på vad som faktiskt körs. En tjänsteenhet, ett startskript eller ett tray-program namnger binären de startar och ofta konfigurationssökvägen de skickar vidare. Mappen som innehåller filen är en andra ledtråd: programdatamappar, tjänstekonfigurationsmappar och användarprofilmappar pekar på olika ägare.

Läs sedan dokumentationen för produkten som äger den komponenten. Om JSON-filen tillhör en wrapper är dess nycklar wrapperns nycklar, och ett troligt utseende objekt byggt efter ett annat produkts exempel kommer att avvisas eller tyst ignoreras.

Två filer med samma namn i olika mappar är en vanlig fälla. Den ena kan vara genererat tillstånd som tjänsten skriver om vid varje start, och den andra kan vara mallen som en människa ska redigera. Att ändra den felaktiga ger en rättelse som håller till nästa omstart.

Vad en Community OpenVPN-profil egentligen är

Community OpenVPN 2.6 läser ett textformat baserat på alternativ. En profil är en sekvens av direktiv: en klientlägesrad, en enhetsrad, en fjärransluten ändpunkt, plus alternativ för identitet, kryptering och rutter, och den kan bädda in certifikat- och nyckelmaterial i inline-block.

Det formatet parsas rad för rad av klienten själv. Att ge den ett JSON-dokument via alternativet config slår inte på någon JSON-parser; den första raden kommer att avvisas som ett okänt direktiv. Att byta namn på en JSON-fil så att den slutar på .ovpn konverterar inte heller innehållet, och en giltig alternativfil blir inte ogiltig för att filändelsen är ovanlig.

OpenVPN Connect och OpenVPN 3 Linux har egna importerings- och hanteringsvägar för profiler. Dessa produkter kan ta emot en profil och lagra den i sin egen databas eller tjänstetillstånd, vilket inte är samma sak som en JSON-fil som råkar beskriva en server.

Redigera tillstånd som en annan komponent äger

Om JSON-filen är genererad är redigering av den en kapplöpning. En körande tjänst kan skriva tillbaka den vid avstängning, vid återanslutning eller vid nästa inställningsändring, och en handredigering försvinner utan fel. Föredra produktens importkommando, hanterings-API eller inställningsgränssnitt, eftersom de vägarna uppdaterar det interna tillstånd som filen representerar. En fil som faller tillbaka efter en omstart berättar vilken väg som var den hållbara.

Om du ändå redigerar en genererad fil, stoppa tjänsten först, ta en säkerhetskopia och gör den minsta möjliga ändringen. Kontrollera sedan om tjänsten skriver om filen vid start, för en fil som faller tillbaka vid start betyder att den egentliga sanningskällan finns någon annanstans och att ändringen aldrig skulle ha bestått.

Lösenord och inbäddade privata nycklar är en separat fråga. JSON kan bära en komplett nyckel lika enkelt som en alternativfil, så behandla varje export som hemlig, håll den borta från delade diskar och maska värdena innan du klistrar in struktur i en forumfråga.

Verifiera ändringen och skydda filen

Verifiering är inte ”JSON går att parsa”. Parsning bevisar bara att klamrarna passar ihop; den säger ingenting om huruvida ägaren känner igen nycklarna. Kontrollera produktens eget tillstånd: listan över aktiva profiler, den valda anslutningen och en återanslutning som verkligen använder de nya värdena. En profil som dyker upp i listan men aldrig blir den valda är fortfarande inte profilen som används.

Håll koll på loggen för den komponent du redigerade, inte bara VPN-klientens logg. En wrapper som avvisar din fil rapporterar det vanligtvis i sin egen logg, och en klient som aldrig fick filen ser identisk ut med en klient som fick dåliga inställningar.

Spara en kopia av filen som fungerar och anteckna produktversionen du testade mot. Dessa format ändras mellan utgåvor, och en struktur som fungerade i fjol kan avvisas efter en uppgradering med ett meddelande som inte nämner schemat alls.

Sammanfattning av genomgången: identifiera processen, läs dess dokumentation, bekräfta om filen ens är JSON, använd den stödda redigeringsvägen och verifiera via produktens eget tillstånd. Filnamnet svarade aldrig på någon av dessa frågor.