Lineage 2 サーバーを DDoS 攻撃から守る

夜になると誰もログイン画面から先へ進めないのに、すでに世界にいるプレイヤーは何の支障もなく遊び続けている。そんな Lineage 2 のプライベートサーバーに、ハードウェアの問題はありません。これはログインサーバーに対する DDoS 攻撃の指紋であり、Lineage 2 の DDoS 対策はまさにそこから始める必要があります。本記事ではまず、追加費用なしでご自身で固められる範囲を示し、次にその対策が技術的にどこで限界を迎えるかを示し、最後にサーバーの手前のネットワークで何が起きる必要があるかを説明します。

本記事の記述はすべて、Debian 12、Debian 13、Ubuntu 22.04 LTS、Ubuntu 24.04 LTS 上で動く L2J とその派生（L2J-Mobius、aCis）、および AuthD、CacheD、L2Server で構成される L2OFF パッケージを前提としています。コマンドは root 向けに書かれているため、一般ユーザーの場合は先頭に sudo を付けてください。

攻撃がいま進行中の場合：設定には手を付けず、ログインサーバーもゲームサーバーも再起動しないでください。まずは測定値を保存します（「ログを取る」の節を参照）。攻撃が終わってからでは、もう残っていません。

Lineage 2 サーバーを DDoS 攻撃から守る：プライベートな L2 サーバーが狙われる理由

Lineage 2 のプライベートサーバーには、都合のよい標的にしてしまう性質がいくつも重なっており、Lineage 2 の DDoS 対策はまさにその性質から始める必要があります。第一に、ご自身のアドレスは最初から公開されています。プレイヤーはパッチ済みの System フォルダーをダウンロードし、その中の l2.ini には ServerAddr= の行とともにログインサーバーの IP アドレスが書かれています。一度でもご自身のプロジェクトを導入した人は、キャラクターを作ったことがあるかどうかに関係なく、このアドレスを知っています。

第二に、プレイヤー層の活動時間が固定されています。攻城戦、エピックレイドボス、イベントはカレンダーに載っているため、まさにその時間の障害は最も目立ちます。第三に、プロジェクトは互いに直接競合しています。サーバーを開ける人は、同じ週末に開く 3 つの別プロジェクトと、同じ数千人のプレイヤーを取り合います。この世界では、競合相手を止めることがよく使われる手です。攻撃はサービスとして買えるもので（この世界では booter や stresser と呼ばれます）、依頼した側に技術も、まとまった金額も要りません。DDoS 攻撃が具体的に何であるかは、記事 DDoS 攻撃とは何か で解説しています。

ポート 2106 のログインサーバーが本当の標的である理由

Lineage 2 は 2 つの別々のプロセスに分かれています。1 つのログインサーバーと、1 つ以上のゲームサーバーです。クライアントはまず 2106 TCP でログインサーバーに接続して認証を受け、そこからゲームサーバーの外部アドレスとポートを含むサーバーリストを受け取り、その後 7777 TCP でゲームサーバーへの 2 本目の接続を確立します。2 つのプロセスは、それぞれ独自の設定ファイル、独自のポート、独自の限界を持っています。

ここから、L2 の運用者が繰り返し語る攻撃の形が導かれます。2106 へのフラッドは、新しいログインだけを塞ぎます。すでに世界に立っている人は、自分で接続を失うまで遊び続けます。つまりオンライン人数は一気に落ちるのではなくゆっくり減り、フォーラムには「サーバーは動いているのに入れない」と書かれます。まさにこの見え方が、ログインサーバーへの攻撃と、全員が同時に弾き出されるゲームサーバーへの攻撃を区別します。

ログインサーバーは、手間の配分が偏っているという意味でも安い標的です。L2J のログインサーバーは起動時に 1024 ビットの RSA 鍵ペア 10 組と Blowfish 鍵 20 個を用意します。ログインを 1 回試すのに、クライアント側の費用はパケットを 1 つ送ることだけですが、サーバー側の費用は秘密の RSA 鍵による復号です。しかも中途半端なセッションは、内蔵のタイマーが破棄するまで 1 枠を占め続けます。LOGIN_TIMEOUT はソースコード上で 60 秒です。初期設定の MaxConnectionPerIP = 50 は、1 つの送信元アドレスに同時 50 接続を許します。つまり 1000 個の送信元アドレスがあれば、それぞれ最大 1 分間残る同時 5 万セッションに届きます。

