お使いのオペレーティングシステムは、どの VPN プロトコルをすでに話せますか？

別のクライアントをダウンロードする前に、オペレーティングシステムがすでに実装しているものを確認してください。その答えだけでインストーラーを完全に省けることがよくあります。Windows、macOS、ChromeOS はいずれも固定された短いトンネルプロトコルの一覧を備えており、そのどれかを話すゲートウェイには追加のドライバーもサービスも更新経路も要りません。これを決めるのはパンフレットのベンダー名ではありません。決めるのはプロトコルであり、エンドポイントがどう認証するかであり、どのアドレスを期待するかです。

製品名ではなくプロトコルを尋ねる

製品名は、回線の上を通るものについてほとんど何も語りません。同じラベルで売られる二つのゲートウェイがまったく異なるトンネルを要求することもあり、一方が内蔵クライアントを受け入れるのに他方は自社ポータル以外を拒否することもあります。同じ箱を説明する二人の管理者が食い違い、どちらも正しいこともあります。述べている層が違うからです。インストーラーが必要かどうかを決めるのは、その下のトンネルです。

ゲートウェイを運用する人に三つ尋ねてください。どのトンネルプロトコルか、どの認証方式か、クライアントが受け入れるべきアドレスと DNS サフィックスは何か。プロトコルは名前で尋ね、答えが製品名で返ってきたら、なぜプロトコルが必要なのかを説明してください。その三つの答えで、ソフトウェアをダウンロードする前にクライアントの疑問は片づきます。

製品名がこれほど多くのチケットに残るのには理由があります。利用者が見るのはポータルの URL であり、トンネルは動いている間は見えません。プロトコルを引き継ぎメモに書くのに一行かかり、後から来る全員の曖昧さが消えます。

内蔵の一覧が止まる場所

標準の一覧は短く、その縁は中身より重要です。IPsec 上の L2TPを事前共有鍵で話すプラットフォームは SSTP を話しません。その違いがクライアントを決めます。表はベンダー別ではなくトンネル別に並んでいるので、ゲートウェイが挙げたプロトコルを調べられます。

表はパンフレットではなくゲートウェイの要件と照らして読んでください。答えが事前共有鍵付きの L2TP over IPsec なら、最初の三つのプラットフォームは何も追加で入れることなく接続します。答えが OpenVPN なら、何かを入れる前に ChromeOS だけが対象です。どの内蔵の列にも現れないプロトコルは、インストーラーが来るという正直な合図です。

Linux は一般化に抵抗する列です。プロトコルの対応は、ディストリビューションが同梱を選ぶデーモンとプラグインの中にあり、最小のイメージでは追加するまでどれも話さないことがあり、同じデスクトップを持つ二つのディストリビューションでも異なります。

コマンドラインからプロファイルを組む

グラフィカルなパネルが書き込むものはすべて手の届く場所に保存され、それがあらかじめ用意されたプロファイルを自動化可能にします。Windows は VPN の項目を.pbkのファイルに、ユーザープロファイルの下とProgramDataの下に保持し、rasphoneはネットワーク一覧に出ない項目を一覧表示して編集できます。マシンがスクリプトで用意され、誰もウィザードをクリックしない場合に効いてきます。プロファイルがトレイに一度も現れずに存在できる理由も説明します。

rasdial
rasdial "VpnName" alice
rasdial "VpnName" /disconnect

手作業で.pbkのファイルを編集するのは可能で、しかも壊す最短の方法でもあるので、形式はツールに任せてください。macOS はサービスをシステム構成に保持し、networksetupはサービス名でそれらを扱います。いくつかのフラグはホスト名ではなくアドレスを求めるので、まずエンドポイントを解決し、クライアントが実際に使う値を保存してください。この区別は自動化で牙をむきます。アドレスで動くスクリプトが名前で失敗することがあり、そのエラーは拒否された引数ではなく壊れたゲートウェイに見えるからです。

networksetup -listallnetworkservices
networksetup -getinfo "ServiceName"
networksetup -setmanualwithdhcprouter "ServiceName" 198.51.100.20

サービスの名前はローカライズされ、利用者が編集できるので、Wi-Fiをハードコードしたスクリプトは別の言語に設定された最初のマシンで壊れます。一覧のコマンドから名前を読み取り、推測せずにそのまま渡してください。

独自クライアントなしの証明書

配備によってはクライアント証明書だけが必要で、他に独自のものは要りません。ドライバーを受け入れる前に試す価値のある中間のケースです。証明書をプラットフォームのストアに置くことは対応していますが、ベンダーのルートを放り込んでクライアントが見つけるだろうと期待するのとは別の行為です。前者は意図的な配置であり、後者はサポートチケットが付いた推測です。

人を捕まえるのは、クライアントがどのストアを読むかという点です。ユーザーストアの証明書は、マシンストア向けに構成されたクライアントには見えず、受け取るメッセージは証明書が欠けていると言うだけで、間違った場所にあるとは言いません。証明書が間違っていると結論づける前に、両方のストアを確認してください。動作する構成がどちらを使うかを書き留めてください。マシンを作り直すとき、そのメモは証明書より長く残ります。

Windows は二つのストアを明示的に分け、macOS はログインキーチェーンとシステムキーチェーンを分けます。名前は違いますが、失敗の形は同じです。クライアントが決して見ない有効な証明書です。

何がインストーラーを強制するか

ゲートウェイによっては、クライアントを私有の証明書ストア、ポスチャエージェント、あるいはオペレーティングシステムでは実行できないサインオン交換に縛ります。Check Point、Cisco、Fortinet のハードウェア上に築かれた配備はしばしばそこに着地し、そこでは内蔵クライアントは近道ではありません。第三者の代替品は接続できても方針に違反することがあり、これは利便性ではなくセキュリティの判断になります。方針が求めるものを導入し、インストーラーの版の横に理由を記録してください。

その記録こそ、人が飛ばす部分であり、次の管理者の一週間を節約する部分です。プロトコル、認証方式、アドレスファミリー、必要なサフィックス、そして追加を強いられたバイナリごとに一行の根拠。チャットのスレッドではなく、インストーラーのメモがある場所に置いてください。二行の文書が繰り返しの調査を防ぎます。