Изтриването на key-method от профил на OpenVPN не променя нищо

Профил, който работи с години, изведнъж отказва да стартира, а съобщението назовава директива, която никой не помни да е добавял: key-method. Следващият резултат от търсенето предлага добавяне на key-method 2 за съвместимост, което е съвет от друга епоха. Парсерът, който отхвърли реда, е актуален и изобщо няма такава опция. Премахването на реда оправя стартирането и не променя нищо в това как двете страни защитават сесията.

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

Симптомът е грешка при парсване, а не провал на ръкостискането

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

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

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

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

Директивата и форматът на предаване са две различни неща

Старата опция key-method избираше как се рамкира TLS обменът на ключове, а съвременният обмен е методът с множество пакети, който тази опция някога е изисквала. Опцията изчезна, защото вече не избираше нищо; форматът, който тя назоваваше, стана единственият. Затова премахването на реда оставя сесията със същото рамкиране както преди. Текстова редакция не може да промени това в нито една посока.

Ето защо връщането на стар двоичен файл, за да „възстанови“ метод 2, е грешният ремонт. То не възстановява нищо освен по-стар парсер с по-стари стойности по подразбиране и ви струва поправките, дошли след него. Същата логика важи за отслабване на проверка на сертификат или списък с шифри в надежда връзката да се върне.

Полезна проверка е версията и парснатата конфигурация, а не наличието на думата във файла:

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

Какво да премахнете и от кой файл

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

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

След това стартирайте предвидената инстанция и прочетете изхода ѝ при стартиране. Чисто стартиране с наличен слушател е потвърждението, че този етап е завършен; тест на клиента след това отговаря на друг въпрос.

Отхвърлен профил и отхвърлен клиент изглеждат еднакво

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

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

Въпроси за съвместимост, на които редът така и не отговори

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

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

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