Бришењето на 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

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

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

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

Старата опција key-method избираше како се врамува TLS размената на клучеви, а современата размена е методот со повеќе пакети што таа опција некогаш го бараше. Опцијата исчезна зашто веќе не избираше ништо; форматот што го именуваше стана единствениот. Затоа бришењето на линијата ја остава сесијата со истото врамување како порано. Текстуална измена не може да го смени тоа во ниту една насока.

Затоа враќањето на стара бинарна датотека за да се „врати“ методот 2 е погрешна поправка. Не враќа ништо освен постар парсер со постари стандардни вредности и ве чини исправките што дојдоа по него. Истата логика важи и за ослабување на проверка на сертификат или список на шифри во надеж дека врската ќе се врати.

Корисна проверка е верзијата и парсираната конфигурација, а не присуството на зборот во датотеката:

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

Што да се отстрани и од која датотека

Уредете ја датотеката што тековниот процес навистина ја чита, и само таа. На пакувани системи тоа обично е профилот во директориумот на клиентот или серверот што го именува единицата, а не копија во вашиот домашен директориум што ја чувате за референца. Генерираниот профил може да се преизгради од шаблон, па промена направена само во распоредената копија ќе се врати по следното извршување на обезбедувањето.

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

Потоа стартувајте ја саканата инстанца и прочитајте го нејзиниот излез при стартување. Чисто стартување со присутен слушател е потврдата дека оваа фаза е завршена; тестот на клиентот потоа одговара на друго прашање.

Одбиен профил и одбиен клиент изгледаат слично

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

Отстранетата опција не е дијагноза за вториот случај, и посегнувањето по неа го троши истиот час двапати. Ако дневникот на клиентот го покажува одбивањето на серверот, прочитајте го тоа одбивање; ако покажува локална грешка, датотеката што треба да се прегледа е профилот на клиентот. Посегнувањето по директива што повеќе не постои ги одложува двете истраги за исто толку.

Прашања за компатибилност на кои линијата никогаш не одговори

Профилите што кружат со оваа директива обично носат приказна за одредена платформа, а приказната го надживува техничкиот причина. На мобилен или десктоп клиент сè уште му треба целосен поддржан профил: доверлив синџир на сертификати, шифра за податоци што ја прифаќаат двете страни, режим на контролен канал што го спроведуваат двете страни и никакви директиви што изградбата на клиентот ги одбива. Ниту едно од тоа не се решава со присуството или отсуството на старата линија key-method.

Компресијата е одделно прашање на политика со иста форма. Бришењето на линија key-method не кажува ништо за тоа дали директивата за компресија е поддржана или прифатлива во вашето распоредување, и двете одлуки треба да се донесат независно. Бришењето на неколку безбедносно релевантни поставки одеднаш додека нешто не се поврзе е патот на кој работен профил станува необјаснет.

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