OpenVPN 管理ソケット：制御チャネルであり、メトリクスではない

管理インターフェースに一度ステータスを尋ねると、それはステータスポートのように見え始める。しかしそうではない。クライアントが受け入れられると、プロトコルの制御コマンドを発行でき、そのクライアントを実行しているアカウントは、それらのコマンドがデーモンに対してできることすべてを引き継ぐ。これを読み取り専用のフィードとして扱うことが、監視連携を認証なしのコンソールに変えてしまう誤りである。

思い込みとその代償

よくある思い込みは、管理リスナーがメトリクスのエンドポイントと等価だというもので、コレクターをつなぎ、カウンターを読み、先へ進めばよいというものだ。実際に起きるのは、コレクターが制御機能を持つセッションを開くことであり、デプロイについてのその他の前提はすべて、そのコレクターが正しく振る舞うことに依存するようになる。

インターフェースには読み取り専用モードをうたうものは何もない。選べるオブザーバーの役割はなく、設定のユーザー名がそれを作るわけでもない。

受け入れられたクライアントが実際に持つもの

コミュニティのデーモンは同時に一つの管理クライアントしか受け入れない。この一つの枠は、GUI、スクリプト、監視エージェントが同時に接続できないことを意味し、最初のものがセッションを保持している間、二つ目は待つか失敗する。設計が同時の読み取り手を前提としているなら、それはすでに誤りだ。

定期的なスナップショットで足りる場合、ステータスファイルの出力はライブセッションなしで同じ数値を与える。そのファイルを一定間隔で書き、通常のファイル権限で読めば、コレクターは制御プレーンから完全に外れ、これがほとんどの監視が実際に必要とする構成だ。

所有するソケットであり、開かれたソケットではない

Unix ドメインソケットは制御経路をネットワークの外に置くので、変化するトンネルアドレスを問題から取り除ける。しかし権限の問題は取り除けない。親ディレクトリはサービスアカウントが書き込め、コントローラーのアカウントが到達できなければならず、これは二つの別個の許可である：

management /run/openvpn/office-management.sock unix /etc/openvpn/management.password
management-client-user vpn-observer
management-client-group vpn-observer

パスワードファイルは最初の行に管理用の秘密を保持する。そのファイルは他の資格情報と同様に保護し、内容をログやサポートチケットに残さないこと。ユーザーとグループの制限は Unix ソケットのピアチェックであり、ファイルシステムの権限ではないので、目的のプロセスにはファイルへのアクセスと一致する身元の両方が必要だ。

権限エラーを消すためにソケットを誰でも使えるようにするのが、唯一避けるべき修正だ。それはローカルの制御チャネルを、ホスト上のどのプロセスでも操作できるものに変えてしまう。

TCP で公開することは同じ設計ではない

リスナーを TCP ポートへ移しても、安全にも便利にもならない。管理パスワードは平文で送られるので、TCP リスナーは資格情報とセッションの両方を、経路を観察できる誰にでもさらす。別のホストから到達するには、許可された管理チャネルか、必要な観測だけを公開する小さなローカルエージェントが必要だ。

平文の転送路上のパスワードは機密性のない認証であり、その組み合わせは保護されているように感じるぶん、見た目より悪い。

求めていない起動時の依存

いくつかの管理オプションはデーモンのライフサイクルを変える。コントローラーが接続するまで起動を保留したり、コントローラーが消えたら終了したりすると、任意のオブザーバーが厳格な依存になる。そうなれば、クラッシュした監視エージェントがトンネルも道連れにする。

ソケット自体以外を有効にする前に、それらのオプションを確認すること。任意の観測は任意のままであるべきで、再起動ポリシーをグラフ用に追加したコレクターに結びつけるべきではない。

失敗したプロセスの後に残ったソケットファイルは、リスナーが存在する証拠ではない。削除する前にどのインスタンスがその経路を所有しているかを特定し、稼働中のデーモンの下でファイルを消すのではなく、サービス自身の復旧手順を使うこと。

受け入れとはどういうことか

四つの確認が設計を覆う：意図したコントローラーの身元が接続すること、その身元のないプロセスが拒否されること、警告なしに切断するコントローラーをデーモンが生き延びること、制御された再起動を経てもトンネルがトラフィックを運ぶことだ。管理接続の成功は制御プレーンだけを証明する。プライベートなアプリケーションのトラフィックが機能するかについては何も語らないので、それは別にテストすること。四つの結果は、次の運用担当者が見つけられる場所に書き留めておくこと。

管理インターフェースのドキュメントは単一クライアントモデルとプロトコルの特権的な性質を説明しており、ダッシュボードをそこに向ける前に読む価値があるのはその部分だ。