機械翻訳について
  1. ユーザー・ガイド
  2. ネットワーキング
  3. ネットワーキング・シナリオ

ネットワーキング・シナリオ

仮想化クラウド環境のすべてのネットワーク・シナリオは、物理スイッチ、ルーターおよびゲートウェイによって接続された個々のIPサブネットのシナリオに類似しています。 つまり、仮想デバイスでは、フレームおよびIPアドレスのソースおよび宛先アドレスとしてのMAC (ハードウェア)アドレスが、パケット内の宛先アドレスととしてのままになります。

コンテンツ配信は本質的に同様に機能します。 ソースIPアドレスと宛先IPアドレスのネットワーク部分が同じ定義済VCNサブネット内にある場合、配信は、ソースと宛先のMACフレーム・アドレスに基づく論理スイッチ(ブリッジ)を介して行われます。 ソースIPアドレスと宛先IPアドレスのネットワーク部分が異なるVCNサブネットにある場合、配信はソースと宛先IPパケット・アドレスに基づきます。

Oracle Private Cloud Applianceの論理スイッチを構成する必要はありません。 MACアドレスは、論理スイッチに接続されているすべてのほかのエンティティで認識されます。 複数のVMを同じVCNサブネットに配置すると、通信しても問題ありません。 インスタンス分離が目標である場合は、それぞれに個別のサブネットまたはVCNを確立します。

論理ルーター

異なるVCNサブネット間のトラフィックは、定義によって少なくとも1つの論理ルーターによって処理されます。 IPパケット・アドレスを使用して転送ステップを決定するデバイス、およびリンクする異なるサブネット上で異なるMACフレーム・アドレスを使用するデバイスは、ルーターと呼ばれます。 ルーターがインターネットにアタッチする場合、これらの仮想デバイスはインターネット・ゲートウェイ(IGW)です。

送信元または宛先のIPアドレス規則にIPネットワーク・アドレス変換(NAT)が含まれている場合、パケットは一部のタイプのNATゲートウェイによって処理されます(いくつかのタイプのNATゲートウェイがあります)。 NATの形式が使用されている場合は、NATゲートウェイ(NATGWまたはNGW)です。

仮想化されたクラウド・ネットワーキングの多くのケースでは、ルーティングは非常にシンプルで、宛先が豊富である小規模の静的ルーティング表によって処理できます。 より複雑な仮想環境では、定期的に更新される動的情報を含む、より複雑な論理ルーターが必要です。

論理ルーターはパケットのIPアドレスを検査します。 IPアドレス(発信元と宛先)は、Oracle Private Cloud Applianceの「ルート・ルール表」というルート表で検索され、IPアドレス・ルールで許可されている場合、パケットを次のホップ(別のルーター)または宛先(ローカル配信用)に転送します。 ルート・ルールがIPアドレスに適用されない場合、パケットはサイレント・ドロップされ、エラー・メッセージは生成されません(これは、ブロックされたプローブが情報を収集しないようにするためのセキュリティ機能です)。 ただし、このエラー・メッセージの欠落は、ルート・ルールを慎重に構成する必要があることを意味します。

ルーティング・ルールに関して特別なIPアドレスは1つです。 これはIPv4アドレス0.0.0.0/0で、基本的にすべてのIPアドレスに一致します。 一部のドキュメントでは、0.0.0.0/0表記法をIPアドレスCIDRブロックと呼びますが、同じユニバーサル一致がコールされてもtrueです。

たとえば、次のルート・ルールでは、VCN内から任意のIPアドレスにパケットが送信され、インターネットへのゲートウェイに到達できます:

Destination                                                          Target
0.0.0.0/0                                          Internet Gateway  vcn-20210714-0910

ルート・ルールは、パケットの宛先を判別するよりも多くなります。 ルート・ルールは、ネットワーク・ファイアウォールの基礎も形成します。

ファイアウォールの使用

