セキュリティ・ルール
ネットワーキング・サービスには、パケット・レベルでトラフィックを制御するためにセキュリティ・ルールを使用する2つの仮想ファイアウォール機能が用意されています。2つの機能は:
- セキュリティ・リスト: ネットワーキング・サービスによる元の仮想ファイアウォール機能。
- ネットワーク・セキュリティ・グループ(NSG): 異なるセキュリティ体制を持つアプリケーション・コンポーネント用に設計された後続の機能。NSGは特定のサービスに対してのみサポートされます。
これらの2つの機能は、仮想クラウド・ネットワーク(VCN)内の仮想ネットワーク・インタフェース・カード(VNIC)のセットにセキュリティ・ルールを適用する様々な方法を提供します。
このトピックでは、2つの機能の基本的な相違点について説明します。また、理解しておく必要のある、重要なセキュリティ・ルールの概念についても説明します。セキュリティ・ルールの作成、管理および適用方法は、セキュリティ・リストとネットワーク・セキュリティ・グループでは異なります。実装の詳細は、次の関連トピックを参照してください:
セキュリティ・リストとネットワーク・セキュリティ・グループの比較
セキュリティ・リストを使用すると、サブネット全体のすべてのVNICに適用されるセキュリティ・ルールのセットを定義できます。特定のサブネットで指定のセキュリティ・リストを使用するには、サブネットの作成中または作成後に、そのサブネットにセキュリティ・リストを関連付けます。サブネットは、最大5つのセキュリティ・リストに関連付けることができます。そのサブネットに作成されるVNICはすべて、そのサブネットに関連付けられているセキュリティ・リストの対象となります。
ネットワーク・セキュリティ・グループ(NSG)を使用すると、選択したVNICのグループ(またはVNICのロード・バランサやDBシステムなどの親リソース)に適用されるセキュリティ・ルールのセットを定義できます。たとえば、すべて同じセキュリティ体制を持つコンピュート・インスタンスのセットに属するVNICです。指定したNSGを使用するには、目的のVNICをグループに追加します。そのグループに追加されたVNICは、すべてそのグループのセキュリティ・ルールの対象となります。VNICは、最大5つのNSGに追加できます。
次の表に、相違点をまとめます。
セキュリティ・ツール | 適用先 | 有効にするには | 制限事項 |
---|---|---|---|
セキュリティ・リスト | そのセキュリティ・リストを使用するサブネット内のすべてのVNIC | セキュリティ・リストとサブネットの関連付け | サブネット当たり最大5つのセキュリティ・リスト |
ネットワーク・セキュリティ・グループ | 同じVCNで選択されたVNIC | NSGへの特定のVNICの追加 | VNIC当たり最大5つのNSG |
NSGでは、VCNのサブネット・アーキテクチャをアプリケーションのセキュリティ要件から分離できるため、セキュリティ・リストのかわりにNSGを使用することをお薦めします。
ただし、必要であれば、セキュリティ・リストとNSGを両方とも使用できます。詳細は、セキュリティ・リストとネットワーク・セキュリティ・グループの両方を使用する場合を参照してください。
VNICと親リソースについて
VNICは、ネットワーキング・サービス・コンポーネントであり、コンピュート・インスタンスなどのネットワーク・リソースが仮想クラウド・ネットワーク(VCN)に接続できるようにします。VNICは、インスタンスがVCNの内外のエンドポイントと接続する方法を決定します。各VNICは、VCN内のサブネットに存在します。
コンピュート・インスタンスを作成すると、そのインスタンスのサブネット内のインスタンスにVNICが自動的に作成されます。インスタンスは、VNICの親リソースとみなされます。コンピュート・インスタンスに別の(セカンダリ) VNICを追加できます。このため、インスタンスのVNICは、コンピュート・インスタンスの関連リソースの一部として、コンソールに目立つように表示されます。
他にも、VNICが自動的に作成される、ユーザーが作成可能な親リソースのタイプがあります。たとえば、ロード・バランサを作成すると、ロード・バランサ・サービスによって、バックエンド・セット間のトラフィックを分散するためにVNICが自動的に作成されます。また、DBシステムを作成すると、データベース・サービスによって、DBシステム・ノードとしてVNICが自動的に作成されます。これらのサービスにより、VNICが作成および管理されます。そのため、これらのVNICは、コンピュート・インスタンスのVNICと同じようにわかりやすくコンソール内に表示されません。
NSGを使用するには、選択したVNICをグループに配置します。ただし、VNIC自体ではなく、グループにVNICを追加する場合、通常は親リソースを使用します。たとえば、コンピュート・インスタンスを作成するときに、オプションでそのインスタンスにNSGを指定できます。概念的にはインスタンスをグループに配置しますが、実際にはインスタンスのプライマリVNICをネットワーク・セキュリティ・グループに配置します。グループのセキュリティ・ルールは、インスタンスではなくVNICに適用されます。また、セカンダリVNICをインスタンスに追加する場合、オプションでそのVNICにNSGを指定でき、ルールはインスタンスではなくそのVNICに適用されます。指定されたNSG内のすべてのVNICが、そのNSGが属するVCN内にある必要があります。
同様に、ネットワーク・セキュリティ・グループにロード・バランサを配置する場合、概念的にはロード・バランサをグループに配置します。ただし、実際にはロード・バランサ・サービスによって管理されるVNICをネットワーク・セキュリティ・グループに配置しています。
NSGのVNICメンバーシップは親リソースで管理し、NSG自体では管理しません。つまり、親リソースをNSGに追加するには、(親リソースを追加するNSGを指定することで)親リソースに対してアクションを実行します。(NSGに追加するVNICまたは親リソースを指定することで) NSGに対してアクションを実行しません。同様に、VNICをNSGから削除するには、NSGではなく親リソースを更新してそのアクションを実行します。たとえば、既存のコンピュート・インスタンスのVNICをNSGに追加するには、VNICのプロパティを更新してNSGを指定します。たとえば、REST APIを使用して、UpdateVnic
をコールします。コンソールで、インスタンスおよび目的のVNICを表示し、そこでVNICのプロパティを編集します。
NSGの使用をサポートする親リソースのリストについては、ネットワーク・セキュリティ・グループのサポートを参照してください。
ルールのソースまたは宛先としてのネットワーク・セキュリティ・グループ
セキュリティ・リストと比較して、NSGのセキュリティ・ルールを記述する方法には、重要な違いがあります。
NSGのルールを記述する場合、トラフィックのソース(イングレス・ルールの場合)またはトラフィックの宛先(エグレス・ルールの場合)としてNSGを指定できます。これとは対照的に、セキュリティ・リスト・ルールでは、ソースまたは宛先としてCIDRを指定します。
NSGを指定できるため、2つの異なるNSG間のトラフィックを制御するルールを容易に記述できます。各NSGは同じVCN内にある必要があります。
また、特定のNSGにあるVNIC間のトラフィックを制御する場合は、ルール独自のNSGをソース(イングレス・ルールの場合)または宛先(エグレス・ルールの場合)として指定するルールを記述できます。
詳細は、ネットワーク・セキュリティ・グループの概要を参照してください。
REST APIの相違点
セキュリティ・リストと比較して、NSGのREST APIモデルにはいくつかの基本的な違いがあります。詳細は、APIの使用を参照してください。
デフォルト・ルール
VCNには、ネットワーキング・サービスの使用を開始する際に役立つデフォルトのセキュリティ・ルールがいくつか含まれているデフォルト・セキュリティ・リストが自動的に付属しています。サブネットを作成するとき、VCNですでに作成したカスタム・セキュリティ・リストを指定しないかぎり、デフォルト・セキュリティ・リストがサブネットに関連付けられます。
比較すると、VCNにはデフォルトのネットワーク・セキュリティ・グループはありません。
制限
2つの機能の制限は異なります。適用可能な制限の一覧と制限の引上げをリクエストする手順は、「サービス制限」を参照してください。
リソース |
スコープ |
Oracle Universal Credits |
Pay As You Goまたはトライアル |
---|---|---|---|
セキュリティ・リスト | VCN | 300 | 300 |
セキュリティ・リスト | サブネット | 5* | 5* |
セキュリティ・ルール | セキュリティ・リスト |
200イングレス・ルール* および 200エグレス・ルール* |
200イングレス・ルール* および 200エグレス・ルール* |
* このリソースの制限を増やすことはできません |
リソース | スコープ | Oracle Universal Credits | Pay As You Goまたはトライアル |
---|---|---|---|
ネットワーク・セキュリティ・グループ | VCN | 1000 | 1000 |
VNIC | ネットワーク・セキュリティ・グループ |
特定のネットワーク・セキュリティ・グループには、VCN内と同じ数のVNICを含めることができます。 特定のVNICは、最大5つのネットワーク・セキュリティ・グループに属することができます。* |
特定のネットワーク・セキュリティ・グループには、VCN内と同じ数のVNICを含めることができます。 特定のVNICは、最大5つのネットワーク・セキュリティ・グループに属することができます。* |
セキュリティ・ルール | ネットワーク・セキュリティ・グループ |
120 (イングレスとエグレスの合計) |
120 (イングレスとエグレスの合計) |
* このリソースの制限を増やすことはできません |
セキュリティ・ルールのベスト・プラクティス
ネットワーク・セキュリティ・グループを使用します
すべて同じセキュリティ体制を持つコンポーネントにはNSGを使用することをお薦めします。たとえば、複数層アーキテクチャでは、各層に対して個別のNSGを使用します。指定された層のVNICは、すべてその層のNSGに属します。特定の層内に、追加の特別なセキュリティ要件を持つ層のVNICの特定のサブセットが存在する可能性があります。そのため、これらの追加ルールに対して別のNSGを作成し、VNICのサブセットを層のNSGと追加のNSGの両方に配置します。
Oracleでは、将来の拡張機能を実装するときに、セキュリティ・リストよりもNSGを優先する予定のため、NSGの使用が推奨されます。
デフォルト・セキュリティ・リストのルールを理解します
VCNには、ネットワーキング・サービスの使用を開始する際に役立つデフォルトのセキュリティ・ルールがいくつか含まれているデフォルト・セキュリティ・リストが自動的に付属しています。これらのルールは、基本的な接続を可能にするために存在します。セキュリティ・リストやデフォルト・セキュリティ・リストを使用しない場合でも、ネットワーク接続されたクラウド・リソースが必要とするトラフィックのタイプをよく理解できるように、ルールに精通してください。このようなルールは、NSGで、または設定したカスタム・セキュリティ・リストで使用できます。
デフォルト・セキュリティ・リストには、pingを有効にするルールは含まれていません。pingを使用する必要がある場合は、Pingを有効化するルールを参照してください。
デフォルト・セキュリティ・ルールを無計画に削除しないでください
VCNに、デフォルト・セキュリティ・リストをデフォルトで使用するサブネットがある場合があります。最初にVCNのリソースでそれらが必要でないことを確認した場合を除き、リストのデフォルト・セキュリティ・ルールは削除しないでください。そうしないと、VCNの接続が中断されることがあります。
OSファイアウォール・ルールがセキュリティ・ルールと一致することを確認します
プラットフォーム・イメージを実行しているインスタンスには、そのインスタンスへのアクセスを制御するOSファイアウォール・ルールもあります。インスタンスへのアクセスのトラブルシューティングを行う場合は、次の項目がすべて正しく設定されていることを確認してください:
- インスタンスが存在するネットワーク・セキュリティ・グループ内のルール
- インスタンスのサブネットに関連付けられているセキュリティ・リスト内のルール
- インスタンスのOSファイアウォール・ルール
インスタンスでOracle Autonomous Linux 8.x、Oracle Autonomous Linux 7、Oracle Linux 8、Oracle Linux 7またはOracle Linux Cloud Developer 8を実行している場合は、firewalldを使用してiptablesルールを操作する必要があります。参照用に、ポート(この例では1521)をオープンするためのコマンドを次に示します:
sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
sudo firewall-cmd --reload
ISCSIブート・ボリュームを持つインスタンスでは、前述の--reload
コマンドで問題が発生することがあります。詳細および回避策については、firewall-cmd --reloadの実行後にインスタンスでシステム・ハングが発生しますを参照してください。
セキュリティ・ルールのためにドロップされたパケットのトラブルシューティングにはVNICメトリックを使用します
ネットワーキング・サービスはVNICのメトリックを提供し、それがVNICトラフィックのレベル(パケットおよびバイト)を示します。2つのメトリックは、セキュリティ・ルールに違反してドロップされるイングレス・パケットおよびエグレス・パケット用です。これらのメトリックを使用すると、セキュリティ・ルールに関連する問題をトラブルシューティングしたり、VNICが目的のトラフィックを受信するかどうかをトラブルシューティングするのに役立ちます。
セキュリティ・リストとネットワーク・セキュリティ・グループの両方を使用する場合
セキュリティ・リストのみ、ネットワーク・セキュリティ・グループのみ、またはその両方を使用できます。これは、特定のセキュリティ・ニーズに依存します。
VCN内のすべてのVNICに適用するセキュリティ・ルールがある場合: 最も簡単な解決策は、ルールを1つのセキュリティ・リストに配置し、そのセキュリティ・リストをVCN内のすべてのサブネットに関連付けることです。これにより、組織内の誰がVCNでVNICを作成するかに関係なく、ルールを確実に適用できます。必要に応じて、VCNのデフォルト・セキュリティ・リストを使用できます。このリストは、VCNに自動的に付属しており、デフォルトで一連の必須ルールが含まれています。
セキュリティ・リストとネットワーク・セキュリティ・グループの両方を使用する場合、特定のVNICに適用される一連のルールは次のアイテムを結合したものになります:
- VNICのサブネットに関連付けられているセキュリティ・リスト内のセキュリティ・ルール
- VNICが存在するすべてのNSGのセキュリティ・ルール
次の図は、この概念を簡単に説明したものです。
関連するいずれかのリストおよびグループのルールでトラフィックを許可する場合(またはトラフィックが既存のトラッキング対象の接続の一部である場合)、目的のパケットは許可されます。同じトラフィックをカバーするステートフル・ルールとステートレス・ルールの両方がリストに含まれる場合は注意が必要です。詳細は、ステートフル・ルールとステートレス・ルールを参照してください。
セキュリティ・ルールの構成要素
セキュリティ・ルールにより、VNIC内外の特定タイプのトラフィックを許可できます。たとえば、一般的に使用されるセキュリティ・ルールでは、インスタンス(具体的にはインスタンスのVNIC)へのSSH接続を確立するためにTCPポート22のイングレス・トラフィックを許可します。セキュリティ・ルールを使用しない場合、VCNのVNIC内外のトラフィックは許可されません。
169.254.0.0/16 CIDRブロックを含むトラフィックに対しては、セキュリティ・ルールは適用されません。これには、iSCSIやインスタンス・メタデータなどのサービスが含まれます。
各セキュリティ・ルールは次の項目を指定します:
- 方向(イングレスまたはエグレス): イングレスはVNICへのインバウンド・トラフィックで、エグレスはVNICからのアウトバウンド・トラフィックです。セキュリティ・リスト用のREST APIモデルは、ネットワーク・セキュリティ・グループとは異なります。セキュリティ・リストには、
IngressSecurityRule
オブジェクトと個別のEgressSecurityRule
オブジェクトがあります。ネットワーク・セキュリティ・グループには、SecurityRule
オブジェクトのみが存在し、オブジェクトのdirection
属性によって、ルールがイングレス・トラフィック用かエグレス・トラフィック用かが決定されます。 - ステートフルまたはステートレス: ステートフルの場合は、ルールに一致するトラフィックに接続トラッキングが使用されます。ステートレスの場合、接続トラッキングは使用されません。ステートフル・ルールとステートレス・ルールを参照してください。
-
ソース・タイプおよびソース(イングレス・ルールのみ): イングレス・ルールに対して指定するソースは、選択したソース・タイプによって異なります。
許可されるソース・タイプソース・タイプ 許可されるソース CIDR トラフィックの発生元のCIDRブロック。0.0.0.0/0を使用して、すべてのIPアドレスを指定します。接頭辞が必要です(たとえば、個々のIPアドレスを指定する場合は/32を含めます)。 ネットワーク・セキュリティ・グループ このルールのNSGと同じVCN内にあるNSG。
このソース・タイプは、ルールがNSGに属し、セキュリティ・リストには属していない場合にのみ使用できます。
サービス サービス・ゲートウェイを介してOracleサービスから受信するパケットのみ。サービス・ゲートウェイがVCNに存在しない場合、OSNエンドポイントのパブリックIPからのトラフィックは、NATゲートウェイまたはインターネット・ゲートウェイを介してVCNにルーティングできます。トラフィックは引き続きOCIバックボーンを通過してVCNに到達します。
ソース・サービスは、目的のサービスCIDRラベルです。
-
宛先タイプおよび宛先(エグレス・ルールのみ): エグレス・ルールに対して指定する宛先は、選択した宛先タイプによって異なります。
許可される宛先タイプ宛先タイプ 許可される宛先 CIDR トラフィックの宛先になるCIDRブロック。0.0.0.0/0を使用して、すべてのIPアドレスを指定します。接頭辞が必要です(たとえば、個々のIPアドレスを指定する場合は/32を含めます)。 ネットワーク・セキュリティ・グループ このルールのNSGと同じVCN内にあるNSG。
この宛先タイプは、ルールがNSGに属し、セキュリティ・リストには属していない場合にのみ使用できます。
サービス サービス・ゲートウェイを介してOracleサービス(オブジェクト・ストレージなど)に送信されるパケットのみ。サービス・ゲートウェイがVCNに存在しない場合、OSNエンドポイントのパブリックIPを宛先とするトラフィックは、NATゲートウェイまたはインターネット・ゲートウェイを介してOSNにルーティングできます。サービス・ゲートウェイを介したルーティングでは、トラフィックをルーティングするOracle Services Network (OSN)エンドポイントを選択できます(「オブジェクト・ストレージのみ」または「すべてのサービス」から選択)。
宛先サービスは、目的のOSNサービスCIDRラベルです。
- IPプロトコル: 単一のIPv4プロトコル、またはすべてのプロトコルをカバーする場合は「all」。
- ソース・ポート: トラフィックの発生元のポート。TCPまたはUDPの場合、すべてのソース・ポートを指定するか、オプションで単一のソース・ポート番号または範囲を指定できます。
- 宛先ポート: トラフィックの宛先のポート。TCPまたはUDPの場合、すべての宛先ポートを指定するか、オプションで単一の宛先ポート番号または範囲を指定できます。
- ICMPタイプおよびコード: ICMPの場合、すべてのタイプおよびコードを指定できます。または、オプションで単一のICMPタイプとオプション・コードを指定できます。タイプに複数のコードがある場合は、許可するコードごとに別々のルールを作成します。
- 説明(NSGルールのみ): NSGセキュリティ・ルールには、ルールのわかりやすい説明を指定できるオプションの属性が含まれます。これは現在、セキュリティ・リスト・ルールではサポートされていません。
セキュリティ・ルールの例については、ネットワーキング・シナリオを参照してください。
使用できるルールの数の制限については、セキュリティ・リストとネットワーク・セキュリティ・グループの比較を参照してください。
NSGを使用していて、同じVCN内の2つのVNICがパブリックIPアドレスを使用して通信する必要がある場合、VNICのパブリックIPアドレスを使用する必要があります。関連するセキュリティ・ルールのソース(イングレスの場合)または宛先(エグレスの場合)として、VNICのNSGを使用しないでください。パケットはVCNのインターネット・ゲートウェイにルーティングされ、その時点ではVNICのNSG情報は使用できません。そのため、ソースまたは宛先としてNSGを指定するセキュリティ・ルールは、特定タイプのトラフィックを許可する場合に無効になります。
ステートフル・ルールとステートレス・ルール
セキュリティ・ルールを作成する際には、ステートフルとステートレスのどちらにするかを選択します。その違いについては、次の項で説明します。デフォルトはステートフルです。インターネットに接続するWebサイト(HTTP/HTTPSトラフィック用)が大量に存在する場合は、ステートレス・ルールをお薦めします。
この項では、特にコンピュート・インスタンスとそのトラフィックについて説明します。ただし、その説明はVNICを含むすべてのタイプのリソースに適用されます。セキュリティ・リストとネットワーク・セキュリティ・グループの比較を参照してください。
ステートフル・ルール
セキュリティ・ルールをステートフルとしてマークすることは、そのルールに一致するトラフィックに対して接続トラッキングを使用することを示します。これは、インスタンスがステートフル・イングレス・ルールに一致するトラフィックを受け取ると、インスタンスに適用されるエグレス・ルールに関係なく、レスポンスがトラッキングされ、元のホストに自動的に戻されることを意味します。また、インスタンスがステートフル・エグレス・ルールに一致するトラフィックを送信すると、イングレス・ルールに関係なく、受信レスポンスが自動的に許可されます。
たとえば、ホストBからHTTPトラフィックを受信して応答する必要があるインスタンス(インスタンスA)に対して、ステートフル・イングレス・セキュリティ・ルールを設定できます。ホストBは、インスタンスかどうかにかかわらず、任意のホストです。ステートフル・イングレス・ルールにより、任意のソースIPアドレス(0.0.0.0/0)から宛先ポート80のみ(TCPプロトコル)へのトラフィックが許可されているため、インスタンスAとホストBは通信を行います。レスポンスは自動的にトラッキングおよび許可されるため、レスポンス・トラフィックを許可するエグレス・ルールは必要ありません。
ステートフル・ルールは、各コンピュート・インスタンスの接続トラッキング表に情報を格納します。その表のサイズは、使用されているコンピュート・シェイプに固有です(「接続トラッキング」のサービス制限ページを参照)。接続トラッキング表が一杯になると、新しい状態情報を追加できず、新しい接続ではパケット損失が発生します。コンピュート・シェイプを大きくすると、表が大きくなりますが、ステートフル・ルールの使用時にパケット損失を防ぐには十分でない場合があります。
サブネットのトラフィック量が多い場合、Oracleではステートフル・ルールではなくステートレス・ルールを使用することをお薦めします。
ステートレス・ルール
次の図は、インスタンスAとホストBを前のように示していますが、ステートレス・セキュリティ・ルールが使用されています。前の項のステートフル・ルールと同様に、ステートレス・イングレス・ルールでは、宛先ポート80のみで、すべてのIPアドレスおよび任意のポートからの(TCPプロトコルを使用した)トラフィックが許可されます。レスポンス・トラフィックを許可するには、対応するステートレス・エグレス・ルールが必要です。このルールでは、ソース・ポート80のみから任意の宛先IPアドレス(0.0.0.0/0)および任意のポートへの(TCPプロトコルを使用した)トラフィックを許可します。
インスタンスAがHTTPトラフィックを開始してレスポンスを取得する必要がある場合は、別のステートレス・ルールのセットが必要です。次の図に示すように、エグレス・ルールには、ソース・ポート = allおよび宛先ポート = 80 (HTTP)が含まれます。イングレス・ルールには、ソース・ポート80および宛先ポート = allが含まれます。
インスタンスAでポート・バインディングを使用してHTTPトラフィックの発生元のポートを正確に指定する場合は、エグレス・ルールのソース・ポートおよびイングレス・ルールの宛先ポートとしてそれを指定できます。
なんらかの理由でステートフル・ルールとステートレス・ルールの両方を使用し、特定の方向(イングレスなど)でステートフル・ルールとステートレス・ルールの両方に一致するトラフィックがある場合は、ステートレス・ルールが優先され、接続はトラッキングされません。レスポンス・トラフィックを許可するには、他の方向(たとえば、ステートレスまたはステートフルのエグレス)に対応するルールが必要です。
ステートフル・ルールの接続トラッキングの詳細
Oracleは接続トラッキングを使用して、ステートフル・ルールと一致するトラフィックに対するレスポンスを許可します(ステートフル・ルールとステートレス・ルールを参照)。各インスタンスには、インスタンスのシェイプに基づいてトラッキングできる同時接続の最大数があります。
TCP、UDPおよびICMPのレスポンス・トラフィックを特定するために、Oracleはパケットについて次の項目の接続トラッキングを実行します:
- プロトコル
- ソースおよび宛先のIPアドレス
- ソースおよび宛先のポート(TCPおよびUDPの場合のみ)
その他のプロトコルについては、OracleはプロトコルとIPアドレスのみをトラッキングし、ポートはトラッキングしません。つまり、インスタンスが別のホストへのトラフィックを開始し、そのトラフィックがエグレス・セキュリティ・ルールによって許可される場合、その後インスタンスがそのホストから受信する一定期間のトラフィックは、レスポンス・トラフィックとみなされ、許可されます。
追跡された接続は、接続のトラフィックが受信されるかぎり保持されます。接続が長時間アイドル状態になると、タイムアウトして削除されます。削除されると、ステートフル・セキュリティ・ルールのレスポンスは削除されます。次の表に、デフォルトのアイドル・タイムアウトを示します:
プロトコル | 状態 | アイドル・タイムアウト |
---|---|---|
TCP | 確立済 | 1日 |
TCP | 設定 | 1分 |
TCP | クローズ | 2分 |
UDP | 確立済(パケットが両方向で受信されたことを意味します) | 3分 |
UDP | 未確立(パケットは一方向のみで受信) | 30秒 |
ICMP | N/A | 15秒 |
その他 | N/A | 5分 |
ステートレス・ルールでのPath MTU Discoveryメッセージの有効化
ステートレス・セキュリティ・ルールを使用してVCN外部のエンドポイント間のトラフィックを許可する場合、ソース0.0.0.0/0および任意のソース・ポートからのイングレスICMPトラフィック・タイプ3のコード4を許可するセキュリティ・ルールを追加することが重要です。このルールを使用すると、インスタンスでPath MTU Discoveryのフラグメンテーション・メッセージを受信できます。このルールは、インスタンスとの接続を確立するために重要です。これがない場合、接続性の問題が発生する可能性があります。詳細は、接続のハングを参照してください。
Pingを有効化するルール
VCNのデフォルト・セキュリティ・リストには、いくつかのデフォルトのルールが含まれていますが、pingリクエストを許可するルールは含まれていません。インスタンスをpingする場合は、インスタンスの適用可能なセキュリティ・リストまたはNSGに追加のステートフル・イングレス・ルールが含まれていることを確認して、ping元となる予定のソース・ネットワークからのICMPトラフィック・タイプ8を明確に許可してください。インターネットからのpingアクセスを許可するには、ソースとして0.0.0.0/0を使用します。pingのこのルールは、デフォルト・セキュリティ・リストにあるデフォルトのICMP関連ルールとは別です。これらのルールは削除しないでください。
断片化されたUDPパケットを処理するルール
インスタンスはUDPトラフィックを送受信できます。接続のUDPパケットが大きすぎる場合は、断片化されます。ただし、パケットの最初のフラグメントにのみ、プロトコルとポートの情報が含まれます。このイングレス・トラフィックまたはエグレス・トラフィックを許可するセキュリティ・ルールで特定のポート番号(ソースまたは宛先)を指定すると、最初のもの以降のフラグメントが削除されます。インスタンスで大規模なUDPパケットを送受信する場合は、適用可能なセキュリティ・ルールのソース・ポートと宛先ポートの両方をALLに設定します(特定のポート番号は使用しません)。