chroot を捨てるべきか、iproute2 を監獄にコピーすべきか

サービスが起動し、クライアントが接続し、サーバー側にはいつまでも経路が現れません。あるいはデーモンが起動を拒否し、実行できなかったコマンドを名指しします。どちらの結果も同じ三行に従っていて、ふつうは強化ガイドからまとめてコピーされます。非特権アカウントへ切り替える、グループを外す、ファイルシステムのルートを変える、の三行です。ファイルを隠すのは三つのうち一つだけで、その一つだけが ルーティングテーブルを変更する権限を奪う。切り分けて試すことで、本当に必要な行がどれか分かります。

監獄が取り上げるもの、それでもデーモンが必要とするもの

ルートの変更は起動後に起きるので、デーモンはすでに開いたものすべてを保持し、後から開くはずだったものすべてを失います。接続がその時点以降に実行するヘルパーは、読み込む共有ライブラリごと新しいルートの中に存在しなければなりません。設定ファイルと証明書だけで組んだ監獄には、どちらもありません。

非特権アカウントへの切り替えは別の制限です。root を手放したプロセスは、バイナリがすぐそこにあっても経路を変更できず、インターフェースを上げられないことがあるので、二つの故障は分けて診断する必要があります。

三つの条件が、必要な修正を決める

第一の条件は、ビルドが経路をどう導入するかです。新しい OpenVPN のリリースはインターフェースとルーティングテーブルをプロセス内で設定しますが、古いパッケージや独自の構成は外部ツールや up と down のスクリプトに頼ります。ログがコマンドを名指ししていれば外部ツールが関与していて、監獄がそれを隠しています。代わりに権限エラーが出ていれば、問題はアカウント側です。

第二は保守です。バイナリをコピーした監獄は、それを提供するパッケージが更新されるたびに作り直さなければなりません。そうしないと最初の更新で壊れたトンネルが残ります。第三は、その制御が本当に chroot を必要とするかどうかで、要求が実は権限分離の話であればアカウントの切り替えだけで足りるかもしれません。

動く監獄に必要なもの

コマンドを実行する監獄には、バイナリ、それがリンクするすべてのライブラリ、そしてデーモンが遅れて開くデバイスノードが要ります。部品をコピーして、VPN を抜いた状態で試してください：

ldd /usr/sbin/ip
chroot /etc/openvpn/jail /sbin/ip route show
chroot /etc/openvpn/jail /sbin/ip link set tun0 up

最初のコマンドは依存関係を並べるもので、これが一番飛ばされがちです。コピーしたバイナリがライブラリを見つけられないときのメッセージは、バイナリが無いときとは違い、どちらもクライアント側から見れば OpenVPN の不具合に見えます。監獄の中で手で実行すれば、サービスを再起動せずに不具合を再現できます。

設定、証明書、CRL があればそれも監獄へコピーしてください。起動後に読み直すはずのファイルはルートが変わった時点で見つからないからで、何をコピーしたか記録しておかないと、ネットワークパッケージの次の更新が原本を置き換え、監獄は古いコピーのまま取り残されます。

代わりに強化を縮める

監獄がガイドにそう書いてあったから存在するだけなら、その一行を消してアカウントの制限を残すのは筋の通った結論です。デーモンはファイルシステムの見え方を保ち、問題は消え、権限降格は長命のプロセスから root を外したままです。

何が残ったのか、なぜそうしたのかを書き留めてください。制御を一つ静かに失ったまま注記の無い設定は、強化がずれていく道です。次の監査は、その行がなぜ消えたのかを尋ねます。

選ぶ前に三行を分けて試す

設定をコピーし、三つの指示をすべて無効にして、クライアントが接続し期待した経路が出ることを確認します。次にアカウントの行だけを戻し、最後に chroot だけを戻します。 トンネルが切れる段階が境界を示します。そうすれば、原因ではなかった監獄を作り直さずに済みます。

経路が戻ったら、ログの詳細度を上げてクライアントのセッションを一度だけ実行し、コマンドや権限の失敗を名指しした行を読んでください。その一行は、クライアントが最後に報告するタイムアウトより価値があります。