インターネットへのアクセスは便利ですが、脆弱性とセキュリティに懸念があります。 ファイアウォールは、ネットワーク要素間のトラフィックの空きパスを制限し、ネットワークを保護するために存在します。 ファイアウォール(論理または物理)は、特定のソースから特定の宛先へのトラフィック・フローを調べ、ルート・ルール表の構成済セキュリティ・ルールに基づいてパケットを許可またはブロックします。

ファイアウォールは、外部ソースから外部ソースへのトラフィックを許可またはブロックするだけでなく、同じVCN内のサブネットに渡されるトラフィックを検証するように構成する必要があります。 脅威は外部ソースから発生する可能性がありますが、ネットワーク内で危険にさらされたインスタンスから発生することもあります。

ネットワーク・セグメンテーションの使用

仮想ネットワークを1つのビッグ・エンティティとして構成し、他のすべてから簡単に到達できるようにします。 ただし、これにより、攻撃者がネットワークを危険にさらすことが比較的容易になります: かつては、どこにでもいる。 ネットワークにセグメンテーションを使用し、リソースおよびデータを様々なセグメントにグループ化することをお薦めします。

Oracle Private Cloud Applianceでは、セグメントは基本的にネットワーク・セキュリティ・グループです。

通常は、類似性またはデータの機密性に基づいてデータとリソースをグループ化します。 たとえば、データセンターから受信したすべてのトラフィックを検査するグループを設定できます。 セキュリティ・ルールに基づいて、このトラフィックをアプリケーション・サーバーのグループに渡してから、データベース・サーバーに渡すことができます。

このアプローチでは、グループ間のファイアウォールによって、データ・センターの危険にさらされたコンポーネントからアプリケーションとデータベース・サーバーが保護されます。

トンネリングの使用

仮想化されたクラウド・ネットワーキングの複雑さの1つは、IPアドレスをVCNサブネットに割り当てる中心的な権限がないことです。 VCN-1のSubnet-1にあるIPアドレス192.168.1.6をVM-1に、別のハイパーバイザがVCN-1のSubnet-1で同じIPアドレス192.168.1.6をVM-7に割り当てるなど、1つのハイパーバイザが割り当てられない。 ただし、様々な表が正しく構成されている場合は、引き続き通信できます。

これらのネットワーク・アドレスの複雑さを効果的に非表示にするために、Oracle Private Cloud Applianceは、IPトンネルを介して論理ルーターなどのネットワーク・コンポーネント間でトラフィックを移動します。 ただし、このトンネルの使用(一般的なIPネットワーク手法)では、ネットワーク・シナリオは変更されません。 インスタンスにはまだIPアドレスがあり、これらのアドレスは引き続き特定のサブネットに割り当てられ、サブネットは仮想ネットワーク・インタフェース・カード(VNIC)に割り当てられます。 同じハイパーバイザで実行されている様々なインスタンスからのすべてのトラフィックは、ソースと宛先の間の次のデバイスへの転送のためにIPトンネルに結合されます。

仮想クラウド・ネットワークの使用

テナンシで実行されるプライベート・クラウド・ネットワークである1つ以上のVCNにリソースが収集されると簡単に言えます。 ただし、リソースのグループを宣言してVCNの境界を作成するよりも、VCNはかなり多く存在します。

VCNを計画することは、デプロイメントの重要な部分です。 VCNは、アプリケーション・サーバー、データベース、提供されるその他のサービスを構築するための基盤として機能します。 VCNは、冗長性、高可用性、スケーラビリティ、セキュリティなどのあらゆるニーズを考慮する必要があります。

この項では、VCNの重要な部分について説明します。

IPアドレス範囲

VCNを計画する場合、最初に行うディシジョンは、使用するIPアドレスCIDRブロックです。

ノート:

CIDRブロックの計算に役立つリソースは、: CIDRのIPアドレス・ガイド

VCNネットワーク・アドレス範囲は、 /16から /30までの任意のVLSMにする必要があります。 これは、4つの使用可能なIPアドレス(/30)から65,536の使用可能なIPアドレス(/16)間の仮想ネットワークをカバーしますが、最も高いIPアドレスと最も低いIPアドレスはエンドポイント・デバイスには役立ちません。

