助け合いフォーラム

AWS

AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 30570
問題を開く
パブリックサブネット上のEC2インスタンスで稼働するWebサーバーに対して、インターネットからHTTP(80番ポート)でアクセスできるようにしたい。
以下の状態の時、必要な設定はどれか。(3つ選択)
・インスタンスにはデフォルト設定のセキュリティグループが割り当てられている
・インスタンスが所属するサブネットのネットワークACLは、全ての通信を拒否するように設定されている

正解

セキュリティグループのインバウンドルールに「送信元:0.0.0.0/0」、「ポート範囲:80」、「許可」の設定を追加する

ネットワークACLのインバウンドルールに「送信元:0.0.0.0/0」、「ポート範囲:80」、「許可」の設定を追加する

ネットワークACLのアウトバウンドルールに「宛先:0.0.0.0/0」、「ポート範囲:すべて」、「許可」の設定を追加する

解説

VPCにはネットワークアクセスを制御する機能として「セキュリティグループ」と「ネットワークACL」があります。

[セキュリティグループとネットワークACLのイメージ図]


■セキュリティグループ
VPC上でネットワークアクセスをインスタンスごとに制御するファイアウォールです。設定は許可ルールのみ指定し、拒否ルールは指定できません。デフォルトの設定では、すべてのインバウンド通信(外部から内部への通信)を拒否、すべてのアウトバウンド通信(内部から外部への通信)を許可しているので、インスタンスへのインバウンド通信には許可ルールを設定する必要があります。
セキュリティグループは通信の状態を管理する「ステートフル」なファイアウォールです。インバウンドまたはアウトバウンドで許可されている通信に関連する後続の通信(リクエストに対応するレスポンスなど)は、明示的に許可設定をしなくても通信が許可されます。

■ネットワークACL
VPC上でネットワークアクセスをサブネットごとに制御するファイアウォールです。IPアドレスを元に許可ルールと拒否ルールの両方を設定可能です。ルールはユーザーが付与したルール番号の順番に評価され、ルール間で矛盾がある場合はルール番号が小さい数字のルールが適用されます。デフォルトの設定ではインバウンド通信(外部から内部への通信)、アウトバウンド通信(内部から外部への通信)ともにすべての通信が許可されています。
ネットワークACLは通信の状態を管理しない「ステートレス」なファイアウォールです。通信の関連を考慮しないので、インバウンド/アウトバウンド両方に許可設定が必要になります。例えば、インバウンドで特定のリクエストの受付を許可していても、アウトバウンドでレスポンスの送信を許可していない場合は正常に通信できません。

各選択肢を確認していきます。

・セキュリティグループのインバウンドルールに「送信元:0.0.0.0/0」、「ポート範囲:80」、「許可」の設定を追加する
セキュリティグループのデフォルトの設定では、すべてのインバウンド通信を拒否しているので、許可設定を追加する必要があります。
インターネットからWebサーバーにHTTPでアクセスさせるには、インバウンドルールに「送信元IP:0.0.0.0/0」、「ポート番号:80」、「許可」の設定が必要です。正しい選択肢です。

・ネットワークACLのインバウンドルールに「送信元:0.0.0.0/0」、「ポート範囲:80」、「許可」の設定を追加する
ネットワークACLでは全ての通信を拒否するように設定されているので、インバウンド通信、アウトバウンド通信ともに許可設定を追加する必要があります。
インターネットからWebサーバーにHTTPでアクセスさせるには、インバウンドルールに「送信元IP:0.0.0.0/0」、「ポート番号:80」、「許可」の設定が必要です。正しい選択肢です。

・ネットワークACLのアウトバウンドルールに「宛先:0.0.0.0/0」、「ポート範囲:すべて」、「許可」の設定を追加する
ネットワークACLでは全ての通信を拒否するように設定されているので、インバウンド通信、アウトバウンド通信ともに許可設定を追加する必要があります。アウトバウンド通信が許可されなければ、Webサーバーからレスポンスを送れません。
インターネットからWebサーバーにHTTPでアクセスさせるには、アウトバウンドルールに「宛先IP:0.0.0.0/0」、「ポート番号:すべて」、「許可」の設定が必要です。正しい選択肢です。

・セキュリティグループのアウトバウンドルールに「宛先:0.0.0.0/0」、「ポート範囲:すべて」、「許可」の設定を追加する
セキュリティグループのデフォルトの設定では全てのアウトバウンド通信を許可しているので、アウトバウンドルールに許可設定を追加する必要はありません。誤った選択肢です。

