OpenVPN に RADIUS を組み込む：プラグインかスクリプトフックか

プラグインは現在のビルドより古いスレッドで今も勧められますが、昨日コンパイルしたサーバーでは読み込み時に失敗します。これはパスで直せる設定ミスではありません。プラグインとスクリプトフックは同じ問題を別の層で解き、一方から他方へ移ると、何を導入するか、何がサーバー権限で動くか、ログイン失敗が実際に何を伝えるかが変わります。

神話：プラグインがサポートされた道である

プラグインは OpenVPN プロセスに読み込まれる共有オブジェクトなので、そのプロセスが公開するインターフェースと一致しなければなりません。ビルドは変わり、パッケージングも変わり、古いインターフェース向けにコンパイルされたライブラリは読み込みを拒否します。サーバー設定ではこの隔たりを埋められず、だから「radiusplugin を入れるだけ」という助言は起動しないサーバーで終わります。

スクリプトフックはプロセスの外に置かれます。OpenVPN はプログラムを実行し、資格情報を渡し、判定を読み戻します。この分離がアップグレードを生き延びさせ、同時にプラグインにはなかった形であなたの責任にします。

どちらの方式も構造上より安全ということはありません。一方はデーモンの中で外部コードを動かし、他方は資格情報を手元に置いて隣であなたのコードを動かします。正しい問いは、その二つのリスクのどちらを実際に運用できるかです。

プラグインが結び付けていたもの

プラグインは RADIUS ホスト、共有シークレット、再試行回数、タイムアウトを記した独自の設定ファイルを持ち、サーバー設定は一行でそれを参照していました。資格情報の扱いはサーバープロセスの中に留まり、パスワードが管理者の守るべきプロセス境界を越えることはありませんでした。

代償は結合でした。OpenVPN の更新のたびに非互換インターフェースの危険があり、パッケージを再構築するディストリビューションのたびに合わなくなるライブラリの危険がありました。それが起きれば障害は大きく即座に現れ、それがこの設計の唯一の慈悲です。

その種のプラグインがまだあなたのビルドで読み込まれるなら、より小さな運用面であり得ます。どのインターフェース向けに作られたかを確認し、試したビルドに固定し、更新は定型のパッケージ更新ではなく完全なログイン試験を要する変更として扱ってください。

スクリプトフックが実際に信頼するもの

フックは auth-user-pass-verify と受け渡し方式、つまり環境変数か一時ファイルで設定します。環境変数方式では OpenVPN が script-security 3 を要求し、これはスクリプトへのパスワード露出を許す文書化された水準です。その水準は既定を意図的に弱めるもので、根拠を添えた許可として扱うべきです。

スクリプトが触れるものすべてがその信頼を継承します。root 所有で、グループやその他から書き込み不可で、絶対パスで参照され、信頼できない値がシェルに届く箇所がないことが必要です。すべての変数を引用し、想定外の文字を拒み、与えられたユーザー名からコマンドを組み立てないでください。ログイン試行のたびに root で走るスクリプトは、まさにその四つの性質のために一度レビューする価値があります。

ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh

ファイル受け渡し方式は環境継承の問題を避け、制限された権限の一時ファイルでスクリプトに資格情報を渡します。クライアントが対応していれば通常はこちらの方が良い既定で、失敗時に片付ける対象が一つ増えるだけです。

終了コードが開いた失敗になるかを決める

判定となるのはスクリプトの終了状態で、ゼロは受け入れ、非ゼロは拒否します。問題を起こすのは、RADIUS 応答に特定の受け入れトークンがあるときだけ受け入れ、それ以外はすべて失敗を返すシェルスクリプトで、これは三つの異なる出来事を一つの答えに潰してしまうからです。誤ったパスワードも、到達できないサーバーも、壊れた応答も、同じ拒否になります。

フックが受け入れか拒否しか返せなくても、スクリプト内でその場合分けをしてください。バックエンドの結果を別に記録し、タイムアウトと転送エラーに警告を出し、監視ではサービス停止による認証失敗と入力ミスによる失敗を見分けられるようにします。

二つの習慣が残りをまとも保ちます。RADIUS が権威なら、パスワードを確認する唯一の場所であるべきで、影のテーブルは同じ問いに二つの答えを作り、二つ目は誰も見ていない攻撃面になります。またフックは再試行のたびに呼ばれるので、遅いスクリプトとせっかちなクライアントが組み合わさると、RADIUS 側で遅延や方針を足さない限りパスワード推測の増幅器になります。

証明書が消えるときに手放すもの

この形の配備の多くはクライアント証明書の確認を完全に切り、ユーザー名とパスワードをクライアントの主張のすべてにします。その設定で失われるのは証明書に基づく身元です。経路は暗号化されたままですが、クライアントを名指しする唯一のものは RADIUS の判定です。以前に証明書の subject に依存していた下流のものは、今後ユーザー名に依存しなければなりません。

制御チャネルの保護は残し、未認証の相手がハンドシェイクを探ったり溢れさせたりできないようにし、利用者ごとの設定がコモンネームに依存する場合は username-as-common-name を使ってください。管理されたゲートウェイはしばしば別の解き方をし、RADIUS と EAP-TLS を話すゲートウェイで証明書認証を終端し、その場合これらのサーバーディレクティブはどれも当てはまりません。隣の製品のモデルではなく、自分のプラットフォームが文書化するモデルを写してください。重要なディレクティブは互いに十分違い、混ぜると解析は通るのに誰も認証しない設定になります。