EC2 Windows：VPN クライアント、VPN サーバー、それとも AWS ゲートウェイ？
Windows EC2 インスタンスで VPN ソフトウェアを動かすことはできますが、クライアント、自己管理サーバー、AWS ゲートウェイは所有者の異なる別の役割です。
あるチームは Windows EC2 インスタンス上で動くアプリに VPN 接続を必要とし、互換性のあるクライアントソフトを見つけて導入したあと、なぜ VPC の残りがそれを使えないのかと問い合わせてきました。導入は成功していましたが、役割は決められていませんでした。ゲスト内で動くソフトは、他人のネットワークに参加するクライアント、他のクライアントを受け入れるサーバー、あるいは AWS が管理するどちらの VPN 製品でもない、のいずれかになり、役割ごとに残る作業は異なります。
症状はたいてい役割の取り違えです
よくある症状は、動いてはいるものの間違った問題を解いているトンネルです。VM 内のクライアントはその VM に外向きの経路を与えますが、ノートパソコン、オフィス、別のサブネットに内向きの経路は与えません。VM 内のサーバーは他者に内向きの経路を与えますが、その時点でリスナー、認証、転送はあなたの管理になります。
マネージドサービスはサービスの運用を AWS に移し、設計はあなたに残します。Site-to-Site VPN はカスタマーゲートウェイと AWS ゲートウェイを介してネットワークを接続し、Client VPN は遠隔端末にマネージドなエンドポイントを与えます。どちらの場合も、ルート、認可ルール、ID ソースはあなたの設定であり、どちらの製品も Windows ゲスト内に汎用クライアントを導入しません。
可能な形は四つあり、表は何が何につながるか、だれが運用負担を負うかでそれらを分けています。
| Role | What connects | Who owns the VPN software |
|---|---|---|
| Client in the Windows VM | This VM dials out into someone else's network | You, plus the software vendor |
| Server in the Windows VM | Inbound clients and sites attach to this VM | You, end to end |
| AWS Site-to-Site VPN | Two networks meet through a customer gateway and an AWS gateway | AWS operates the tunnels; you own the peer and route design |
| AWS Client VPN | User devices attach to an endpoint AWS operates | AWS operates it; you own the access rules |
製品名ではなく行を読んでください。同じ Windows インスタンスでも、中で動くソフトによって異なる二つの行に位置します。
VM 内のクライアント：VM がネットワークに参加する
外向きクライアントは、何かを導入する前に Windows のビルド、アーキテクチャ、ドライバーの要件を確認する必要があります。クライアントはインスタンスのルートと DNS を変更するため、そこで既に動いているサービス、とくに遠隔管理に使う経路に影響する可能性があります。クライアントが設定するアダプター名とインターフェイスメトリックを記録してください。新しいインターフェイスが既存のものより優先されることがあるからです。インスタンスを SSH や RDP ではなくセッションマネージャーで管理している場合は、クライアント接続後もその経路が機能することを確認してください。
有効にする前に、クライアントがどの通信を運ぶべきかを決めてください。フルトンネルは管理セッションを巻き込んであなたを締め出すことがあり、分割トンネルはインスタンスがプライベートネットワークに到達する一方で他の通信が別の出口を通ることを許します。二つ目の管理経路を用意して試験し、クライアントが導入するルートを記録して、後の変更を説明できるようにしてください。
VM 内のサーバー：他のクライアントがそこに参加する
自己管理サーバーでは、リスナー、証明書や鍵の素材、ユーザーデータベース、転送ルールはあなたのものです。サーバーが他のクライアントの通信を転送する場合、インスタンスはルーターになり、ゲストレベルの転送に加えて AWS レベルのルートとセキュリティグループの変更が必要です。
リスナーをゲストから、次に別のサブネットから確認し、そのうえでインスタンスが転送する先のホストを確認してください。正常なローカルサービスは転送経路について何も証明しないため、両方の結果を変更記録に残します。
マネージドゲートウェイが保つのはサービスであり、あなたのアクセス設計ではありません
AWS Site-to-Site VPN はカスタマーゲートウェイと AWS ゲートウェイのトンネルの役割を文書化していますが、その接続を購入してもすべてのリモートアクセス設計が置き換わるわけではありません。Client VPN はクライアントペルソナを伴うマネージドエンドポイントを文書化しますが、認可ルールと宛先ルートはあなたのものです。AWS はエンドポイントとその証明書を動かし続けますが、だれがどのアプリに到達できるかは、あなたが書き維持する認可ルールのままです。
五つの軸で製品を選ぶ：それぞれの役割、受け入れるプロトコル、想定する ID ソース、通信の転送方法、可用性の提供方法です。フォーラムのスレッドに引用された単一のスループット数値は無視してください。公開される容量はサービスとともに動きます。また、マネージドなトンネルの組が任意のゲストクライアントの挙動を変えると決めつけないでください。
製品より先に役割を選ぶ
方向を名指す一文を書いてください。この VM はネットワークに参加する、この VM はクライアントを受け入れる、または AWS ゲートウェイが定義されたネットワークをつなぐ、のいずれかです。
その一文が製品の候補リスト、ソフトの所有者、そしてあなたが調べることになる障害の種類を決めます。要件が遠隔ユーザーのアプリ到達なら、アプリの VM に導入したクライアントは誤った形です。要件が一つの VM からパートナーネットワークへの到達なら、マネージドなサイト間ゲートウェイは作業に対して過剰な仕組みです。どちらの答えも正当ですが、あなたが書いた一文に合うのは片方だけです。