コンシューマー向けルーターやNASのファームウェアは、起動のたびにOpenVPN設定を再生成することがよくあり、追加したディレクティブは次の起動までしか持ちません。同じことはウェブフォームに入力した鍵にも当てはまり、保存後に保存値が壊れて戻ることがあります。これらの症状はどちらも変更が拒否されたことを意味しません。編集がファームウェアの出力として扱われるファイルに入り、永続的な場所は起動シーケンスの一歩前にあるという意味です。

編集したファイルが再生成される理由

起動スクリプトはテンプレートからサーバー設定を組み立ててからデーモンを起動するので、レンダリングされたファイルはソースではなくビルド成果物になります。起動後に追加されたものは、そのスクリプトの次回実行には見えません。二つ目のパターンはより微妙で、ウェブインターフェースの鍵と証明書の入力はエスケープされた形で保存され、フォームを保存するとそのエスケープされたテキストがデーモンの読むファイルに押し込まれることがあります。いずれにせよ、レンダリングされた設定は永続的な変更を行うのに適した場所ではありません。

起動シーケンスが何をいつ書き込むかを見てください。答えはほとんどの場合、ファームウェアのinitまたは自動起動ディレクトリにあるスクリプトです。

スクリプトがファイルを組み立てる場所にディレクティブを挿入する

QTS機器はデーモンを起動するinitスクリプトの中でOpenVPNサーバー設定を再生成するため、編集はそこで行う必要があります。生成されたファイルを編集するのではなく、起動コマンドの直前に追記を加えます。

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スクリプトを置き換え、自動起動ディレクトリを消すことがあるため、パッチは再インストールして再テストする必要があります。再生成されたファイルを保管しておいたコピーと比較し、ディレクティブが正確に一度だけ存在することを確認します。ウェブインターフェースに見える値は、ページが保存されたフィールドを読むだけなので、デーモンが受け取った証拠にはなりません。パッチのコマンドとファームウェアのバージョンを保守ノートに書き、次の更新に引き継いでください。

次にクライアントを接続し、プッシュされたオプションについてサーバーログを読みます。フォームの中にしか存在しなかった設定は、誰も検証していない設定です。

関連記事