A configuración de OpenVPN no router revértese tras reiniciar: repara o xerador

O firmware dun router doméstico ou dun NAS adoita reconstruír a súa configuración de OpenVPN en cada arranque, así que unha directiva que engades sobrevive exactamente ata o seguinte arranque. O mesmo ocorre coas chaves escritas nun formulario web, onde o valor gardado pode volver corrupto tras gardar. Ningún destes síntomas significa que o cambio fose rexeitado. Significa que a edición aterrou nun ficheiro que o firmware trata como saída, e que o lugar duradeiro está un paso antes na secuencia de arranque.

Por que se rexenera o ficheiro editado

Un script de inicio ensambla a configuración do servidor a partir dun modelo e despois lanza o daemon, o que converte o ficheiro renderizado nun artefacto de compilación en lugar dunha fonte. Todo o que se engade despois do inicio é invisible para a seguinte execución dese script. O segundo patrón é máis sutil: as entradas de chave e certificado na interface web gárdanse en forma escapada, e gardar o formulario pode empurrar ese texto escapado ao ficheiro que le o daemon. En calquera caso, a configuración renderizada é o lugar equivocado para facer un cambio duradeiro.

Mira que escribe a secuencia de arranque e cando o escribe. A resposta case sempre é un script dentro do directorio init ou de inicio automático do firmware.

Insire a directiva onde o script constrúe o ficheiro

Os equipos QTS rexeneran a configuración do servidor OpenVPN dentro do script init que arranca o daemon, así que a edición ten que ocorrer alí. Engade o anexo xusto antes do comando de arranque en lugar de editar o ficheiro xerado.

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

Ancorar a inserción nun comando que non se mova, porque os números de liña cambian entre compilacións. Como o propio script init se substitúe durante o arranque, o cambio debe reemitirse desde o gancho de inicio automático do firmware cada vez que arranca o sistema. Tras un reinicio, conta as aparicións no ficheiro xerado: unha liña significa que o parche funcionou, mentres que dúas significan que o gancho se executa máis dunha vez. Investiga a execución dobre por separado, porque non é a mesma falla que un cambio que desapareceu.

Repara un formulario que gardou chaves escapadas

Nas páxinas de estilo Asus os campos de certificado e chave mostran texto escapado, e gardar tras un axuste non relacionado pode devolver esas entidades ao disco. Traballa desde unha copia descodificada e garda só unha vez, cando todas as edicións estean listas.

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

Ao cambiar un conxunto de parámetros novo, pega só a carga base64 se a etiqueta pide o corpo da chave, e conserva as liñas de armadura só cando o campo espera un bloque PEM completo. Recuperar unha páxina xa gardada na súa forma escapada adoita significar baleirar os campos afectados e aplicar, o que permite ao firmware reconstruílos. Xera calquera cousa por riba de 2048 bits nunha estación de traballo, porque a subministración de entropía do router fai a operación lenta e ás veces pouco fiable. Garda o ficheiro de parámetros nun lugar ao que poidas chegar tras un restablecemento de fábrica.

Comproba de novo tras as actualizacións

As actualizacións de firmware substitúen os scripts init e poden borrar o directorio de inicio automático, así que o parche debe reinstalarse e probarse de novo. Compara o ficheiro rexenerado coa copia que gardaches e confirma que a directiva está exactamente unha vez. Un valor visible na interface web non é proba de que o daemon o recibise, porque a páxina le campos gardados. Escribe o comando do parche e a versión do firmware nas notas de mantemento para que a próxima actualización as arrastre.

Despois conecta un cliente e le o rexistro do servidor para a opción enviada. Un axuste que só existiu algunha vez nun formulario é un axuste que ninguén probou.