Left 4 Dead 2 サーバーを DDoS 攻撃から守る

Left 4 Dead 2 サーバーが落ちるのは、めったに都合のよい時間帯ではありません。落ちるのはキャンペーンの最後のチャプター、Versus マッチの 2 ラウンド目、あるいは BAN されたプレイヤーが 3 回目に弾かれたちょうどその瞬間です。いま撃たれている人に必要なのは、ネットワーク技術の原則論ではなく、手順の順序です。本記事ではまず、Left 4 Dead 2 サーバーを DDoS 攻撃から守る方法のうち手元の機能でまだできる範囲を示し、次にその手立てが物理的にどこで終わるかを示し、最後にその手前のネットワークで何が起きる必要があるかを説明します。

本記事の記述はすべて、SteamCMD のアプリケーション ID 222860 でインストールした専用サーバー（srcds）を Debian 12、Debian 13、Ubuntu 22.04 LTS、Ubuntu 24.04 LTS 上で動かす場合を前提としています。コマンドは root 向けに書かれているため、一般ユーザーの場合は先頭に sudo を付けてください。順序を決める点を先に 1 つ挙げます。攻撃がいま進行中の場合は、手当たり次第に設定を変えないでください。そして測定値を保存する前にサーバーを再起動しないでください。攻撃が終わってからでは、もう残っていません。

Left 4 Dead 2 サーバーが DDoS 攻撃の標的として狙われる理由

64 人規模のシューターとの違いは、1 試合の人数です。協力キャンペーンには生存者用の 4 スロット、Versus マッチには両陣営を合わせて 8 スロットしかありません。そのため障害が当たるのは個々のプレイヤーではなく、常に試合全体です。5 チャプターのうち 3 番目でキャンペーンが中断すれば、参加者全員のその晩が終わります。これが攻撃を仕掛ける側にとって魅力的な理由です。技術も、まとまった金額も必要ないのに、相手側では 1 時間分のプレイ時間が失われます。

加えて構造上の理由があります。Left 4 Dead 2 は Source エンジンで動き、Source のサーバーは IP アドレスとポートで公開されていて誰でも見つけられます。これは前提であって、手違いではありません。問い合わせに応答しないサーバーはどのリストにも載らず、どのロビーからも見つけてもらえません。つまり問題は、攻撃側がご自身のアドレスを知っているかどうかではなく、そこを撃たれたときに何が起きるかだけです。ゲームトラフィックは UDP で流れ、UDP には要求できるような接続確立の手順がなく、しかも送信元アドレスは偽装できます。その際に技術的に何が起きているかは、記事 DDoS 攻撃とは何か で解説しています。

3 つ目の点は Left 4 Dead 2 に固有で、Counter-Strike、Garry's Mod、Team Fortress 2 には対応するものがありません。多くのプレイヤーはサーバーブラウザーではなく、ロビーシステムから入ってきます。最大 4 人のロビーが Steam のマッチメイキングによって専用サーバーに割り当てられ、そのサーバーは予約を受け取ります。この仕組みは、ご自身が使える最も効果的なアクセス制限であると同時に、追加の攻撃対象領域でもあります。どちらも後の節で詳しく扱います。

実際に問題になるポート

Left 4 Dead 2 サーバーは、ゲームを成り立たせるものすべてをちょうど 1 つの UDP ポートで扱います。標準は 27015 で、起動行の -port または +hostport で決まります。

./srcds_run -game left4dead2 -console -nohltv \
  -port 27015 \
  +ip 203.0.113.10 \
  +maxplayers 4 \
  +exec server.cfg \
  +map c1m1_hotel

この表の 1 行目が問題の核心です。ゲームトラフィックとサーバー問い合わせが 27015/UDP を分け合っており、Left 4 Dead 2 には独立したクエリポートがありません。このポートを一律で遮断したり、大まかにレート制限したりする人は、同じ動作で自分のプレイヤーも追い出し、攻撃側の望みどおりに攻撃を成立させます。

A2S 問い合わせは数十バイトのパケット 1 つですが、応答はその何倍にもなります。UDP では送信元アドレスを偽装できるため、お使いのサーバーは被害者になるだけでなく増幅器にもなります。攻撃側は標的のアドレスを名乗って他人のゲームサーバーに問い合わせ、その応答を標的に向けさせます。Valve は 2020 年 12 月に A2S_INFO へ前置きの要求（S2C_CHALLENGE）を追加しました。問い合わせる側は、応答を受け取る前にこれを送り返す必要があります。これでリフレクションは弱まりましたが、古い問い合わせプログラムには今も応答するため、なくなってはいません。

