スクリプトは VPN を起動するだけで、プロビジョニングはしない

接続名を指定して scutil --nc start を実行するスクリプトを書き、自分の Mac では動くのに、オフィスの新規導入マシンではどれも失敗する。スクリプトが壊れているわけではなく、もともとできなかったことを頼まれているのだ。既存の接続を起動することは、新しい接続を作ることと同じ操作ではない。

プロビジョニングとセッション制御は、二人の担当者がいる二つの仕事であり、そうでないと仮定したワークフローは、書いた本人のマシンでしかテストを通らない。

起動コマンドが実際に話している相手

セッション制御コマンドは、すでに存在し承認済みの構成を対象にする。以前に保存されたサーバー設定・ID 参照・ポリシーを使って、その名前の接続を立ち上げるようシステムに依頼する。それらが一度も導入されていなければ、起動するものは何もない。

だから障害は新しいハードウェアで起き、管理者のノート PC では起きない。そのノート PC は何か月も前に、やったことを忘れた誰かがプロビジョニングしたものだ。起動コマンドは、前四半期に誰かが配線したドアベルだと考えてほしい。押すことは配線を敷くことと同じではない。

VPN 構成の三人の担当者

組織が管理するプロファイルはデバイス管理から来る。プロファイルはサーバーアドレス、認証の取り決め、組織が要求するポリシーを運び、VPN 管理者がそれらを用意する人である。スクリプトが一覧で見つけた表示名からその設定を再構築すべきではない。

ネイティブの個人用 VPN 構成は Apple の Network Extension API で作成され、組み込みの IPsec と IKEv2 が対象になる。これは保存手順とユーザー承認を伴うアプリケーションインターフェースであり、ベンダーが提供する任意のトンネル種別を黙って作るシェルコマンドではない。

サードパーティクライアントは第三のケースで、独自のインポート形式、独自の管理ツール、そして多くの場合独自の特権ヘルパーを持つ。そのセッションはそのベンダーのプロセスが所有する。似た名前のシステムサービスを見つけても、システムコマンドがトンネルを制御している証拠にはならず、そう仮定するとベンダーがクライアントを更新するまで動いているように見えるスクリプトができる。

ネイティブのプロビジョニングには保存と承認がある

Apple のモデルは読み込み、変更、保存だ。アプリケーションは起動後の最初の保存の前に既存の環境設定を読み込み、構成を変更してから保存する。保存は永続化できないときにエラーを報告し、その結果を無視すると三手順後にプロビジョニングの失敗が接続の失敗に変わる。

最初の保存では、ユーザーがアプリケーションを承認することも必要だ。これは意図的なセキュリティ境界であり、新しい Mac での初回実行は対話的になるが、それ以降の接続と切断は自動化できる。初回実行は人が立ち会う人間の作業として計画すること。二回目以降を自動化し、そのことをランブックに書いて、誰も不可能を約束しないようにすること。完全に無人な初回実行を約束する導入計画は、プラットフォームが提供しないものを約束している。

Apple はまた、API に頼る前に構成プロファイルでサーバーとの互換性を検証することを勧めている。この確認を先に行うと、「サーバーがこのクライアントを受け入れない」と「クライアントが設定を一度も保存していない」が分かれ、これは別チームの別チケットである。

再現可能な起動コマンドが仮定してよいこと

プロビジョニングの後なら、スクリプトは所有者のインターフェースを通じて 既存の接続を対象にできる。接続の安定した識別子と望む操作だけを渡し、それ以外は渡さない。推測した環境設定パスを読むべきではなく、メニューに表示される名前がシステム全体で一意だと仮定すべきでもない。

ネイティブ接続では、scutil --nc start のような名前付きセッション要求は制御操作である。サーバー設定を導入せず、資格情報を取り込まず、初回保存の承認も行わない。連鎖の最後の手順として扱い、連鎖そのものとしては決して扱わない。

秘密情報はコマンドライン引数と通常の診断出力から外に置くこと。導入が選んだ識別の仕組みこそ起動コマンドが頼るべきものであり、シェル履歴に貼られたパスワードはどのレビューでも指摘対象になる。

二つの受け入れ確認

一つ目の確認はプロビジョニングであり、新規導入の Mac を用意して構成が存在し、正しい管理者が所有し、完全に承認されていることを証明する。接続性を試す前にこれを行うのは、プロビジョニングされていないマシンでの接続テストがスクリプトについて何も証明しないからだ。

二つ目の確認はセッションだ。接続し、許可されたリソースに到達し、きれいに切断する。これで失敗にはそれぞれ担当者が付き、それが二つの仕事を分ける実務上の利点である。プロファイルの欠落は配布の問題、保存エラーは承認の問題、ログイン拒否は認証の問題、起動成功後のタイムアウトはセッション層の問題であり、どれも「スクリプトが壊れている」ではない。