・セキュリティグループのインバウンドルールに「送信元:0.0.0.0/0」、「ポート範囲:すべて」、「拒否」の設定を追加する
セキュリティグループのデフォルトの設定では全てのインバウンド通信を拒否しています。また、セキュリティグループでは拒否設定を追加できません。誤った選択肢です。

・ネットワークACLのインバウンドルールに「送信元:0.0.0.0/0」、「ポート範囲:すべて」、「許可」の設定を追加する
ネットワークACLではインバウンド通信、アウトバウンド通信ともに許可設定を追加する必要がありますが、ポート番号の設定が不適切です。
「ポート番号:80」に指定しなければ、SSHなどHTTP以外の通信ができてしまうので、セキュリティに問題が発生します。誤った選択肢です。

参考

【Amazon VPC(Virtual Private Cloud)】
Amazon VPC(Virtual Private Cloud)は、AWS上で動作する仮想ネットワーク環境を提供するサービスです。VPCでネットワーク空間を作成し、その中にインスタンスなどのAWSリソースを配置します。
VPCは1つのリージョン内に複数作成できます。そして、1つのVPCはリージョン内にある全てのAZにまたがります。VPCで作成されるネットワーク空間は、各VPCが独立しているプライベートネットワークです。そのため、デフォルトでは他のVPCやインターネットと通信できません。

[VPCのイメージ]


【サブネット】
サブネットとは、VPC内のネットワーク空間を論理的に分割したものです。各サブネットは、1つのAZに属し、1つのAZ内に複数のサブネットを作成できます。
サブネットのうち、インターネットゲートウェイへのルーティング設定がある場合は「パブリックサブネット」、ない場合は「プライベートサブネット」といいます。パブリックサブネットには、インターネットから直接アクセスされるAWSリソースを配置します。一方、プライベートサブネットには、インターネットから直接アクセスされないAWSリソースを配置します。

[サブネットのイメージ]


【CIDR(Classless Inter-Domain Routing)ブロック】
CIDR(Classless Inter-Domain Routing)とは、ネットワークの範囲を指定するIPアドレスの設定方法のことです。CIDRはIPアドレスを「172.16.0.100/24」のように表記します。この「/24」をプレフィックス長と言い、IPアドレスとプレフィックス長によって所属するネットワークが決まります。プレフィックス長が「/24」の場合、IPアドレスを2進数表記にした時に左から24ビット目までの範囲がプレフィックスです。プレフィックスに該当するIPアドレスの部分がネットワークアドレスとなり、このネットワークアドレスの範囲を「CIDRブロック」といいます。


[CIDRブロックのイメージ]


VPCを利用するには最初にVPCを作成し、その後にサブネットを作成します。VPCとサブネットの作成時に、それぞれネットワークアドレスの範囲をCIDRブロックで指定します。
VPCの中にサブネットが存在するので、サブネットのCIDRブロックはVPCのCIDRブロックの範囲内で作成する必要があります。(例:VPCが172.16.0.0/18のCIDRブロックで、サブネットが10.0.0.0/22や172.16.0.0/16のCIDRブロックは作成できない。)


[CIDRブロックの設定例]


VPCとサブネットそれぞれに指定したCIDRブロックによって、VPC内のサブネット数と1つのサブネット当たりに利用できるIPアドレス数が決まります。
VPCでは各サブネットCIDRブロック内で、最初の4つのIPアドレスと最後のIPアドレスの合計5つのIPアドレスが予約されています。予約されたIPアドレスはAWSリソースに割り当てることができないため、利用できないIPアドレス分を考慮してCIDRブロックを指定する必要があります。

CIDRブロックが「172.16.0.0/24」の予約IPアドレス(利用できないIPアドレス)
・172.16.0.0 … ネットワークアドレス
・172.16.0.1 … VPCルーター用
・172.16.0.2 … DNSサーバー用
・172.16.0.3 … 将来の利用のためにAWSで予約
・172.16.0.255… ネットワークブロードキャストアドレス

CIDRブロックが「172.16.0.0/18」のVPCに「172.16.0.0/24」のサブネットを作成した場合、VPC内のサブネット数と1つのサブネット当たりに利用できるIPアドレスは、以下のようになります。
・サブネット数 = 2^(サブネットのプレフィックス長 - VPCのプレフィックス長) = 2^(24-18) = 64
・1サブネット当たりのIPアドレス数 = 2^(32 - サブネットのプレフィックス長)-5 = 2^(32-24)-5 = 251

