3.7時刻同期とアドレス変換

時刻同期とアドレス変換は地味に見えて、障害調査そのものを成立させる基盤です。複数機器のsyslogを突き合わせて事象の因果を追うには、全機器の時計が揃っていなければなりません。またNATは、インターネット接続の要でありながら「変換されない」「戻りの通信だけ落ちる」といった方向性のある障害を生み、症状から設定の欠落を逆算する力が問われます。この節では、show ntp status と show ip nat translations という2つの出力を軸に、正常な姿と異常な姿の差分を読めるようにします。

3.7.1NTPの階層と同期状態

• NTP（UDP 123）はstratumという階層番号で基準からの距離を表す。stratum 0 はGPSや原子時計などの参照クロックそのもの、stratum 1 はそれに直接接続されたサーバ、以降1ホップ同期するごとに+1される。stratum 16 は「同期していない（無効）」を意味し、この値が見えたら時刻は信頼できない。
• 設定は上流を指す ntp server <ip>、自身を基準として振る舞わせる ntp master <stratum>、改ざん防止の ntp authenticate と鍵設定。検証は show ntp status で Clock is synchronized の有無・stratum値・reference（同期先）を、show ntp associations で候補一覧と選択された同期先（* 印）を確認する。
• よくある落とし穴は、同期に時間がかかること（数分オーダー）と、タイムゾーン設定（clock timezone）と同期は別物であること。NTPが正常でも表示時刻が9時間ずれているならタイムゾーンの問題である。またsyslogにミリ秒とタイムゾーンを含める service timestamps log datetime msec localtime show-timezone を入れておくと、機器間の相関が取りやすい。
• PTP（Precision Time Protocol・IEEE 1588）は、ハードウェアタイムスタンプを用いてサブマイクロ秒級の精度を実現する高精度同期プロトコル。グランドマスタを頂点に、バウンダリクロック（区間を分けて再配布）やトランスペアレントクロック（通過遅延を補正して転送）を組み合わせる。金融取引の記録や産業制御、放送などミリ秒では足りない用途で選ぶ。通常の機器ログの相関にはNTPで十分である。

3.7.2NATの4つのアドレス

• NATの用語は「どちら側のホストか（inside/outside）」×「どちら側から見た表記か（local/global）」の掛け合わせで理解する。inside local＝内部ホストの実アドレス（内側から見た内部）、inside global＝内部ホストが外から見えるアドレス（外側から見た内部＝変換後の公開アドレス）、outside global＝外部ホストの実アドレス、outside local＝外部ホストを内側から見せるアドレス（通常は outside global と同じ）。
• 種類は静的NAT（1対1固定・外部から特定サーバへアクセスさせたいとき）、動的NAT（プールから空きを割り当て・プール枯渇で新規接続が失敗する）、PAT（overload）（1つのグローバルアドレスをポート番号で多重化し多数の内部ホストを収容）。ip nat inside source list 1 interface GigabitEthernet0/0 overload のように overload を付けるとPATになる。
• 最も多い設定漏れがインタフェースの役割指定である。変換は ip nat inside を付けたインタフェースから ip nat outside を付けたインタフェースへパケットが通過するときに初めて起こる。ACLとプールが完璧でもどちらか一方の指定を忘れると変換は一切発生せず、show ip nat translations は空のままになる。これが「設定したのにNATされない」の定番原因である。

ある日、支社のインターネット接続が「一部の端末だけ繋がらない」という報告が入りました。まず切り分けの起点として、あなたは複数機器のsyslogを突き合わせようとしましたが、ルータとファイアウォールのログの時刻が約7分ずれていて因果が追えません。show ntp status を実行すると、ルータ側は Clock is synchronized, stratum 4 と正常でしたが、ファイアウォール側は stratum 16 と表示されていました。stratum 16 は「同期していない＝時刻は無効」を意味するので、まずここを直さなければ調査そのものが成立しません。上流NTPサーバへの到達性とUDP 123の通過を確認し、ntp server を正しく設定して数分待つと Clock is synchronized に変わり、ログの時刻が揃って相関が取れるようになりました。ここで「時刻がずれているだけだから後回しでいい」と判断するのは、調査の前提条件を欠いたまま推測を重ねることになり、遠回りになります。時刻が揃った状態で改めてログを見ると、繋がらない端末からの通信がルータでNATされていないことが分かりました。show ip nat translations を見ると、動作している端末の変換エントリは並んでいるものの、新規の変換が一定数以上増えていません。設定を確認すると、ip nat inside source list 1 pool BRANCH_POOL と書かれており、overload が付いていない動的NATでした。プールに含まれるグローバルアドレスの数を超える端末が同時に外部通信を試みたため、プールが枯渇して新規の変換が作れず、後から接続した端末だけが失敗していたのです。ここで「プールにアドレスを追加する」のも一つの解ですが、割り当て可能なグローバルアドレスが限られている以上、根本的な対処は overload を付けてPATにすることです。PATならポート番号で多重化するため、1つのグローバルアドレスで多数の内部ホストを収容できます。なお、もし症状が「一部の端末だけ」ではなく「どの端末も一切変換されない」であったなら、疑うべき場所は全く異なります。その場合は show ip nat translations が完全に空になるはずで、原因はプール枯渇ではなく、ip nat inside または ip nat outside のインタフェース指定漏れか、ACLが対象トラフィックに一致していないことです。「一部だけ／全部」という症状の広がりが、そのまま疑うべき層を教えてくれる——これがNATトラブルシュートの型です。

3.7.3この節のまとめ

• NTPはstratumが1ホップごとに+1、16は未同期。判定は show ntp status の Clock is synchronized。タイムゾーンは別設定
• PTP（IEEE 1588）はハードウェアタイムスタンプでサブマイクロ秒。ミリ秒精度で足りる機器ログ相関はNTPで十分
• NATはinside local＝内部実アドレス／inside global＝変換後の公開アドレス。ip nat insideとoutsideの両方が必須で、overloadでPAT（ポート多重化）になる