導入要件
ホスティング・サーバー事業者向け DDoS 対策
一つのテナントへの攻撃が、ラック全体や仮想化クラスター全体の原因不明の停止につながらないようにします。共有リソース、顧客ごとのポリシー、保護した通信の入口を把握してください。

顧客から見えないホスティングの境界を確認
- 分離した仮想マシンの背後にある共通の制約
- VM を分離してもアップリンク、NIC キュー、ハイパーバイザーの容量が個別になるわけではありません。帯域が小さく見えても、ホストのパケット処理能力が尽きる場合があります。物理インターフェース、ホスト、ゲストの観測を分けます。
- 同じネットワーク上の異なる用途
- VPN、メール、ゲーム、Web サイトでは正規の通信パターンが異なります。一律の規則で過負荷が誤遮断に変わることもあります。対象プレフィックスまたはサービスと、変更承認者を定めてください。
- 再販経路での責任分担
- ホスト事業者、最終顧客、上流事業者がアドレス、経路、対応の別々の部分を担当することがあります。広告の検証、誤検知の報告、復旧連絡を誰が行うか合意します。
フィルター層の運用者を選ぶ
保護付きネットワークサービスはホスティングの境界へ提供できます。適切な機器を持つ事業者は、Defense Fabric のローカルフィルターも検討できます。ソフトウェアライセンス、伝送、テナント向けサービスは別の責任です。
共通の入口を保護
プレフィックスまたは公開エンドポイント、提供帯域、上流保護の範囲を定義します。
管理責任の明確なローカルポリシーを適用
ローカルフィルターが必要なら、サーバー機器、ポート配置、通信分散、選択した規則を検証します。
テナントの利用を確認
対応する用途の実際の接続を試験し、旧ポリシーに戻せる経路を残します。
導入手順の一例です。実際のサービスは見積書と受入記録で定義します。
設計を左右する質問
- 管理された提供と自社フィルターサーバーの制御のどちらが必要ですか?
- ライセンスとトランジットの価格だけでなく運用範囲を比較します。ローカルフィルターには互換機器、保守、観測、合意した対応手順が必要です。
- どの通信が複数のフィルターノードを通過しますか?
- 入口、戻り経路、状態管理の担当、障害時の動作を定義します。ノードやインターフェースを追加するだけでは、ノード喪失時の実用容量は保証されません。
- 運用上、顧客をどう区別しますか?
- 許可されたプレフィックスやエンドポイントと、サービス責任者・ポリシーの対応表を最新に保ちます。障害調査で活用し、共有アドレスや広い規則が一人の顧客だけを示すとは考えないでください。
代表的なホスティング用途を組み合わせて試験
- 共有送信元アドレスを使う用途も含め、実際に販売するサービスの成功した接続を記録します。
- 同じ時間帯にホストキュー、ドロップ、規則カウンター、アプリケーション成功を観測します。
- 合意したポリシー切り戻しと予備経路を試験し、無関係のテナントがサービスを維持できるか確認します。
この導入に関する質問
Defense Fabric ライセンスに保護付きトランジットとサーバーは含まれますか?
いいえ。互換ハードウェア、ホスティング、伝送は別途予算が必要です。任意の Peeryx ネットワークサービスも独立した項目になります。
一つのゲームプロファイルで全アプリケーションを保護できますか?
いいえ。実際のプロトコルに対応する文書化済み機能を使い、正規トラフィックを試験してください。FiveM と Minecraft Java の提供には、それぞれ互換性確認が必要です。