こんにちは!
佐藤です。
本記事では、Microsoft Azure環境をCatoクラウドへ接続するための、 vSocket構築手順を解説します。
Azureの操作に慣れていない方でもスムーズに構築が進められるよう、図を多めに用いて手順をまとめましたので、
ぜひご活用いただければ幸いです。
はじめに
vSocket(virtual Socket)とは、組織のクラウド環境をCatoクラウドに接続するための仮想アプライアンスです。
本社や工場などの拠点をCatoへ接続する際には、通常「Socket」と呼ばれる物理アプライアンスを設置しますが、
クラウド環境ではその代わりとしてvSocketを利用します。
現在vSocketは以下の主要なクラウドサービスで利用可能です。
- AWS (Amazon Web Services)
- Google Cloud
- Microsoft Azure
- VMware ESXi
上記の中でも、本記事では Azure vSocketの構築手順を紹介していきます。
内容については今後変更の可能性がありますこと、ご了承ください。
図例については、一例としてご参考にいただけますと幸いです。
Cato社が提供する最新版の構築手順は下記となりますので、本記事と併せてご参照ください。
Deploying-Azure-vSockets-from-the-Marketplace
※本書と上記ナレッジベースの内容に差異がある場合、ナレッジベースの内容を正とします。
構成イメージ
本記事では、
vSocketを1台のみ構築する「シングル構成」でのデプロイを想定して構築手順を解説します。
手順内で使用している画像は、筆者が実際に検証を行った際の画面キャプチャとなります。
設定内容によって表示が一部異なる場合がありますので、あくまで参考情報としてご参照ください。
構成イメージは以下のようになります。各リソースの役割などは後ほど説明していきます。
その他の構成
HA構成
Azure vSocketをHA構成とする場合、基本的にはシングル構成と同様の手順ですが、各種パラメーターの指定に注意が必要です。
再掲にはなりますが、以下KnowledgeBaseの「Adding a Secondary vSocket for High Availability」の箇所をご参照ください。
また、以下のトラブルシューティングページもご活用ください。
複数VNetとの接続
複数VNetとvSocketを接続したいといった場合には、VNet Peeringによって実現可能です。
詳細は、以下の記事をご参照ください。
事前準備
既に作成済みのセキュリティグループなどを使用する場合は、
前提条件として、以下の項目をクリアしていることをご確認ください。
- Azure vSocket は、パブリック DNS サーバにアクセスできる必要があります。
VNet(仮想ネットワーク) がプライベート DNS サーバのみを使用するように構成されていないことを確認してください。
確認方法としては、構築に用いるVNetの画面で「Azure提供のDNSサービス」が指定されていれば問題ありません。