VCNに選択されたCIDRブロックのサイズは重要です。 サイズが大きすぎると、ネットワーク内の他の場所で使用できるIPアドレスが無駄になります。 サイズが小さすぎると、VCNに十分なIPアドレスがないため、ソリューションはスケーリングされません。 常に別のVCNを作成して相互にピアリングできますが、これは慎重な計画によって回避できる問題です。

VCN CIDRブロックに関するいくつかの重要なポイントがあります:

  • VCNは、RFC1918プライベート・アドレス範囲のいずれかを使用する必要があります: 10.0.0.0/8、172.16.0.0/12および192.168.0.0/16。

  • VCNは連続したIPv4 CIDRブロックを使用します。 IPv6はサポートされていません。

  • 作成後にVCNおよびサブネット・サイズ(10.100.0.0/21など)を変更することはできません。 IPアドレス範囲は、ピアリングするVCNと重複できません。

  • VCN内のサブネットは相互に重複することはできません。

  • 範囲内の最大および最小のIPアドレスは、ネットワーク機能用に予約されています。

IPサブネット

サブネットは、CIDRで確立された継続的なIPアドレス範囲を使用するVCNの下位区分です。 サブネットは、IPアドレス別にリソースをグループ化します。

VCNのパースペクティブから、サブネットはパブリックまたはプライベートにできます。 Oracle Private Cloud Applianceのコンテキストでは、プライベートVCNアドレスは、同じプライベート・アドレス領域を使用している他のVCNと対話する前に、NATを使用して変更する必要があります。 パブリックVCNアドレスにより、データ・センター・ネットワークへの接続が可能であり、ラック外からアクセスできます。

ただし、RFC1918アドレス空間は、パブリックIPアドレス空間(外部データ・センター接続が可能)とプライベートIPアドレス空間(Oracle Private Cloud Applianceラック内で接続可能)の両方にサブネット化できます。

たとえば、VCNではIP CIDRブロックを使用してこれを実行できます: 

Subnet Name                           Subnet Access                               IP CIDR Block

Public_Subnet_01                      Public                                      10.100.0.0/24
Private_Subnet_01                     Private                                     10.100.1.0/24

Public_Subnet_01には、10.100.0.0から10.100.0.255までの256個のIPアドレスがあります(これらの2つのアドレスはデバイスには使用されず、ほとんどのIPネットワークで特別な用途があります)。 ネットマスクは255.255.255.0です

Private_Subnet_01には、10.100.1.0から10.100.1.255までの256個のIPアドレスもあります(また、下位アドレスと上位アドレスはデバイスにはあまり役立ちません)。 ネットマスクは255.255.255.0です。

2つのアドレス範囲が重複していないことに注意してください。 (パブリック・レンジが10.100.0.0/23の場合、256個のデバイスが10.100.1.0/24と重複します。)

ルート表

VCNは、ルート表を使用して、インスタンスによるトラフィックの送受信を管理するルールを保持します。 VCNは、次のような宛先へのフォーム到達を許可または禁止できます:

  • グローバル・パブリック・インターネット

  • 日付センター・ネットワークなどのオンプレミス・ネットワーク

  • ピアVCN

VCNが作成されるたびに、デフォルト・ルート表を持つ仮想ルーターも作成されます。

セキュリティを向上させるには、デフォルト・ルールを使用するのではなく、サブネットごとに専用のルート表を作成することをお薦めします。これは、必要なセキュリティ・レベルに適していない可能性があります。 専用ルート表は、各サブネットが必要とするルート・ルールをより効果的に管理できます。 たとえば、サブネットでグローバル・パブリック・インターネットへのトラフィックの送信が許可されている場合、そのサブネットのルート表には、「ユニバーサル宛先」0.0.0.0/0を使用してインターネット・ゲートウェイにトラフィックをルーティングするルールが必要です。

ノート:

