自宅サーバーのDDoS対策！自宅IPを隠してマイクラを公開する方法

• 友達に配ったサーバーが急に重くなったり、頻繁に落ちたりして、DDoS攻撃を疑っている
• まだ公開していないが、自宅のIPアドレスが外部に見えるのが怖くて公開に踏み切れない
• VPSやLinuxの設定は難しそうで、もっと簡単に自宅IPを隠す方法がないか探している

サーバーが重くなるたびにDDoSを疑いながら、対策の仕方がわからず様子見している人は多いです。

DDoS攻撃は、自宅回線側の設定だけでは止め切れません。

自宅のグローバルIPが攻撃者に知られている限り、次の攻撃も同じIPへ届くためです。

だからこそ発想を変え、自宅IPそのものを外部から見えなくする構成に切り替えます。

• TCPShieldでJava版の接続を隠す方法
• VPSを踏み台にしたiptables中継構成
• Cloudflare SpectrumでJava版をさらに隠す方法
• HAProxyで複数VPSに接続を振り分ける方法

読み終えるころには、自分の環境でまず何から手をつけるかが1つに決まります。

spaこの記事を書いた人

マイクラサーバーの構築と運用を繰り返して4年。今も経済サバイバル「spa77.works SMP」を運用中で、その経験をもとに記事100本以上を執筆。

プロフィール詳細 →お仕事の相談 →

自宅サーバーのDDoS対策は攻撃を防ぐより自宅IPを隠すことが基本方針

家庭用回線とルーターの防御力では、大量の通信を送りつけるDDoS攻撃を正面から受け止め切れません。

そこで、外部と自宅の間に保護サービスやVPSを挟み、攻撃先になる自宅IPそのものを知られない状態を作ります。

攻撃が始まってから自宅のルーターでできることはほぼないので、最初からVPSなどを挟んで、自宅IPを友達にも見せない形にしておくほうが現実的です。

どこまで自分で組むかによって、取れる選択肢は次の4つです。

• VPSを自分で中継させずに始めるTCPShield
• Java版もBedrock版も守れるVPS+iptables中継
• VPS中継の上へさらに一段隠すCloudflare Spectrum
• 人数が増えたときに複数VPSへ振り分けるHAProxy

上から順に構築の難易度が上がるため、まずは手軽に導入できる選択肢から確認しましょう。

なお、自宅サーバーの公開方法自体を広く比べたい場合は、ポート開放なしで立てる方法の比較で4つの方法を並べています。

この記事では、DDoS対策として自宅IPを隠す構成に絞って進めます。

対策を組む前にDDoSかサーバー負荷かを切り分ける

サーバーが重い、接続が切れるという症状だけでは、DDoSとは判断できません。

いきなり中継構成を作る前に、次の順番で確認します。

1. サーバーコンソールでメモリ使用量、CPU負荷、プレイヤー数を確認する
2. ルーターやVPSの通信量が普段より急増していないか確認する
3. latest.logで、同じ時刻に大量の接続・切断やエラーが出ていないか確認する
4. サーバーを止めたあとも回線やルーターの負荷が続くか、契約先へ確認する

メモリやCPUだけが張り付いているなら、先にサーバーが重いときの確認方法で原因を切り分けてください。

回線側の異常が疑われても、攻撃元を自分で断定せず、回線事業者やVPS事業者の障害・DDoS対応窓口へ相談してください。

Java版とBedrock版でプロトコルが違う点を先に整理する

自宅サーバーのDDoS対策を組む前に、使っている版のプロトコルを確認しておきます。

Java版はTCPの25565番、Bedrock版・Geyserを使ったクロスプレイはUDPの19132番と、使うプロトコルそのものが別です。

この版とプロトコルの違いが、このあとに紹介する各対策の対応範囲を左右します。

TCPShieldでJava版の接続先を保護する

VPSを自分で中継させずにJava版の接続先を隠したい場合は、TCPShieldのようなMinecraft向け保護サービスを使う方法です。

プレイヤーの接続をTCPShieldのネットワーク経由にし、自宅側を保護CNAMEへ向ける構成です。独自ドメインを使い、プレイヤーにはIPアドレスではなく保護後のホスト名を案内します。

設定は3つに分かれます。

• TCPShieldのDNSとバックエンドを設定する
• 自宅側を直接接続できない状態にする
• 実IPをログへ渡すか決める

3つ目は運用方針で判断が分かれるため、必要かどうかを先に決めてください。

TCPShieldのDNSとバックエンドを設定する

先に、自宅サーバーへ直接接続できる状態を作っておきます。保護サービスの設定前からサーバーが動いていないと、どこで失敗したかわからなくなるためです。

