Mac で .vpn ファイルを開くものは何か。まず書き出したベンダーを特定する
.vpn ファイルはベンダーの書き出しであり、万能な Mac プロファイルではない。クライアントを選ぶ前、または名前を変える前に、書き出したベンダーとゲートウェイのプロトコルを確認する。
.vpn で終わるファイル名に共通の形式定義はない。拡張子は通常、ベンダーが書き出したサイト設定を示し、それを読むパーサーはそのベンダーのエコシステムに属するもので、macOS のものではない。拡張子をクライアント選択の指標とみなすのが最初の誤りである。必要な事実は書き出したベンダーであり、答えは拡張子ではなくヘッダーにある。
何かをインストールする前に、ファイルを作成したアプリケーションはどれか、反対側にあるゲートウェイサービスはどれかという二つの問いに答える。答えがパーサーとプロトコルを決め、それらは通常ファイルを渡した人から入手できる。
拡張子は形式について何も語らない
ファイル拡張子は命名の慣習にすぎない。macOS は .vpn を汎用の VPN インポーターに対応付けておらず、この拡張子を持つすべてのファイルが同じフィールドを含むという標準もない。同じ拡張子はベンダーの書き出し、テキストの束、あるいはヘルプデスクが手作業で改名したものにも現れうる。
OpenVPN プロファイルは別の、判別可能な形式で、通常は .ovpn で終わり、client、remote、dev tun といったディレクティブを含む。Mac のネイティブ VPN 構成プロファイルは、運用者が特定のペイロード種別を持つ設定ファイルとして提供するもので、どのクライアントでも開ける任意の文書ではない。
Shrew Soft の歴史的な Access Manager の文書は、同製品が自社のサイト定義をどう書き出し、取り込むかを説明している。そのようなファイルには対応するパーサーと、製品に属するゲートウェイプロトコルが必要だ。パーサーを当てずっぽうに試すのではなく、どのアプリケーションが書いたのかを提供元に尋ねる。文書は形式の背景であり、現在の Mac に古いクライアントを入れる推奨ではない。
保護されたコピーでヘッダーのフィールドを読む
ファイルがテキストなら、すでに保持しているマシン上のコピーを調べる。file コマンドはコンテナを示し、最初の数行は通常 XML plist、JSON、または OpenVPN 風のディレクティブを明らかにする。特定のためにファイルを公開の変換サービスに上げたり、フォーラムに貼ったりしない。
file site-config.vpn
head -20 site-config.vpn
ヘッダーにはサーバー名、認証ドメイン、証明書ブロックが含まれることもある。そのヘッダーのスクリーンショットはファイル本体より安全ではない。この種の内容は普通の設定に見えても機微であり、秘密鍵を埋め込んだプロファイルは鍵そのものに等しい。調査はローカルかつ許可された範囲で行う。
ファイルがバイナリまたは暗号化されているなら、拡張子からの推測をやめる。書き出したベンダーに形式名と対応クライアントを尋ねるが、ヘックスダンプは未知のコンテナを対応済みの取り込みには変えない。
書き出したベンダーをパーサーとプロトコルに対応させる
書き出したベンダーとパーサーは一致していなければならない。ベンダーの書き出しは、そのクライアントだけが理解するサイト設定、認証オプション、ゲートウェイの挙動を符号化していることがある。汎用の OpenVPN クライアントは OpenVPN プロファイルを読めるが、他製品のサイト文書を理解する理由はない。
ゲートウェイのプロトコルが後半である。正しく解析できたファイルでも、特定のトンネルプロトコルと認証フローを期待するサービスを記述しているにすぎない。フィールドを読めば書き出したベンダーの意図は分かるが、現在のゲートウェイが何を受け付けるかは分からない。
クライアントを選ぶ前に、書き出したベンダー、ゲートウェイのプロトコル、対応する Mac アプリケーションという三つの値を書く。どれかが不明なら取り込みは推測であり、推測こそが私的な内容を含むファイルを無関係なアプリケーションに持ち込む経路である。
取り込みの成功は接続の成功ではない
フィールドを表示するインポーターは、それを解析できたことだけを示している。セッションの確立には正しいプロトコル、正しい資格情報、そして古い設定が行っていた証明書や登録の各手順も必要だ。手作業で作り直した接続は、元のクライアントが強制していた本人確認やデバイスポリシーを落とすことがある。
古いワークフローを無効にした状態で、新しいクライアントを私的なリソースに対して試す。接続は成立するが内部サービスに届かないのは移行の成功ではなく、背後にポリシーや経路の欠落を抱えたパーサーの成功である。
新しい経路が検証されるまで、元のファイルとその出所を保管する。クライアントが形式を拒否したなら、その拒否はベンダーについての有用な証拠であり、何かが接続するまでフィールドを削る理由ではない。
変換するのではなく対応プロファイルを求める
.vpn を .ovpn に改名してもプロトコルは変換されない。サーバーアドレスを無関係な形に写す、認識できない認証オプションを消す、証明書ブロックを取り除くといった作業は、取り込めても認証できないファイルを生む。
信頼できる道は、サービスの所有者から新しいプロファイルを、対応する Mac クライアントが文書化した形式で受け取ることだ。同時に、ゲートウェイが古い書き出しの対応しなかったプロトコルへ移っている可能性があるため、クライアントの要件も尋ねる。
サービスの所有者が現行のプロファイルを用意できないなら、移行は所有者の側で止まっており、Mac アプリケーションの選択の問題ではない。書き出したベンダー、拒否された形式、正確なエラーを記録し、依頼がファイル名ではなく証拠を運ぶようにする。