AWS Client VPN か Site-to-Site か: 接続を開くのは誰かで見分ける

これを決めるのは四つの確認であり、そのどれもがプロトコルの名前ではありません。誰が接続を開くのか、AWS が何を認証するのか、接続がどのようにネットワークへ取り付くのか、そしてどんなルーティングとポリシーが付いてくるのか。これらに順番に答えれば、製品の選択はたいてい自然に決まります。設計を買ってから答えると、問題の半分を取り違えたトンネルを擁護することになります。四つのうちのどれも暗号の選択を求めていないのであって、プロトコルから始まる設計が要件を書いていない証拠になりがちなのはそのためです。

各確認は、カテゴリではなく、実際に使う予定のエンドポイント、クライアント、アドレスファミリーに対して行ってください。マネージド VPN 製品は、似て見える OpenVPN や IPsec の構成要素とは異なります。

第一に、誰が接続を開くのか

アクセスを必要とするものがノート PC、電話、あるいは管理者一人のワークステーションなら、接続は遠隔の端末から始まり、設計はリモートクライアントアクセスです。アクセスを必要とするものが一つのルーターの背後にある機械でいっぱいの支社なら、接続はそのルーターから始まり、設計はゲートウェイ間接続です。ほとんどの場合はこの確認で決まり、ベンダーの説明資料がすでに暗号の話で会話を枠づけているときに飛ばされがちなのもこの確認です。

開始する側の構成要素を名指しできないなら、ここで止めてください。一つのトンネルで両方を賄おうとする設計は、たいていゲートウェイのふりをしたクライアントセッションに行き着きます。

第二に、AWS が何を認証するのか

Client VPN では、AWS は設定されたクライアントまたは利用者の ID を認証します。証明書、ディレクトリ、フェデレーション ID のいずれかで、構成によります。Site-to-Site VPN では、AWS はゲートウェイのピア ID を認証します。この違いは見た目だけのものではありません。一方のモデルは利用者を追加し資格情報を取り消すことで規模を広げ、もう一方は一つのゲートウェイの背後にあるすべてを信頼することで規模を広げます。

ゲートウェイの認証は、その背後の従業員やアプリケーションのすべてを認証するわけではないので、トンネル自体が信頼されていても、アプリケーション ID とリソース単位のアクセスは残しておいてください。ルーターが有効なピア ID を持つ支社を、その建物のすべての机が許可されていると自動的に読み替えるべきではありません。

第三に、接続がどう取り付くのか

Client VPN は VPC サブネットの関連付け、または対応する直接の Transit Gateway アタッチメントを通じて取り付きます。Site-to-Site VPN は AWS VPN のターゲット、多くの場合仮想プライベートゲートウェイまたは Transit Gateway に取り付きます。Client VPN のアーキテクチャガイドは Transit Gateway の選択肢を記述しており、その存在はノート PC のセッションを支社のゲートウェイに変えるものではなく、上述のクライアント認証と認可を取り除くものでもありません。

そのまわりでルートを設計する前に、アカウントとリージョンが実際にどのアタッチメントに対応しているかを確認し、次にそのアタッチメントを誰が持っているかを確認してください。ドキュメントに存在しても、設定できないネットワーク上にある選択肢は選択肢ではありません。

第四に、どんなルーティングとポリシーが付いてくるのか

Client VPN は、許可した宛先ネットワークに対するクライアント接続の管理と認可ルールをもたらします。接続した利用者には、意図したエンドポイントへのルート、それを許可する認可ルール、そしてリソース自体が要求するアクセスが依然として必要です。Site-to-Site VPN は顧客ゲートウェイが表すネットワーク間を、設計に応じて対応する静的ルートまたは BGP でルーティングするので、支社ルーターの背後の個々の機械がそれぞれクライアントログインを必要とすることはありません。

どちらの方向にも、カテゴリから対応していない挙動を推測しないでください。リモートアクセス VPN が戻りトラフィックを運べない、あるいはゲートウェイ構成を支えられないというのは普遍的な話ではなく、IPsec が NAT によって自動的に遮断されるわけでもありません。AWS は NAT トラバーサルと顧客ゲートウェイの要件を記述しており、実際の制約は対応するゲートウェイ構成です。クライアント向けに開始される接続を要求したり、一つのセッションの背後へ LAN を転送したりする前に、エンドポイントの制限を確認してください。同じ注意はアドレスファミリーにも当てはまります。IPv4 で動くエンドポイントは IPv6 の経路を意味しないので、クライアントやゲートウェイが実際に折衝するファミリーを確認してください。

Site-to-Site VPN は接続ごとに二つのトンネルを与えますが、その冗長性は前提にできる機能ではなく設計の作業です。顧客ゲートウェイの運用、ルートのフェイルオーバー、テストの網羅はすべて計画する必要があります。ノート PC のセッションを抽象的な VPN サーバーと比べても、どちらについても何も証明できません。

二つの設計が交わるところ

両サービスは排他的ではなく、よくある本番の形は両方を使います。従業員は Client VPN、支社網は Site-to-Site、そして会話すべき宛先の間に明示的なルートとアクセスポリシーを置きます。表は四つの確認の要約であって、実行の代わりではありません。

どちらの製品も置き換えないものがあります。暗号化の要件が VPN のエンドポイントより先まで及ぶアプリケーションへの TLS です。準拠の範囲がアプリケーションで終わるなら、トンネルは伝送路であり、証明書が依然として統制です。

設計レビューの前に四つの答えを一行ずつ書き出してください。二つが食い違うとき、たとえば利用者認証のクライアント設計と支社規模のルーティング要件が並ぶとき、その食い違いこそが所見であり、切り替えの最中に気づくより今のほうが安く済みます。