Watter program besit daardie config.json in jou OpenVPN-opstelling?

Jy vind ’n lêer met die naam config.json, dit noem ’n VPN-bediener, en die aanname volg dadelik: dit moet die OpenVPN-verbinding wees. Dikwels is dit nie. ’n JSON-lêer met daardie naam kan aan ’n lessenaarfrontend behoort wat die kliënt begin, aan ’n daemon wat sy eie instellings stoor, of aan ’n produk se uitvoerformaat, en elkeen daarvan het sy eie skema.

Die lêernaam is die minste nuttige leidraad. Begin by die proses wat die lêer lees, kyk dan of die formaat wat dit verwag selfs JSON is, en besluit eers daarna of die wysiging van die lêer die ondersteunde manier is om iets te verander.

Begin by die proses, nie by die lêernaam nie

Kyk wat werklik aan die gang is. ’n Diens-eenheid, ’n bekendstellingskrip of ’n taakbalkprogram sal die binêre lêer noem wat dit begin en dikwels ook die konfigurasiepad wat dit deurgee. Die gids wat die lêer bevat, is ’n tweede leidraad: toepassingsdata-gidse, dienskonfigurasie-gidse en gebruikersprofielgidse dui op verskillende eienaars.

Lees dan die dokumentasie van die produk wat die betrokke komponent besit. As die JSON aan ’n omhulsel behoort, is sy sleutels die omhulsel se sleutels, en ’n oortuigend-voorkomende objek wat uit ’n ander produk se voorbeeld gebou is, sal verwerp of stilweg geïgnoreer word.

Twee lêers met dieselfde naam in verskillende gidse is ’n algemene lokval. Een kan gegenereerde toestand wees wat die diens by elke begin herskryf, en die ander kan die sjabloon wees wat ’n mens veronderstel is om te wysig. Om die verkeerde een te verander, lewer ’n oplossing op wat tot die volgende herbegin hou.

Wat ’n Community OpenVPN-profiel werklik is

Community OpenVPN 2.6 lees ’n opsiegebaseerde teksformaat. ’n Profiel is ’n reeks opdragte: ’n kliëntmodus-reël, ’n toestelreël, ’n afgeleë eindpunt, plus identiteit-, syfer- en roete-opsies, en dit kan sertifikaat- en sleutelmateriaal binne inline-blokke insluit.

Daardie formaat word reël vir reël deur die kliënt self ontleed. Om dit ’n JSON-dokument deur die config-opsie te gee, skakel nie ’n JSON-ontleder aan nie; die eerste reël sal as ’n onbekende opdrag verwerp word. Om ’n JSON-lêer se naam na .ovpn te verander, skakel ook nie die inhoud om nie, en ’n geldige opsielêer word nie ongeldig omdat sy uitbreiding ongewoon is nie.

OpenVPN Connect en OpenVPN 3 Linux het hul eie invoer- en bestuurspaaie vir profiele. Daardie produkte kan ’n profiel aanvaar en in hul eie databasis of dienstoestand stoor, wat nie dieselfde ding is as ’n JSON-lêer wat toevallig ’n bediener beskryf nie.

Toestand wysig wat ’n ander komponent besit

As die JSON gegenereer is, is die wysiging daarvan ’n resies. ’n Lopende diens kan dit by afskakeling, by herverbinding of by die volgende instellingsverandering terugskryf, en ’n handwyseriging verdwyn sonder ’n fout. Verkies die produk se invoeropdrag, bestuurs-API of instellingskoppelvlak, want daardie paaie werk die interne toestand by wat die lêer verteenwoordig. ’n Lêer wat ná ’n herbegin terugspring, vertel jou watter pad die duursame een was.

As jy wel ’n gegenereerde lêer wysig, stop eers die diens, hou ’n rugsteun en maak die kleinste moontlike verandering. Kyk dan of die diens die lêer herskryf wanneer dit begin, want ’n lêer wat by die begin terugspring, beteken die werklike bron van waarheid is elders, en die wysiging sou nooit blywend wees nie.

Wagwoorde en inline privaatsleutels is ’n aparte kwessie. JSON kan ’n volledige sleutel net so maklik soos ’n opsielêer dra, so behandel enige uitvoer as geheim, hou dit uit gedeelde skywe, en verwyder waardes voordat jy struktuur in ’n forumvraag plak.

Die verandering verifieer en die lêer beskerm

Verifikasie is nie “die JSON ontleed” nie. Ontleding bewys net dat die krulhakies pas; dit sê niks oor of die eienaar die sleutels herken nie. Kyk na die produk se eie toestand: die lys aktiewe profiele, die gekose verbinding en ’n herverbinding wat werklik die nuwe waardes gebruik. ’n Profiel wat in die lys verskyn maar nooit die gekose een word nie, is steeds nie die profiel in gebruik nie.

Hou die log dop vir die komponent wat jy gewysig het, nie net vir die VPN-kliënt nie. ’n Omhulsel wat jou lêer verwerp, rapporteer dit gewoonlik in sy eie log, en ’n kliënt wat die lêer nooit ontvang het nie, lyk identies aan ’n kliënt wat slegte instellings ontvang het.

Hou ’n kopie van die werkende lêer en teken die weergawe van die produk op waarteen jy getoets het. Hierdie formate verander tussen vrystellings, en ’n struktuur wat verlede jaar gewerk het, kan ná ’n opgradering verwerp word met ’n boodskap wat die skema glad nie noem nie.

Opsomming van die deurloop: identifiseer die proses, lees sy dokumentasie, bevestig of die lêer hoegenaamd JSON is, gebruik die ondersteunde wysigingspad en verifieer deur die produk se eie toestand. Die lêernaam het nooit enige van daardie vrae beantwoord nie.