VPCではCIDRブロックのプレフィックス長を/16から/28の間で指定します。AWSは次のプライベートIPv4アドレス範囲から、CIDRブロックを指定することを推奨しています。
・10.0.0.0 ~ 10.255.255.255
・172.16.0.0 ~ 172.31.255.255
・192.168.0.0 ~ 192.168.255.255

【IPアドレスの種類】
○プライベートIPアドレス
プライベートIPアドレスはVPC内でのみ有効なIPアドレスで、VPC内の他のインスタンスや、VPCと接続しているネットワークと通信するために使用します。VPC内のEC2インスタンスなどのAWSリソースには、パブリックサブネット・プライベートサブネットに関係なく、すべてプライベートIPアドレスが自動で割り当てられます。プライベートIPアドレスは、AWSリソースを停止・起動した後も同一のIPアドレスが利用されます。


○パブリックIPアドレス
パブリックIPアドレスはインターネット上で一意のIPアドレスです。パブリックIPアドレスを割り当てられたAWSリソースは、インターネットなどVPC外のネットワークと通信できるようになります。パブリックIPアドレスは、インスタンスをパブリックサブネットに作成するときに自動で割り当てられます。
Elastic IPアドレス(後述)ではないパブリックIPアドレスは、AWSリソースが停止する時にIPアドレスが解放(AWSに返却)され、AWSリソースが起動する時に新規のIPアドレスが割り当てられます。


○Elastic IPアドレス
Elastic IPアドレスは、インターネットと通信可能な固定のパブリックIPアドレスです。Elastic IPアドレスはAWSアカウントと紐づいており、AWSリソースに手動で割り当てます。割り当てたElastic IPアドレスは、AWSリソースが停止・起動してもIPアドレスが変わりません。


Elastic IPアドレスは割り当てたAWSリソースが終了しても同一のIPアドレスが保有されるので、利用料金が発生し続けます。また、保有しているElastic IPアドレスを使用して、同一のIPアドレスを別のAWSリソースに再び割り当てられます。


【ルートテーブル】
VPC内での通信において、どのネットワークへデータを転送するかを定義する機能です。ルートテーブルに従って、送信先ごとに指定したターゲットへデータを転送することを「ルーティング」といいます。VPC内の各サブネットは、1つのルートテーブルを関連付けることができます。ルートテーブルが関連付けられていないサブネットは、VPC全体に適用される「メインルートテーブル」に従ってルーティングが行われます。

【インターネットゲートウェイ】
VPC内のAWSリソースとインターネットを接続する機能です。インターネットゲートウェイへのルーティングが設定されたサブネットは、パブリックサブネットになります。パブリックサブネットでは、インターネットとサブネット両方からの接続開始要求を通します。インターネットゲートウェイは一つのVPCに一つしか作成できないので、複数のパブリックサブネットで共有して利用します。

[インターネットゲートウェイのイメージ]


[インターネットゲートウェイ向けルートテーブルの例]


【NATゲートウェイ】
プライベートサブネットからインターネットへの通信を可能にするIPv4専用の機能です。NAT(Network Address Translation)とは、IPアドレスを別のIPアドレスに変換する機能のことです。プライベートサブネット内にあるAWSリソースのプライベートIPアドレスを、NATゲートウェイのパブリックIPアドレス(Elastic IPアドレス)に変換し、インターネットへ接続します。
NATゲートウェイを利用するには、Elastic IPアドレスを割り当てたNATゲートウェイをパブリックサブネット内に作成し、プライベートサブネットのルートテーブルにターゲットがNATゲートウェイのルーティングを設定します。
NATゲートウェイはプライベートサブネット内リソースからインターネットへの接続開始要求は通しますが、インターネットからプライベートサブネット内リソースへの接続開始要求は通しません。

[NATゲートウェイのイメージ]


[NATゲートウェイ向けルートテーブルの例]


NATゲートウェイはAWSによってAZ内で冗長化されており、NATゲートウェイの機器障害時やトラフィック増加時でも継続して利用できます。ただし、AZに障害が発生した場合には利用できなくなるため、さらに可用性を高める場合は複数のAZにそれぞれNATゲートウェイを配置する必要があります。

