Pse shtimi i opt-verify nuk do ta rregullojë gabimin e kriptimit të OpenVPN

Gjeni një sugjerim për të shtuar opt-verify, e shtoni rreshtin, dhe gabimi i kriptimit mbetet saktësisht aty ku ishte. Ky rezultat është i parashikueshëm, sepse opsioni nuk negocioi kurrë një kriptim. Ishte një kontroll konsistence i opsioneve, i vjetëruar në 2.6 dhe i hequr në 2.7, dhe një profil që ende analizohet me të nuk ka imponuar asgjë me këtë.

Ndihmon të dini çfarë bënte rreshti më parë përpara se të konkludoni se është pjesa që mungon. Historiku shpjegon gjithashtu pse nuk mund të ndihmojë tani.

Çfarë impononte opsioni më parë

Manuali i 2.6 e shënon opt-verify si të vjetëruar dhe përshkruan sjelljen e mëparshme: serveri i hedh poshtë klientët opsionet e deklaruara të të cilëve nuk përputhen me të vetat, duke krahasuar gjëra si lloji i pajisjes dhe MTU. Ai kontroll varet gjithashtu nga fakti që kontrolli i konsistencës së opsioneve të mbetet i aktivizuar, kështu që një server që punon me disable-occ nuk e ka pasur kurrë. Vini re nga çfarë ndërtohet krahasimi: nga tekst që përshkruan konfigurimin e palës tjetër. Ai nuk thotë asgjë për atë se cilën kriptim do të përdorë kanali i të dhënave.

Ky është arsyeja e parë pse flamuri nuk mund të rregullojë një gabim kriptimi. Zgjedhja e kriptimit rregullohet nga politika data-ciphers dhe nga ajo që mbështesin të dyja palët, dhe një kontroll tekstual konsistence as e zgjeron atë listë as e kryen negocimin. Arsyeja e dytë është shtrirja: kontrolli ka të bëjë me atë nëse opsionet e deklaruara duken të përputhshme, jo me cilësinë e rrugës që rezulton.

Çfarë bën 2.7 kur e sheh rreshtin

Në 2.7 opsioni nuk është më. Analizuesi ende e njeh emrin, prandaj një profil i vjetër ngarkohet pa gabim sintakse, dhe ai raporton se opsioni u hoq në vend që ta kalojë në heshtje. Të njohësh një emër dhe të imponosh një sjellje janë gjëra të ndryshme, dhe ende ndodh vetëm e para. Shënimet e heqjes japin arsyen: sapo parametrat mund të negociohen, dy palë mund të kenë ligjërisht vargje opsionesh të ndryshme ndërsa bien dakord për lidhjen.

Prandaj një profil që analizohet nuk është provë se është kryer ndonjë kontroll pranimi. Nëse sinjali i vetëm është që klienti u lidh, keni mësuar se sintaksa u pranua.

Ku qëndron në të vërtetë dështimi

Ruajeni gabimin e parë konkret përpara se të ndryshoni ndonjë gjë, sepse mesazhet e mëvonshme zakonisht janë pasojat e tij. Një dështim negocimi i kanalit të të dhënave i përket politikës së miratuar të kriptimit dhe aftësive që të dyja palët reklamojnë në të vërtetë. Një dështim versioni ose suitë TLS i përket kanalit të kontrollit. Një refuzim certifikate kërkon identitetin dhe zinxhirin e besimit, jo një flamur përputhshmërie.

Identifikoni gjithashtu motorin në të dy skajet. Një aplikacion desktopi mund të përmbajë një ndërtim të ndryshëm nga binari i rreshtit të komandës me të cilin keni testuar, dhe mbështetja e opsioneve ndryshon mes tyre. Konsultoni dokumentacionin e atij motori në vend që të supozoni se çdo program që importon një profil sillet njësoj.

Zëvendësoni qëllimin, jo vetëm rreshtin

Nëse një server i menaxhuar më i vjetër mbështetej vërtet te kontrolli i konsistencës, shënoni çfarë kufizimi impononte përpara përditësimit. Mbajtja e një opsioni të injoruar në një profil më të ri nuk mund ta ruajë atë politikë, dhe fshirja e rreshtave pa kriter as nuk mundet.

Mos iu përgjigjni një sugjerimi të vjetër se të gjitha kriptimet janë çaktivizuar duke aktivizuar çdo algoritëm historik.

Pas një korrigjimi të miratuar, shqyrtoni rezultatet e negociuara në një lidhje të re dhe provoni aplikacionin që përdoruesi ka vërtet nevojë. Mbani versionin e serverit dhe politikën efektive pranë atij rezultati, që personi tjetër të shohë çfarë u dakordësua dhe jo vetëm çfarë u pranua.

Qëllimi është një kufizim i mbështetur dhe një rrugë e vërtetuar që funksionon, jo një flamur i vjetër që ende analizohet.