一つの VPN サービスで Windows、Mac、Linux のデスクトップをまかなえるか

あるチームの三台のノート PC、三つの異なる VPN メニュー、そして Mac 以外ではどこでも接続できると書かれたチケット。メニューが違っても、そのクライアント群の背後にある設計は同一であり得る。揃えるべきものは、多くの展開が想定するより狭い。ゲートウェイの同一性、資格情報の種類、ルートの集合、リゾルバの方針、この四つだ。誰かがプロファイルを書き出す前にこの四つを書き留めておけば、プラットフォーム側の作業は調査ではなくチェックリストになる。

クライアントファイルではなく、アクセス契約から始める

アクセス契約とは、ベンダーのコンソールを開かなくてもレビュー担当者が確認できる五行のことだ。そこには 到達可能でなければならないプライベートプレフィックス、解決できなければならない内部名、それに答えるリゾルバ、ローカル経路に残してよい通信、そしてクライアントが期待すべきゲートウェイ証明書が記される。展開におけるその他すべては、これらの行をファイル形式へ翻訳したものにすぎない。

オフィスの例で形は具体になる。アプリケーションサーバーは 10.60.0.0/16 に、プライベート名は corp.example の配下に、内部リゾルバは 10.61.0.53 にあり、通常のブラウジングは端末がもともと使っている経路のままだ。この最後の項目はクライアントの既定値ではなく方針の決定であり、誰も言わなければ多くのクライアントはすべてをトンネルに流す。契約は日付と担当者とともに記録しておく。後になってトンネルが変わったのか方針が変わったのかを教えてくれるのは、その記録だけだからだ。

弁護できるプロトコルを一つ、認証の組み合わせを一つ選ぶ

三つのプラットフォームすべてが追加ソフトなしで動く必要がある場合、証明書ベースのゲートウェイ認証を伴う IKEv2 と、利用者側の EAP が定番の選択だ。Windows、macOS、NetworkManager はいずれも IKEv2 クライアントを同梱している。厄介なのは、IKEv2 に対応しているという言葉がラベルを述べているだけで、機能の集合を述べていないことだ。EAP 方式、ハードウェアに支えられた鍵、証明書からアカウントへの対応付け、自動再接続は、プラットフォームごとに実装されている。三つのうち二つで動く組み合わせは珍しくないので、試験するまではそう仮定しておくべきだ。

展開ガイドを書く前に、事後ではなく、すべての対象プラットフォームでその組み合わせを試験する。EAP-MSCHAPv2 と EAP-TLS の両方を提供するゲートウェイなら、フォールバックの余地がある。ただしそのフォールバックは、障害の最中に発見されるのではなく、サポート対象として文書化されていなければならない。サポートされる経路が二本あれば安上がりの保険になる。文書化されていない三本目は、将来のチケットだ。

単一の組み合わせで三つのクライアントすべてを覆えないとき、正直な選択肢は、クライアントを増やす、ゲートウェイのプロファイルを増やす、サポート対象プラットフォームの一覧を狭める、のいずれかだ。最も騒ぐプラットフォームで証明書検証を切ることは、そのどれでもない。その変更は互換性の隙間を傍受のリスクに変えてしまい、展開の後続のどの手順でも修復できない。

契約からプラットフォームごとに一つの成果物を作る

Windows は VPNv2 プロファイルを使う。MDM で配信するか、Add-VpnConnection とその XML ペイロードでローカルに作成する。引っかかるのはスコープと信頼だ。デバイススコープのプロファイルとユーザースコープのプロファイルは別のストアにインストールされるため、クライアントが必要とする証明書は、選んだスコープに合うストアに置かれていなければならない。この対応を誤ると、きれいにインポートできてから最初の接続で失敗するプロファイルができる。

macOS は管理対象 VPN ペイロードを含む構成プロファイルを使う。署名して MDM で配信するか、パイロットでは手動でインストールする。ID と CA チェーンは別々のペイロードとして運ばれる。だからこそ、何の文句もなくインストールできて、接続時に失敗するプロファイルが生まれる。インストール結果だけでなく、ペイロードの一覧を確認すること。

Linux は NetworkManager の背後のバックエンドに依存し、strongSwan と NetworkManager プラグインは別々のパッケージだ。接続プロパティは汎用の VPN キーではなくプラグイン固有なので、別のプラグインからコピーしたキーはエラーなく保存できて、有効化で失敗することがよくある。実際に動く場所にプラグインがあることを確かめるため、きれいなイメージ上で接続を作る。

三つの成果物は形式が異なるが、どれも同じ五行の契約を符号化している。成果物が完成したかどうかの判定はこれだ。すべての行がどこかに表されており、途中で余計なものが発明されていないこと。

きれいなアカウントでルート、リゾルバ、再接続を検証する

接続できたことは受け入れ試験ではない。Windows では Get-VpnConnection がプロファイルを表示し、route print がプライベートプレフィックスがトンネルインターフェースに載ったかを示す。macOS では scutil --nc list が有効なサービスを確認し、scutil --dns がシステムが実際に使うリゾルバの順序を示す。

Linux では nmcli connection show --active で接続が上がっていることを確かめ、resolvectl status でリンクごとの DNS を見る。接続ファイルにはあるのにリンクごとの出力に無いリゾルバは、分割 DNS が適用されていないことを意味する。これは名前が解決することと、名前がトンネル経由で解決することの違いであり、次の一手をどのサポートチームが持つかが変わる。リンクごとの出力は、接続が上がった後だけでなく、前と後の両方で比較すること。

キャッシュされた資格情報も管理者が入れた証明書も無い、新しいアカウントで一連の確認をすべて実行する。そのうえでサスペンドとレジュームの後に繰り返し、資格情報の再入力を強制した後にもう一度行う。この二つの遷移が、初回接続では決して見えない再接続の失敗の大半を浮かび上がらせる。

パッケージに版を付け、ロールバック経路を残す

各プラットフォームのパッケージに、それが実装する契約リビジョンのタグを付け、どのクライアント版とゲートウェイ版で受け入れたかを記す。クライアント更新後に挙動が変わったとき、タグは推測すべきファイルではなく、再試験すべき契約を指す。

各プラットフォームの前のパッケージを取得可能なまま残し、その隣に削除コマンドを書いておく。VPN プロファイルのアンインストールは、Windows、macOS、Linux のいずれでもインストールの鏡像ではない。そしてその違いは最悪のタイミングで現れる。予備の端末で一度削除を演習しておけば、アーカイブは希望ではなく計画になる。