【NATインスタンス】
NATゲートウェイと同じく、プライベートサブネットからインターネットへの通信を可能にするIPv4専用の機能です。NATゲートウェイはマネージドサービスなのに対し、NATインスタンスはEC2インスタンスから作成するため、ユーザーが障害対応などの運用管理を実施する必要があります。
NATインスタンスを利用するには、パブリックサブネットにパブリックIPアドレスまたはElastic IPアドレスを割り当てたNATインスタンスを作成した後、プライベートサブネットのルートテーブルにターゲットがNATインスタンスのルーティングを設定します。
NATインスタンスはNATゲートウェイと同じく、プライベートサブネット内リソースからインターネットへの接続開始要求は通しますが、インターネットからプライベートサブネット内リソースへの接続開始要求は通しません。

[NATインスタンスのイメージ]


NATインスタンスは運用管理が必要ですが、NATゲートウェイでは利用できないポート転送機能の設定や、VPC外からプライベートサブネット内へ接続する際の踏み台サーバーとして利用できます。ポート転送とは、インターネットからNATインスタンスの特定のポート番号に接続した時、プライベートサブネット内にあるインスタンスの特定のポートへ転送する機能です。踏み台サーバーとは、例えばインターネットからプライベートサブネット内にあるサーバーの保守をしたい場合に、一旦NATインスタンスへSSH接続をした後、NATインスタンスから目的のサーバーへ再度SSH接続をすることで、VPC外からは直接接続できないプライベートサブネット内のサーバーへの接続を可能にするものです。

【Egress-Onlyインターネットゲートウェイ】
NATゲートウェイとインターネットゲートウェイの特徴を併せ持つIPv6専用の機能です。VPCからインターネットへ(Egress)の接続開始要求は通しますが、インターネットからVPCへ(Ingress)の接続開始要求は通しません。
Egress-Onlyインターネットゲートウェイを利用するには、VPCにEgress-Onlyインターネットゲートウェイを作成し、プライベートサブネットのルートテーブルに、送信先が「::/0(デフォルトルート)」、ターゲットが「Egress-OnlyインターネットゲートウェイID」となるルートを追加します。

[Egress-Onlyインターネットゲートウェイ向けルートテーブルの例]


【ENI(Elastic Network Interface)】
AWSリソースのネットワークインターフェイスです。オンプレミス環境におけるNIC(Network Interface Card)と同じ役割を持ち、VPC内のEC2インスタンスやNATゲートウェイなどに割り当てて利用します。

■Elastic Fabric Adapter (EFA)
Elastic Fabric Adapter (EFA)は、AWSが提供する高性能なネットワークインターフェースで、科学研究、工学、機械学習などの高パフォーマンスを要求する計算タスクに最適です。EFAは特定のEC2インスタンスタイプでのみ利用可能で、これらのインスタンスに接続して使用します。

[EFAの設定画面]



【拡張ネットワーキング(Enhanced Networking)】
拡張ネットワーキング(Enhanced Networking)は、Amazon EC2インスタンスのネットワーク性能を向上させる機能です。インスタンス間での高スループット・低レイテンシーを実現できるため、リアルタイム性が求められるアプリケーションに最適です。さらに、追加料金もかかりません。

【VPCフローログ】
VPC内のENIに流れるネットワークトラフィック情報を出力する機能です。ログはAmazon CloudWatch LogsまたはS3へ保存されます。
VPCフローログには、送信元/送信先IPアドレス、送信元/送信先ポート番号、プロトコル番号、通信の許可/拒否の結果などが記録されます。VPCフローログを利用することでVPC内のリソースが受信した不審な通信や、VPC内のリソースから発信された不要な通信の発見に繋がります。

[VPCフローログの中身]


【VPCエンドポイント】
VPC内のAWSリソースから、S3やDynamoDBなどインターネットから直接利用できるVPC外のAWSサービスへアクセスは、通常インターネットゲートウェイを経由して通信します。VPCエンドポイントは、セキュリティ上の制約でインターネットとの通信が制限されているプライベートサブネット内のAWSリソースから、インターネットゲートウェイを経由せずにVPC外のAWSサービスへアクセス可能にする機能です。

VPCエンドポイントにはゲートウェイ型とAWS PrivateLink(インターフェイス型)の2種類があり、それぞれ利用できるAWSサービスが異なります。

■ゲートウェイ型
S3とDynamoDBで利用できます。S3やDynamoDBへ接続したいリソースが配置されているVPCにVPCエンドポイントを割り当て、ルートテーブルにターゲットがVPCエンドポイントのルーティングを設定します。

