intra-VCNルーティングおよびVCNゲートウェイ・イングレス・ルーティングの拡張機能の発表

Oracle Cloud Infrastructure（OCI）は、ソフトウェア定義の仮想ネットワーキングを提供します。一元化されたネットワーク・コントロール・プレーンには、サブネット、インスタンス、ネットワーク・ゲートウェイなど、仮想クラウド・ネットワーク（VCN）にデプロイされる内容の完全な情報および制御があり、OCIはVCNネットワーク内のルーティングを簡略化できます。

設計により、OCIは、中央制御プレーンおよびデータベースを使用してVCN内のルーティングを処理します。VCN内の任意の2つのエンドポイント間で直接ローカル・ルーティングを実行し、トラフィックをルーティングします。お客様は、ルーティングの設定について心配する必要はありません。トラフィックがインターネットからインターネット・ゲートウェイまたはNATゲートウェイを介してVCNを入力するか、サービス・ゲートウェイを介してOCIサービスからVCNに入ると、OCIはルーティングも処理します。イングレス・トラフィックは、VCN内の宛先に直接ルーティングされます。

簡易ルーティングによって、お客様はVCNネットワークを簡単に構築および管理してクラウド・リソースをホストできます。OCIルーティング機能をさらに強化するために、次の新しいルーティング機能と拡張機能を紹介します。

• Intra-VCNルーティング: 同じintra-VCN内の2つの異なるサブネット間を移動するVCN内トラフィックに独自のルートを定義できます。

• OCIインターネットおよびNATゲートウェイ・イングレス・ルーティング: インターネットまたはNATゲートウェイを介して、VCNへのインバウンド・パブリック・トラフィック用の独自のルートを定義できます。

• サービス・ゲートウェイ・イングレス・ルーティングの拡張: OCIサービスからVCN内の宛先にトラフィックをルーティングするサービス・ゲートウェイ用の独自のルートを定義できます。

これらの新機能により、VCN内のトラフィックやインターネットまたはOCIサービスからのVCNのルーティング方法を制御する、より柔軟で簡単な方法が提供されます。VCN内またはイングレス・トラフィック・ルーティングにより多くの制御を適用する簡単なソリューションを提供することで、既存のVCN直接ローカル・ルーティングを拡張します。これらの新機能と元のVCN直接ローカル・ルーティングを利用することで、ルーティング要件を満たす、よりシンプルでスケーラブルなネットワーク設計を実現できます。

このブログの次のセクションでは、機能の概要、機能によって解決される問題、および有効にするネットワーク設計によって、これらの新機能について個別に説明します。設計例にファイアウォールが表示された場合は、OCIネットワーク・ファイアウォールを使用します。OCIネットワーク・ファイアウォール、セキュリティ機能および主要な顧客ユース・ケースについてさらに学習するには、同僚のTroy Levinが書いたブログ「多層防御、OCIネットワーク・ファイアウォールを使用したレイヤー」を参照してください。

Intra-VCNルーティング

Intra-VCNルーティングは、同じVCN内のサブネット間のユーザー定義ルーティングをサポートします。この機能を導入する前に、同じVCN内の2つのエンドポイント間のトラフィックは常にソースから宛先に直接ルーティングされるため、この動作は変更できません。これで、ルート・ルールを定義して、VCN内のinter-subnetトラフィック（2つのサブネット間のトラフィック）のルーティングに中間ホップを挿入できます。

Intra-VCNルート・ルールは、サブネットVCNルート表で定義されます。Intra-VCNルート・ルールのターゲットは、同じVCN内のプライベートIP、ローカル・ピアリング・ゲートウェイ（LPG）または動的ルーティング・ゲートウェイ（DRG）にすることができます。

問題解決

Intra-VCNルーティングにより、仮想ファイアウォールなどの仮想ネットワーク・アプライアンスを、単一のVCN内のinter-subnetトラフィックの転送パスに簡単に挿入できます。異なるアプリケーション層間のトラフィックにファイアウォールを使用（east-westのトラフィックや横のトラフィックと呼ばれることが多い）ことは、よりセキュアなアプリケーション・デプロイメントの一般的なプラクティスになりました。アプリケーション層が同じVCNにデプロイされている場合、intra-VCNトラフィックの直接ルーティングでは、アプリケーション・トラフィックのルーティング・パスに中間ホップとしてファイアウォールを追加できません。