加えて、ほとんどのゲームサーバーと異なるこのゲーム固有の性質があります。Lineage 2 は TCP だけで動きます。メーカーはこのゲームについて TCP のポート 80、2009、2106、7777 を挙げ、UDP は名前解決のためのポート 53 だけを挙げています。つまりフィルタリングしなければならない UDP のゲームトラフィックは存在せず、その代わりに送信元アドレスを偽装した古典的な SYN フラッドが直接効き、カーネルの接続追跡が最初の詰まりどころになります。

Lineage 2 サーバーへの攻撃がサーバーのオープンに合わせて季節的に起きる理由

Lineage 2 のプライベートサーバーへの攻撃は、サーバーのオープンの前後に集中します。開設の日付と時刻が数週間前から公開されているからです。Lineage 2 のプロジェクトのオープン予定カレンダーは、クロニクル（Interlude、High Five、Classic、Essence）ごとに今後のオープンを一覧にし、レートと正確な開始時刻まで載せて、毎日更新されます。攻撃側は下調べをする必要がありません。自分にとって最も都合のよい時刻が、運用者自身の告知に書いてあります。

2 つ目の理由は経済的なものです。Lineage 2 のプライベートサーバーは前半で稼ぎます。プレイヤー基盤は最初の数日で集まり、寄付は最初の数週間に入り、そのあとは人口が減り続けます。最初の 1 時間に入れなかったプレイヤーは、同じ週末にオープンするプロジェクトへ移ります。そしてそのプロジェクトは必ず存在します。そのため開設日の 1 時間の障害は、1 時間分の売上ではなく、サーバーの寿命全体の一部を失わせます。

3 つ目の理由は技術的なものです。グランドオープンでは、数千人のプレイヤーが同時にログインしようとします。ログインサーバーはまさにその 1 分間にもともと限界にあり、そこに加わるフラッドは、ピーク時の負荷とほとんど区別がつきません。静かな火曜日なら何も起こらない規模の攻撃が、オープンの時間には十分な威力を持ちます。運用中に予告された日程についても同じです。攻城戦とエピックレイドボスはカレンダーに載っており、同じ理由で好まれる攻撃の窓になります。オープン直後の混雑が過ぎると動機は下がるため、運用者は攻撃を継続的な状態ではなく波として体験します。

実際に問題になるポート

次の表は、Lineage 2 のプライベートサーバーのポート、対応する設定ファイル、そして値を決めるディレクティブを一覧にしたものです。初期設定は L2J に同梱の設定ファイル、および L2OFF パッケージの構築手順に基づいています。

この表は 2 つの問いにも同時に答えています。Lineage 2 にはクエリポートも RCON ポートもありません。サーバーリスト用にプレイヤー数を配る独立したサービスもなく、Source 系のゲームのような遠隔操作用のポートもありません。サーバーリストはログインサーバー自身が作り、認証済みのクライアントへ 2106 の同じ接続で送ります。遠隔操作は L2J ではゲーム内のコマンドとデータベース経由で行います。これで他のゲームにある 2 つの攻撃経路がなくなり、その分だけポート 2106 に集まります。

知っておくべき数量の目安

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

この節が最も長いのは意図的です。きちんと設定された Lineage 2 サーバーは、どこに置かれていようと、小規模から中規模の攻撃を自力で耐えます。

1. 現状把握：そもそも何が待ち受けているのか

ルールを 1 つ書く前に、お使いのサーバーが外に何を提供しているかを確認します。推測せず、実際に見てください。

ss -lntp

