はじめに

自宅のUbuntuサーバでKVMを使ってWindowsを立てたときの話です。

何気なくVMを起動しただけでしたが、
その直後にマインクラフトサーバの外形監視がNGになりました。

マインクラフトサーバの外形監視の方法については以下の記事にまとめています。

■ 事象

KVMでWindowsを起動
マインクラフトの外形監視がアラート（NG）
ただし、サーバ自体は動いている

最初はこう思いました。

「サーバが落ちた？」

でも、違いました。

■ 内部と外部で見え方が違う

内部から確認すると、サーバは正常に動いていました。

コンテナも起動している
ローカルからは接続できる
内部監視もOK

つまり、

👉 中は正常

一方で、

外部（AWS）からの監視はNG
外から接続できない

👉 外からは異常

この時点で、切り分けの方向が決まります。

■ 切り分けのポイント

今回の分岐はシンプルでした。

👉 「中の問題か？」ではなく
👉 「外との境界の問題ではないか？」

ここでやったことはシンプルです。

tcpdumpで通信を確認
iptablesを確認
ルーティングを確認

■ 調査ログ（抜粋）

実際に確認したログを一部マスクして掲載します。

tcpdump（外部パケット確認）

$ sudo tcpdump -i enp12s0 udp port 19132

IP 192.168.*.*.***** > 192.168.*.255.19132: UDP, length 33
IP 192.168.*.*.***** > server-host.19132: UDP, length 33
IP server-host.19132 > 192.168.*.*.*****: UDP, length 146

内部からの通信は確認できましたが、
外部からのパケットは一切観測されませんでした。

👉 外から届いていないことが確定

iptables（NAT確認）

$ sudo iptables -t nat -L -n

DNAT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:19132 to:172.*.*.*:19132

ポートフォワーディング自体は正常に設定されていました。

👉 ホストまでは来ていれば転送される状態

ip route（ルーティング確認）

$ ip route

default via 192.168.*.1 dev enp12s0
192.168.*.0/24 dev enp12s0 src 192.168.*.*

ルーティングも正常で、通信経路に問題は見当たりませんでした。

■ ログから分かること

内部通信は正常
iptablesも正常
ルーティングも正常

👉 にもかかわらず外部から届かない

この時点で、

👉 サーバの中ではなく
👉 外側で止まっている

と判断できました。

■ 原因

原因は、ルータ側でした。

KVM起動によるネットワークの変化で、
ルータのNATテーブルが崩れていたようです。

ルータを再起動したところ、あっさり復旧しました。

■ 学び

今回のポイントはシンプルです。

👉 中は正常、外からは異常

この状態に気づけるかどうかで、
切り分けのスピードは大きく変わります。

もし「サーバが悪い」と思い込んでいたら、

Dockerを疑い
OSを疑い
設定を疑い

と、かなり遠回りしていたと思います。

■ まとめ

内部監視だけでは不十分
外形監視だけでも不十分
両方見て初めて“ズレ”に気づける

監視は「検知」だけでなく、

👉 比較して違和感に気づくためのもの

そう感じたトラブルでした。

■ おわりに

今回のようなケースは、

仮想化（KVM）
Docker
家庭用ルータ
UDP通信

が重なると、意外と起きます。

「なんかおかしい」

と思ったときに、

👉 内と外、どちらの視点で見ているか

を一度意識してみると、
切り分けが一気に進むかもしれません。