VPN 経由の SSHFS マウントはユーザーセッションが所有すべきか？

VPN が起動した後に共有フォルダーをマウントする場合、混同しやすい二つの ID が関わります: ネットワークを構成する権限を持つコンポーネントと、ファイルサーバーにログインする権限を持つアカウント。両者が同じであることはまれです。root 所有の VPN フックは、デスクトップユーザーの SSHFS マウントを始める場所としては不適切であり、ユーザーのエージェントも意図したマウントの所有権も持たないからです。所有権を先に正しく決めれば、トリガーは単純になります。

二つの ID、二つの別個の権限

VPN クライアントはルートとインターフェースを変更する特権を必要とします。SSHFS マウントには、ファイルサーバーが受け入れる SSH ID と、ファイルを読むアカウントが所有する FUSE マウントが必要です。root として実行する一つのスクリプトは最初の要件を満たし、二番目を静かに壊します。

root としてマウントすると、ファイルはデスクトップセッションの外に置かれ、ユーザーの鍵を保持するエージェントにアクセスできない可能性があります。マウントは存在するのにユーザーは書き込めず、障害はサーバー側の権限問題のように見えます。その誤診は半日とストレージチームへのチケットを費やします。

自動化を書く前に、どのアカウントがマウントを所有するかを、その選択がトリガーの置き場所と到達できる資格情報を決めるため、決めてください。

まず手動でユーザー所有のマウントを確立する

空のマウントポイント、承認された SSH アカウント、トンネル経由でサーバーへの有効なパスを持つサインイン済みユーザーから始めます。手動マウントは、あらゆる自動化が再現すべき基準を確立します。

mkdir -p "$HOME/mnt/team"
sshfs [email protected]:/exports/team "$HOME/mnt/team"
mount | grep sshfs

名前は例なので、サーバーが実際に提供するホストとエクスポートパスに置き換えてください。最初の接続で承認されたプロセスを通じてホスト鍵を検証します。VPN アカウントのパスワードが自動的にストレージアカウントの資格情報ではないことには注意が必要で、これは失敗の一般的な原因です。

そのユーザーが所有するマウントポイントで、通常のユーザーとして実行します。既定ではマウントしたアカウントだけがファイルに到達し、allow_other はその境界をすべてのローカルユーザーに広げます。これは意図的なアクセスの拡大であり、自動化のための回避策ではありません。

トリガーを同じセッションコンテキストで動作させる

サポートされた VPN イベント統合にユーザーセッションのアクションを実行させるようにし、特権 callback がデスクトップの資格情報を借用できると仮定しないでください。トリガーは、たまたま tun0 という名前のインターフェースではなく、意図した接続識別子に限定します。誤った対象に一致するディスパッチャールールは、このマウントと無関係なものも含め、あらゆるネットワーク変更で発火します。

アクションは、期待されるホスト名を確認し、既存のマウントに気づき、一回の限定的な試行を行うべきです。数秒ごとに新しい SSHFS プロセスを起動したり、サーバーが停止している間に資格情報のプロンプトを再試行したりするポーリングループは、短い障害を大量のスタックしたプロセスに変えます。試行はタイムアウトと一回の再試行で制限します。

nmcli -g UUID connection show --active
systemctl --user list-units 'sshfs*'
pgrep -a sshfs

最初のコマンドは、ディスパッチャーが一致させるべき接続識別子を返します。残りの二つは試行がすでに実行中かどうかを示し、これが重複を防ぐチェックです。

無人サービスは、独自の実行コンテキストで独自の承認済み資格情報とホスト検証の仕組みを必要とします。グラフィカルエージェントがロック解除されていると仮定できず、ロック解除を試みるべきでもありません。

強制的なクリーンアップの前に切断を計画する

計画的な切断では、ファイル操作を終え、マウントしたユーザー自身のワークフローからアンマウントします。プロセスではなくマウントポイントを対象にし、成功を報告する前に結果を確認します。

fusermount3 -u "$HOME/mnt/team"
mountpoint "$HOME/mnt/team"

このワークフローが作成したマウントだけをアンマウントし、ビジー状態ならそれはアプリケーションの判断です。フックに成功を返させるためだけの強制デタッチは、データ損失を防ぐどころか隠します。

予期しない損失は異なる挙動をします。SSHFS は、ネットワーク中断がファイルシステム操作をブロックしうること、reconnect オプションがトランスポートを復元してもハンドルは復元しないことを文書化しています。再接続前に開いたファイルは次の書き込みで失敗することがあり、中断された書き込みは保持されません。この違いは、一つのファイルを何時間も開いたままにするエディターにとって最も重要なので、復旧を前提にせず、再オープンの手順を計画してください。

依存する前に、使い捨てのファイルで挙動をテストしてください。トンネルが戻った後にディレクトリが再び現れても、以前のハンドルや未保存の作業が生き残ったことの証明にはなりません。