サイト間トンネルとは何ですか？

サイト間トンネル（S2S）とは、Versa SASE ゲートウェイまたはVOSデバイスと、ピアネットワーク（企業のデータセンター、クラウドVPCまたはVNetゲートウェイ、あるいはサードパーティ製デバイスなど）との間で確立される、暗号化されたIPsecまたはGRE接続のことです。このトンネルは、2つのネットワーク間をあたかも直接有線で接続されているかのように、プライベートアプリケーションや統合トラフィックを伝送します。

主なポイント

• S2Sトンネルでは、IPsecまたはGREを使用して、Versa ゲートウェイとピアを接続します。
• ピアには、データセンター、クラウドのVPC/VNet、およびサードパーティ製デバイスが含まれます。
• 高可用性（HA）を確保するには、静的ルートよりも冗長トンネルを備えたBGPの使用が推奨されます。
• Concertoは、IPsec、GRE、EoGRE、およびGeneveトンネルインターフェースに対応しています。
• VOSクラウドゲートウェイは受動的な状態を維持し、トンネルの確立は常に支店側から行われます。

このページの内容： その重要性 ・ 仕組み ・ 種類 · サイト間トンネルおよびVersa · よくある質問

サイト間トンネルはなぜ重要なのでしょうか？

企業のトラフィックの大部分は、依然としてSD-WANファブリック自体以外の場所、つまりレガシーアプリケーションをホストするデータセンター、本番ワークロードを実行するクラウドVPC、あるいはZscalerのようなセキュリティパートナーのクラウドなどに到達する必要があります。これらの各宛先への専用回線を個別に敷設する方法はスケーラビリティに欠けます。一方、サイト間トンネルを利用すれば、通常のインターネット回線を通じて、リモートアクセスVPNのように各ユーザーのデバイスに専用のクライアントをインストールする必要なく、同様のプライベートで暗号化された接続性を実現できます。

サイト間トンネルは、重要なリソースへの唯一の経路となる場合が多いため、その接続方法と同様に、障害発生時の対応も極めて重要です。単一の静的ルートでは、サイレント障害を迅速に検知する方法がありません。一方、冗長化されたトンネルをBGPやBFDと組み合わせることで、障害発生した経路を数秒で迂回させることができます。また、地理的に離れたゲートウェイへの第2のトンネルを設けることで、リンクだけでなく、ピア側の地域的な障害からも保護されます。

サイト間トンネルとは何ですか？

サイト間トンネルは、ポイントツーポイントプロトコルを使用してトラフィックをカプセル化する仮想トンネルインターフェースとして構成されます。最も一般的なのは、トラフィックの認証と暗号化を行うIPsec、あるいはそれ自体では暗号化を行わずトラフィックをカプセル化するGREです。このトンネルは、VOS CPEデバイス（物理デバイスまたはクラウドベース）を、ピア（クラウド管理型サービス、または同じプロトコルをサポートするサードパーティ製デバイス）に接続します。

プラットフォームに応じて、2つの構成モデルが存在します。Versa Directorでは、トンネルはワークフローテンプレートの「トンネル」タブで定義され、その後デバイスに関連付けられます。Concertoでは、サイト間トンネルは「サイト間トンネル」または「サブテナントサイト間トンネル」というカテゴリの下に、ネットワークインターフェースとして直接追加されます。 トンネルには、ルーティングテーブル（静的またはBGP）によってトラフィックを転送するトンネルが選択される「ルートベース」と、明示的な送信元/宛先/ポートのルールによってトンネルが選択される「ポリシーベース」があります。後者は、ルートベースの設定をサポートしていない一部のサードパーティ製ピアで必要となります。

サイト間トンネルの種類

Concertoのトンネルインターフェースは、IPsec（暗号化、デフォルト）、GRE、EoGRE（Ethernet over GRE、住宅用ゲートウェイのモビリティサービス向け）、Geneve（UDPにカプセル化されたレイヤー2フレーム）の4つのカプセル化サブカテゴリをサポートしています。 一方、Directorのワークフローモデルでは、トンネルは名前付きピアタイプごとに整理されます。具体的には、AWS Transit Gateway（IPsecまたはGRE、AWS側でDirectorが自動設定）、Azure Virtual WAN（IPsec）、Zscaler（IPsecまたはGRE、冗長化のために2つのトンネルが必要）、プロバイダーとテナント間のDirector管理トンネルVersa Director（SaaSオンランプ、Cloud Service Gateways、およびTitan ハブをテナントに拡張するもの）、およびCisco、Juniper、Palo Altoなどの一般的なサードパーティ製IPsecピアを対象とする「その他」です。

