【Catoクラウド】vSocketで複数VPC/VNetを接続したい

本記事は 夏休みクラウド自由研究 8/8付の記事です

AWS/Azure等のパブリッククラウドをCatoクラウドへ接続する方法には、以下の3つがありますが、このうち最も手軽で多く利用されている方法がvSocketです。

  接続方法 対象環境 主な利用シーン
1 vSocket AWS/Azure/VMware ESXi 通常の場合
2 Cloud Interconnect
(旧名称:Cross Connect)
AWS/Azure/GCP/Oracle Cloud 高スループット・低遅延な通信を必要とする場合
3 IPSec すべての環境 1および2が利用できない・用途にマッチしない場合

vSocketは、VPC/VNET内に仮想マシンを構築しSocketとして動作させるもので、物理Socketと同等の機能が利用できます。AWS/Azure環境を物理的な拠点と同等にCatoクラウドへ接続でき、とても便利です。

実際のご利用環境では、複数のAWS VPC や Azure VNetが存在することがほとんどかと思います。このような場合のCatoクラウドへの接続構成について、よくご質問をいただくため、本記事にて構成例をご紹介します。

AWS 複数VPCを接続する際の構成

AWSで複数VPCを接続する方法としては、以下2つの構成パターンがあります。

パターン1 VPCごとにvSocketを構築する

各VPCにvSocketを作成し、それぞれCatoクラウドに接続する構成です。

メリット

各VPCが完全に独立してCatoクラウドへ接続します。Catoクラウド上でも、それぞれのVPCが独立したSiteとして表示されますので、通信量・通信内容の確認や、管理がSiteごと(=VPCごと)に可能です。

デメリット

接続するVPCごとに、Catoクラウドライセンスが必要です。図の例ですと、3つのVPCに対し合計3つのSiteライセンス契約が必要です。また、VPCごとにvSocketの構築が必要です。

パターン2 複数VPCをTransit Gatewayで接続し、1つのVPCからCatoへ接続する

Transit Gatewayを構築してVPCを相互接続し、1つのVPCのみCatoクラウドへ接続する構成です。

なお、VPC同士をVPC Peeringで接続する構成は利用できません。AWSのVPC Peeringは、接続先のVPCより先のNWには通信できないという制約(2hop制限)があるためです。

メリット

Catoクラウドのライセンス契約は1Site分のみ必要となります。またvSocketの構築も1セットのみです。

デメリット

Catoクラウドへのすべての通信が、Transit Gateway および vSocketのVPCを経由することとなります。各VPCのセキュリティ要件上問題ないか、ご検討が必要な場合があるかもしれません。

また、この構成では、Catoクラウド上ではすべてのVPCがあわせて1つのSiteとして扱われますので、VPCごとの通信量を確認するなどができません。Siteご契約帯域も、すべてのVPCを合算した通信量にてご契約頂く必要がございます。

もしvSocketや、そのVPC内に障害が発生した場合、すべてのVPCでCatoクラウドへの通信が不可となります。

パターン2の構成の詳細

Transit Gatewayを使用する場合、各SubnetとTransit Gatewayのルートテーブルで、もれなくルートの設定が必要です。設定のポイントを上記の図にまとめましたので、ご参照ください。

構築後、通信が通らない場合、よくある原因に以下の2つがあります。うまく行かない場合は見直してみてください。

  1. 上記図内の①~③のルートテーブルに、ルートが足りていない。※特にCatoモバイルユーザのルートを設定し忘れがちです
  2. 通信先のAWSリソース(EC2等)で、セキュリティグループやOSのFirewallが設定されていて、CatoのSiteやモバイルユーザのIPアドレスレンジからの通信が許可されていない。

Transit Gatewayを使用した構成については、Cato Networksのナレッジベースにも解説がありますので、合わせてご参照ください。

How to Implement Cato vSocket in AWS Multiple VPCs Environment | Cato Knowledge Base

Azure 複数VNetを接続する際の構成

Azureで複数のVNetをCatoへ接続したい場合、同様に2つのパターンがあります。

パターン1 VNetごとにvSocketを構築する

AWSの例と同様です。VNetごとに個別に管理できますが、SiteライセンスがVNetの数だけ必要です。

パターン2 複数VNetをVNet Peeringで接続し、1つのVNetからCatoへ接続する

Azureの場合は、VNet PeeringでVNet間を接続します。

メリット・デメリットはAWSと同様です。

パターン2の詳細

複数VNetを接続する場合、Peeringを作成の上で、各Subnetのルートテーブルでルートの設定が必要です。設定のポイントを上記の図にまとめましたので、ご参照ください。

構築後、通信が通らない場合、よくある原因はAWSと同様です。サーバが所属するルートテーブルや、セキュリティグループを確認します。また、Peeringのオプション「Allow forwarded traffic」が有効になっているかも合わせて確認します。

Peeringを使用した構成については、Cato Networksのナレッジベースにも解説がありますので、合わせてご参照ください。

How to Use a vSocket in Azure Multiple VNets Environment | Cato Knowledge Base

図の中ではvSocketが3つのNICを持っていますが、2024年11月時点でAzureのvSocketは2NICタイプに変更となっています。ご了承ください。
NIC数の変更については、以下の記事をご参照ください。
【Catoクラウド】AzureのvSocketが2ポート対応した件
AzureのvSocketが2NICのマシンタイプをサポートしたので、作成方法と移行方法を紹介してます。

まとめ

AWS、Azureともに、複数環境を個別にCatoクラウドへ接続する方法と、まとめて接続する方法があります。メリット・デメリットを確認の上、接続方法をご選択ください。

もちろん、環境分離したいVPC/VNetは個別に接続し、その他はまとめて接続するといった構成も可能です。

SCSKでは、Catoクラウドとパブリッククラウドの両方に精通したエンジニアが多数在籍しており、最適な構成のご提案が可能です。お悩みの点などありましたら、ぜひご相談ください。

タイトルとURLをコピーしました