Настройките на OpenVPN на рутера се връщат след рестарт: поправете генератора

Фърмуерът на потребителски рутер или NAS често пресъздава конфигурацията на OpenVPN при всяко стартиране, така че директива, която добавите, оцелява точно до следващото зареждане. Същото важи за ключове, въведени в уеб формуляр, където запазената стойност може да се върне осакатена след запис. Нито един от тези симптоми не означава, че промяната е отхвърлена. Това означава, че редакцията е попаднала във файл, който фърмуерът третира като изход, а трайното място е една стъпка по-рано в последователността на зареждане.

Защо редактираният файл се генерира наново

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

Вижте какво записва последователността на зареждане и кога го записва. Отговорът почти винаги е скрипт в директорията init или autostart на фърмуера.

Вмъкнете директивата там, където скриптът строи файла

Устройствата 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 скриптовете и могат да изтрият директорията autostart, така че кръпката трябва да се инсталира и тества отново. Сравнете регенерирания файл с копието, което сте запазили, и потвърдете, че директивата присъства точно веднъж. Стойност, видима в уеб интерфейса, не е доказателство, че демонът я е получил, защото страницата чете запазени полета. Запишете командата за кръпката и версията на фърмуера в бележките за поддръжка, за да ги пренесе следващата актуализация.

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