サイト間トンネルおよびVersa

Director でサイト間トンネルを設定するには、ワークフローテンプレートの [トンネル] タブにトンネルを組み込み、ピアタイプ、トンネルプロトコル、WAN/LAN ネットワーク、および LAN VRF を選択し、そのテンプレートをデバイスに関連付けます。ピア固有のフィールドには、BGP AS 番号、PSK、および NAT アドレス指定が含まれます。 Concertoでは、「ネットワークインターフェース」の直下に「サイト間トンネル」インターフェースを追加し、IKE/IPsecパラメータを設定して、ルートベースまたはポリシーベースのトンネルタイプを選択することで、同様の結果が得られます。

VersaのSD-WANとSSEの統合ガイドでは、シングルCPEおよびデュアルCPE、シングルWANおよびデュアルWANの各トポロジーにおいて、VOSブランチからSSEの適用ポイントであるVOS Cloud Gateway（VCG）へのサイト間トンネルの展開手順を解説しています。 VOS VCGは設計上、IKEをパッシブモードで実行するため、トンネルの確立は常にブランチ側から行われます。冗長トンネルにおけるフェイルオーバーメカニズムとしては、BGPとBFDの組み合わせが推奨されており、地理的に離れたVCGへの第2のトンネルを設けることで、地域的な障害に対する耐性を高めることができます。

よくある質問

IPsecとGREのサイト間トンネルの違いは何ですか？

IPsecはトンネル内のトラフィックを認証・暗号化しますが、GREは単にカプセル化するだけで、それ自体による暗号化は行いません。AWS Transit GatewayやZscalerなど、一部のピアタイプはどちらのプロトコルもサポートしており、GREは保護された転送を実現するために、別のIPsecトンネルと組み合わせて使用されることもあります。

サイト間トンネルには、静的ルーティングとBGPのどちらを使用すべきでしょうか？

冗長トンネルが存在する場合は、BGPとBFDを組み合わせることが推奨されます。これは、BGPが経路の障害を検知し、デフォルトでは通常15～18秒以内に自動的に再ルーティングを行うためです。静的ルーティングは単一のトンネルでは機能しますが、複数の経路にわたってこれほどスムーズなフェイルオーバーを行うことはできません。

Versa は、サイト間トンネルにおいてどのようなピアタイプをサポートしていますか？

Directorのワークフローモデルは、AWS Transit Gateway、Azure Virtual WAN、Zscaler、Directorが管理するピア（プロバイダー側のDirectorとテナント側のDirector間）、およびCisco、Juniper、Palo Altoなどのサードパーティ製IPsecデバイス向けの汎用「その他」タイプに対応しています。一方、Concertoでは、トンネルをIPsec、GRE、EoGRE、またはGeneveごとに分類しています。

ルートベースのトンネルとポリシーベースのトンネルの違いは何ですか？

ルートベースのトンネルでは、ルーティングテーブル（静的またはBGP）に基づいて、どのトンネルでトラフィックを転送するかが決定されます。一方、ポリシーベースのトンネルでは、トラフィックを明示的な送信元、宛先、およびポートのルールと照合します。旧式のCisco ASAデバイスなど、一部のレガシーなサードパーティ製ピアでは、ポリシーベースの設定が必要となります。

VOS Cloud Gateway がサイト間トンネルを一切開始しないのはなぜですか？

VOS Cloud Gateways は設計上、IKE パッシブモードで動作するため、自ら IPsec ネゴシエーションを開始するのではなく、ブランチ側からネゴシエーションが開始されるのを待ちます。VOS ブランチ側もパッシブモードに設定してはなりません。そうしないと、どちらの側もトンネルを確立できなくなってしまいます。

サイト間トンネルに関する詳細

さらに詳しく知りたい場合は、私たちが信頼している情報源を以下にご紹介します。

関連用語

サイト間トンネルについてお読みの方は、次にこれらもぜひご参照ください。