1. TCPShieldのパネルでバックエンドのIPアドレスとポートを登録する
2. 保護用のドメインを追加し、表示された保護CNAMEを確認する
3. DNSのサブドメインを保護CNAMEへ向ける
4. ルートドメインで接続したい場合は、公式DNSガイドに従って専用サブドメインとSRVレコードを設定する
5. DNS変更が反映されるまで待ち、まずサブドメインで接続を試す

Java版のSRVを使う場合、TCPShield公式ガイドではSRVのポートをTCPShieldが受ける25565として設定し、バックエンドの実ポートはパネル側で対応させます。

SRVのtargetへ保護CNAMEを直接入れると無効なホスト名になる場合があるため、公式のDNS Setupの例をそのまま確認してください。

自宅側を直接接続できない状態にする

保護ホスト名から接続できることを確認したら、自宅ルーターやOSのファイアウォールで、ゲームポートへの接続元をTCPShieldのネットワークに絞ります。

許可するIP範囲はTCPShieldが公開しているIPv4リストを使い、記事や古い設定例を固定値として扱わないでください。

保護ホスト名から参加でき、TCPShield公式のチェック項目にある、バックエンドが起動していること、DNSが正しいこと、TCPShieldからの接続をファイアウォールが許可していることの3点を満たせば、Java版の基本構成を確認できます。

公式のSetup Checklistもあわせて確認してください。

実IPをログへ渡すか決める

中継を通すと、サーバー側から見える接続元が保護サービスのIPになることがあります。プレイヤーごとのIP banやログを使うなら、サービスのプラグイン方式またはPROXY protocol方式を選び、サーバー側の受け取り設定までそろえます。

TCPShieldの公式案内では、プラグインとPROXY protocolを同時に使えない構成に注意が必要です。どちらを使うかを先に決め、設定を重ねないでください。

接続できない場合は、まず保護を外して自宅サーバー自体が起動しているかを確認し、再び保護ホスト名へ戻します。

DNSを元へ戻すときも、自宅IPを新しい参加者へ広げないよう、直接公開へ戻す必要があるかを考えてから変更します。

VPSを中継させてiptablesで自宅IPを隠す構成を作る

ここからは、自分でLinuxを触ってネットワークを組みたい人向けの構成です。

Bedrock版やGeyserMCによるクロスプレイの自宅IPを現実的な費用で隠せるのはこの方法なので、クロスプレイ勢もここが本命になります。

自宅サーバーの手前にVPSを立て、外部からの接続をすべてVPSで受け止めてから自宅サーバーへ転送すれば、自宅IPを直接晒さずに公開できます。

クラウド上のVPSでパケットを中継する構成なら、Linux標準のiptablesで組むのが扱いやすい選択です。

作業は次の4つに分かれます。

• VPS側でパケット転送を有効にする
• iptablesでDNATとSNATの転送ルールを書く
• 自宅側のファイアウォールでVPSからの通信だけ許可する
• 中継経路の成功確認と戻し方

最初の3つがそろって初めて、外部から見えるIPがVPSのものだけになり、自宅IPが隠れます。

中継用のVPSがまだ手元にない場合は、root権限とSSHを自由に使える契約を選んでおくと、ここからの手順をそのまま実行できます。

VPS側でパケット転送を有効にする

VPSでパケット転送を有効にしないと、iptablesのルールを書いても通信が自宅サーバーまで届きません。

まず、コマンドで一時的に有効化します。

sudo sysctl -w net.ipv4.ip_forward=1

続けて、再起動後も設定を残すために/etc/sysctl.confへ恒久設定を追記します。

echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

設定値が1になっていることを、次のコマンドで確認してから次へ進みます。

sysctl net.ipv4.ip_forward

net.ipv4.ip_forward = 1と表示されれば、VPSはパケット転送を受け付ける状態だとわかります。

恒久設定の保存方法はディストリビューションによって異なるため、再起動後にも同じ値が保持されるかの確認が必要です。

iptablesでDNATとSNATの転送ルールを書く

Java版のTCP25565番を例にした最小構成は、DNATと戻り用のルールの2段階です。まずVPSに届いた通信の宛先を自宅サーバーへ書き換えるDNATルールをPREROUTINGに追加します。

sudo iptables -t nat -A PREROUTING -p tcp --dport 25565 -j DNAT --to-destination [自宅のグローバルIP]:25565

続けて、戻りの通信の送信元をVPS自身のIPへ書き換えるルールをPOSTROUTINGチェーンに加えます。

VPSのIPを明示して送信元を書き換える場合は、SNATを使います。