注目するのはローカルアドレスの列です。0.0.0.0:2106 と 0.0.0.0:7777 はそこにあるべきものです。0.0.0.0:9014 と 0.0.0.0:3306 は誤りです。この 2 つは、攻撃側がご自身のサーバーリストに自分をぶら下げたり、データベースを叩いたりできるポートです。一方 127.0.0.1:3306 は「ローカルのみ」を意味し、ファイアウォールルールは不要です。攻撃側からの見え方は、外部からのポートスキャンで分かります。

nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. ポート 9014 とデータベースを開いたネットワークから外す

ポート 9014 は、ゲームサーバーがログインサーバーに登録するための通り道であり、どんな場合でも開いたネットワークに置いてはいけません。L2J は正しい初期設定をすでに用意しています。LoginHostname = 127.0.0.1 がこのポートをループバックインターフェースに結び付けるため、外からはまったく到達できません。ログインサーバーとゲームサーバーを 2 台の別のマシンで動かす場合は、* の代わりに具体的な内部アドレスを書き、このポートを相手側だけに開放してください。

同じ規則がデータベースにも当てはまります。/etc/mysql/mariadb.conf.d/50-server.cnf に次の記述があるか確認してください。

bind-address = 127.0.0.1

そしてデータベースのユーザーを入れ替えてください。同梱の Server.properties は Login = root になっており、ファイル自身がそれは推奨されないと注記しています。最小限の権限を持つ独自のユーザーを作る方法は MariaDB と MySQL を安全に設定する にあります。そのあとで結果を確認します。

ss -lntp | grep -E ':9014|:3306'

その上のファイアウォールは短くて済みます。Lineage 2 サーバーには外向きの開放が 2 つで足り、自分自身を締め出さないよう、次の順番どおりに実行してください。

ufw allow 22/tcp comment 'SSH'
ufw allow 2106/tcp comment 'L2 ログイン'
ufw allow 7777/tcp comment 'L2 ゲーム'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

復旧手段まで含む完全な手順は 自分を締め出さずに UFW ファイアウォールを設定する にあります。

3. サーバーが登録されたら AcceptNewGameServer を切る

LoginServer.properties には出荷時から AcceptNewGameServer = True と書かれており、その上のコメントが意味をそのまま説明しています。どのゲームサーバーでも、ご自身のログインサーバーの空き枠に登録できるという意味です。9014 がループバックインターフェースだけにある限り、これは無害です。何か別の理由でこのポートに到達できるようになった瞬間に、それは開いた扉になります。ですから、ご自身のゲームサーバーが一度登録されて ID を得たら、値を False にしてください。

AcceptNewGameServer = False

ゲームサーバー側の対応する設定は AcceptAlternateID = True です。構築中は、希望の ID がふさがっていればログインサーバーが別の ID を割り当ててくれるので便利です。本番のシステムでは逆を望むはずです。固定の ID と、それがふさがっていた場合のエラーです。

4. ログインサーバーのフラッド対策を正しく設定する

L2J はログインサーバーに独自の接続ブレーキを備えています。設定は LoginServer.properties にあり、時間の値はすべてミリ秒です。

EnableFloodProtection = True
FastConnectionLimit = 15
NormalConnectionTime = 700
FastConnectionTime = 350
MaxConnectionPerIP = 50

これらの値は互いに関係しています。同じ送信元アドレスからの前の接続より FastConnectionTime 未満の間隔で届いた接続は、速いと数えられます。そうした接続が FastConnectionLimit 件に達すると、そのアドレスは拒否されます。NormalConnectionTime は、カウンターが再び減り始める間隔です。MaxConnectionPerIP は、アドレスごとの同時接続数の上限です。

同時 50 接続は 1 人のプレイヤーにはかなり大きな値で、値を下げると体感できるほど効きます。それでもここは慎重にしてください。同じ世帯の複数のプレイヤー、インターネットカフェ、そして何よりキャリア NAT の後ろにある回線（L2 の世界ではトルコ、ブラジル、東欧の一部から来る多くのプレイヤーが該当します）は、1 つの公開アドレスを共有しています。ここを 3 にする人は、本物のプレイヤーを締め出します。まずは平常時を 1 週間測り、それから段階的に下げてください。

