はじめに
自宅の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通信
が重なると、意外と起きます。
「なんかおかしい」
と思ったときに、
👉 内と外、どちらの視点で見ているか
を一度意識してみると、
切り分けが一気に進むかもしれません。