費用をかける前に自分でできること

ここから先の部分は費用がかからず、サーバーがどこに置かれていても役に立ちます。ボリューム型攻撃を代わりに引き受けてはくれませんが、小規模から中規模の攻撃を空振りさせ、DDoS 攻撃と誤って報告される障害を取り除きます。

1. 現状把握：本当に待ち受けているものは何か

ルールを 1 つ書く前に、どのサービスが到達できる状態なのかをはっきりさせます。長く運用してきた Left 4 Dead 2 サーバーでは、ほぼ必ず予想より多くなります。srcds のほかにキャンペーン配布用のウェブサーバー、統計用のデータベース、ときには Versus 用の 2 台目のサーバーが動いているからです。

ss -lntup

127.0.0.1 または ::1 にバインドされているものは、開放の必要がありません。0.0.0.0 や [::] で待ち受けているものは、インターネットから到達できます。攻撃側からの見え方は外部からのポートスキャンで分かり、経験上それは自分の予想からずれています。

nmap -Pn -sU -sT -p 27000-27050,80,443,3306 YOUR.SERVER.IP.ADDRESS

土台をこれから用意する場合や、いまの構成を追いかけたい場合は、記事 SteamCMD でゲームサーバーをインストールする が SteamCMD から srcds の起動までの道筋を説明しています。

2. srcds が本当に必要とするポートだけを開けたままにする

外に向けて UDP ポート 1 つ、ご自身のアドレス向けに TCP ポート 1 つ、それだけです。RCON は開いたインターネットに置くものではありません。RCON を握った相手は、マップを変え、全プレイヤーを BAN し、サーバーを停止できます。

ufw allow 27015/udp comment "L4D2 ゲームポートと A2S"
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment "RCON"
ufw allow from 203.0.113.10 to any port 22 proto tcp comment "SSH"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable

203.0.113.10 はご自身のアドレスに置き換えてください。このアドレスが定期的に変わる場合は、恒久的な開放ではなく SSH ポートフォワーディングを使います。有効化の順序が、自分自身を締め出すかどうかを決めます。復旧手段まで含む手順は記事 自分を締め出さずに UFW ファイアウォールを設定する にあります。それでも締め出してしまった場合は、KernelHost の KVM ルートサーバーと専用サーバーには IPMI も iDRAC もないため、カスタマーエリアの VNC コンソールからサーバーに入ってください。これはゲスト側のネットワークスタックに依存しません。

3. ロビー検索から消えずに A2S 問い合わせを絞る

この分野で最も高くつく失敗がここにあります。ゲームトラフィックとサーバー問い合わせが同じポートを占めているため、ブレーキはポートではなく 2 つのパケットの種類を見分ける必要があります。

Steam のゲームサーバー基盤は、2020 年 12 月の変更以降そのための独自の制限を備えており、起動前に環境変数として設定します。STEAM_GAMESERVER_RATE_LIMIT_200MS=N は、1 つの送信元アドレスからコネクションレスパケット、つまり接続を確立しない A2S_INFO、A2S_RULES、A2S_PLAYERS が 200 ミリ秒の窓の中で N 件を超えて届いた時点で、それらを破棄します。Valve は使える範囲として 25 から 75 を挙げており、初期状態ではこの制限は無効です。

export STEAM_GAMESERVER_RATE_LIMIT_200MS=50
./srcds_run -game left4dead2 -console -port 27015 +exec server.cfg +map c1m1_hotel

systemd のユニットでは、同じ値を [Service] セクションに Environment=STEAM_GAMESERVER_RATE_LIMIT_200MS=50 として書きます。そうしないと次の再起動で消えます。このブレーキは、お使いのサーバーのビルドが最新の Steamworks 基盤を含んでいる場合にだけ効きます。そして守るのはサーバーの計算時間であって、回線ではありません。パケットはすでに届いています。