そして知っておくべき制約があります。このブレーキはログインサーバーの Java プロセスの中で動きます。それが判断する 1 つ 1 つのパケットは、すでにお使いの回線を通り、すでに計算時間を使っています。ごく少数の発信元には効きますが、ボットネットには効きません。

5. 失敗回数を制限し、banned_ip.cfg を使う

LoginServer.properties のもう 2 つのディレクティブが、どれだけ推測を許すかを決めます。

LoginTryBeforeBan = 5
LoginBlockAfterBan = 900

LoginTryBeforeBan は、アカウントとパスワードの組み合わせが無効だった回数のうち、これを超えるとアドレスが遮断される値で、LoginBlockAfterBan は秒単位の遮断時間です（900 は 15 分に相当します）。そのあとは数え直しになります。

恒久的な遮断は、ログインサーバーの設定ディレクトリーにある banned_ip.cfg に書きます。単独のアドレス、ネットワーク全体、そして任意で失効時刻をミリ秒単位の UNIX タイムスタンプとして書けます。# 以降はすべてコメントです。

198.51.100.7
203.0.113.0
198.51.100.44 1789689600000

さらに AutoCreateAccounts = False を設定してください。初期設定の True は、知らないアカウント名でログインされるたびに自動でアカウントを作ります。構築中は便利ですが、運用中は贈り物になります。攻撃側はこれでいくらでもアカウントを作れ、そのどれもがご自身のゲームサーバーのアドレスを含むサーバーリストを取得できます。アカウントは代わりに、ご自身のウェブサイトの登録から作らせてください。そうすれば、誰が ID を得るかを管理できます。

6. 2106 と 7777 の接続レートをカーネルで制限する

Java のブレーキが判断するには遅すぎるものを、カーネルはより早く、より安く判断します。小規模な攻撃や作りの粗いボットには、送信元アドレスごとの上限が効きます。

iptables -I INPUT -p tcp --dport 2106 --syn -m connlimit --connlimit-above 8 --connlimit-mask 32 -j DROP
iptables -I INPUT -p tcp --dport 2106 --syn -m hashlimit --hashlimit-name l2login --hashlimit-mode srcip --hashlimit-above 6/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p tcp --dport 7777 --syn -m connlimit --connlimit-above 6 --connlimit-mask 32 -j DROP

1 つ目のルールは、1 つのアドレスが同時に 8 本より多く開いた時点で、ログインサーバーへの新しい接続を破棄します。正規のクライアントに必要なのはちょうど 1 本です。2 つ目は新規接続のレートをアドレスごとに毎秒 6 件へ制限し、20 件の余裕を持たせます。これはサーバー再起動後の再接続の集中をまだ通せる値です。3 つ目はゲームサーバーでアドレスごとに同時 6 接続を許します。Lineage 2 では多重起動（デュアルボックスやトリプルボックス）が普通であり、厳しすぎる上限はお金を払っているプレイヤーに当たるからです。

3 つの数値はいずれも出発点で、絶対の正解ではありません。同時 2000 人のサーバーは、200 人のサーバーとは違う振る舞いをします。まず測り、それから設定してください。iptables のルールだけでは再起動で消えるため、Debian と Ubuntu では次のように保存します。

apt-get install -y iptables-persistent
netfilter-persistent save

UFW を使っている場合、こうしたルールは /etc/ufw/before.rules に書きます。そうしないと、次の ufw reload で消えてしまいます。

7. SYN フラッドを受け止める：SYN クッキー、バックログ、接続追跡

Lineage 2 は TCP だけで動くため、SYN フラッドはすぐ思い浮かぶ経路です。SYN フラッドとは、送信元アドレスを偽装した接続要求を送り、その確認に決して応答しない攻撃で、サーバーは要求 1 件ごとに、決して使われないメモリーを確保することになります。4 つの設定がこれを弱めます。

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sysctl -w net.core.somaxconn=4096
sysctl -w net.ipv4.tcp_synack_retries=2

なかでも SYN クッキーの行が最も重要です。カーネルは何も記憶せずに要求へ応答し、相手が実際に接続を完了したときに初めて状態を作ります。これで偽装された送信元は空振りになります。恒久的に有効にするには、値を /etc/sysctl.d/ の下のファイルに置き、sysctl --system で読み込みます。