- vSocket インスタンスは、次のリソースへのアウトバウンド接続が必要です。
- WANインターフェイスからインターネットへの下記ポートの通信許可
- UDP 53
- UDP 443
- TCP 443
- LANインターフェイスからVNet内への DNS および HTTP、Azure Resource Manager への HTTPS
- MGMTインターフェイスから、インターネットへのUDP 53、management.azure.com へのTCP 443
- WANインターフェイスからインターネットへの下記ポートの通信許可
※セキュリティグループの設定例は後の手順「2-5オプションの指定」に記載しています。
Azure vSocketの構築手順
vSocketの構築手順を説明していきます。
以下の流れで構築を進めます。
2. Azure 設定
2-1. サブスクリプションとリージョンの指定
2-2. vSocketタイプの指定
2-3. ネットワーク指定
2-4. 各種パラメータの指定
2-5. オプションの指定
2-6. タグの指定
2-7. vSocketのデプロイ
3.疎通確認
1. Cato Site設定
Cato側でのSite(拠点)作成を行います。
1. CMAのナビゲーション・メニューから、「Network」 > 「Sites」をクリックします。
2. 「New」をクリックします。
3. Add Siteウィンドウから、サイトの設定を行い、「Apply」をクリックしてください。
• Site Name : ユニークなサイト名
• Site Type : 適切なものを選択
• Connection Type : vSocket Azureを選択
• Country : 使用する国を選択
• State : 使用する地域を選択(日本の場合選択不要)
• Time Zone : 使用するタイムゾーンを選択
• License Type/License :使用するライセンス
• Downstream : ライセンスの帯域幅に従って設定
• Upstream : ライセンスの帯域幅に従って設定
• Native Range : 使用するLAN側のIPレンジを設定
• Local IP : 使用するLAN側のLocal IPを設定
5. 「Site Configuration」>「Socket」をクリックし、シリアル番号(S/N)をコピーして控えてください。
※ このシリアル番号は、この後vSocketを構築する際に使用します
2. Azure 設定
Azure側での設定を行います。
2-1. サブスクリプションとリージョンの設定
1. Azure Marketplace から “Cato” を検索し、任意の「サブスクリプション」と「プラン」の”Cato Socket Template” を選択します。
2.「作成」 をクリックします。
3. vSocketを作成するサブスクリプション、リソースグループを選択します。
4. vSocketを作成するリージョンを選択します。
2-2. vSocketタイプの指定
作成しようとしているvSocketのタイプを選択します。
- Primary : シングル構成の場合に選択。またはHA構成のPrimaryを構築する際に選択
- Secondary : HA構成で、Primary側の構築はすでに完了していて、Secondaryを構築する場合に選択
2-3. ネットワーク設定
1. ネットワークインターフェースの数を指定します。
インタフェースは、WAN、LAN、MGMTの3つが使用されます。
シングル構成の場合はWAN、LANインタフェースのみの2NIC構成も可能です。
- WANインタフェース:Catoクラウドへの接続
- LANインタフェース:Azure内部リソースへのトラフィックを処理
- MGMTインタフェース:HA構成時vSocketとAzureAPI間の連携を管理
2NICと3NICの違いや、3NIC→2NICへ移行する際のポイントについて、以下のブログにて詳細が記載されております。
2. vSocketを作成するVNetを指定します。
3. 各インターフェイスのサブネットを指定します。
VNet・サブネットは既存のものを選択することも、新規に作成することも可能です。
新規作成の場合は、(New)とついているリソースが自動で作成されます。
なお、「Edit virtual network」または「Edit subnet」から新規作成されるリソースの詳細設定が可能です。
リソース名など、管理上分かりやすいように変更することをお勧めします。
4. 「Edit virtual network」から、VNetの任意の名前とアドレスレンジを設定します。
🖋 マークからは、サブネットの設定を行うことが可能です。
5. サブネットについても「名前」と「サブネットレンジ」の設定を入力し、「保存」をクリック
既存のセキュリティグループやルートテーブルを使用したい場合は、指定のリソースを選択してください。
2-4. 各種パラメータの指定
Socketのパラメータを指定します。
※ Cato管理画面のシリアルと一致しない場合、vSocketがデプロイ後に認識されません。
• vSocket LAN IP : 手順1で設定したLocal IPを入力します。
※Cato管理画面のLocal IPと一致しないと、トラフィックがルーティングされません。
• VM Size : vSocketのVMサイズを指定します。
・D8ls_v5:2NIC、3NIC対応
・D2s_v5:2NICのみ対応
• vSocket interface IP allocation type / WAN・MGMT interface IP allocation:
WAN・MGMTのプライベートIPアドレスを、自動で割り振るか(Dynamic)、手動で指定するか(Static)の選択です。
Staticを選択すると、IPアドレスの入力欄が表示されます。お好みの方で設定ください。
2-5. オプションの指定
その他のオプション設定です。
それぞれの概要を説明します。
Public IP Addresses
パブリックIPの新規作成の有無を選択します。
Microsoftより
2026年3月31日以降、デフォルトのインターネットへのアウトバウンドアクセス機能が含まれなくなると発表がありました。
それに伴い、これまでは、パブリックIPを「None」に設定することが可能でしたが、
新たにデプロイされるvSockeはパブリックIPが必須の設定となります。
なお、Noneを選択して作成した既存のvSocketについては、Microsoftによるサポートが継続されるため変更は不要ですが、
Cato社としてもパブリックIPやNATゲートウェイなどを明示的に設定することを推奨しています。
参考元のCato社公式KBは以下になります。
Security Groups
セキュリティグループを新規作成するか、既存のものを使うかの選択です。
こちらもこれまでは、Noneの選択が可能でしたが、
上記の通りデフォルトでパブリックIPが設定されるため、必須設定になると予想しています。
具体的な設定内容ですが、Cato社推奨は以下の通りとなっています。
- WANセキュリティルール:すべてのインバウンドトラフィックを拒否し、すべてのアウトバウンドトラフィックを許可
⇒すべてvSocket起点のアウトバウンド通信とその戻り通信であり、インバウンドトラフィックは不要なため - LANセキュリティルール:両方向全てのトラフィックを許可
⇒インバウンドLANトラフィックはCatoのFWルールなどで制御可能なため
上記を踏まえた設定例は以下のようになります。
※WAN_OUTBOUND_ALLOWについてはデフォルトのルールですでに許可されているので設定しなくても問題ありません。
※LANセキュリティグループはデフォルトからの変更はありません。
セキュリティグループを作成すると優先度650000番台のデフォルトルールが作成されます。
ルールとしてはロードバランサーからの通信を許可したり、インターネットへの通信を許可したりなどがありますが、
その中でも65000番にVirtualNetworkからVirtualNetworkへの通信を許可するルールがあります。
当初は「VNet内の通信を許可するものなのかな」ぐらいに思っていましたが、
疎通確認時にICMPを許可せずとも外部のモバイルクライアントからのpingが成功したため、
ここでいう「Virtual Network」とはVNet内だけでなくCatoクラウドの環境も含まれているようです。
つまり、Catoクラウド内の通信であれば、デフォルトですべての通信が許可されているということになります。
Availability
HA構成時のAzureの可用性セット・可用性ゾーンを利用するかどうかです。
シングル構成時は「None」で問題ありません。
- Availability Set:単一データセンター内での障害から保護する。
- Availability Zone:リージョン内の複数データセンターで冗長化。データセンター単位の障害から保護する。
2-6. タグの指定
vSocketに関連するリソースにタグを付けたい場合は、ここでご指定ください。
2-7. vSocketのデプロイ
最後に、設定内容の確認画面が表示されます。
内容に誤りが無いことを確認の上、「作成」をクリックします。
デプロイには数分かかります。
CMA上のSite一覧で以下のように「Connected」と表示されていれば作成完了です。
3. 疎通確認
実際に作成したvSocketを通して、VNet内のリソースにアクセスできるかを確認してみました。
以下のイメージ図のように、外部のCatoクライアントをインストールしたPCからTest VMへログインできるかを試します。
新たに内部セグメントを追加する際には、以下の2点注意をしてください。
- LANサブネットに割り当てられているルートテーブルと同じものを割り当てる
「宛先:0.0.0.0/0 ネクストホップ:LAN NICのアドレス」ルールが設定されているルートテーブルが
LANサブネットにデフォルトで割り当てられています。
Catoと通信させたい内部のサブネットにはすべてこのLANルートテーブルを割り当ててください。
- CMA上でルーティングを登録する
こちらも忘れがちですのご注意ください。
Azure上でセグメントを追加した際は、Catoにも、そこへのルーティングを知らせる必要があります。
上記画像の例ですと、LANサブネット:192.168.34.0/24 なので、ゲートウェイ:192.168.34.1 となります。
テスト用のVMを作成したので、実際に疎通確認を行ってみました。
SSHコマンドを打った後、VM作成時に事前設定したログイン用パスワードを入力し、接続することができました。
おわりに
本記事では、Azure環境をCatoクラウドへ接続させるためのvSocket構築手順を解説しました。
マーケットプレイスからのデプロイは、非常に手軽で便利な一方、
自動生成されたリソース(セキュリティグループや、ルートテーブルなど)を
既存のネットワーク構成に適用できるように調整するという手順も必須です。
Azureに限らずですが、問題なく通信できていたとしても「何をどこで管理しているか」はしっかりと把握しておくべきだと感じました。
以上です。ご覧いただきありがとうございました!





















