SSL VPNとサイト間VPNはなぜ対立概念ではないのか
SSL VPNとサイト間VPNは別の軸を表します。誰がネットワークに加わるか、トンネルをどう築くかという違いです。両者を並べて呼ぶのはカテゴリー錯誤です。
同じVPNを二人の管理者に説明させると、一方は「SSL VPN」と答え、もう一方は「サイト間」と言うことがあります。まるでメニューの競合する選択肢であるかのように。しかし両者は別の問いへの答えであり、代替案として扱うと解決できない比較を生みます。一方のラベルはどの端点を結ぶかを示し、もう一方はその間のトラフィックを何が運ぶかを示します。軸を分けておけば、議論の大半は消えます。
二つのラベル、二つの別の問い
トポロジーは誰が何に加わるかに答えます。リモートアクセスの設計は個々のユーザーやデバイスをゲートウェイに接続し、通常はユーザーごとのIDとアドレスプールを持ちます。サイト間の設計は二つのネットワークをゲートウェイ経由で結ぶので、重要なIDはピアゲートウェイであり、キーボードの前の人物ではありません。これらはアドレス計画から午前2時に誰がアクセスを取り消せるかに至るまで、別の運用上の問題です。
メカニズムはトンネルをどう築き、どう認証するかに答えます。IKEv2を用いたIPsec、内部でIPを運ぶTLSベースの製品、ブラウザ向けのアプリケーションポータルはメカニズムの選択肢であり、それぞれに独自のネゴシエーション、暗号スイート、障害モードがあります。どれもトポロジーを含意せず、トポロジーがメカニズムを選ぶこともありません。
二つの軸を一つの表に置けば混乱は見えてきます。格子のどのセルも埋められるからです。表にできないのは、ベンダーがどの組み合わせを出荷したかを告げることです。製品名は両方の軸を一つのマーケティング表現に押し込めてしまうからです。
カテゴリー錯誤はどこから来るのか
ベンダーは長年「SSL VPN」を「IPsec VPN」の反対として売ってきたため、メカニズムの比較がトポロジーの選択に見えました。この表現はそれ自体の前提でも古びています。現在の設計はサポートされたTLSバージョンを使い、SSLという名前は主に製品カテゴリーとして残っているからです。
| Axis | Question it settles | What it cannot tell you |
|---|---|---|
| Topology | Whether users join a gateway or two networks join each other | Which protocol carries the traffic, or how peers prove identity |
| Mechanism | Which protocol suite builds the tunnel and negotiates keys | Whether the endpoints are people, devices or routers |
| Access surface | Whether the client sees a routed network or a set of published applications | Which topology or mechanism is underneath the portal |
| Authentication | What proof each side presents, and to whom | Whether the traffic is later authorized per resource |
同じ圧縮から二つの神話が生まれます。第一は、IPsecといえばサイト間だというもの。IKEv2はクライアントとゲートウェイの関係のためにも設計されたので、一台のノートPCがIPsecで参加できます。第二は、TLSベースの製品はリモートアクセス専用だというもの。OpenVPNは二つのサイト間でトラフィックを運ぶためによく使われ、そのTLSの利用はブラウザセッションではなく制御と認証の交換に集中しています。
どんな説明にも役立つテストがあります。一語を入れ替えて端点とプロトコルの両方が変わるなら、その文は軸を混ぜています。「SSL VPN対サイト間」はこのテストに失敗します。最初の語はメカニズムの一族を、二番目はトポロジーを指すからです。
比較できるように展開を説明する
四つの欄を書いて埋めます。端点、メカニズム、認証、アクセス面です。支社リンクは、二つの名前付きプレフィックス間の証明書認証付きIKEv2ゲートウェイ対で、ユーザーレベルのポータルがないものとして読めます。リモートアクセスサービスは、ユーザーごとにアドレスを割り当て、ログイン時に第二要素を要求し、内部DNSゾーンだけを公開するTLSベースのクライアントとして読めます。
これらの文は、製品名にはない比較可能性を持ちます。二つのリモートアクセス設計は同じユーザーワークフローと同じ失効経路に対して測れ、二つのサイト間設計は同じプレフィックス一覧、トラフィックポリシー、障害要件に対して測れます。ラベルは比較を整理するのであって、置き換えるのではありません。
用語には公表された拠り所もあります。IETFのVPN用語文書は、リモートアクセスやサイト間を含む複数のサービスモデルを、それらを築くメカニズムから切り離しています。まさに繰り返し失われる区別です。
製品名ではなく、交渉されたプロトコルを読む
箱のラベルは、稼働中のトンネルが何に合意したかを確定しません。TLS側でピアに直接尋ね、パンフレットのバージョンではなくハンドシェイクが生んだプロトコルバージョンと暗号を読みます。
openssl s_client -connect vpn.example.net:443 -tls1_3 -briefIPsecゲートウェイなら、同等の観察は実装自身の状態出力から得られます。使用中のIKEとESPの提案を報告します。いずれにせよ要点は同じです。メカニズムの軸は生きたセッションから読む必要があります。クライアントとゲートウェイはどちらの管理者の予想よりも古いものへ下方交渉できるからです。
ipsec statusall | grep -E "IKE|ESP"その後も、どのラベルも答えない問いが残ります。どのプロトコルバージョンがまだ受け入れられるか、ゲートウェイのIDをどう検証するか、どのアルゴリズム群が許されるか、誰が特定のユーザーを特定のリソースに許可するか、デバイスを失ったとき何がアクセスを取り消すか。トポロジー図とメカニズム名はその一覧の始まりであり、代替ではありません。
二つのラベルは残しつつ、あるがままに使ってください。どの端点を結び、トンネルをどう築くかを短く言う手段です。どちらか一方を他方の排除に使った瞬間、その説明は何も説明しなくなります。