見落とされがちな詰まりどころが、カーネルの接続追跡です。これがあふれると、サーバーは正規のパケットまで破棄し、ログには「nf_conntrack: table full, dropping packet」と出ます。現在値と上限は次のコマンドで分かります。

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

8. ウェブサイト、ログインサーバー、ゲームサーバーを別々の IP アドレスに置く

登録、寄付ショップ、投票ページを備えたプロジェクトのウェブサイトは、ドメインからいつでも見つけられます。これがログインサーバーと同じ IP アドレスにあると、ウェブサイトへの攻撃が同時にログインも止め、その逆も起きます。3 つの役割を別々のアドレスに分けてください。そうすれば、ウェブサイトへの攻撃中もゲームには到達でき、2106 への攻撃中もすでに接続しているプレイヤーは遊び続けられます。

その際、DNS レコードはきれいに保ってください。最も多い誤りは、以前のアドレスを指す A レコードの忘れ残りです。これがあると、攻撃側がプレイヤーと同じ名前から新しいアドレスを見つけるため、どんなアドレス変更も無意味になります。

そしてここには願望ではなく率直さが必要です。ログインサーバーのアドレスは秘密にできません。それはすべてのプレイヤーがダウンロードする System フォルダーの l2.ini に書かれています。ゲームサーバーのアドレスは、ログインサーバー自身が配ります。L2J では外部アドレスとして ipconfig.xml に（古い派生では Server.properties の ExternalHostname として）書かれ、認証に成功したすべてのクライアントに伝えられます。隠すことは戦略ではありませんが、フィルタリングは戦略です。

9. いざというときにデータが残るようにログを取る

最も重要なのは、ほとんど誰も事前にやらない手順、つまりすべてが平常に動いているうちに基準値を作っておくことです。平常時の値がなければ、障害のあとで毎秒 4 万パケットが多かったのか、それとも単に土曜の夜だったのかを判断できません。apt-get install -y vnstat sysstat で測定は常に走り続けます。障害の最中は、4 つのコマンドで足ります。

sar -n DEV 1 10
ss -tn state syn-recv | wc -l
ip -s link show eth0
tcpdump -ni eth0 'tcp port 2106' -c 200 -q

Lineage 2 で最も物を言うのは 2 行目です。これは半開きの接続を数えます。プレイヤーが数百人のときに 5 桁の値が出ていれば、それは SYN フラッド以外のものではありません。tcpdump では必ず -c で件数を区切ってください。全負荷の状態での取得は、すでに過負荷のサーバーにさらに負荷をかけます。測定値の読み方は DDoS 攻撃を検知する にあります。

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

ここからは、どの設定ファイルでも解決できない部分です。これまでの対策はすべてお使いのサーバー上、つまり回線の末端で動きます。ファイアウォールのルールが判断するのは、すでにケーブルを通り終えたパケットです。破棄はできますが、送られなかったことにはできません。

一度計算してみてください。一般的なゲームサーバーは 1 Gbit/s につながっており、これは毎秒 125 メガバイトで、誰かがそれより多く送った時点で回線は埋まります。Lineage 2 サーバーに対しては、そこまで大きな攻撃すら必要ありません。2 つ目の指標が先に効くからです。パケットレートです。64 バイトの小さなパケットなら、1 Gbit/s の回線には毎秒約 149 万パケットが入ります。通常のサーバーのカーネルが破棄を始める前に処理できるのは、CPU とネットワークカードによりますがそのうち毎秒数十万です。

TCP だけのゲームでは、3 つ目の限界が加わります。半開きの接続はどれも接続追跡とバックログのエントリーを 1 つ占め、L2J のログインサーバーはセッションを最大 60 秒保持します。つまり毎秒数十万パケット程度の、お使いの回線を 3 分の 1 も埋めない攻撃で、ログインを完全に塞げます。運用者にはこれが「使用率はまったく高くなかったのに、それでも誰も入れなかった」という形で見えます。

