Waarom die byvoeg van opt-verify jou OpenVPN-syferfout nie regstel nie

Jy kry ’n voorstel om opt-verify by te voeg, voeg die reël by, en die syferfout bly presies waar dit was. Daardie uitkoms is voorspelbaar, want die opsie het nooit ’n syfer onderhandel nie. Dit was ’n opsie-konsekwentheidstoets, in 2.6 afgeskaf en in 2.7 verwyder, en ’n profiel wat daarmee steeds ontleed, het daardeur niks afgedwing nie.

Dit help om te weet wat die reël vroeër gedoen het voordat jy aflei dat dit die ontbrekende stuk is. Die geskiedenis verduidelik ook waarom dit nou nie kan help nie.

Wat die opsie vroeër afgedwing het

Die 2.6-handleiding merk opt-verify as afgeskaf en beskryf die vroeëre gedrag: die bediener laat kliënte val wie se verklaarde opsies nie met sy eie ooreenstem nie, en vergelyk dinge soos toesteltipe en MTU. Daardie toets hang ook daarvan af dat opsie-konsekwentheidstoetsing aan bly, so ’n bediener wat met disable-occ loop, het dit nooit gehad nie. Let op waaruit die vergelyking gebou is: teks wat ’n eweknie se konfigurasie beskryf. Dit sê niks oor watter syfer die datakanaal sal gebruik nie.

Dit is die eerste rede waarom die vlag nie ’n syferfout kan herstel nie. Syferkeuse word deur die data-ciphers-beleid en deur wat beide partye ondersteun bepaal, en ’n tekstuele konsekwentheidstoets brei nie daardie lys uit nie en voer ook nie die onderhandeling uit nie. ’n Tweede rede is omvang: die toets gaan daaroor of verklaarde opsies versoenbaar lyk, nie oor die gehalte van die pad wat daaruit volg nie.

Wat 2.7 doen wanneer dit die reël sien

In 2.7 is die opsie weg. Die ontleder herken steeds die naam, en daarom laai ’n ou profiel sonder ’n sintaksfout, en dit rapporteer dat die opsie verwyder is eerder as om dit in stilte oor te slaan. Om ’n naam te herken en om ’n gedrag af te dwing, is verskillende dinge, en net die eerste gebeur steeds. Die verwyderingsnotas gee die rede: sodra parameters onderhandel kan word, kan twee partye wettiglik verskillende opsiestrings hê terwyl hulle oor die verbinding saamstem.

’n Profiel wat ontleed, is dus nie bewys dat enige toelatingstoets geloop het nie. As jou enigste sein is dat die kliënt gekoppel het, het jy geleer dat die sintaks aanvaar is.

Waar die fout werklik sit

Bewaar die eerste konkrete fout voordat jy enigiets verander, want latere boodskappe is gewoonlik die gevolge daarvan. ’n Datakanaal-onderhandelingsfout hoort by die goedgekeurde syferbeleid en by die vermoëns wat beide partye werklik adverteer. ’n TLS-weergawe- of suitefout hoort by die beheerkanaal. ’n Sertifikaatverwerping het die identiteit en die vertroueketting nodig, nie ’n versoenbaarheidsvlag nie.

Identifiseer ook die enjin aan beide kante. ’n Rekenaartoepassing kan ’n ander bou meebring as die opdragreël-binêre lêer waarmee jy getoets het, en opsie-ondersteuning verskil tussen hulle. Gaan na daardie enjin se dokumentasie in plaas daarvan om te aanvaar dat elke program wat ’n profiel invoer, dieselfde werk.

Vervang die bedoeling, nie net die reël nie

As ’n ouer bestuurde bediener werklik op die konsekwentheidstoets gesteun het, teken dan aan watter beperking dit voor die opgradering afgedwing het. Om ’n geïgnoreerde opsie in ’n nuwer profiel te hou, kan daardie beleid nie bewaar nie, en om reëls blindelings te skrap ook nie.

Moenie op ’n ou voorstel reageer dat alle syfers gedeaktiveer is deur elke historiese algoritme te aktiveer nie.

Na ’n goedgekeurde regstelling, ondersoek die onderhandelde resultate op ’n nuwe verbinding en toets die toepassing wat die gebruiker werklik nodig het. Hou die bedienerweergawe en die effektiewe beleid langs daardie resultaat, sodat die volgende persoon kan sien wat ooreengekom is eerder as wat bloot aanvaar is.

Die doel is ’n ondersteunde beperking en ’n werkende geauthentiseerde pad, nie ’n nalatenskap-vlag wat steeds ontleed nie.