回避策として、2つのアプリケーション層を2つの個別のVCNにデプロイし、inter-VCNルーティングを使用して、east-westトラフィックのルーティング・パスにファイアウォールを追加する必要があります。この回避方法の欠点は、アプリケーションの成長に伴って、増加し続けるVCNの数が増え、ネットワークが急激に複雑になることです。

Intra-VCNルーティングで有効なネットワーク設計

例として、east-westトラフィック ファイアウォールを続けましょう。Intra-VCNルーティング機能を使用すると、アプリケーション層を同じVCN内の別のサブネットにデプロイし、単にファイアウォールをターゲットとして持つサブネット間にカスタム・ルート・ルールを構成することで、2つのアプリケーション層間でファイアウォールを簡単に挿入できるようになりました。

1つの設計オプションとして、次の例に示すように、OCIネットワーク・ファイアウォールを使用する各アプリケーションVCNにファイアウォールをデプロイします。2つのサブネットのルート表には、ファイアウォールのプライベートIPアドレス10.1.0.99がターゲットとして相互にルート・ルールがあります。サブネット間のトラフィックはファイアウォールにルーティングされます。ファイアウォールは、検出後のトラフィックをファイアウォール・サブネット・ゲートウェイ（この例では10.1.0.1）にルーティングします。ファイアウォール・サブネットは、VCNのデフォルトの直接ローカル・ルーティングを使用して、トラフィックを各方向（Web層サブネットまたはアプリケーション層サブネット）の宛先にルーティングします。

また、中央サービス・ハブVCNにファイアウォールをデプロイし、アプリケーションを複数のスポークVCNに配置して中央ファイアウォールを共有することもできます。このオプションは、単一のファイアウォールのみを配備する必要があるため、コスト効率が高く、操作的にシンプルな設計とみなされます。

次の図は、このような設計の例を示しています。この例では、サービス・ハブVCNとアプリケーション・スポークVCNはDRGによって接続されています。サンプル・アプリケーションのWeb層およびアプリケーション層は、同じVCNの2つのサブネットにデプロイされます。2つのサブネットには、DRGをターゲットとするVCN内サブネット・ルート・ルールがあります。DRGは、アプリケーション・トラフィックをservice-hub VCNのファイアウォールに転送して検査します。図は1つのアプリケーションVCNのみを示していますが、本番デプロイメントでは、中央ファイアウォールを共有するために、DRGにアタッチされたスポークとしてより多くのアプリケーションVCNを持つことができます。

DRGによるinter-VCN接続または一元化されたネットワーク仮想アプライアンス設計のためのDRGの使用の詳細は、このブログでは範囲外です。これらのトピックについてさらに学習したい場合は、次のドキュメントをお読みください。

• DRGを使用した集中ネットワーク仮想アプライアンスを介したトラフィックのルーティング

• DRGを介した様々なリージョンのVCNのピアリング

Intra-VCNルーティングを使用してeast-westトラフィック検査用にファイアウォールを挿入する主な利点は、VCNの無秩序な増加をなくすことです。同じVCNのサブネットにアプリケーション層をデプロイし、異なる層間にファイアウォールを追加できます。これにより、ネットワークをよりシンプルかつスケーラブルに保ちます。

インターネットおよびNATゲートウェイ・イングレス・ルーティング

インターネットからのトラフィックは、インターネット・ゲートウェイまたはNATゲートウェイを介してVCNにルーティングされます。各VCNには独自のインターネットまたはNATゲートウェイがあります。イングレス・ルーティングをサポートする前に、インターネットまたはNATゲートウェイは常に、イングレス・パブリック・トラフィックをそのVCN内の宛先に直接ルーティングします。このダイレクト・ルーティングは変更できません。