どの程度の規模が実際にあるかを示すために書いておきます。KernelHost のサーバーでは、ゲームサーバーに対する 112.2 Gbit/s 超、毎秒 870 万パケット超の攻撃、そしてボイスサーバーに対する 473.4 Gbit/s 超、毎秒 4150 万パケット超のマルチベクトル攻撃などを除去しました。これに効くローカルな設定はありません。ボリューム型攻撃は、サーバーの手前のネットワークで終わらせる必要があります。実際に起きているときに何をするかは 深刻な DDoS 攻撃、どうするか にあります。

KernelHost が用意している対策

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

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

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

決定的な性質が 2 つあります。保護は常時動いており、攻撃を受けてから反応する必要がないため、最初にサーバーが消えている数分がありません。とくにグランドオープンでは、これが成功した立ち上げと失敗した立ち上げの差になります。そしてヌルルーティングは使いません。お使いの IP アドレスはネットワークに残り、破棄されるのは有害なパケットだけです。IP アドレスをネットワークから外す事業者は、ご自身にとって攻撃側と同じ結果をもたらします。どのゲームとプロトコルが対象かは ゲームサーバーの DDoS 対策をリアルタイムで にまとめています。

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

プロジェクトによっては、たまたまではなく、狙って何週間も攻撃されます。Lineage 2 の世界では、サーバーリストの上位に入るサーバーにとってこれが通常です。そのために Advanced DDoS Protection があり、月額 50.00 EUR から、PrePaid、最低利用期間なしで利用できます。違いは容量の大きさではなく、制御できることにあります。

• フランクフルトの中核から割り当てる専用の保護 IP。お使いのサーバーは当社のネットワーク内でこのアドレスに切り替えられます。ご自身の側で作り直す作業は必要ありません。
• ポートとプロトコルごとに自分で管理できる保護ルールをカスタマーエリアで設定できます。2106 TCP で何を許可するか、7777 TCP で何を許可するかを分けて指定できます。これは Lineage 2 では決定的な点です。2 つのポートはトラフィックの形がまったく違い、一方は短い接続が多数、他方はごく長い接続が少数だからです。
• 変更はリアルタイムで反映されます。そのため攻撃が進行している最中に調整でき、オープンの時間の前にルールを厳しくして、そのあとで緩めることもできます。
• アプリケーションに合わせた保護プロファイルを用意しており、任意の TCP または UDP ポートで動く改造したサーバーファイルや独自のサーバーファイルにも対応します。L2J、L2J-Mobius、aCis、L2OFF パッケージのどれを運用していても、ルールセットには関係ありません。ポートとプロトコルを基準にしているからです。

2 つの段階の比較

ほとんどの Lineage 2 プロジェクトでは、標準で含まれる常時保護と、きちんとしたサーバー設定を組み合わせれば十分です。Advanced DDoS Protection は、誰かが個人的な問題として攻撃してくる場合への答えで、経験上それはグランドオープンの前の週に起こります。

よくある失敗とその対処

「ログインできないのに、ゲームサーバーは普通に動いている」：これは偶然ではなく、Lineage 2 サーバーへの攻撃のいつもの形です。ログインサーバーとゲームサーバーは、2 つのポートで動く 2 つのプロセスです。ss -tn state syn-recv | wc -l と sar -n DEV 1 10 を測ってください。帯域幅に異常がないまま半開きの接続が増えているなら、それは 2106 への接続フラッドです。

「IP アドレスを変えたのに、翌日にはまたオフラインになった」：攻撃側は、ご自身のプレイヤーと同じ経路で新しいアドレスを受け取ります。つまり変更された l2.ini を含む新しい System フォルダー、ご自身の告知、あるいは忘れられた DNS レコードです。アドレスの変更は時間稼ぎであって、解決ではありません。

「MaxConnectionPerIP を 3 にしたら、プレイヤーから苦情が来た」：Lineage 2 では多重起動が普通で、キャリア NAT の後ろのプレイヤーは 1 つの公開アドレスを何百人もと共有しています。平常時の測定値を満たす値に戻し、代わりに新規接続のレートをカーネルで制限してください。

