SNATを通った通信は、server側では通常、変換後のsource IPから来たように見えます。そのため複数clientが同じSNAT IPへ集約されると、server logのsource IPだけでは元clientを一意に特定できず、NAT translation logとtimestamp・portを突き合わせます。
⭕️インフラエンジニアが
NATで理解しておきたいこと✅️SNATとDNATの利用例
NATと聞くと、
なんとなく
IPアドレスを変換する仕組み
として覚えがち。でも現場では、
「どの向きの通信で、何を変換するのか」
を見ることがかなり大事。まずSNAT。
SNATは、
Source NAT。つまり、… pic.twitter.com/lKpy1yxt4X
— けんと＠設計構築チャンネル (@yeiquer12) 2026年6月18日
SNAT通信では外部サーバーから見える送信元が社内PCではなくFWのグローバルIPになると説明したポスト。
SNAT後の通信元IPはサーバーからどう見える？
先に答えると、SNATを通った通信は、server側では通常、変換後のsource IPから来たように見えます。そのため複数clientが同じSNAT IPへ集約されると、server logのsource IPだけでは元clientを一意に特定できず、NAT translation logとtimestamp・portを突き合わせます。
元のclientをどう特定する？
仕組みを構成上の位置と観測点に分けると、用語だけでなく実際のpacket・stateを説明できます。
| 項目 | 仕組み・役割 | 実務での判断 |
|---|---|---|
| client IP | 変換前source | NAT装置内のinside local |
| SNAT IP | 変換後source | server access logで見えるaddress |
| source port | PAT時の識別材料 | timestampと合わせる |
| X-Forwarded-For | proxyが付与するheader | trusted proxyで上書き管理が必要 |
Client 10.0.0.20:51500 → SNAT 203.0.113.20:40001 → Server 198.51.100.10:443
NAT log: before/after 5-tuple + time
Server log: 203.0.113.20:40001 + timeserver logとNAT logをどう照合する？
server logとNAT logをどう照合する？では、対象と期待値を固定し、状態取得、実通信、変更後確認の順に進めます。commandは例であり、本番投入前に対象OSの公式資料と現行設定を確認してください。
| STEP | 実施内容 | 確認する結果 |
|---|---|---|
| 1 | server logの時刻・source IP/port・destinationを取得 | sessionを特定 |
| 2 | 時刻同期とtimezoneを確認 | logずれを補正 |
| 3 | NAT translation/logで5-tupleを逆引き | 元client候補 |
| 4 | DHCP/VPN/proxy logへ必要な場合だけ進む | identityを裏付け |
show ip nat translations verbose
show ip nat statistics
# Web access log例
203.0.113.20:40001 - - [04/Aug/2026:20:15:03 +0900] "GET /health HTTP/1.1" 200NAT event time=2026-08-04T20:15:03+09:00
original_src=10.0.0.20:51500
translated_src=203.0.113.20:40001
dst=198.51.100.10:443proxy headerは信用してよい？
一つの表示だけで原因を決めず、症状ごとに次の観測点を選びます。正常時の同条件出力が比較基準です。
| 症状・誤り | 主な原因候補 | 次に確認すること |
|---|---|---|
| 同じSNAT IPが多数 | IPだけでclient特定不可 | port・time・destination |
| log時刻がずれる | NTP/timezone差 | device clockとoffset |
| translation消失 | session終了・log未保存 | central logとretention |
| XFFをそのまま信用 | client偽装 | trusted proxyでheader再生成 |
調査用logをどう設計する？
調査可能性は障害後に追加できません。NAT装置とserverのNTP、session log項目、保持期間、access権限を設計段階で決めます。個人情報を含むlogは目的と保管期間を限定します。
- 対象機器・interface・VRF/VLAN
- 取得日時・timezone・software version
- 変更前後の同一command出力
- 期待値・実測値・判定者
- 異常時の停止条件とrollback結果
関連する仕組みを次に確認する
定義だけで終わらせず、隣接する仕組みと障害切り分けへ進みます。
まとめ：時刻と変換前後5-tupleでserver logをNAT logへ結ぶ
時刻と変換前後5-tupleでserver logをNAT logへ結ぶことが結論です。構成図、設定・command、正常時と異常時の結果を同じ条件で保存し、第三者が判断を再現できる状態にしてください。