インターネットおよびNATゲートウェイでのイングレス・ルーティングでは、イングレス・パブリック・トラフィックを宛先に直接ルーティングするのではなく、インターネットまたはNATゲートウェイでトラフィックをカスタム・ルート・ルールで指定したターゲットにルーティングできるように、インターネットまたはNATゲートウェイでカスタム・ルーティングを定義できるようになりました。たとえば、トラフィックをファイアウォールまたは別のネットワーク仮想アプライアンスに送信するようにインターネットまたはNATゲートウェイに指示できます。

次の図は、インターネットおよびNATゲートウェイでのイングレス・ルーティングの有無によるシナリオの違いを示しています。

インターネットおよびNATゲートウェイでイングレス・ルーティングを使用するには、VCNルート表をインターネットまたはNATゲートウェイに関連付け、インターネットまたはNATゲートウェイでこのルート表で使用するルート・ルールを定義します。これらのルート・ルールは、イングレス・パブリック・トラフィックのルーティング方法をインターネットまたはNATゲートウェイに指示します。ルート・ルールは、ターゲットとしてVCNにプライベートIPアドレスを持つことができます。インターネットまたはNATゲートウェイ・ルート表のVCN内の宛先にカスタム・ルートが定義されていない場合、インターネットまたはNATゲートウェイは、元の直接ローカル・ルーティングを使用して、イングレス・トラフィックを宛先に直接ルーティングします。

問題解決

インターネットまたはNATゲートウェイ・イングレス・ルーティングを使用すると、インターネットまたはNATゲートウェイとVCN内の宛先の間でネットワーク仮想アプライアンス（仮想ファイアウォールなど）を簡単に挿入できるため、ゲートウェイは、最初にイングレス・パブリック・トラフィックを仮想アプライアンスに検査または他のプロセスのためにルーティングできます。この要件はより一般的になっています。たとえば、クラウドでホストされている多くのWebアプリケーションは、インターネット上のパブリック・ユーザーにサービスを提供します。ユーザーは、アプリケーションWeb層のパブリックIPアドレスを介してインターネットからアプリケーション・サービスにアクセスします。インターネットは信頼できない環境とみなされるため、アプリケーション所有者は、VCN内のリソースに到達する前に、ユーザーからのイングレス・パブリック・トラフィックをファイアウォールで検査する必要があります。

通常、これらのWebアプリケーションのWeb層は、ロード・バランサおよびバックエンド・セット内の複数のインスタンスを含むパブリック・サブネットにデプロイされます。アプリケーション・サービスにアクセスするためのパブリックIPアドレスは、多くの場合、Web層ロード・バランサに割り当てられます。インターネット・ユーザーとWeb層の間のトラフィックは、VCNのインターネット・ゲートウェイを介してルーティングされます。インターネット・ゲートウェイとWeb層の間の転送パスにファイアウォールを挿入するには、中間ルーティング・ホップとしてファイアウォールを追加する必要があります。インターネット・ゲートウェイの現在の直接ローカル・ルーティングでは、トラフィックは常にVCN内の宛先に直接ルーティングされるため、このインテントが妨げられます。Web層ロード・バランサでサービスのパブリックIPアドレスを保持する場合、イングレス・トラフィックはインターネット・ゲートウェイによる直接ルーティングでファイアウォールをバイパスします。

次の図の例では、問題を示しています。この例では、アプリケーションWeb層のパブリックIPアドレスは150.136.118.162です。プライベートIP 10.1.1.104を持つアプリケーションWeb層ロード・バランサに割り当てられます。インターネット・ユーザーがアプリケーション・サービスにアクセスすると、トラフィックはパブリックIPアドレス150.136.118.162に送信されます。トラフィックは、アプリケーションVCNのインターネット・ゲートウェイにルーティングされます。インターネット・ゲートウェイは、宛先IPアドレスをWeb層ロード・バランサのプライベートIP 10.1.1.104に変更し、トラフィックをロード・バランサに直接ルーティングします。イングレス・トラフィックのルーティングでファイアウォールがバイパスされます。

