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

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

Корисно је знати шта је ред некада радио пре него што закључите да је он део који недостаје. Историја такође објашњава зашто сада не може да помогне.

Шта је опција некада наметала

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

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

Шта 2.7 ради када види ред

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

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

Где грешка заиста живи

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

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

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

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

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

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

Циљ је подржано ограничење и радни аутентификовани пут, а не стара заставица која се још увек парсира.