sudo iptables -t nat -A POSTROUTING -p tcp -d [自宅のグローバルIP] --dport 25565 -j SNAT --to-source [VPSのグローバルIP]

VPS側の送出インターフェースのIPを自動で判定させたい場合は、MASQUERADEを指定します。

sudo iptables -t nat -A POSTROUTING -p tcp -d [自宅のグローバルIP] --dport 25565 -j MASQUERADE

自宅のグローバルIPが変わる回線では、DNATの--to-destinationやPOSTROUTINGの宛先も新しいIPへ更新しなければ通信が届きません。

固定IPサービスを使うか、DDNSに合わせてルールを更新する仕組みをあらかじめ用意します。

Bedrock版やGeyserのUDP接続を中継する場合は、TCP用の-p tcpとJava版のポートをそのまま流用しません。

-p udpへ変更し、[GeyserのUDPポート]をPREROUTINGとPOSTROUTINGの両方へ同じように指定します。

sudo iptables -t nat -A PREROUTING -p udp --dport [GeyserのUDPポート] -j DNAT --to-destination [自宅のグローバルIP]:[GeyserのUDPポート]
sudo iptables -t nat -A POSTROUTING -p udp -d [自宅のグローバルIP] --dport [GeyserのUDPポート] -j MASQUERADE

VPSのクラウドファイアウォール、自宅ルーター、Geyserの待ち受け設定の3か所すべてでUDPを許可し、Bedrock端末を外部回線から使って確認します。TCPの疎通だけでBedrockも動くと判断しないでください。

DNATを書いても、VPSのFORWARDチェーンやクラウドファイアウォールで転送が拒否されていると、自宅サーバーへ届きません。

OSのファイアウォールを有効にしている場合は、対象ポートの転送を許可し、SSH接続用のポートまで閉じないように注意します。

自宅側のファイアウォールでVPSからの通信だけ許可する

自宅ルーターまたはOSのファイアウォールで、送信元IPをVPSの固定IPだけに絞り込みます。

VPS以外のIPから25565番宛てに届く通信は、すべて拒否する設定です。

これをやらないと中継の意味がなくなり、自宅IPへ直接攻撃されるリスクがそのまま残ります。

中継経路の成功確認と戻し方

設定後は、自宅と同じLANではなくスマホのテザリングなど外部回線から、VPSのIPまたはVPSに向けたドメインで接続します。

次の3点がそろえば、中継の基本動作を確認できます。

• Java版ならVPSのTCPポート、Bedrock版ならVPSのUDPポートへ参加できる
• 自宅サーバー側のログに接続が現れる
• 自宅のグローバルIPへ直接つないだ場合は、ゲームポートを受け付けない

確認用に、VPSのNATルール一覧を表示しておきます。

sudo iptables -t nat -S

運用へ移る前に、iptablesのルールも再起動後に残るよう環境に合った方法で保存し、再起動後に同じ一覧を確認してください。

接続できない場合は、まず自宅サーバーを直接起動しているか、次にVPSの転送設定、最後にファイアウォールの順で切り分けてください。

設定を撤回するときは、追加したルールと同じ条件で-Aを-Dに変えて1本ずつ削除します。

iptables -Fのように全ルールを消す操作は、SSH接続まで切れる可能性があるため行いません。

Cloudflare Spectrumは契約と原点設計が必要な上級構成

Cloudflare SpectrumをVPS中継の前段に置くと、接続先として見せるアドレスをCloudflare側へ寄せられます。

ただし、プラン・対象プロトコル・原点への接続方法をそろえる必要があり、初心者が設定画面だけで完結させる構成ではありません。

Cloudflareの公式ドキュメントでは、SpectrumでTCPとUDPのアプリケーションを扱える一方、プライベートネットワークの原点を使う場合は仮想ネットワークやCloudflare Tunnelなど別の準備が必要と説明されています。

公式のGet startedで、契約中のプランと原点の方式を先に確認してください。

確認するのは次の2点です。

• Spectrumを選ぶ前に決めること
• Spectrum構成の成功確認と撤回

どちらも決まっていないうちは、VPS中継の構成で止めておくほうが安全です。

Spectrumを選ぶ前に決めること

次の項目を決められない場合は、先にTCPShieldまたはVPS中継だけで運用します。

PROXY protocolを使う場合、Cloudflare公式ではTCPとUDPで方式が異なり、受け側の実装も必要とされています。

公式のProxy Protocol設定を確認せずに、PaperやHAProxyへ設定を足さないでください。

Spectrum構成の成功確認と撤回