[VPCエンドポイント(ゲートウェイ型)でS3やDynamoDBにアクセスする時のイメージ]


[VPCエンドポイント(ゲートウェイ型)向けルートテーブルの例]


■AWS PrivateLink(インターフェイス型)
CloudWatch LogsやS3など多数のサービスで利用できます。サービスへ接続したいリソースが配置されているサブネットにプライベートIPアドレスを持つENIを作成し、ENIとサービスをリンクさせます。

[PrivateLinkでCloudWatch LogsやS3にアクセスする時のイメージ]


【VPCエンドポイントポリシー】
VPCエンドポイントを作成すると、VPC内のリソースはVPCエンドポイントからVPC外のAWSサービスへアクセスできるようになります。VPCエンドポイントからの接続先を制限するには「VPCエンドポイントポリシー」を使用します。VPCエンドポイントポリシーは、VPCエンドポイントのゲートウェイ型とAWS PrivateLink(インターフェイス型)の両方で利用できます。
VPCエンドポイントポリシーを設定するには、許可/拒否する接続先のAmazonリソース名(ARN)を指定します。

[VPCエンドポイントポリシーの設定画面]
下記の設定では、S3バケットの「A-bucket」への通信を許可しています。


【VPCでのセキュリティ】
VPCにはネットワークアクセスを制御する機能として「セキュリティグループ」と「ネットワークACL」があります。

[セキュリティグループとネットワークACLのイメージ図]


■セキュリティグループ
VPC上でネットワークアクセスをインスタンスごとに制御するファイアウォールです。設定は許可ルールのみ指定し、拒否ルールは指定できません。デフォルトの設定では、すべてのインバウンド通信(外部から内部への通信)を拒否、すべてのアウトバウンド通信(内部から外部への通信)を許可しているので、インスタンスへのインバウンド通信には許可ルールを設定する必要があります。
セキュリティグループは通信の状態を管理する「ステートフル」なファイアウォールです。インバウンドまたはアウトバウンドで許可されている通信に関連する後続の通信(リクエストに対応するレスポンスなど)は、明示的に許可設定をしなくても通信が許可されます。
セキュリティグループでは送信元や宛先にIPアドレスの範囲を指定する他、別のセキュリティグループも指定できます。指定したセキュリティグループに所属するインスタンスからの通信を一括して許可できるので、送信元や宛先のインスタンス台数が変化する場合に便利です。

■ネットワークACL
VPC上でネットワークアクセスをサブネットごとに制御するファイアウォールです。IPアドレスを元に許可ルールと拒否ルールの両方を設定可能です。ルールはユーザーが付与したルール番号の順番に評価され、ルール間で矛盾がある場合はルール番号が小さい数字のルールが適用されます。デフォルトの設定ではインバウンド通信、アウトバウンド通信ともにすべての通信が許可されています。
ネットワークACLは通信の状態を管理しない「ステートレス」なファイアウォールです。通信の関連を考慮しないので、インバウンド/アウトバウンド両方に許可設定が必要になります。例えば、インバウンドで特定のリクエストの受付を許可していても、アウトバウンドでレスポンスの送信を許可していない場合は正常に通信できません。

セキュリティグループとネットワークACLには下記の違いがあります。


【AWS Network Firewall】
AWS Network Firewallは、VPC向けのファイアウォール機能を提供するマネージドサービスです。侵入防止システム(IPS)やドメイン名によるトラフィックのフィルタリングなど、セキュリティグループやネットワークACLよりもさらに高度な機能を備えています。
Network Firewallは、VPC上のアウトバウンド及びインバウンド両方のトラフィックを検査できます。インターネット上の特定のドメイン名を含むURLへのアクセスのみを許可したり、特定の送信元からのトラフィック以外は全てブロックするなど、きめ細かな通信の制御が可能です。

Network Firewallは3つのコンポーネントから構成されます。

・ファイアウォール
Network Firewallの本体となるコンポーネントです。ファイアウォールポリシー(後述)に基づきネットワークトラフィックの監視及び制御を行います。
VPCのサブネットに紐づけることで、指定したサブネット内にファイアウォールエンドポイントが作成されます。ネットワークトラフィックはこのエンドポイントを通じてファイアウォールとやりとりをするため、ルートテーブルの設定で、このエンドポイントにトラフィックをルーティングする必要があります。