CIDRブロック0.0.0.0/0は、IPv4アドレス空間のすべてのアドレスに一致します。 これは、「任意のサブネット・マスクを持つ任意のIPv4アドレス」を意味します。

グローバル・パブリック・ネットワーク・アクセスを必要としないサブネットには、ルート表にそのルールを含めないでください。 さらに、次もあります。

  • VCN内のソースと宛先とのトラフィックは、ルート表ルールによって制御されません。

  • ルールが重複する場合(通常は異なるCIDRブロックまたはサブネットに関して)、より具体的なルールが適用されます(最も長い一致と見られることが多い)。

  • トラフィック・フローに適用されるルールがない場合、トラフィックは暗黙的に削除されます(エラー・メッセージは送信されません)。

ルート表のすべてのルールにターゲットがあります。 ターゲットは、任意のネットワークの共通コンポーネントの機能ネットワーク・ノードです:

  • 動的ルーティング・ゲートウェイ(DRG): ルート表ルールは静的に構成されていませんが、BGPなどのルーティング・プロトコルを使用して変更します。

  • グローバル・パブリック・インターネットに接続するためのインターネット・ゲートウェイ(IG)。

  • IPアドレス変換用のNATゲートウェイ(NATG)。

  • サービス・ゲートウェイ(SG)は、他のサブネットの多様なサービスに到達できます。

  • ピアVCNに接続するためのローカル・ピアリング・ゲートウェイ(LPG)。

  • プライベートIPアドレス。VCN内の特定のインスタンスにトラフィックをルーティングします。

たとえば、VCNには、次のルールを持つルート表を含めることができます:

Subnet Name                           Route Table                                Target

Public_Subnet_01                      Public_Subnet_01_Route_Table               IG
Private_Subnet_01                     Private_Subnet_01_Route_Table              NAT Gateway

ルート表は、VCNセキュリティの基盤です。

セキュリティ・リストとネットワーク・セキュリティ・グループ

オンプレミス・ネットワークにはファイアウォールのようなセキュリティが必要な場合があります。 しかし、セキュリティは常にすべてのコンテキストで重要であり、すべての脅威が組織の外部から来るわけではありません。

Oracle Private Cloud Applianceには、パケット・レベルでトラフィックを制御するためにファイアウォールのように動作する2つのセキュリティ・ネットワーキング・メカニズムが用意されています:

  • セキュリティ・リスト。サブネットの物理ファイアウォールなどに使用されます。

  • ネットワーク・セキュリティ・グループ(NSG)。サブネットをまたがるインスタンスのグループのファイアウォールとして機能します。

セキュリティ・リストを使用して、サブネットのすべてのインバウンド(イングレス)トラフィックとアウトバウンド(エグレス)トラフィックに適用されるルールを定義します。 サブネット当たり最大5つのセキュリティ・リストを関連付けることができます。 ルート表と同様に、デフォルトのセキュリティ・リストと専用のセキュリティ・リストがあります。 より適切に管理および管理するには、サブネットごとに専用のセキュリティ・リストを必ず使用してください。

セキュリティ・リストとは対照的に、NSGでは、インスタンスが異なるサブネットにあっても、インスタンスのグループのルールを作成できます。 たとえば、すべてのデータベース・サーバーまたは特定のアプリケーションを実行しているすべてのアプリケーション・サーバーに同じNSGを適用できます。 セキュリティを特定のサブネットに適用するかわりに、NSGを作成し、適切なインスタンスをNSGに追加します。

セキュリティ・リストまたはNSGを使用する必要はありません。 セキュリティ・リストは、NSGを確立せずに使用することも、セキュリティ・リストを作成せずにNSGを作成することもできます。 ただし、セキュリティ・リストとNSGの両方を使用する場合、VNICに適用されるルールは、VNICのセキュリティ・リストに含まれるルールとNSGからのそのVNICに固有のルールの和集合(両方のセット)になります。