1 つ下の層では、同じトラフィックをカーネルで切り分けられます。Source エンジンのコネクションレスパケット、つまりサーバー問い合わせと接続確立は、すべて 4 バイトすべてが立った値（0xffffffff）で始まり、すでに接続済みのプレイヤーのトラフィックにはこの先頭がありません。これを手がかりに、nftables で送信元アドレスごとのレート制限をかけられます。

table inet l4d2 {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/second burst 20 packets } drop
    }
}

このファイルは nft -f で読み込みます。優先度 -10 によって、このルールは UFW のフィルターチェーンより前に効きます。@th,64,32 は UDP ヘッダーの直後の 4 バイトを読みます。まずは緩めに始めて、正規の問い合わせが確実に通っていると確認できてから絞ってください。サーバーリストへのご自身の掲載が、これに懸かっています。

4. ロビーシステムをアクセス制限に使う

これは Left 4 Dead 2 と前作にしかない手立てです。マッチメイキングを経由しない接続をそもそも受け付けるかどうかを、サーバー自身が決めます。それを決めるのは server.cfg の 4 つのディレクティブです。

sv_allow_lobby_connect_only 1
sv_search_key "your-own-key"
sv_steamgroup "103582791400000000"
sv_steamgroup_exclusive 2

• sv_allow_lobby_connect_only 1 はマッチメイキングのロビーからの参加だけを通します。開発者コンソールでの connect 203.0.113.10:27015 と Steam の招待は拒否されます。値 0 はどちらも許可します。
• sv_search_key は自由に決められる検索キーです。同じキーが設定されたロビーだけが、マッチメイキングでこのサーバーを見つけます。このキーがなければ、公開の検索には現れません。
• sv_steamgroup はサーバーを Steam グループに結び付け、そのグループのサーバー一覧に表示させます。
• sv_steamgroup_exclusive には 3 段階あります。0 は誰でも通し、1 は 0 と同じように振る舞いながらロビー経由の参加を要求し、2 はグループのメンバーと IP アドレスへの直接接続だけを通します。

固定したコミュニティであれば、検索キーと sv_steamgroup_exclusive 2 の組み合わせが、このゲームにある最も効果的な無料のアクセス制限です。公開サーバーではこれは使えません。誰にも見つけられないサーバーは、オフラインのサーバーと同じだけ空っぽです。

そして、宣伝文では省かれがちな部分です。これらのディレクティブが守るのはゲームのロジックであって、回線ではありません。27015/UDP をあふれさせる攻撃側は、そもそも参加する気がありません。そのパケットは拒否されますが、それでも届いており、帯域幅を使い、ネットワークスタックを 1 回通る分の負荷をかけています。使い捨てアカウントによる参加フラッドには sv_allow_lobby_connect_only 1 が非常によく効き、booter にはまったく効きません。

5. ロビー予約と、sv_force_unreserved のほうが適している場合

ロビー予約とは、マッチメイキングのロビーがお使いのサーバーを一定の時間だけ確保する仕組みです。予約がある間、そのサーバーはほかのロビーから見て使用中とみなされ、予約はしばらく経ってから自然に切れます。4 スロットのサーバーにとって、これは乏しい資源です。32 人や 64 人のシューターと違い、1 試合を塞ぐのにごくわずかで足ります。

マッチメイキングを使わずにサーバーを運用する場合は、この対象領域をまるごと外せます。

sv_force_unreserved 1
sv_allow_lobby_connect_only 0

sv_force_unreserved 1 を設定すると、サーバーはロビーシステムからの予約要求に応答しなくなり、予約情報を伴う参加を拒否します。L4DToolZ で協力プレイのスロットを 4 つより多く運用する場合も、同じ設定がいずれにしても必要です。そうしないと、最初の 4 スロットが埋まった時点でロビーが予約を取り、残りのスロットには誰も入れなくなります。裏返しははっきりしています。その場合、プレイヤーはサーバーブラウザーか connect からしか入ってこられません。

2 つの運用形態のどちらかを、意識して選んでください。半分開いたマッチメイキングと半分開いた直接参加の混合は、両方の欠点だけを集めた形です。

6. RCON を固める

弱いパスワードで開いた RCON ポートは、DDoS の問題ではなく乗っ取りの問題です。rcon_password は空のままにも、推測できる値にもしないでください。openssl rand -base64 32 の出力で十分です。Source のタイトルには、ログイン試行に対するブレーキも用意されています。

