ゲームラグ白書 › L5 データセンターのネットワーク機器
DDoS対策の経由・誤検知 DDoS scrubbing latency, false positives
原因ID dc-ddos · 主担当 インフラチーム・ネットワークインフラ · 副担当 ゲーム開発チーム・サーバー開発
図と実験のあるメインページでこのカードを開く →
攻撃を防ぐためにトラフィックをスクラビングセンターに回すと経路が長くなり、正常なユーザーを攻撃と誤認してブロックすることもあります。
なぜ 攻撃の検知後（または常時）、入ってくるトラフィックをスクラビングセンターに迂回 → すると 経路が長くなり、一部の正常なパケットを攻撃と判定 → 画面では 全体のPingが上昇、特定の地域・通信事業者だけ接続不可
- 症状
- 入力遅延, 接続不可・無限ロード, ワープ
- 要因
- 遅延, パケットロス
- 誰に起きるか
- サーバー全体, 特定の地域・ISP
- いつ
- 人が集中したとき, ときどきランダムに
- 担当
- 主担当 インフラチーム・ネットワークインフラ · 副担当 ゲーム開発チーム・サーバー開発
- ゲーム開発チームの対応
- ゲームのトラフィックパターン（ポート、パケットサイズ、毎秒のパケット数）をまとめてインフラチームに共有、UDPパケットは1,200バイト以下に保つ。
- インフラチームの対応
- ゲームのトラフィックパターンに合わせた防御ルール、地域ごとのスクラビング拠点、トンネル区間でTCPのパケットサイズを小さくする（MSSの調整）、地域・通信事業者別の接続失敗率で誤検知を確認。
- 数値の目安
- スクラビング拠点が同じ国にあれば数ms、別の国の拠点を経由すると30〜100ms以上が加わります。通常は入ってくる方向だけが迂回し、サーバーの応答は直接出ていきます。フィルタリング済みのトラフィックをトンネルで戻して受け取る場合は、一度に送れるサイズ（MTU）も小さくなり、大きなパケットだけが消える問題につながることもあります。
- グラフでは
- ある時点から階段状に上昇 · RTT（Ping）、地域・通信事業者別の接続失敗率
- 確認箇所
- 防御機器・サービスの迂回（スクラビング）の開始・終了記録と遮断ログを、RTTのグラフや地域・通信事業者別の接続失敗率と同じ時間軸に並べて確認。問題の地域からmtr・tracerouteで、経路にスクラビング拠点が入っていないか確認
- 該当する場合
- 迂回がオンになった時刻にRTTが一段上がってとどまり、オフになると戻る。または遮断ログに正常なユーザーのアドレスがあり、その地域・通信事業者だけ接続失敗率が上がる
- 該当しない場合
- 迂回・遮断の記録がない時刻にRTTが上がるなら「迂回ルーティング」か「BGPの経路変更・収束」。大きなパケットだけが消えるなら「MTUの不一致（大きなパケットだけ消える）」
- 確認手段
- インフラのツールで確認（ゲームコード不要）
出典
- Maximum transmission unit and maximum segment size Cloudflare
入ってくるトラフィックはフィルタリング後にGREトンネル（MTU 1,476）で転送、出ていく応答はインターネットへ直接（DSR）、TCP MSSは1,436以下に制限することを推奨、合わせないと大きなパケットが破棄されるかフラグメント化される - Azure network round-trip latency statistics Microsoft Azure
拠点の位置ごとの往復遅延の規模：ソウル・釜山地域間8ms、ソウル・東京間30ms、ソウル・シンガポール間68ms
あわせて読みたい原因
同じ層：L5 データセンターのネットワーク機器
同じ症状（入力遅延）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る