Security Groups — トラブルシューティング

このドキュメントでは、Security Groups の使用時によく発生する問題と解決方法をまとめています。

問題 1: ルールを追加したがトラフィックがブロックされる

症状: 特定のポートまたはプロトコルに対して Allow ルールを作成したが、リソースへの（またはリソースからの）接続が成功しない。

よくある原因: Security Group が対象リソースにアタッチされていない、またはリソースが別の Security Group を使用している。

解決方法:

リソースの設定ページ（例：仮想サーバーの詳細ページ）にアクセスします。
ネットワーク設定のセクションで Security Groups の項目を確認し、ルールを設定した Security Group がアタッチ済みの一覧に表示されているか確認します。
アタッチされていない場合は、リソースの設定ページから Security Group を追加します。
リソースに複数の Security Group が使用されている場合は、別の Security Group に Deny ルールがあって上書きしていないか確認します。

症状: Delete をクリックするとエラーメッセージが表示され、削除操作を実行できない。

原因: Security Group が 1 つまたは複数のリソースにアタッチされています。ネットワーク接続の中断を防ぐため、使用中の Security Group の削除はシステムによって許可されていません。

解決方法:

注意: Security Group をリソースからデタッチする際は、ネットワーク接続が失われないよう、そのリソースに別の適切な Security Group が少なくとも 1 つ残っていることを確認してください。

症状: Allow ルールが正常に作成され（ステータスが Active）、Security Group もリソースにアタッチ済みだが、接続が失敗する。

よくある原因: 方向（Inbound/Outbound）が違う、プロトコルが違う、またはポートが違う。

解決方法:

トラフィックの方向を確認: リソースへの接続には Inbound rule タブのルールが必要です。リソースからの送信には Outbound rule タブのルールが必要です。ルールが正しいタブに設定されているか確認してください。
Protocol を確認: ルールのプロトコル（TCP、UDP、ICMP）が実際のトラフィックの種類と一致しているか確認します。例えば、DNS は通常 TCP ではなく UDP のポート 53 を使用します。
Port range を確認: ルールのポートが、サービスが実際にリッスンしているポートをカバーしているか確認します。例えば、アプリケーションがポート 8080 で動作している場合、ルールは 80 ではなく 8080 を開放する必要があります。
IP type を確認: 接続が IPv6 アドレスを使用している場合、IP type が IPv6 のルールが必要です。IPv4 ルールは IPv6 トラフィックには適用されません。
Sources / CIDR を確認: 接続元の IP アドレスがルールで指定した CIDR 範囲内にあるか確認します。CIDR が原因かどうかわからない場合は、一時的に 0.0.0.0/0 を設定して問題を切り分けてください。

症状: Security Group またはルールを作成、更新、または削除した後、ステータスが長時間（数分以上）Pending のまま Active に移行しない。

原因: インフラ側でシステムが操作を処理しているか、ネットワークサービスで一時的な障害が発生しています。

解決方法:

1〜2 分後にページを再読み込み（F5）してステータスが更新されているか確認します。
5 分経過してもステータスが Pending のままであれば、操作を再試行します（例：ルールを再保存する、または Security Group を削除して再作成する）。
FPT Cloud のお知らせページにシステム障害の通知がないか確認します。
15 分経過しても問題が解決しない場合は、Security Group 名、VPC ID、および問題が発生し始めた時刻を添えて FPT Cloud テクニカルサポートにお問い合わせください。