VCNを作成する際、3つのイングレス・ルールと1つのエグレス・ルールを含むデフォルト・セキュリティ・リストが作成されます。 デフォルトのルールはステートフルです。つまり、どの接続であるか、およびリクエストにレスポンスが続いていること、およびルールでこれを考慮に入れる必要があることを意味します。 対照的に、状態に関係なく、すべてのパケットにステートレス・ルールが適用されます。

デフォルトのイングレスおよびエグレス・セキュリティ・ルールは、表示すると次のようになります。 まず、イングレス・ルール(10.0.0.0/16 CIDRブロックの場合): 

Stateless Source       Source Type  IP Protocol Source Port Range Destination Port Range  Type and
                                                                                          Code

No        10.0.0.0/16  CIDR Block   ICMP                                                  3
No        0.0.0.0/0    CIDR Block   ICMP                                                  3, 4
No        0.0.0.0/0    CIDR Block   TCP         22 - 22            22 - 22
これらのルールは、行ごとに次のように読み取ることができます:

  • ICMPプロトコル・タイプ= 3メッセージ形式(宛先に到達できません)およびすべてのコードを使用して、VCN 10.0.0.0/16 CIDRブロックから発生したトラフィックに適用されるステートフル・ルールがあります。 つまり、このルールにより、10.0.0.0/16 CIDRブロック内のデバイスは、任意のコード(NetやHost Unreachableなど)を持つ宛先に到達できないメッセージを、送信者(VCNサブネット内の別のインスタンス)に戻すことができます。

  • ICMPプロトコル・タイプ= 3メッセージ形式(Destination Unreachable)およびコード= 4 (メッセージは断片化されている必要があるが、Do Not Fragment (DF)ビットがパケットに設定されているIPアドレス(0.0.0.0/0 CIDRブロック)から発生するトラフィックに適用されるステートフル・ルールがあります: これらはパスMTU検出メッセージです)。 つまり、このルールでは、コンテンツがこのVCNサブネットに設定されたMTUサイズを超えているため、断片化する必要があるパケットにDFビットが設定されていることをデバイスに通知できます。

  • 接続指向TCPプロトコルおよびソース・ポートまたは宛先ポート= 22 (SSH)を使用して、任意のIPアドレス(0.0.0.0/0 CIDRブロック)から発生するトラフィックに付加されるステートフル・ルールがあります。 つまり、このルールでは、このVCNサブネットのSSHが許可されます。

この最後のルールによって、新しいVCNおよびサブネットを作成し、Linuxインスタンスを起動し、SSHを使用して新しいセキュリティ・リスト・ルールを記述せずにそのインスタンスに接続できます。

重要:

デフォルトのイングレス・セキュリティ・リストには、リモート・デスクトップ・プロトコル(RDP)アクセスを許可するルールは含まれていません。 「Windowsイメージ」を使用している場合は、認可されたソースIPアドレスおよびすべてのソース・ポートから、宛先ポート3389上のTCPトラフィックに対してステートフル・イングレス・ルールを追加してください。 詳細は、「RDPアクセスを有効にするには」を参照してください。

単一のエグレス・ルールは非常にシンプルです:

Stateless Source       Source Type  IP Protocol Source Port Range Destination Port Range  Type and
                                                                                          Code

No        0.0.0.0/0    CIDR Block   All

これは、次のように読み取ることができます: 「送信元アドレスを持つパケット、およびVCNを離れる任意のIPプロトコルを持つパケットを許可するステートフル・ルールがあります。」。 これは基本的に、何も問題なくVCNサブネットから離れる可能性があることを示しています。

デフォルトのセキュリティ・リストには、ステートレス・ルールはありません。 ただし、デフォルトのセキュリティ・リストに対していつでもルールを追加または削除できます。

これらのデフォルト・ルールをNSGで使用するには、デフォルトのイングレスおよびエグレス・ルールにIngress_Security_List_Subnet01やEgress_Security_List_Subnet01などの個別名を付けます。 これらのルールをNSGに追加する前に、まずNSGを作成する必要があります。 NSGを作成するには、名前を付け、既存のコンパートメントに割り当てる必要があります。 タグを追加することもできますが、後で追加できます。