Miks opt-verify lisamine OpenVPN-i šifriviga ei paranda

Leiad soovituse lisada opt-verify, lisad rea ja šifriviga jääb täpselt sinna, kus see oli. See tulemus on etteaimatav, sest valik ei pidanud kunagi šifri üle läbirääkimisi. See oli valikute järjepidevuse kontroll, versioonis 2.6 aegunuks kuulutatud ja versioonis 2.7 eemaldatud, ning profiil, mis sellega veel parsitakse, ei ole sellega midagi jõustanud.

Kasulik on teada, mida rida varem tegi, enne kui järeldad, et see on puuduv tükk. Ajalugu selgitab ka, miks see praegu aidata ei saa.

Mida valik varem jõustas

Versiooni 2.6 käsiraamat märgib opt-verify aegunuks ja kirjeldab varasemat käitumist: server viskab välja kliendid, kelle deklareeritud valikud ei ühti tema omadega, võrreldes selliseid asju nagu seadme tüüp ja MTU. See kontroll sõltub ka sellest, et valikute järjepidevuse kontroll jääb sisse lülitatuks, nii et serveril, mis töötab disable-occ-iga, ei ole seda kunagi olnud. Pane tähele, millest võrdlus on üles ehitatud: tekstist, mis kirjeldab vastaspoole konfiguratsiooni. See ei ütle midagi selle kohta, millist šifrit andmekanal kasutab.

See on esimene põhjus, miks lipp ei saa šifriviga parandada. Šifri valikut juhivad data-ciphers poliitika ja see, mida mõlemad pooled toetavad, ning tekstiline järjepidevuse kontroll ei laienda seda loendit ega tee läbirääkimist. Teine põhjus on ulatus: kontroll puudutab seda, kas deklareeritud valikud näivad ühilduvat, mitte sellest tuleneva tee kvaliteeti.

Mida 2.7 teeb, kui see rea näeb

Versioonis 2.7 valikut enam ei ole. Parser tunneb nime endiselt ära, mistõttu vana profiil laaditakse ilma süntaksiveata, ja see teatab, et valik eemaldati, selle asemel et sellest vaikselt mööda minna. Nime äratundmine ja käitumise jõustamine on erinevad asjad ning praegu toimub ainult esimene. Eemaldamise märkused annavad põhjuse: kui parameetrite üle saab läbi rääkida, võivad kaks poolt õiguspäraselt omada erinevaid valikustringe, olles ühenduse osas ühel meelel.

Profiil, mis parsitakse, ei ole seega tõend, et mõni vastuvõtukontroll toimus. Kui sinu ainus signaal on see, et klient ühendati, siis oled teada saanud, et süntaks võeti vastu.

Kus tõrge tegelikult asub

Jäta esimene konkreetne viga alles enne, kui midagi muud, sest hilisemad teated on tavaliselt selle tagajärjed. Andmekanali läbirääkimise tõrge kuulub kinnitatud šifripoliitika ja mõlema poole tegelikult kuulutatud võimekuste juurde. TLS-i versiooni või komplekti tõrge kuulub juhtkanali juurde. Sertifikaadi tagasilükkamine vajab identiteeti ja usaldusahelat, mitte ühilduvuslippu.

Tuvasta ka mootor mõlemas otsas. Töölauarakendus võib sisaldada teistsugust buildi kui käsurea binaar, millega testisid, ja valikute tugi erineb nende vahel. Vaata selle mootori dokumentatsiooni, selle asemel et eeldada, et iga profiili importiv programm käitub ühtemoodi.

Asenda kavatsus, mitte ainult rida

Kui vanem hallatav server tõesti tugines järjepidevuse kontrollile, kirjuta üles, millist piirangut see enne uuendust jõustas. Ignoreeritud valiku hoidmine uuemas profiilis ei saa seda poliitikat säilitada, ja ridade valimatu kustutamine ei saa samuti.

Ära vasta vanale soovitusele, et kõik šifrid on välja lülitatud, kõigi ajalooliste algoritmide lubamisega.

Pärast kinnitatud parandust vaata läbi läbiräägitud tulemused uuel ühendusel ja testi rakendust, mida kasutaja tegelikult vajab. Hoia serveri versioon ja kehtiv poliitika selle tulemuse kõrval, et järgmine inimene näeks, milles kokku lepiti, mitte ainult seda, mis lihtsalt vastu võeti.

Eesmärk on toetatud piirang ja töötav autenditud tee, mitte pärandlipp, mis veel parsitakse.