ここに、人によっては一週間を無駄にする思い込みがあります。Mac にはログイン前と呼ばれる瞬間が一つだけあり、VPN クライアントはその瞬間に起動するかしないかだ、という思い込みです。実際のマシンには、ネットワークアクセスが問題になる瞬間が少なくとも三つあり、それらはその時点で誰が資格情報を持てるかによって分かれています。ログイン項目から起動するクライアントが覆うのはそのうちの一つだけで、しかも最後のものです。

一つの設定が起動全体を覆うという神話

製品ページをもう一度読み、その機能がどの段階を指しているかを見てください。ログイン時に起動と書かれたチェックボックスはログイン項目を意味し、これはユーザーセッションができた後に実行されます。要求時に接続と書かれたチェックボックスは、通信が規則に一致したときにクライアントが接続を開くという意味で、そのためにはクライアントと資格情報が利用可能である必要があります。

どちらも起動プロセスには届きません。これはベンダーが外し忘れた制限ではなく、OS が許している範囲です。ボリュームが解除される前には、クライアントを起動するための動作中のシステムがなく、ログアウト後はユーザーの秘密はセッションとともに去ります。二つの別々の壁であり、どちらも別のチェックボックスには屈しません。

段階を分けると、元の問いは形を変えます。VPN がログイン前に起動するかどうかを問う代わりに、三つの具体的な瞬間のどれが機能する必要があるかを問い、そしてそれぞれの持ち主が違うことに気づきます。暗号化スタック、ネットワーク拡張、あるいはユーザーセッションです。

各段階で実際に何が起きるか

起動は暗号化されたボリュームから始まり、汎用的な作業に使えるシステムができる前にそれを解除する必要があります。その解除は限られた文脈で限られた資格情報を用いて行われ、Apple は有効な解除なしには暗号化データに到達できないとはっきり文書化しています。

次にログインウィンドウが来ます。システムは動いていますが、まだユーザーセッションはありません。ユーザーがログアウトしていればユーザー文脈の拡張はすでに終了しており、グローバルのシステム拡張はまだ動いているかもしれませんが、動いていることは VPN が必要とする資格情報を保持していることと同じではありません。

その後にセッションが来て、通常のクライアントは ログインキーチェーンを読み、二つ目の要素を求め、プッシュされた経路を適用できます。人がログイン前と呼ぶ機能のほとんどは実際にはこの段階であり、ログイン前ではなくセッションの早い時期に起動します。

StageWhat it can useWhat it cannot do
FileVault unlockCredentials supplied at the console to unlock the volumeRun an ordinary VPN app or read a user keychain
Login windowSystem context, possibly a joined networkUse a user secret that only exists after login
User sessionLogin keychain, interactive MFA, full client featuresExist before the volume unlocks

launch daemon が不在のユーザーのためにサインインできない理由

高い特権があれば解決しそうに思えますが、解決しません。launch daemon はユーザーセッションを持たないシステムプロセスとして動くため、解除すべきキーチェーンも、要求に答える人間もありません。ソケットを開きファイルを読むことはできますが、資格情報を持つユーザーになることはできません。特権は身元ではなく、まさにここで両者が混同されます。

その隙間に人が作るのはパスワードを埋め込んだスクリプトであり、元の問題より悪い問題です。

要件の正直な版はもっと狭いものです。誰もいない間にマシンが保護された資源に到達しなければならないなら、その資源が受け入れる身元は、人なしでマシンが保持できるものでなければなりません。デバイス証明書、システムキーチェーン内の資格情報、あるいは二つ目の要素が誰かのポケットの電話へのプッシュではないアカウントです。その身元を意図的に設計すれば、段階の問いはたいてい自ら答えを出します。

Windows のログイン前機能はそのまま移せない

Windows には一部のリモートアクセス製品向けに文書化されたログイン前アクセスの仕組みがあり、名前は能力よりもうまく旅をします。Windows の展開ガイドに書かれた機能は、同じベンダーが macOS で同等のものを実装しているかについては何も教えてくれません。

Mac のハードウェア、macOS の版、クライアントの版、そして実際に使っている認証方式を網羅した声明を求めてください。一般的なサポートの主張では足りません。動くか動かないかの差は、しばしばその四つのうちの一つにあるからです。

ベンダーが答えられないなら、それが答えです。展開の途中で隙間に気づくのではなく、セッション段階を計画し、無人の場合の代替を設計してください。

代わりに何を求めるか

要件を段階の言葉で書いてください。どの資源が、誰に必要で、どの文脈で、接続がまだないときにどれだけの遅延まで許容するのか。

答えが、サインインした後にトンネルを必要とするユーザーなら、要求時接続と起動項目で十分で安価です。答えが、夜間に再起動して報告しなければならないマシンなら、設計にはサポートされたディスク解除の経路、デバイスの身元、そしてネットワークが決して上がらないときにも機能する復旧手順が必要です。答えがトンネルに依存する組織のサインインなら、ログイン、身元、VPN の設計を別々に買うのではなく一緒に作る必要があります。

Apple の FileVault の文書 が解除段階の正しい出発点です。その後に続くものはすべてクライアントと身元の問いであり、購入前にベンダーの声明で決着させるべきものです。

関連記事