無料インスタンスの安否報告
以前Oracle Cloudで作成したインスタンスの安否報告
前回の記事で月末の更新を予定していましたが、諸々立て込んでいて一日遅れになってしまいました。
Oracle Cloudで作成したインスタンスの安否についてと、ここ1ヶ月でサーバ関連で実施した作業内容をざっくり書いていきます。
前回の記事の続きなので、まだ前回の記事を読んでない方は下記のリンクからどうぞ。（宣伝）
https://blog.ctsetera.dev/posts/2026-10-04-01/
インスタンスは…
1カ月経過しても生きています！！！！
とりあえず1カ月持ちこたえてくれてよかったですね。
サーバでゲームを遊ぶためにはポートを開放する必要がありますが、 やはり外部にポートを開放しておくとポートスキャンなどの攻撃に晒されてしまいます。
私の検証した限り、TShock（Terrariaのサーバアプリケーション）のポートに 4秒程度の間隔でSYNパケットを送りつけるだけで60秒ほどで落とせてしまいました。*1
DoS攻撃ですらないbotのノックで落ちます。
このままではゲームサーバとしては致命的ですし、他にも攻撃の手段は色々あるわけで…。
結局どうしたかというと、Terrariaを含むさまざまなゲームに対応したリバースプロキシサーバを提供してくれる
playit.ggを利用することにしました。
無料で利用できます。ただし、無料ユーザは、好きなリージョンを選択できないなどの制約があります。
Oracle Cloud同様、こちらも導入から今日まで無料で使わせていただいております。ありがとうございます。
参考までに、playitサーバ ⇔ ゲームサーバのpingの結果を貼っておきます。
4 packets transmitted, 4 received, 0% packet loss, time 3004msrtt min/avg/max/mdev = 8.606/8.696/8.818/0.080 msただし、これも日によっては結果が大きく変わってしまうかもですね。
一応、無料ユーザでもリソースに空きがあれば近くのリージョンを優先的に割り当ててくれるようですが。
ゲームサーバとクライアントの間にリバースプロキシサーバが入ることによって、こちら側でゲーム用のポートを開放する必要がなくなりました。
ちょうどこれの対応が終わった次の週くらいから、某言語の脆弱性発見や某大手IT企業へのサイバー攻撃などが話題に上がり始めましたね。
大事になる前に早めに手を打っておいてよかったです。
ゲーム用のポートを閉じたので、こちらも閉じておこうと思いまして。
ちなみにOracle Cloudでインスタンスを作成した直後の状態では、22番ポートは開放されています。
これを閉じて、普段はTailscale越しにsshし、sshdすら死んでしまったときのために、OCIコンソール上からもログインできるようにしておきました。
負荷試験…と言うと、どことなくカッコイイ響きですが、ただゲームで遊んだだけですｗ
負荷試験中は、以下のスクリプトを実行してCPUとRAMの使用率をチェックしていました。
while true; do timestamp=$(date '+%Y-%m-%d %H:%M:%S')
cpu=$(top -bn1 | awk '/Cpu\(s\)/ {print 100 - $8}')
ram=$(free | awk '/Mem:/ {printf "%.2f", $3/$2 * 100}')
echo "$timestamp CPU=${cpu}% RAM=${ram}%"
sleep 1done | tee loadtest_$(date +%Y%m%d_%H%M%S).log./benchmark.shOracle Cloudのインスタンスがかなりハイスペックなので（特にメモリ）、 身内同士でTerrariaをプレイする程度なら全く問題ない負荷状況でした。
2026-10-11 06:46:30 CPU=60% RAM=38.53%2026-10-11 06:46:31 CPU=55.9% RAM=38.53%2026-10-11 06:46:32 CPU=40% RAM=38.53%2026-10-11 06:46:33 CPU=43.3% RAM=38.53%2026-10-11 06:46:35 CPU=48.5% RAM=38.53%2026-10-11 06:46:36 CPU=46.9% RAM=38.53%2026-10-11 06:46:37 CPU=46.9% RAM=38.53%2026-10-11 06:46:38 CPU=45.5% RAM=38.52%2026-10-11 06:46:39 CPU=45.5% RAM=38.52%2026-10-11 06:46:40 CPU=40% RAM=38.52%2026-10-11 06:46:42 CPU=43.3% RAM=38.52%2026-10-11 06:46:43 CPU=51.6% RAM=38.52%2026-10-11 06:46:44 CPU=44.1% RAM=38.52%2026-10-11 06:46:45 CPU=46.4% RAM=38.52%2026-10-11 06:46:46 CPU=43.3% RAM=38.52%2026-10-11 06:46:48 CPU=54.8% RAM=38.53%2026-10-11 06:46:49 CPU=43.3% RAM=38.53%2026-10-11 06:46:50 CPU=51.4% RAM=38.54%2026-10-11 06:46:51 CPU=41.9% RAM=38.54%2026-10-11 06:46:52 CPU=45.5% RAM=38.54%2026-10-11 06:46:53 CPU=41.4% RAM=38.54%2026-10-11 06:46:55 CPU=46.9% RAM=38.55%2026-10-11 06:46:56 CPU=46.9% RAM=38.55%2026-10-11 06:46:57 CPU=45.5% RAM=38.56%2026-10-11 06:46:58 CPU=46.7% RAM=38.56%2026-10-11 06:46:59 CPU=41.4% RAM=38.56%2026-10-11 06:47:00 CPU=47.1% RAM=38.56%2026-10-11 06:47:02 CPU=41.9% RAM=38.56%2026-10-11 06:47:03 CPU=46.9% RAM=38.56%2026-10-11 06:47:04 CPU=45.5% RAM=38.56%2026-10-11 06:47:05 CPU=45.5% RAM=38.56%2026-10-11 06:47:06 CPU=41.9% RAM=38.56%2026-10-11 06:47:08 CPU=45.7% RAM=38.60%2026-10-11 06:47:09 CPU=40.6% RAM=38.59%2026-10-11 06:47:10 CPU=45.5% RAM=38.59%負荷試験はこれで問題なし…としたいところではありすが、 リバースプロキシを噛ませるようにしたため通信経路が増えてしまいました。
リバースプロキシ導入前後でテストプレイをみんなで実施したのですが、 リバースプロキシ導入後、友人の環境では少なからずラグが発生していたようです。*2
もしラグが気になるようであれば、Tailscale越しにゲームサーバに直接アクセスしてもらう方法も検討中です。
ここ最近、脆弱性についてのニュースをよく耳にしますよね。
先月発見された脆弱性で自分のサーバに影響がありそうだったものというと、
Tailscale SSHとMultipath TCPの脆弱性くらいだと思います。
幸い、私はTailscale SSHもMultipath TCPも使用しておらず、念のため確認しましたが両方ともオフでした。
とりあえず、先月末の時点で配布されているパッケージのアップデートをしてrebootしておきました。 *3
次回の更新は未定ですが、年内にはワールドデータをCloudflare R2に自動バックアップするスクリプトを用意して、 問題がなければ来年頭くらいに今遊んでいるワールドデータをサーバに仮移行する予定です。
ここ最近、VimキーバインドとNeovimのカスタマイズがマイブームなので、いつかその話もブログでしたいですね。
この記事もWSL上のAlmaLinux 10にインストールしたNeovimで執筆しています。
厳密にはたぶん落ちているわけではない。
私はDockerイメージでTShockを構築しているのですが、 ゲーム用のポートに雑にアクセスをすると、Dockerイメージ内のTS/Thockが ゲーム用のポート（デフォルトでは7777）をListenしなくなります。
判断基準は「体感できるかどうか」です。
ただ、実際にテストプレイをした後で、playitサーバのIPにpingコマンドを打ってもらうと15msほどで返ってきていました。
pingコマンドの応答速度=オンラインゲームの応答速度ではないですが、参考までに。
なお、自分がdnf upgradeした段階ではまだMultipath TCPの脆弱性に対応したカーネルの更新が来ていなかったので、 今月は情報をチェックしておいて、更新が来たらすぐに対応したいです。