OpenVPN か IKEv2 か：プロトコルを選ぶ前の四つの確認

OpenVPN と IKEv2 のどちらを選ぶかは、たいていプロトコルの問題として論じられますが、その枠組みは判断を無駄にします。決め手は、サーバーと端末が同じ完全なプロファイルに対応しているかどうか、そしてそのプロファイルがネットワーク間の移動に耐えるかどうかです。二つのスタックは互いに置き換えられません。OVPN ファイルは構文が違うだけの IKEv2 プロファイルではありません。順番に実行する四つの確認は、どんな機能表よりも速くその問いに答えます。

クライアントがなければ議論は終わる

Windows と macOS には IKEv2 クライアントが同梱されているため、そこでの IKEv2 プロファイルの展開に追加費用はかからず、OS がすでに公開しているプロビジョニングの選択肢を引き継ぎます。同じマシンで OpenVPN を使うなら、インストール・更新・サポートが必要なサードパーティ製クライアントが必要になり、そのクライアントはプロファイルが使うすべての選択肢を受け入れる必要があります。ほかを比較する前に、対象にすべきプラットフォームを数えてください。動くクライアントのないプラットフォームは比較対象にすらなりません。

Windows では、一つのコマンドが既存のプロファイルを一覧し、それぞれの種類を示します。それが表示する名前が、後の確認で使う名前です。

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

クライアントのインストールを促す表示こそが、それらのプラットフォームでの OpenVPN 列の実際の答えであり、それはプロトコルの制限ではなく展開作業です。どちらの構成でも、信頼の確認、身元の検証、保守がなくなるわけではありません。コミットする前に、プロファイルをどう配布するか、資格情報をどう更新するか、紛失した端末をどう除外するかを尋ねてください。単純なインストールでも、週末に誰もやりたくない復旧手順が隠れていることがあります。

モビリティは共同の設定であり、プロトコルの約束ではない

IKEv2 は両端が対応して有効にしたときに MOBIKE を使え、これによりクライアントはアドレスが変わってもトンネルを維持できます。RFC 4555 がこの拡張を定義しており、条件付きの言い回しが重要です。この機能を無視するサーバーは代わりに再ネゴシエーションします。ファイル転送では同じに見えても、通話ではまったく違って見えることがあります。

実際に気にしている切り替えを、観察できる何かを動かしたまま試してください。Windows では ping -t <internal-host> を流し続け、ほかの環境では素の ping を使い、Wi-Fi からモバイルに切り替えて途切れを観察します。MOBIKE の失敗は、静かなアドレス更新ではなく、クライアントログでの完全な再認証として現れます。測っているのはトンネルが変化に耐えるかどうかであり、プロトコルが対応を宣伝しているかどうかではありません。

OpenVPN クライアントは各プラットフォームの挙動とプロファイルのタイマーに従って再接続するため、同じテストでも中断の形が変わることがあります。プロトコルに付いたラベルではなく、利用者にとって重要な事象を比較してください。

資格情報はサービスに属し、スタックに属さない

証明書などのログインの仕組みは、接続を終端するサービスに属します。あるクライアントのパスワード要求は別のクライアントとの互換性を何も語らず、別のゲートウェイで動くプロファイルはこのゲートウェイについて何も語りません。二つのスタックを比較する間も、サーバーの身元に関する規則はそのままにしてください。障害を特定する前にプロトコルを切り替えると、たいてい二つ目の互換性のないプロファイルができあがります。

どちらのプロトコルも責める前に、クライアントが提示する資格情報を調べてください。期限切れや誤発行の証明書はどちらでも同じように失敗します。以下の出力は、秘密鍵を読まずに subject、issuer、有効期間を示します。

openssl x509 -in client.crt -noout -subject -issuer -dates

社内接続では、会社が公開している方法を使ってください。比較を実験として扱うのはやめてください。自分で両者を比較するなら、まず両方の選択肢が同じゲートウェイで終わるかを確認してください。その一点が、結果のどこまでがプロトコルの話かを決めます。資格情報を名指しする拒否は資格情報の問題であり、プロトコルをいくら切り替えても直りません。

トンネルが実際に何をルーティングするかを確認する

接続後、必要なルートが存在し、名前が解決されることを確認してください。社内リソース向けのプロファイルは、通常のブラウジングを意図的にローカル経路に残すことがあり、それは障害ではなくポリシーの判断です。重要なのは、チームが使う宛先にトンネル経由で到達できるかどうかです。

Windows では二つのコマンドがルートと名前の照会をカバーします。Linux での相当物は ip route show default と resolvectl query <internal-host> です。

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

トンネルは上がっているのに有用なものを何もルーティングしないのは、プロファイルをサービス間でコピーしたときによくある結果で、一般的な接続テストではインターフェースが上がっているため表示されません。利用者が最初に開くリソースを試してください。どの経路からでも届く公開アドレスではありません。名前が公開アドレスに解決されるのにルートがトンネル内を指すなら、DNS の答えとルートは別々の判断に属しており、両方の修正が必要です。

確認のあとに保守を見積もる

抽象的にどちらかのプロトコルがより保守しやすいということはありません。保守は、誰がゲートウェイを運用するか、プロファイルがどう端末に届くか、紛失した端末がどれだけ早くアクセスを失うかに依存します。単純な端点クライアントが運用の難しいサーバーの前に置かれることも、その逆もあります。作った人が去った後、チームがどちらを動かし続けられるかを尋ねてください。

作業をカバーする対応済みの接続を選び、機能一覧ではなく実際に必要なアクセスに対して試してください。各選択肢がどのゲートウェイで終わるかを記録してください。二つの異なるゲートウェイは、比較をプロトコルと同じくらいルートの話にします。実際に持ち歩く端末で四つの確認を繰り返し、それを通過するプロファイルを残してください。