rcon_password "A_RANDOM_VALUE_HERE"
sv_rcon_minfailures 3
sv_rcon_maxfailures 5
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

これで、30 秒のうちに 3 回失敗したアドレスは 1 日遮断されます。サーバーコンソールで find sv_rcon を実行すると、お使いのビルドがこれらの変数のどれを持っているか分かります。それでも手順 2 のファイアウォール制限のほうが効果的です。試行そのものをアプリケーションまで通さないからです。RCON が必要ないのであれば、パスワードは空のままにしてください。そうすれば 27015 の TCP 側は待ち受けません。

7. カスタムキャンペーンはゲームポートで配らず外に出す

カスタムキャンペーンは、Left 4 Dead 2 が 15 年たっても遊ばれている理由であり、同時に Counter-Strike にはこの形では存在しない負荷の源でもあります。1 つのキャンペーンはマップ、モデル、テクスチャ、サウンドを含む VPK パッケージで、競技用のマップ 1 枚の何倍もの重さになります。

プレイヤーにとって楽なのは Steam ワークショップです。その場合パッケージは Steam から届き、お使いのサーバーからは届かないため、帯域幅を消費しません。ばらのファイルを自分で配る場合は、配布をゲームポートではなくウェブサーバーに載せます。

sv_allowdownload 1
sv_allowupload 0
sv_downloadurl "https://cdn.example.org/l4d2/"
sv_consistency 1

sv_downloadurl 用のファイルは bzip2 書庫としてウェブサーバーに置きます。mymap.bsp は mymap.bsp.bz2 になります。sv_downloadurl がない場合、srcds はファイルをゲーム接続経由で自分で送ります。そうなると、新しいプレイヤーの接続試行 1 回ごとにダウンロード 1 本分の費用がかかり、ダウンロード途中の中断でも同じだけかかります。これは回線を埋めるきわめて安価な方法で、どの統計を見ても攻撃には見えません。

実務で痛い点を 3 つ挙げます。sv_allowupload 0 は設定しておくべきです。クライアントからサーバーへのアップロードは必要ありません。sv_downloadurl 用のウェブサーバーがゲームと同じホストにあると、ダウンロードとゲームトラフィックが同じ回線と同じ IP アドレスを分け合うため、443/TCP への攻撃が進行中の試合にも当たります。そして sv_consistency 1 は攻撃に対する保護ではなく、クライアント側のファイルの差異に対する保護です。あるキャンペーンがそれなしでは確実に起動しないと分かった場合にだけ、無効にしてください。

8. SourceMod、Metamod と拡張機能

DDoS として報告される障害のかなりの部分は、DDoS ではありません。サーバーバイナリか拡張機能に穴が開いているために、1 人のクライアントが引き起こすクラッシュや負荷の急増です。これに効くのは帯域幅ではなく、手入れです。

• Metamod:Source と SourceMod をエンジンのバージョンに合わせて保つ。 Left 4 Dead 2 には今も更新が来ており、合っていない拡張機能は、更新直後のクラッシュの最も多い原因です。
• 自前の介入ではなく Left4DHooks を使う。 L4D2 固有のイベントは、この拡張機能にまとめて用意されています。同じ関数に自分で手を入れるのは、特定のパケットの並びで落ちるサーバーバイナリへの最短経路です。
• L4DToolZ は意識して使う。 この拡張機能は、固定で組み込まれたスロットの上限を引き上げます。追加のスロットは追加のプレイヤーであり、計算時間を生みます。ロビーシステムと組み合わせる場合は sv_force_unreserved 1 が必要です。
• 拡張機能は少なく。 どのプラグインも同じプロセス内のコードです。独自のウェブサービスを持つ拡張機能は追加のポートを開き、しばしば、まさに守りたいアドレスを公開します。

BAN は恒久的に保存してください。そうしないと再起動で消えます。Source のタイトルにはそのために banid と writeid、および addip と writeip があり、生成されたファイルは exec banned_user.cfg と exec banned_ip.cfg で読み込み直されます。

9. 接続追跡と受信バッファーの負担を下げる

