Om key-method uit ’n OpenVPN-profiel te verwyder verander niks

’n Profiel wat jare lank werk weier skielik om te begin, en die boodskap noem ’n opdrag wat niemand onthou om by te voeg nie: key-method. Die volgende soekresultaat stel voor om key-method 2 vir versoenbaarheid by te voeg, wat raad uit ’n ander era is. Die ontleder wat die reël verwerp het, is ’n huidige een, en dit het glad nie so ’n opsie nie. Om die reël te verwyder maak die begin reg, en dit verander niks aan hoe die twee eweknieë die sessie beskerm nie.

Daardie gaping tussen wat ’n profiel bevat en wat die protokol werklik doen, is die hele onderwerp hier, en dit verduidelik verskeie ander wysigings wat mense terselfdertyd maak. Dit verduidelik ook waarom daardie wysigings gewoonlik in ’n bondel opdaag.

Die simptoom is ’n ontleedfout, nie ’n handdrukfout nie

Opsies word gelees voordat enige pakkie gestuur word. ’n Profiel met ’n onbekende opdrag misluk in daardie stadium, so die proses bereik nooit die netwerk nie en lewer nooit ’n handdrukfout nie. Die bewoording identifiseer gewoonlik die opsie en die lêer, wat dit een van die makliker foute maak om toe te skryf. Geen pakkie, geen roete en geen vuurmuur is daarby betrokke nie.

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

As die boodskap die opdrag noem, is die diagnose klaar: die lêer bevat iets wat hierdie bou nie aanvaar nie. As die boodskap eerder ’n lêerpad noem, is die probleem ’n ontbrekende insluiting of sleutel, wat ’n ander afdeling van dieselfde beginstadium is.

Wat jy nie moet aflei nie, is dat die kliënt of bediener ’n ouer protokolmodus nodig het. ’n Ontleedfout is ’n woordeskatprobleem tussen jou lêer en die binêre program, en die binêre program het in hierdie geval bloot ’n woord uit sy woordeskat laat val.

Opdrag en draadformaat is twee verskillende dinge

Die ou key-method-opsie het gekies hoe die TLS-sleuteluitruiling omraam word, en die moderne uitruiling is die meervoudige-pakkie-metode wat daardie opsie vroeër aangevra het. Die opsie het weggeval omdat dit niks meer gekies het nie; die formaat wat dit genoem het, het die enigste geword. Om die reël te verwyder laat die sessie dus dieselfde omraming as vantevore gebruik. ’n Tekswysiging kan dit in geen rigting verander nie.

Dit is waarom die herinvoering van ’n ou binêre program om “metode 2” te herstel die verkeerde herstel is. Dit herstel niks behalwe ’n ouer ontleder met ouer verstekwaardes nie, en dit kos jou die regstellings wat daarna gekom het. Dieselfde redenasie geld vir die verswakking van ’n sertifikaatkontrole of ’n syferlys in die hoop dat die verbinding terugkom.

’n Nuttige kontrole is die weergawe en die ontlede konfigurasie, nie die teenwoordigheid van die woord in die lêer nie:

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

Wat om te verwyder, en uit watter lêer

Wysig die lêer wat die lopende proses werklik lees, en net daardie lêer. Op verpakte stelsels is dit gewoonlik die profiel onder die kliënt- of bedienergids wat deur die eenheid genoem word, nie ’n kopie in jou tuisgids wat jy vir verwysing hou nie. ’n Gegenereerde profiel kan ook uit ’n sjabloon herbou word, so ’n wysiging wat net aan die ontplooide kopie gemaak is, sal ná die volgende voorsieningsloop terugkeer.

Skrap die verouderde reël en laat die eindpunt, sertifikate, syferbeleid en beheerkanaalinstellings alleen. Dit is ondersteunde opsies wat die proses nodig het, en hulle is nie by die ontleedfout betrokke nie. As dieselfde profiel ander opdragte bevat wat jy nie herken nie, kontroleer elkeen teen die weergawe wat jy hardloop eerder as om ’n groep daarvan te skrap totdat die proses begin.

Begin dan die bedoelde instansie en lees sy begin-uitset. ’n Skoon begin met die luisteraar teenwoordig is die bevestiging dat hierdie stadium klaar is; ’n kliënttoets daarna beantwoord ’n ander vraag.

’n Verwerpte profiel en ’n verwerpte kliënt lyk eenders

Twee foute veroorsaak soortgelyke ondersteuningsdrade en het verskillende bewyse nodig. ’n Bediener wat sy eie konfigurasie verwerp, begin nooit nie, so geen kliënt kan daaraan koppel nie. ’n Bediener wat goed begin en een kliënt weier, loop, en sy log bevat die rede: ’n sertifikaatprobleem, ’n gestuurde opsie wat die kliënt nie aanvaar nie, ’n syferverskil.

Die verwyderde opsie is nie ’n diagnose vir die tweede geval nie, en om daarna te gryp mors dieselfde uur twee keer. As die kliëntlog die bediener se verwerping wys, lees daardie verwerping; as dit ’n plaaslike fout wys, is die kliëntprofiel die lêer om te ondersoek. Om na ’n opdrag te gryp wat nie meer bestaan nie, vertraag beide ondersoeke met dieselfde hoeveelheid.

Versoenbaarheidsvrae wat die reël nooit beantwoord het nie

Profiele wat met hierdie opdrag sirkuleer, dra gewoonlik ’n verhaal oor ’n spesifieke platform, en die verhaal oorleef die tegniese rede. ’n Mobiele of lessenaarkliënt het steeds ’n volledige ondersteunde profiel nodig: ’n vertroude sertifikaatketting, ’n datasnyfer wat beide kante aanvaar, ’n beheerkanaalmodus wat beide kante implementeer, en geen opdragte wat die kliënt se bou verwerp nie. Nie een daarvan word deur die teenwoordigheid of afwesigheid van die ou key-method-reël beslis nie.

Kompressie is ’n aparte beleidsvraag met dieselfde vorm. Om ’n key-method-reël te verwyder sê niks oor of ’n kompressie-opdrag op jou ontplooiing ondersteun of aanvaarbaar is nie, en die twee besluite moet onafhanklik geneem word. Om verskeie sekuriteitsrelevante instellings gelyktydig te skrap totdat iets koppel, is hoe ’n werkende profiel ’n onverklaarde een word.

Hou ’n kort rekord van wat jy verwyder het en waarom: die opsie, die weergawe wat dit verwerp het, en die opdrag wat die fout gewys het. Die volgende persoon wat die profiel erf, sal presies daardie drie feite nodig hê, en dit is nou goedkoper om neer te skryf as om later te reconstrueer.