深夜2時のネットワーク障害を解決する：CIDR重複とDNSトラブルシューティングのガイド

Table of Contents

午前2時の悪夢：「すべてがダウンしている」時

火曜日の午前2時14分、私のスマートフォンが鳴り響きました。PagerDutyのアラートは端的にこう告げていました：CRITICAL - Database Connection Timeout。ノートPCを開く頃には、Slackのインシデント用チャンネルは、必死な様子の@channelメンションで溢れかえっていました。どうやら、新しいマイクロサービスのデプロイによって、アプリケーション層とプライベートサブネット内のRDSインスタンス間の接続が消失してしまったようです。

アドレナリンだけで乗り切れるのは最初だけです。極限まで疲労していると、脳はバイナリ計算を正確に処理できなくなります。私は基本的なネットワークロジックにさえ疑心暗鬼になっていました。「10.0.32.0/20には10.0.48.5が含まれるんだっけ？」「Terraformのスクリプトが、誤ってレガシーVPCのCIDRブロックと重複させてしまったのか？」本番環境で障害が発生している最中に、ナプキンの裏にIPレンジを書き出して計算している時間はありません。

根本原因：サブネット重複の隠れた危険性

踏み台サーバー（Jump box）にSSHでログインし、基本的な診断を開始しました。アプリケーションはデータベースに接続しようとしていましたが、パケットがどこかへ消えていました。ルーティングテーブルを確認すると、不審な点が見つかりました。最近、データ分析プロジェクトのために新しいVPCをピアリング接続したのですが、そのCIDRブロックが非常に近い値だったのです。

# 現在のルーティングテーブルを確認
ip route show

# 競合の原因はすぐに見つかりました
default via 10.0.0.1 dev eth0
10.0.16.0/20 dev eth1 proto kernel scope link src 10.0.17.5
10.0.32.0/20 via 10.0.0.1 dev eth0 # このルートがDBへのトラフィックを奪っていました

原因は、ネットワーク構築における典型的な失敗である「サブネットの重複」でした。新しいVPCピアリングのルートが、データベースへのパスを覆い隠して（マスキングして）いたのです。これを修正するには、利用可能なIPスペースを再計算し、既存の12個のサブネットと競合しない範囲を再割り当てする必要がありました。ここで手動計算を行うのはリスクが高すぎます。ビットを一つ間違えるだけで、インフラの半分を隔離してしまう可能性があるからです。

プレッシャー下で手動計算が失敗する理由

私は、優秀なシニアエンジニアが障害対応中にサブネットマスクを暗算しようとして、失敗する姿を何度も見てきました。そのほとんどが「オフバイワン（1件ずれ）」エラーです。使用可能な最初のIP、最後のIP、そしてブロードキャストアドレスを瞬時に特定する必要がありますが、IPv6を扱っている場合、その複雑さは圧倒的なものになります。

私は苦い経験から学びました。推測はやめるべきです。設定変更を適用（Apply）する前に、専用のツールを使ってネットワークアーキテクチャを検証してください。本番環境の復旧作業で切羽詰まっている時、睡眠不足の脳に頼らない「信頼できる情報源」が必要なのです。

解決策：迅速なサブネット計算とIP検証

重複を解消するために、10.0.0.0/16の割り当て内でクリーンな/22ブロックが必要でした。このブロックは、ピアリングされている他の5つのVPCとも衝突してはいけません。私は通常、こうしたツールにおけるプライバシーには非常に慎重です。内部ネットワークのトポロジーを、リモートサーバーにデータを記録するようなWebサイトに貼り付けるのは、セキュリティ監査のリスクを招くだけです。

このようなシナリオで、私は現在ToolCraftのサブネット計算機を使用しています。理由は単純で、100%クライアントサイドで動作するからです。すべてがブラウザ内で実行され、内部IPの範囲がマシンから外に出ることはありません。データ漏洩のリスクを冒さずにCIDRブロックの境界を可視化したいとき、これは救世主となります。

復旧のステップ・バイ・ステップ

競合の特定： 既存のサブネットを計算機に入力し、それらがどこで始まり、どこで終わるかを正確に把握します。
空き領域の探索： 10.0.128.0/22のような新しい候補となるCIDRブロックをテストし、10.0.32.0/20の範囲と重ならずに、必要な1,022個のホストを確保できるか確認します。
IPコンバーターによる検証： エラーログに10進数のIP（例：167772165）が表示されている場合は、それをドット付き10進表記に変換し直して、特定の失敗しているノードを特定します。

IPサブネット計算機を使用したことで、私たちの「新しい」ブロックがVPNゲートウェイ用の予約範囲を侵食していることに気づきました。範囲を安全な上位アドレスにずらし、Terraformの変数を更新して、ターゲットを絞ったデプロイを実行しました。

DNSとCLIツールによる検証

ルートが修正されたら、次はデータベースのDNSエンドポイントが正しいIPに解決されることを確認する必要があります。DNSキャッシュは厄介な問題として知られています。ネットワークが修正されても、アプリケーションが古い、壊れたアドレスに通信しようとし続けることがあるからです。

すぐにdigを実行してレコードを確認しました：

# 内部DNSの解決を確認
dig +short production-db.internal.company.com

# 古いIPが返される場合は、ローカルキャッシュをクリア
sudo systemd-resolve --flush-caches

ローカルでdigを実行できない場合は、オンラインのDNSルックアップツールが次善の策となります。これにより、ローカルネットワークの外からレコードがどのように見えるかを検証できます。TTLが期限切れになっているか、変更が実際に環境全体に伝播したかを確認するのに役立ちます。

プロフェッショナルのワークフロー：CLI + プライベートツール

障害を乗り切るコツは、単にコマンドを知っていることだけではありません。どのツールを最初に手に取るべきかを知っていることです。私の現在のスタックは、スピードと安全性のために最適化されています：

CLI (ip, dig, traceroute): サーバーから何が見えているか、即座にローカルで検証するために使用します。
クライアントサイドのオンラインツール: 計画と計算にはToolCraftを使用します。セキュリティを損なうことなく、IP変換やサブネット計算などの重労働を処理してくれます。
Infrastructure as Code (IaC): 修正が恒久的であり、文書化され、ピアレビューされていることを保証します。

なぜプライバシーが譲れないのか

多くのエンジニアが、適当な「フォーマッタ」サイトをメモ帳のように扱っています。しかし、内部IPはインフラ全体をマッピングするメタデータです。もしサイトがあなたの入力をログに記録していれば、それはセキュリティ上の脆弱性を作ったことになります。だからこそ、ページが読み込まれた後はオフラインで動作するツールを好んで使っています。これは、企業環境におけるユーティリティツールのゴールドスタンダードです。

最後に

午前3時30分までには、トラフィックは再び正常に流れ始めました。データベースの接続エラーは消え、レイテンシのグラフもようやく落ち着きました。修正自体は複雑なものではありませんでしたが、障害対応のプレッシャーの中では、適切なツールの存在が不可欠でした。サブネットマスクを計算する時も、JWTをデコードする時も、信頼できるプライベートなツールキットを持っておくことで、思考が追いつかないほど疲れている時でも致命的なミスを防ぐことができます。

次に真夜中にルーティングテーブルと睨めっこすることになったら、思い出してください。自分で計算しようとせず、計算機を使い、digで検証し、常に重複がないかダブルチェックすることを。