・ファイアウォールポリシー
ルールグループ(後述)をまとめたものです。ファイアウォールに紐づけることで、実際の動作を定義します。

・ルールグループ
詳細なフィルタリングのルールをまとめたものです。ファイアウォールポリシーに紐づけて使用します。

[プライベートサブネットからインターネットへの通信を制御する場合のイメージ]

プライベートサブネットのルートテーブルでファイアウォールエンドポイントにルーティングし、ファイアウォールサブネットのルートテーブルでNATゲートウェイにルーティングすることで、プライベートサブネットとインターネット間の通信をNetwork Firewallで制御できます。

【VPCの相互接続】
VPCで作成されるネットワーク空間は、各VPCが独立しているプライベートネットワークです。そのため、デフォルトでは他のVPCと通信できません。他のVPCと接続するには「VPCピアリング」または「AWS Transit Gateway」を利用します。

■VPCピアリング
VPC同士を1対1で接続する機能です。同一アカウントのVPC同士や他のAWSアカウントのVPC、異なるリージョンのVPCでも、同一のプライベートネットワーク内に存在しているかのように相互に通信できます。

[VPCピアリングのイメージ]


■AWS Transit Gateway
複数のVPCや複数のオンプレミスネットワークを相互に接続するハブ機能を持つサービスです。VPCピアリングはVPC同士を1対1で接続するサービスなのに対し、Transit Gatewayは複数のVPCを1つのハブで相互に接続できるのでネットワーク経路を簡素化できます。

[VPCピアリングを使用したVPC同士の接続]


[Transit Gatewayを使用したVPC同士の接続]


Transit GatewayはVPC間の他に、AWS Direct ConnectやAWS VPNで接続されたオンプレミスネットワークとも接続できます。AWS Direct ConnectとAWS VPNはともに、オンプレミスなどAWS外のネットワークとAWS内のネットワークをセキュアに接続するサービスです。

【Amazon VPC Lattice】
Amazon VPC Latticeは、複数のVPCやアカウントにまたがるアプリケーション間の通信を簡素化し、一元的に管理するフルマネージドサービスです。HTTP、HTTPS、gRPCなどのアプリケーション層の通信プロトコルをサポートしており、VPC Latticeを介して各アプリケーションを接続できます。さらに、VPC Latticeにはサービスディスカバリー機能が組み込まれており、他のサービスの位置情報(例えば、IPアドレスやポート番号)を動的に検出できます。これにより、マイクロサービスアーキテクチャの複雑なネットワーク構成を効率的に管理することができます。

[VPC Latticeを使用した接続の例]


よく似たサービスとして、AWS Transit Gatewayがあります。Transit Gatewayはネットワークレベルでの接続を提供し、複数のVPCやオンプレミスネットワークを一元的に接続するハブとして機能します。一方、VPC Latticeは主にアプリケーション層での通信管理を提供し、アプリケーション間の通信を最適化します。
上に戻る

ネットワークACLのアウトバウンドルールの「ポート範囲:すべて」の理由

公開日 2024/07/09

回答のうちの1つに
『ネットワークACLのアウトバウンドルールに「宛先:0.0.0.0/0」、「ポート範囲:すべて」、「許可」の設定を追加する』
とありますが、
ポート範囲:80ではない理由はなんでしょうか。

消去法で正解したものの、理屈がよくわかっていません。
初歩的なところで申し訳ないのですが、どなたが教えてください。。。

2024/07/09 09:03

TCPの通信ではサーバ、クライアント双方が特定の「ポート」を使用します。
サーバ側は特定サービス(HTTPなら80、HTTPSなら443とか)がわかっていますが、クライアント側ポートはOSが自動的に割り振るためどのポート番号になるかは特定できません。

https://xtech.nikkei.com/it/pc/article/NPC/20070621/275460/

クライアントソフトも通信の際にはポート番号を利用します。サーバーソフトと異なり、 通信を始める際に、空いている番号をOSが自動で割り当てます。クライアントがサーバーにアクセスしたときに、クライアントのポート番号が伝わります。 そのため、クライアントのポート番号は自動で決めても問題ないのです。

なので、アウトバウンド(=クライアント向け通信)の宛先ポート番号の範囲は「利用可能なすべて」を指定しないといけないんですね。

まぁそういう意味だと、クライアントのIPアドレスも不定なので全てを意味する 0.0.0.0/0 になってるわけですが。


コメント

この返信に対して
コメントを記入できます

この投稿に対して返信しませんか?