Access Server はネットワークインターフェース名の変更後にバインドを失いました：キーを修正する

ネットワークインターフェースの名前を変更した、あるいはアダプターが別の名前で戻ってきたマシンを復元したところ、OpenVPN Access Server のデーモンが起動しなくなりました。Web インターフェースがまだ応答するかどうかは、どのコンポーネントが古い名前に結び付いていたかによって変わります。サービスは壊れておらず、設定も失われていません。ひとつの設定が、ホストにもう存在しないインターフェースを指したままです。

反射的に再インストールや再初期化を行い、エラーが消えるまでデータベースを編集したくなります。どれも障害より大きな変更であり、最後のものはサーバーを復旧する価値にしていたユーザー、権限、プロファイル依存を消してしまいます。これはバインドの問題で、名前の付いた修正方法があります。

症状が実際に語っていること

バインドできないデーモンは通常、自分のログでそれを告げます。アドレスが利用できない、またはインターフェースが存在しないという内容です。メッセージは具体的で、デーモンが試したアドレスを示します。ホスト上の ip -br addr と比較すれば、インターフェースが改名されたのか、削除されたのか、古いアドレスなしで起動されたのかが分かります。

作業中は常に許可された復旧コンソールを開いておいてください。変更しようとしているバインドが唯一の管理セッションを運んでいるなら、戻る道を自分で断つことになります。ローカルコンソール、二つ目の管理アドレス、文書化された帯域外の経路があれば、変更は元に戻せます。

編集する前に設定を照会する

Access Server は独自の CLI でサーバー設定を公開しています。文書化された表示は次のとおりです。

sacli ConfigQuery

導入済みリリース向けに文書化された管理環境で実行し、別ホストの無関係なシェルからは実行しないでください。変更前に現在値を保護された場所へ保存し、出力全体を公開サポートスレッドに貼り付けないでください。

この出力はサーバー設定の表示であり、完全なバックアップではありません。ユーザーとグループのプロパティは別に照会されるため、きれいなバインドは識別情報を復元せず、復元された識別情報はリスナーを直しません。両方を別々の記録として残してください。

どのリスナーが壊れているかを特定する

Access Server は複数のリスナーを動かします。OpenVPN デーモンはトンネルのトラフィックを、Web サービスは管理ポータルとクライアントポータルを担い、他のコンポーネントが独自のポートを持つこともあります。ブラウザー要求の失敗はどれが失敗したかを示さず、エラーメッセージのポート番号も示しません。

デーモンのバインドキーはデーモンごとに文書化されており、公式チュートリアルではキー名が ip_address で終わっていても値はインターフェース識別子です。その一文を二度読んでください。チュートリアルは UDP と TCP のデーモンが 一つのインターフェースを共有することも前提としているため、片方のキーだけを直すのは部分的な修理です。

一致する行ではなく、指定された設定を変更する

チュートリアルは ConfigPut を特定のキーに対して文書化しています。たとえば vpn.daemon.0.server.ip_address や vpn.daemon.0.listen.ip_address です。製品自身の方法でキー名と新しい値を、導入済みリリースが文書化する構文で使い、診断したリスナーに属するキーだけを変更してください。

してはいけないのは、データベース内で値が古いインターフェース名と等しい行をすべて探し、一括で置き換えることです。それは古い名前がリスナー設定にしか現れなかったという前提に立ちますが、スキーマはそれを保証していません。変更をレビューできなくもします。

さらに二つの誘惑を退ける価値があります。すべてのインターフェースで待ち受ける既定値に戻すのは露出の判断であり、綴りの修正ではありません。意図したローカルバインド、公開される経路、その手前のフィルタリングがその選択と一致している必要があります。設定を再初期化すると問題を解決するのではなく名前を変えるだけです。新規インストールは、改名前に機能していたユーザーと権限をまさに捨ててしまうからです。

適用し、経路が機能することを証明する

値を修正したら、製品が文書化するライフサイクルで適用します（ ライフサイクル ）。チュートリアルはキーを設定した後に sacli start を使います。これはホスト全体の再起動でもデータベースのリセットでもありません。

ss -lntup | grep -E '1194|443'
sacli ConfigQuery | grep -i ip_address

リスナーを確認し、許可された VPN 接続を一本確立し、プライベートなリソースに 一つ到達し、管理ページを想定された経路で開きます。既存のユーザー権限と失効はそのまま残してください。それらをリセットする復旧は、バインドを直して導入を失ったことになります。作業が終わるのは、同じサービスが意図したインターフェースで動いたときです。