Прашыўка на спажывецкім роўтары або NAS часта перабудоўвае канфігурацыю OpenVPN пры кожным запуску, таму дырэктыва, якую вы дадаяце, жыве роўна да наступнай загрузкі. Тое ж датычыцца ключоў, уведзеных у вэб-форму, дзе захаванае значэнне можа вярнуцца скажоным пасля захавання. Ні адзін з гэтых сімптомаў не азначае, што змена адхілена. Гэта азначае, што праўка трапіла ў файл, які прашыўка лічыць вынікам, а трывалае месца знаходзіцца на крок раней у паслядоўнасці загрузкі.

Чаму адрэдагаваны файл ствараецца наноў

Скрыпт запуску збірае канфігурацыю сервера з шаблона і затым запускае дэман, таму згенераваны файл з'яўляецца артэфактам зборкі, а не крыніцай. Усё, дададзенае пасля запуску, нябачна для наступнага запуску гэтага скрыпта. Другі ўзор танчэйшы: увод ключоў і сертыфікатаў у вэб-інтэрфейсе захоўваецца ў экраніраваным выглядзе, і захаванне формы можа запісаць гэты экраніраваны тэкст у файл, які чытае дэман. У любым выпадку згенераваная канфігурацыя — няправільнае месца для трывалай змены.

Паглядзіце, што запісвае паслядоўнасць загрузкі і калі менавіта. Адказ амаль заўсёды — скрыпт у каталогу init або аўтазапуску прашыўкі.

Устаўце дырэктыву там, дзе скрыпт будуе файл

Прылады QTS перабудоўваюць канфігурацыю сервера OpenVPN унутры init-скрыпта, які запускае дэман, таму праўка павінна адбывацца там. Дадайце дапісанне непасрэдна перад камандай запуску, а не рэдагуйце згенераваны файл.

sed -i '/daemon_mgr/i echo client-config-dir clientconfig >>/etc/openvpn/server.conf' /etc/init.d/vpn_openvpn.sh
grep -c client-config-dir /etc/openvpn/server.conf

Прывяжыце ўстаўку да каманды, якая не зрушыцца, бо нумары радкоў змяняюцца паміж зборкамі. Паколькі сам init-скрыпт замяняецца падчас загрузкі, змену трэба паўтараць з кукі аўтазапуску прашыўкі пры кожным старце сістэмы. Пасля адной перазагрузкі палічыце ўзнікненні ў згенераваным файле: адзін радок азначае, што латка спрацавала, а два — што кука выконваецца больш за адзін раз. Даследуйце падвойны запуск асобна, бо гэта не тая ж паломка, што зніклая змена.

Аднавіце форму, якая захавала экраніраваныя ключы

На старонках у стылі Asus палі сертыфіката і ключа паказваюць экраніраваны тэкст, і захаванне пасля старонняй праўкі можа запісаць гэтыя сутнасці назад на дыск. Працуйце з дэкадаванай копіяй і захоўвайце толькі адзін раз, калі ўсе праўкі гатовыя.

openssl dhparam -out dh2048.pem 2048
grep -n "BEGIN DH PARAMETERS" dh2048.pem

Пры замене новага набору параметраў устаўце толькі карысную нагрузку base64, калі поле просіць цела ключа, і пакіньце радкі брані толькі тады, калі поле чакае поўны блок PEM. Аднаўленне старонкі, ужо захаванай у экраніраваным выглядзе, звычайна азначае ачышчэнне пацярпелых палёў і прымяненне, што дазваляе прашыўцы пабудаваць іх зноў. Генеруйце ўсё вышэй за 2048 біт на працоўнай станцыі, бо запас энтрапіі роўтара робіць аперацыю павольнай і часам ненадзейнай. Захоўвайце файл параметраў у месцы, да якога вы зможаце дабрацца пасля скіду да заводскіх налад.

Праверце яшчэ раз пасля абнаўленняў

Абнаўленні прашыўкі замяняюць init-скрыпты і могуць сцерці каталог аўтазапуску, таму латку трэба зноў усталяваць і праверыць. Параўнайце пераствораны файл з копіяй, якую вы захавалі, і пацвердзіце, што дырэктыва прысутнічае роўна адзін раз. Значэнне, бачнае ў вэб-інтэрфейсе, не з'яўляецца доказам таго, што дэман яго атрымаў, бо старонка чытае захаваныя палі. Запішыце каманду латкі і версію прашыўкі ў нататкі аб абслугоўванні, каб наступнае абнаўленне перанесла іх далей.

Затым падключыце кліента і прачытайце журнал сервера наконт перададзенай опцыі. Налада, якая існавала толькі ў форме, — гэта налада, якую ніхто не правяраў.

Падобныя артыкулы