Чаму даданне opt-verify не выправіць памылку шыфра ў OpenVPN

Вы знаходзіце параду дадаць opt-verify, дадаяце радок, а памылка шыфра застаецца роўна там, дзе была. Такі вынік прадказальны, бо опцыя ніколі не ўзгадняла шыфр. Гэта была праверка ўзгодненасці опцый, састарэлая ў 2.6 і выдаленая ў 2.7, і профіль, які з ёй усё яшчэ разбіраецца, тым самым нічога не ўвёў у дзеянне.

Карысна ведаць, што радок рабіў раней, перш чым рабіць выснову, што ён і ёсць адсутны элемент. Гісторыя таксама тлумачыць, чаму зараз ён не можа дапамагчы.

Што опцыя раней уводзіла ў дзеянне

Дапаможнік 2.6 пазначае opt-verify як састарэлую і апісвае ранейшыя паводзіны: сервер адкідае кліентаў, абвешчаныя опцыі якіх не супадаюць з яго ўласнымі, параўноўваючы такія рэчы, як тып прылады і MTU. Гэта праверка таксама залежыць ад таго, што праверка ўзгодненасці опцый застаецца ўключанай, таму сервер, які працуе з disable-occ, ніколі яе не меў. Звярніце ўвагу, з чаго будуецца параўнанне: з тэксту, які апісвае канфігурацыю суразмоўцы. Ён нічога не кажа пра тое, які шыфр будзе выкарыстоўваць канал даных.

Гэта першая прычына, чаму сцяг не можа выправіць памылку шыфра. Выбар шыфра кіруецца палітыкай data-ciphers і тым, што падтрымліваюць абодва бакі, а тэкставая праверка ўзгодненасці не пашырае гэты спіс і не выконвае ўзгадненне. Другая прычына — абсяг: праверка тычыцца таго, ці выглядаюць абвешчаныя опцыі сумяшчальнымі, а не якасці шляху, які ў выніку атрымліваецца.

Што робіць 2.7, калі бачыць радок

У 2.7 опцыі няма. Разборшчык усё яшчэ распазнае імя, таму стары профіль загружаецца без сінтаксічнай памылкі, і ён паведамляе, што опцыя выдалена, а не прапускае яе моўчкі. Распазнаць імя і ўвесці паводзіны ў дзеянне — розныя рэчы, і цяпер адбываецца толькі першае. Заўвагі пра выдаленне тлумачаць прычыну: калі параметры можна ўзгадняць, два бакі могуць цалкам законна мець розныя радкі опцый, дамаўляючыся пра злучэнне.

Профіль, які разбіраецца, такім чынам не з’яўляецца доказам таго, што хоць якая праверка допуску выконвалася. Калі ваш адзіны сігнал — што кліент падключыўся, вы даведаліся, што сінтаксіс быў прыняты.

Дзе насамрэч знаходзіцца збой

Захавайце першую канкрэтную памылку, перш чым нешта мяняць, бо наступныя паведамленні звычайна з’яўляюцца яе вынікамі. Збой узгаднення канала даных адносіцца да зацверджанай палітыкі шыфраў і да магчымасцей, якія абодва бакі фактычна абвяшчаюць. Збой версіі або набору TLS адносіцца да кантрольнага канала. Адхіленне сертыфіката патрабуе ідэнтычнасці і ланцуга даверу, а не сцяга сумяшчальнасці.

Вызначце таксама рухавік на абодвух канцах. Настольная праграма можа ўключаць іншую зборку, чым камандны бінарнік, з якім вы тэставалі, і падтрымка опцый паміж імі адрозніваецца. Звярніцеся да дакументацыі гэтага рухавіка, замест таго каб меркаваць, што кожная праграма, якая імпартуе профіль, паводзіць сябе аднолькава.

Замяніце намер, а не толькі радок

Калі стары кіраваны сервер сапраўды спадзяваўся на праверку ўзгодненасці, запішыце, якое абмежаванне ён уводзіў да абнаўлення. Захаванне праігнараванай опцыі ў навейшым профілі не можа захаваць гэтую палітыку, і бессістэмнае выдаленне радкоў таксама не можа.

Не адказвайце на старую параду, што ўсе шыфры адключаны, уключэннем кожнага гістарычнага алгарытму.

Пасля зацверджанай выпраўлення праверце ўзгодненыя вынікі на новым злучэнні і пратэстуйце праграму, якая карыстальніку сапраўды патрэбна. Трымайце версію сервера і эфектыўную палітыку побач з гэтым вынікам, каб наступны чалавек бачыў, пра што дамовіліся, а не толькі што было прынята.

Мэта — падтрыманае абмежаванне і працоўны аўтэнтыфікаваны шлях, а не састарэлы сцяг, які ўсё яшчэ разбіраецца.