この点は見落とされがちで、ボリューム型攻撃のように見えて実はそうではない障害を説明します。カーネルは UDP トラフィックについても接続追跡（conntrack）にエントリーを作り、送信元アドレスが偽装されている場合はアドレス 1 つごとに新しいエントリーになります。テーブルが埋まると、カーネルは区別なくパケットを破棄します。攻撃とご自身のプレイヤーが一緒に弾き出されます。現在値と上限は、ひと目で分かります。

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

最も効くのは、ゲームトラフィックをそもそも追跡させないことです。エンジンは自分のセッションを自分で管理しています。

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport 27015 notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport 27015 notrack
    }
}

iptables での対応は iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK と、OUTPUT に対して --sport を使った同じ行です。その後、このポートには明示的な開放が必要になります。追跡がなくなると、既存の状態を条件にするルールは効かなくなるからです。srcds が取り出すより速くパケットが届く場合は、さらに受信バッファーがあふれます。プレイヤーには、空いている回線でのパケットロスのように見えます。

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

このファイルは /etc/sysctl.d/ に置き、sysctl -p で有効にします。そもそもこの値が必要かどうかは、カーネル自身が教えてくれます。nstat -az の UdpRcvbufErrors が増えていれば効きます。カウンターが 0 のままなら、この調整では何も変わりません。これは余裕の確保であって、保護ではありません。

10. 攻撃中に推測しなくて済むように測る

攻撃中の最も重要な問いは、どれだけ届いているか、どのポートに届いているか、そしてそれは問い合わせのトラフィックかゲームのトラフィックか、です。4 つのコマンドで足ります。

ip -s link show eth0
nstat -az | grep -i udp
sar -n DEV 1 10
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xffffffff"

1 つ目のコマンドは 10 秒の間隔をおいて 2 回実行してください。そうすれば絶対値ではなくレートが得られます。最後の行はコネクションレスパケットだけを表示します。つまり、クエリフラッドが悪用するまさにその種類です。ほとんど誰も接続していないのに数秒で件数が埋まるなら、答えは出ています。記録は短く保ってください。負荷がかかっている状態では、記録そのものが計算時間を食います。測定値の読み方は記事 サーバーで DDoS 攻撃を検知する にあります。

ただし最も重要なのは、ほとんど誰も事前にやらない手順です。すべてが平常に動いているうちに基準値を作っておくことです。平常時の値がなければ、障害のあとで毎秒 4 万パケットが多かったのか、それとも Versus サーバーが満員だっただけの金曜の夜なのかを判断できません。

ここまでの対策が限界を迎える地点

ここからは率直な部分です。ここまでに書いたことはすべて、パケットがお使いのネットワークカードに届いてから効きます。ファイアウォールのルールが判断するのは、すでにケーブルを通り終えたパケットです。破棄はできますが、送られなかったことにはできません。

一度計算してみてください。一般的なゲームサーバーは 1 Gbit/s につながっており、これは毎秒 125 メガバイトです。可能な限り小さいパケットサイズなら、この回線には毎秒約 149 万パケットが入り、10 Gbit/s の回線なら約 1488 万パケットが入ります。これは CPU、カーネル、ファイアウォールとは無関係な物理的な上限です。通常のサーバーのカーネルが破棄を始める前に処理できるのは、プロセッサーとネットワークカードによりますが毎秒数十万パケットです。つまり、お使いの回線を 3 分の 1 も埋めない攻撃でも、破棄に計算時間を取られてサーバーを止められます。運用者にはこれが「使用率はまったく高くなかったのに、それでも全部落ちた」という形で見えます。

これに対して実際の攻撃があります。KernelHost の運用から 2 例、どちらもリアルタイムで除去したものです。7777/UDP のゲームサーバーに対する 112.2 Gbit/s 超、毎秒 870 万パケット超の UDP フラッド、そして 9987/UDP のボイスサーバーに対する 473.4 Gbit/s 超、毎秒 4150 万パケット超のマルチベクトル攻撃です。ご自身の回線と比べてください。473.4 Gbit/s は 1 Gbit/s の接続の約 470 倍で、10 Gbit/s の接続でもなお約 47 倍です。

だからこそ、よく使われる 2 つの非常手段は満足のいくものではありません。ヌルルーティング（ブラックホーリング）は攻撃されている IP アドレスをネットワークから外します。攻撃は終わりますが、お使いのサーバーも終わります。プレイヤーにとっての結果は、攻撃が成功した場合とまったく同じです。攻撃を受けてから迂回させる方式は、切り替え時間として、まさにキャンペーンの決着がつく数分を奪います。効くのは、サーバーの手前のネットワークで常に動いているフィルタリングだけです。

