Защо добавянето на opt-verify няма да поправи грешката с шифъра в OpenVPN

Намирате предложение да добавите opt-verify, добавяте реда и грешката с шифъра остава точно там, където беше. Този резултат е предвидим, защото опцията никога не е договаряла шифър. Това беше проверка за съгласуваност на опциите, отхвърлена в 2.6 и премахната в 2.7, а профил, който с нея все още се анализира, не е наложил с това нищо.

Полезно е да знаете какво правеше редът преди, преди да заключите, че той е липсващото парче. Историята също обяснява защо сега не може да помогне.

Какво налагаше опцията преди

Ръководството за 2.6 отбелязва opt-verify като отхвърлена и описва по-ранното поведение: сървърът изхвърля клиенти, чиито декларирани опции не съвпадат с неговите, сравнявайки неща като тип устройство и MTU. Тази проверка също зависи от това проверката за съгласуваност на опциите да остане включена, така че сървър, работещ с disable-occ, никога не я е имал. Забележете от какво е изградено сравнението: текст, описващ конфигурацията на отсрещната страна. То не казва нищо за това кой шифър ще използва каналът за данни.

Това е първата причина флагът да не може да поправи грешка с шифъра. Изборът на шифър се управлява от политиката data-ciphers и от това какво поддържат двете страни, а текстовата проверка за съгласуваност нито разширява този списък, нито извършва договарянето. Втората причина е обхватът: проверката е за това дали декларираните опции изглеждат съвместими, а не за качеството на пътя, който се получава.

Какво прави 2.7, когато види реда

В 2.7 опцията я няма. Парсерът все още разпознава името, поради което стар профил се зарежда без синтактична грешка, и съобщава, че опцията е премахната, вместо да я прескочи мълчаливо. Разпознаването на име и налагането на поведение са различни неща и само първото все още се случва. Бележките за премахването дават причината: след като параметрите могат да се договарят, две страни могат законно да имат различни низове с опции, докато се съгласяват за връзката.

Профил, който се анализира, следователно не е доказателство, че е извършена каквато и да е проверка за допускане. Ако единственият ви сигнал е, че клиентът се е свързал, вие сте научили, че синтаксисът е бил приет.

Къде всъщност живее отказът

Запазете първата конкретна грешка, преди да промените нещо, защото следващите съобщения обикновено са нейни последствия. Отказ при договаряне на канала за данни принадлежи на одобрената политика за шифри и на възможностите, които двете страни действително обявяват. Отказ на версия или набор от TLS принадлежи на контролния канал. Отхвърлянето на сертификат се нуждае от идентичността и веригата на доверие, а не от флаг за съвместимост.

Идентифицирайте и машината от двата края. Настолно приложение може да включва различна сборка от командния двоичен файл, с който сте тествали, и поддръжката на опции се различава между тях. Проверете документацията на тази машина, вместо да предполагате, че всяка програма, която импортира профил, се държи по същия начин.

Заменете намерението, а не само реда

Ако по-стар управляван сървър наистина е разчитал на проверката за съгласуваност, запишете какво ограничение е налагал преди надграждането. Задържането на игнорирана опция в по-нов профил не може да запази тази политика, а безразборното изтриване на редове също не може.

Не отговаряйте на старо предложение, че всички шифри са изключени, като включите всеки исторически алгоритъм.

След одобрена корекция прегледайте договорените резултати на нова връзка и тествайте приложението, което потребителят действително има нужда. Дръжте версията на сървъра и ефективната политика до този резултат, за да може следващият човек да види какво е било договорено, а не какво просто е било прието.

Целта е поддържано ограничение и работещ удостоверен път, а не наследен флаг, който все още се анализира.