「iptables のルールが効かない」：よくある原因は 3 つです。ルールが UFW のチェーンの後ろにあって一度も到達しない、前回の再起動で消えていた（この場合は netfilter-persistent save か /etc/ufw/before.rules への記述が助けになります）、あるいは攻撃がボリューム型で、ルールはすでに埋まった回線の上で正しく動いている、のいずれかです。iptables -L INPUT -n -v で一致カウンターが増えているか確認してください。0 のままなら、そのルールには届いていません。

「全プレイヤーにラグスパイクが出るのに、回線は静かなまま」：それなら DDoS 攻撃ではありません。Java のサーバーでよくある容疑者は、ガベージコレクションによる停止、適切なインデックスのないデータベース、そしてループに入ったスクリプトかカスタムイベントです。まず sar -n DEV 1 10 を確認してください。パケットレートが普通のままなら、原因はネットワークではなくサーバーの中にあります。

「これまで使っていた事業者に IP アドレスを遮断された」：それがヌルルーティングです。事業者はそれで自分のネットワークを守りますが、ご自身にとっての結果は攻撃の成功と同じで、多くの場合そのあと数時間続きます。判断に迷うときは、フィルタリングなのかヌルルーティングなのかを尋ねてください。その答えは、どんなハードウェアの仕様よりも可用性を左右します。

「tcpdump で見ても、おかしなところがない」：手前のネットワークですでにトラフィックが除去されている場合、サーバーには何も届かないのが当然です。フィルタリングが機能しているときの通常の姿です。逆に回線が飽和していると、測定に使おうとした SSH セッションさえ届かないことがあります。その場合は、ゲスト側のネットワークに依存せず動作する、カスタマーエリアの VNC コンソールを使ってください。

「グランドオープンは 2 週間後だ」：それなら移転は今で、オープンの週ではありません。移転にはプレイヤー向けの新しい System フォルダー、DNS の切り替え、そしてテスト実行が必要です。そのすべてを、日程を告知する前に終えておきたいはずです。告知した時点から、どの競合相手もご自身にとって最も都合の悪い時刻を知ることになります。

まとめ

• Lineage 2 のプライベートサーバーが開いたネットワークに必要とするポートはちょうど 2 つです。ログインサーバー用の 2106 TCP と、ゲームサーバー用の 7777 TCP です。ポート 9014、データベース（L2J では 3306、L2OFF では 1433）、そして L2OFF の内部ポート 2002、2006、2008、2104、2108 はそこに含まれません。
• Lineage 2 は TCP だけで動き、クエリポートも RCON ポートもありません。そのため典型的な攻撃はポート 2106 への SYN フラッドまたは接続フラッドで、UDP フラッドではありません。
• ログインサーバーへの攻撃は、新しいログインだけを塞ぎます。世界にいるプレイヤーが遊び続けているのに誰も入ってこられないなら、原因は 7777 ではなくポート 2106 に探すべきです。
• EnableFloodProtection、MaxConnectionPerIP、LoginTryBeforeBan、AutoCreateAccounts を意識して設定し、登録が済んだら AcceptNewGameServer を False にして、接続レートはカーネルでも制限してください。Java のブレーキは回線の後ろで初めて効くからです。
• Lineage 2 サーバーへの攻撃はサーバーのオープンに合わせて増えます。日付と時刻が数週間前から公開されており、経済的な損害が開設日に最も大きいからです。保護は告知の前に整えるもので、告知のあとではありません。
• 回線の容量を超え、毎秒数十万パケットを超えた領域を決めるのは、サーバーの手前のネットワークでのフィルタリングだけです。KernelHost ではそれが 2 段階で、常時動いており、追加料金なし、ヌルルーティングなしです。

プロジェクトをすでに KernelHost で動かしている場合、フィルタリングは何もしなくても有効です。それでも異常に気づいたときは サポートチケット を開いてください。お使いの IP アドレス向けにフィルタールールを調整します。攻撃が進行中の場合は、WhatsApp の緊急チャット +43 650 8209883 でもご連絡いただけます。