KernelHost が用意している対策

すべてのサーバーに標準で含まれる常時保護

KernelHost の DDoS 対策は 2 段階で構成されており、有効化も注文も設定もなしに常時動いています。

• 第 1 段階：グローバルなスクラビングネットワークにおける 17 Tbps の緩和能力。 ボリューム型攻撃は、データセンターに届くはるか前に、発生源の近くで除去されます。
• 第 2 段階：フランクフルトにおける 3.2 Tbps の Arbor リアルタイムフィルタリング。 サーバーの直前で、Layer 3 から 7 のプロトコル固有のパターンを検知し、パケット単位で破棄します。

決定的な性質が 2 つあります。第一に、フィルタリングは常時動いているため、プレイヤーが弾き出される切り替え時間がありません。第二に、ヌルルーティングは使いません。攻撃されている IP アドレスはネットワークに残り、破棄されるのは有害なパケットだけです。この保護はどのサーバープランにも追加料金なしで含まれ、別の保護パッケージも設定も必要なく、提供開始時点から有効です。サーバーはフランクフルトの maincubes Premium Datacenter に設置されています。どのゲームとプロトコルが対象かは、記事 ゲームサーバーの DDoS 対策をリアルタイムで にまとめています。

継続的に攻撃されるプロジェクト向けの Advanced DDoS Protection

プロジェクトによっては、たまたまではなく、狙って何週間も攻撃されます。パターンを変えながら、しかも決まってキャンペーンの約束をした晩に来ます。そうした場合のために Advanced DDoS Protection があり、月額 50.00 EUR から、PrePaid、最低利用期間なしで利用できます。違いは容量の大きさではなく、制御できることにあります。

• 専用の保護 IP。 当社のネットワーク内でお使いのサーバーをこのアドレスに切り替えます。ご自身の側で作り直す作業は必要ありません。
• ポートとプロトコルごとに自分で管理できる保護ルール。 どのポートをどのプロファイルでフィルタリングするかをカスタマーエリアで指定できます。つまり 27015/UDP と、キャンペーンを配布するウェブサーバーを別に扱えます。
• 変更はリアルタイムで反映されます。チケットも待ち時間もありません。攻撃が進行している最中に調整できます。
• それぞれのゲームに合った保護プロファイル。 Left 4 Dead 2 とほかの Source タイトルはもちろん、40 を超えるゲームとプロトコルに対応し、改造したサーバー向けの自由な TCP プロファイルと UDP プロファイルもあります。

ここでも PrePaid の方式です。最低利用期間なし、解約予告期間なし、契約なし、初期費用なしです。攻撃の波が過ぎたら、単に更新しなければ終わります。

2 つの段階の比較

ほとんどの Left 4 Dead 2 プロジェクトでは、標準で含まれる常時保護と、きちんとしたサーバー設定を組み合わせれば十分です。Advanced DDoS Protection は、誰かが個人的な問題として攻撃してくる場合への答えです。

よくある失敗とその対処

サーバーはロビー検索から消えたのに、動作は続いている場合：多くは 27015/UDP を一律で遮断したか、レート制限を厳しすぎる値にしたためです。ゲームトラフィックと問い合わせが同じポートを分け合っているので、大まかなルールは両方に当たります。代わりに、コネクションレスパケットへの一致で処理してください。ポートに到達できるのにサーバーが見えないままなら、sv_search_key、sv_steamgroup_exclusive、sv_lan 0、sv_region 255 を確認し、起動時にうっかり -nomaster を付けていないかも見てください。

サーバーコンソールに「Invalid split packet length」が出続ける場合：これはボリューム型攻撃ではなく、誤って組み立てられたネットワークパケットが短い間隔で送られている状態です。トラフィックはごく小さいままなのに、サーバーは重くなります。まず帯域幅がそもそも異常なのかを確認し、サーバーバイナリと拡張機能を最新にしてください。ここで帯域幅は役に立ちません。

全プレイヤーの ping が高いのに、回線は埋まっていない場合：これは量ではなくパケットレートを示しています。ip -s link show の破棄パケットと nstat -az の UDP カウンターを見てください。システムログに nf_conntrack: table full と出ているなら、ゲームポートを notrack で追跡から外します。