ファイアウォールが問題を回避するための回避策として、インターネット・ゲートウェイがイングレス・パブリック・トラフィックをファイアウォールにルーティングするように、アプリケーション・サービスのパブリックIPアドレスをファイアウォールに移動する必要があります。ファイアウォールは、宛先NAT（DNAT）を実行して宛先IPアドレスをWeb層ロード・バランサのプライベートIPアドレスに変更し、ロード・バランサにパケットをルーティングします。

次の図は、この回避方法の設計を示しています。この設計では、アプリケーション・サービスにアクセスするパブリックIPアドレス（150.136.118.162）がファイアウォールに移動されます。ファイアウォールのプライベートIPアドレスは10.1.0.99です。インターネット・ユーザーは、ファイアウォール・パブリックIPアドレス150.136.118.162にトラフィックを送信します。IGWはイングレス・トラフィックを受信すると、宛先IPアドレスをファイアウォールのプライベートIP 10.1.0.99に変更し、トラフィックをファイアウォールにルーティングします。ファイアウォールは、宛先IPアドレスを独自のプライベートIP（10.1.0.99）からWeb層ロード・バランサのプライベートIP（10.1.1.1.04）に変換し、10.1.0.1のファイアウォール・サブネット・ゲートウェイにルーティングします。ファイアウォール・サブネットは、デフォルトのVCN直接ローカル・ルーティングを使用して、パケットをWeb層ロード・バランサに直接ルーティングします。

この回避方法には、次の課題があります。

• ネットワーク設計とファイアウォール構成の複雑さ

• 各ファイアウォール仮想ネットワーク・インタフェース・カード（vNIC）が持つことができるIPアドレスの数に制限されたスケーラビリティ

• NATingのファイアウォールに対する余分な負担は、パフォーマンスに影響する可能性あり

• ファイアウォールNATスケーラビリティー制限に到達可能

インターネットおよびNATゲートウェイ・イングレス・ルーティングにより、仮想ファイアウォールや、イングレス・パブリック・トラフィック転送パスへのその他のネットワーク仮想アプライアンスの挿入をよりシンプルに設計できます。

インターネットおよびNATゲートウェイ・イングレス・ルーティングで有効な設計

インターネットおよびNATゲートウェイ・イングレス・ルーティングでは、ゲートウェイ・ルート表に独自のルート・ルールを作成して、ゲートウェイのデフォルトのダイレクト・ルーティング動作を上書きできます。ファイアウォール挿入の同じ設計目標を達成するために、宛先サブネットまたはVCN CIDR（すべてのイングレス・トラフィックをファイアウォールに送信する場合）のルート・ルールを、ファイアウォールのプライベートIPをターゲットとして作成できます。イングレス・パブリック・トラフィックのネイティブ・ルーティング・パスにファイアウォールが追加されます。

次の図は、インターネット・ゲートウェイ・イングレス・ルーティングによって有効化される簡易ファイアウォール挿入設計を示しています。

この例では、プライベートIP 10.1.1.104を持つWeb層ロード・バランサにアプリケーション・パブリックIPアドレス150.136.118.162を保持します。イングレス・パブリック・トラフィックが常にファイアウォールを通過するように、インターネット・ゲートウェイでイングレス・ルーティングを使用します。インターネット・ゲートウェイのイングレス・ルート表で、Web層サブネットCIDR 10.1.1.0/24のルート・ルールを、ファイアウォールのプライベートIPアドレス10.1.0.99をターゲットとして追加します。インターネット上のアプリケーション・ユーザーからのトラフィックは、宛先としてパブリックIPアドレス150.136.118.162を持ち、インターネット・ゲートウェイにルーティングされます。

インターネット・ゲートウェイは、宛先IPアドレスを150.136.118.162からWeb層ロード・バランサのプライベートIP 10.1.1.104に変更し、イングレス・ルート表の10.1.1.0/24のルート・ルールに基づいてパケットをファイアウォールにルーティングします。ファイアウォールはパケットを検査し、事後検査パケットをファイアウォール・サブネット・ゲートウェイ（10.1.0.1）に送信します。ファイアウォール・サブネットは、デフォルトのVCN直接ローカル・ルーティングを使用して、宛先IP 10.1.1.104に基づいてパケットをWeb層ロード・バランサにルーティングできます。戻りトラフィックの場合、Web層サブネットは、0.0.0.0/0ルート・ルールを使用し、ファイアウォールをサブネットVCNルート表のターゲットとして使用して、トラフィックをファイアウォールにルーティングします。ファイアウォール・サブネットは、接続後のトラフィックを、ルート表の0.0.0.0/0ルートを使用してインターネット・ゲートウェイにルーティングします。

