Прошивка побутового роутера або 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-скрипти й можуть стерти каталог автозапуску, тож латку треба перевстановити й перевірити заново. Порівняйте перегенерований файл зі збереженою копією і підтвердьте, що директива присутня рівно один раз. Значення, видиме у вебінтерфейсі, не є доказом, що демон його отримав, бо сторінка читає збережені поля. Запишіть команду латки й версію прошивки в нотатки з обслуговування, щоб наступне оновлення перенесло їх далі.

Потім підключіть клієнт і прочитайте в журналі сервера передану опцію. Налаштування, яке колись існувало лише у формі, — це налаштування, яке ніхто не перевіряв.

Схожі статті