ファイアウォールのルールは正しいのに、それでも効かない場合：iptables -L INPUT -n -v で一致カウンターが増えているか確認してください。0 のままなら、ルールが UFW のチェーンの後ろにあるか、前回の再起動で失われたために到達していません。増えているのに何も変わらないなら、サーバーの手前の回線が飽和しており、そこから先はネットワークでのフィルタリングしか効きません。

スロットが空いているのに、サーバーがプレイヤーを受け付けない場合：多くはロビー予約が残っています。サーバーを一貫してマッチメイキング経由で運用するか、sv_force_unreserved 1 を設定してプレイヤーにはサーバーブラウザーから参加してもらってください。L4DToolZ で協力プレイのスロットを 4 つより多くする場合は、この設定はいずれにしても必須です。

新しいプレイヤーの読み込みが延々と続き、その間回線が埋まっている場合：srcds がキャンペーンのファイルをゲームポート経由で自分で配っています。sv_downloadurl をウェブサーバーに向け、ファイルを bzip2 書庫としてそこに置くか、プレイヤーを Steam ワークショップに案内してください。

IP アドレスを変えたら攻撃が止まり、1 日か 2 日で戻ってきた場合：それが通常の姿です。お使いのサーバーは再登録された時点で新しいアドレスを自分で公開し、忘れられた DNS レコードやステータス表示付きの Discord ボットが残りを済ませます。IP アドレスの変更は数時間を稼ぐだけで、解決ではありません。

サーバーで見知らぬ管理コマンドが実行されている場合：DDoS 攻撃ではなく、RCON アクセスの侵害です。パスワードを直ちに変更し、27015 の TCP 側をご自身のアドレスだけに限定してください。

まとめ

• Left 4 Dead 2 サーバーが外に必要とするポートはちょうど 1 つ、27015/UDP です。ゲームトラフィックと A2S 問い合わせがこれを分け合っており、独立したクエリポートはありません。
• 27015/TCP は RCON であり、ご自身のアドレスだけに限定します。RCON が必要ないなら rcon_password は空のままにしてください。
• ロビーシステムは、このゲームにある最も効果的な無料のアクセス制限です。sv_allow_lobby_connect_only 1、独自の sv_search_key、sv_steamgroup_exclusive 2 が、マッチメイキングを通らないものをすべて遮断します。ただし対象は参加であって、パケットではありません。
• カスタムキャンペーンは Steam ワークショップか sv_downloadurl の後ろに置き、ゲームポートで配らないでください。そうしないと、中断された接続試行のたびにご自身の帯域幅で支払うことになります。
• レート制限は、コネクションレスパケット（0xffffffff で始まるもの）とゲームトラフィックを見分ける必要があります。27015/UDP への大まかなルールは、自分のプレイヤーを追い出します。
• 64 バイトのパケットなら、1 Gbit/s の回線には毎秒約 149 万パケットが入ります。それを超えた領域を決めるのはサーバーの手前のネットワークだけで、サーバー自身のどの設定でもありません。
• KernelHost では、17 Tbps のグローバルなスクラビングと、フランクフルトにおける 3.2 Tbps の Arbor リアルタイムフィルタリングが常時、追加料金なしで、ヌルルーティングも切り替え時間もなくフィルタリングします。

プロジェクトをすでに KernelHost で動かしている場合、フィルタリングは何もしなくても有効です。それでも異常に気づいたときは サポートチケット を開いてください。当社のチームがお使いの IP アドレス向けにフィルタールールを調整します。攻撃が進行中の場合は、WhatsApp の緊急チャット +43 650 8209883 でもご連絡いただけます。その際は 4 つの情報をすぐにお知らせください。IP アドレス、ポート、ご自身のタイムゾーンでの時間帯、そして見えている症状（プレイヤーが弾き出される、サーバーがロビー検索に出ない、ping が高い）です。これで確認のやり取りが 1 往復減り、キャンペーンが進行中のときはそれが効きます。

ほかの事業者で運用していて定期的に撃たれている場合は、回線がその手前で終わっているサーバーにルールを足し続けるより、KernelHost への移転が近道です。常時保護はどのサーバープランにも含まれており、いざというときに初めて注文する追加機能ではありません。