この新しい設計では、ファイアウォールがインターネット・ゲートウェイとアプリケーションWeb層の間のネイティブ・ルーティング・パスに追加されます。ファイアウォール上のNATingが不要になります。アプリケーションのパブリックIPアドレスをファイアウォールに移動する必要がなくなったため、ファイアウォールVNICでサポートされているIPアドレスの最大数に懸念はありません。イングレス・パブリック・トラフィックのファイアウォール（またはネットワーク仮想アプライアンス）を自然なルーティング設計によって挿入するための、よりシンプルでスケーラブルなソリューションが提供されます。

OCIサービスからのトラフィックに対するサービス・ゲートウェイ・イングレス・ルーティングの拡張

サービス・ゲートウェイは、以前にOCIトランジット・ルーティング設計のイングレス・ルーティングをサポートしていました。オンプレミスのコンピュート・インスタンスがハブVCN内のサービス・ゲートウェイを介してOracle Service Networkにアクセスするために使用されました。サービス・ゲートウェイに関連付けられたルート表には、DRGをターゲットとする顧客のオンプレミス・ネットワークのルートを設定できます。ただし、宛先がVCN内にある場合、サービス・ゲートウェイは常にトラフィックを直接ルーティングします。ルートを変更できませんでした。

このサービス・ゲートウェイのイングレス・ルーティングの拡張により、サービス・ゲートウェイに対して独自のルート・ルールを定義して、VCN内部宛先にトラフィックをルーティングできます。これらのカスタム・ルート・ルールは、サービス・ゲートウェイに関連付けられているVCNルート表に作成する必要があります。これらのルート・ルールのターゲットは、DRGまたはVCN内のプライベートIPです。

問題解決

サービス・ゲートウェイ・イングレス・ルーティングの拡張により、仮想ファイアウォールなどのネットワーク仮想アプライアンスを、サービス・ゲートウェイを介してOCIサービスからVCNへのトラフィックのルーティング・パスに簡単に挿入できます。

多くの顧客は、OCIサービスからのトラフィックが信頼できない外部トラフィックであると考えています。サービス・ゲートウェイが、VCN内の内部リソースに到達する前に、セキュリティ検査のためにファイアウォール経由でサービス・ゲートウェイを送信することを希望しています。このサービス・ゲートウェイ・イングレス・ルーティングの拡張機能がない場合、サービス・ゲートウェイは常にVCN内の宛先に直接トラフィックをルーティングし、ファイアウォールはバイパスされるため、ファイアウォールを挿入する簡単な方法はありません。次の図の例は、チャレンジを示しています。

この例では、アプリケーションのアプリケーション層がOCIサービスにアクセスする必要があります。アプリケーション層からOCIサービスへのトラフィックは問題なくファイアウォールを介してルーティングできますが、サービス・ゲートウェイによって宛先IPがアプリケーション層のプライベートIPである10.1.2.106に変更され、アプリケーション層の宛先に直接ルーティングされるため、OCIサービスからアプリケーション層への戻りトラフィックはファイアウォールをバイパスします。

ファイアウォール・バイパスの問題を回避するには、トラフィックをファイアウォールとサービス・ゲートウェイの視点からOCIサービスの間に表示する方法が必要です。回避策として、アプリケーション層からOCIサービスへの初期トラフィックについて、サービス・ゲートウェイにさらに送信する前に、アプリケーション層プライベートIPからファイアウォール内のプライベートIPにソースIPアドレスをNATにファイアウォールで接続できます。この変更により、サービス・ゲートウェイでは、OCIサービスへのアウトバウンド・トラフィックはファイアウォールによってソーシングされます。そのため、OCIサービスからアプリケーションへのレスポンス・トラフィックを受信すると、宛先IPがファイアウォールのプライベートIPに変更され、パケットがファイアウォールにルーティングされます。ファイアウォールでは、宛先IPを実際のアプリケーション層プライベートIPに戻し、事後検査パケットをアプリケーション層にルーティングする必要があります。次の図は、この回避方法設計の例を示しています。

