Зошто додавањето opt-verify нема да ја поправи грешката со шифрата во OpenVPN

Наоѓате предлог да додадете opt-verify, ја додавате линијата и грешката со шифрата останува точно таму каде што беше. Тој исход е предвидлив, бидејќи опцијата никогаш не преговарала шифра. Тоа беше проверка на конзистентноста на опциите, застарена во 2.6 и отстранета во 2.7, а профил што сѐ уште се парсира со неа не наметнал ништо со тоа.

Помага да се знае што правела линијата порано пред да се заклучи дека е делот што недостасува. Историјата исто така објаснува зошто сега не може да помогне.

Што наметнуваше опцијата порано

Прирачникот за 2.6 ја означува opt-verify како застарена и го опишува поранешното однесување: серверот ги отфрла клиентите чии декларирани опции не се совпаѓаат со неговите, споредувајќи работи како типот на уред и MTU. Таа проверка зависи и од тоа проверката на конзистентноста на опциите да остане вклучена, така што сервер што работи со disable-occ никогаш не ја имал. Забележете од што е изградена споредбата: од текст што ја опишува конфигурацијата на другата страна. Таа не кажува ништо за тоа која шифра ќе ја користи каналот за податоци.

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

Што прави 2.7 кога ја гледа линијата

Во 2.7 опцијата ја нема. Парсерот сѐ уште го препознава името, затоа стар профил се вчитува без синтаксичка грешка, и известува дека опцијата е отстранета наместо тивко да ја прескокне. Да се препознае име и да се наметне однесување се различни работи, и само првото сѐ уште се случува. Белешките за отстранување го даваат причината: штом параметрите можат да се преговараат, две страни можат законски да имаат различни низи со опции додека се согласуваат за врската.

Затоа профил што се парсира не е доказ дека се извршила каква било проверка за прием. Ако единствениот сигнал е дека клиентот се поврзал, сте дознале дека синтаксата била прифатена.

Каде навистина живее дефектот

Зачувајте ја првата конкретна грешка пред да промените нешто, бидејќи подоцнежните пораки обично се нејзини последици. Неуспех во преговорите на каналот за податоци и припаѓа на одобрената политика за шифри и на можностите што двете страни навистина ги објавуваат. Неуспех на верзија или комплет TLS и припаѓа на контролниот канал. Отфрлањето на сертификат бара идентитет и синџир на доверба, а не знаме за компатибилност.

Идентификувајте го и моторот на двата краја. Десктоп апликацијата може да содржи различен билд од командната бинарна датотека со која сте тестирале, а поддршката за опции се разликува меѓу нив. Проверете ја документацијата на тој мотор наместо да претпоставите дека секоја програма што увезува профил се однесува исто.

Заменете ја намерата, не само линијата

Ако постар управуван сервер навистина се потпирал на проверката на конзистентност, запишете какво ограничување наметнувал пред надградбата. Задржувањето на игнорирана опција во понов профил не може да ја зачува таа политика, а ниту безобѕирното бришење на линии не може.

Не одговарајте на стар предлог дека сите шифри се исклучени со вклучување на секој историски алгоритам.

По одобрена исправка, проверете ги преговараните резултати на нова врска и тестирајте ја апликацијата што на корисникот навистина му е потребна. Држете ја верзијата на серверот и ефективната политика до тој резултат, за да може следниот човек да види што е договорено, а не само што е прифатено.

Целта е поддржано ограничување и работна автентицирана патека, а не старо знаме што сѐ уште се парсира.