Spectrumのホスト名からJava版へ参加でき、原点のVPSへ直接接続できない状態になって初めて、IP秘匿の目的を確認できます。Cloudflareの表示だけで成功と判断せず、外部回線から実際の参加テストまで行ってください。

接続できない場合は、原点のVPSが単独で動くか、Spectrumのプロトコルとポートが一致しているか、PROXY protocolを受け側が理解できるかの順に切り分けます。

撤回するときは、いきなり自宅IPへ戻さず、まずSpectrumを外したVPSの保護ホスト名へDNSを戻します。

HAProxyはJava版の複数VPSを設計できる人向け

人数が増えて1台のVPSでは足りなくなった場合、HAProxyでJava版のTCP接続を複数のバックエンドへ振り分ける構成を検討できます。

ただし、HAProxyを置くだけで自宅IPが隠れるわけではありません。HAProxy自身を外部公開の入口にし、各バックエンドがHAProxy以外から直接接続されないよう、VPSのファイアウォールと接続先の設計までそろえる必要があります。

HAProxyを選ぶ条件を確認する

Bedrock版・Geyserクロスプレイを守る目的で、Java版向けのTCP設定をそのままHAProxyへ流用しないでください。

UDPの対応可否、セッション維持、ヘルスチェック、契約先の許可範囲を確認できないなら、Bedrock版はVPS中継を土台にするほうが安全です。

1台のVPSで始める段階では、HAProxyを追加せず、まずVPS中継の成功確認とファイアウォールの閉じ方を終わらせます。複数台へ増やすときは、停止時間と切り戻し先を決めてから構成を変更します。

対策手段ごとの対応範囲を比較する

ここまでの対策について、難易度や対応範囲、必要な設計を一覧にまとめました。

どの構成でも、自宅側または原点側への直接接続を閉じられなければ、IP秘匿は完成しません。

表では、○は記事内の前提を満たした場合に利用できることを示します。要確認・要検証の項目は、契約内容や採用するバージョン・構成によって結果が変わるため、公式資料と実機テストが必要です。

方式ごとの成功判定と切り戻し先を決める

設定を終えたら、「接続できた」だけでなく、直接経路が残っていないことと、失敗時に戻せることまで確認します。

自宅IPを一度公開したあとで再び隠す場合、古いIPが知られている可能性があります。直接公開から保護構成へ移すときは、回線事業者へグローバルIPの変更可否を確認することも選択肢です。

自分でVPSを触りたくない、まずJava版だけ守りたい場合はTCPShieldから始めます。

Bedrock版・Geyserクロスプレイも守りたい、または自分の手でネットワークを組みたい場合は、VPS+iptables中継が土台です。

Cloudflare SpectrumとHAProxyは、そのVPS中継の上へJava版の防御や分散を上乗せする上級構成です。

ここまで自分で設計・検証できない場合は、無理に重ねずTCPShieldまたは単一VPS中継で止めます。

自宅サーバーを公開し続けるなら対策はどれを選ぶか

対策を重ねるほど設定の手間も増えるため、友達の人数、対策にかけられる時間、自宅IPが晒される不安のバランスで選びます。

身内だけの小規模サーバーでDDoSの不安が小さいなら、無理に何かを挟む必要はありません。

身内の数人で遊ぶだけなら、ポート開放して自宅IPを友達にだけ教えるのが一番早いです。

自宅IPが晒される不安のほうが大きいなら、Java版はTCPShield、Bedrock版はVPS中継から始めます。

覚えておきたいのは、VPS中継も万能ではない点です。

それでも設定を続けるのが負担なら、自宅の回線を晒さないレンタルサーバーへ移す選択も現実的に検討できます。

公開に使うIPが最初から自宅と切り離されるため、中継の設計そのものが不要になります。

よくある質問

まとめ：難易度に合わせて自宅IPを隠す対策を選ぶ

自宅サーバーのDDoS対策は、攻撃を正面から防ぐことではなく、自宅IPを外部から見えなくすることです。

• Java版だけならTCPShieldの対応プランを確認してから使う
• Bedrock版やGeyserのクロスプレイは、VPS中継とiptablesが現実的な選択肢
• Cloudflare SpectrumとHAProxyは、契約と原点の設計まで決められる場合にだけ重ねる
• どの構成でも、自宅側は中継元からの通信だけ許可する
• 設定の手間が負担なら、レンタルサーバーへ移して自宅IPを出さない方法もある

自宅IPが表に出ない状態にできれば、公開したあとも回線を落とされる心配をせずに遊べます。

自宅サーバーとレンタルサーバーの費用の違いは、自宅サーバーの電気代とレンタル料金の比較で整理しています。

中継の設計まで自分で決めきれない場合は、構築の相談も選択肢です。