この回避方法の設計は、ファイアウォール上のネットワークアドレスの変換に依存します。そのスケールとパフォーマンスは、ファイアウォールのNATスケールとパフォーマンスによって制限できます。VCN内部宛先へのトラフィックに対するサービス・ゲートウェイのイングレス・ルーティングの強化により、よりシンプルなソリューションが提供されます。

サービス・ゲートウェイ・イングレス・ルーティングの拡張によって有効な設計

サービス・ゲートウェイ・イングレス・ルーティングの拡張により、OCIサービスからのトラフィックの自然な転送パスにファイアウォールを挿入できます。ファイアウォールにトラフィックをルーティングするようにサービス・ゲートウェイに指示するカスタム・ルート・ルールをサービス・ゲートウェイ・ルート表で定義します。このルート・ルールにより、宛先IPアドレスがアプリケーション層のプライベートIPであっても、OCIサービスからアプリケーションに戻されるトラフィックは常にファイアウォールを介してルーティングされます。ネットワーク・アドレス変換を行うのにファイアウォールは必要ありません。次の図は、OCIサービス・トラフィック・ルーティングでのファイアウォール挿入の簡易設計の例を示しています。

この例では、アプリケーション・サブネット・ルート表に、ファイアウォールのプライベートIPアドレス10.1.0.88がターゲットであるOCIサービスのルートがあります。このルートでは、アプリケーション層からOCIサービスに送信されるエグレス・トラフィックがファイアウォールにルーティングされます。ファイアウォール・サブネットのルート表には、サービス・ゲートウェイをターゲットとするOCIサービスのルートがあり、ファイアウォール検査後にエグレス・トラフィックがサービス・ゲートウェイにルーティングされます。サービス・ゲートウェイはトラフィックを受信し、アプリケーション層プライベートIP 10.1.2.106のソースを参照します。そのため、OCIサービスからのレスポンス・トラフィックでは、サービス・ゲートウェイによって宛先IPアドレスが10.1.2.106に変更されます。サービス・ゲートウェイのルート表にはアプリケーション・サブネット10.1.2.0/24のルート・ルールがあり、ファイアウォールのプライベートIP 10.1.0.88がターゲットであるため、サービス・ゲートウェイはトラフィックをファイアウォールにルーティングします。ファイアウォール・サブネットは、VCN直接ローカル・ルーティングを使用して、検査後のトラフィックをアプリケーション層にルーティングします。

この設計は、サービス・ゲートウェイとVCN内の宛先の間に仮想ファイアウォール（またはネットワーク仮想アプライアンス）を挿入するネイティブ・ルーティング・ソリューションを提供します。この拡張性と高性能のソリューションでは、ネットワーク・アドレスをファイアウォールで変換する必要はありません。

まとめ

Intra-VCNルーティング、インターネットおよびNATゲートウェイ・イングレス・ルーティングの新しい機能およびサービス・ゲートウェイ・イングレス・ルーティングの拡張により、OCIはバリアント・ルーティング設計の柔軟性を高めます。これらの新しい機能を元のVCNダイレクト・ローカル・ルーティングと組み合せて使用することで、よりシンプルかつスケーラブルなネットワーク設計を実現し、VCN内トラフィックのネイティブ・ルーティング・パスに仮想ファイアウォールまたはその他の仮想ネットワーク・アプライアンスをインターネットまたはOCIサービスからのイングレス・トラフィックに挿入できます。

Oracle Cloud Infrastructureでは、最優先として、お客様のニーズと最善の利益を維持しています。お客様のニーズに応えるため、ソリューションや機能を継続的に進化させています。最新の情報をいち早くお届けしますので、ご期待ください。