DHCP・DNS・NAT障害の切り分け｜症状から原因を絞る確認手順を図解

2026年8月10日

ネットワーク中級編 39／全50記事

この記事は、「ネットワーク中級編｜構築・検証・障害切り分けを身につける」の第39回です。

前回は、ルーティングテーブルやデフォルトルート、戻り経路を確認し、レイヤー3の通信障害を切り分ける方法を学びました。今回は、その上で利用されるDHCP・DNS・NATを組み合わせて、「IPアドレスを取得できない」「名前でアクセスできない」「社内通信はできるがインターネットへ出られない」といった障害を切り分けます。

← 前の記事：ルーティング障害の切り分け中級編一覧次の記事：遅延・パケットロスの調査方法 →

DHCP・DNS・NAT障害の切り分け｜症状から原因を絞る確認手順を図解

「インターネットにつながらない」という申告だけでは、 DHCP、DNS、NATのどこに問題があるのか判断できません。重要なのは、いきなり設定を変更するのではなく、 IPアドレス取得、ゲートウェイ到達性、外部IP通信、名前解決、NAT変換という順序で正常な範囲を確認し、原因候補を狭めることです。

対象レベル Level 2・中級

想定読了時間 約35分

身につく成果 DHCP・DNS・NAT障害を順番に切り分けられる

前提知識 DHCP・DNS・NAT・ルーティング

演習環境 ブラウザ／Wireshark任意

現場では、利用者から「ネットにつながりません」「Webサイトが開けません」「PCを交換したら通信できなくなりました」といった曖昧な申告を受けることがあります。

このとき大切なのは、DHCP、DNS、NATを別々の暗記事項として考えるのではなく、 端末が外部サービスへ通信できる状態になるまでの処理としてつなげて考えることです。

この記事を読み終えるとできること

症状からDHCP・DNS・NATのどこを疑うか判断できる
DHCPでIPアドレスを取得できない原因を整理できる
IP通信とDNS障害を切り分けられる
NAT変換が行われているか確認できる
WiresharkでDHCP・DNS通信を確認できる
調査結果を根拠とともに報告できる

DHCP・DNS・NAT障害を一連の通信として考える

最初に覚える考え方

DHCP・DNS・NAT障害の切り分けでは、「IP設定を取得できたか」→「IPで通信できるか」→ 「名前を解決できるか」→「外部へ変換して出られるか」の順に確認します。

PCをネットワークへ接続し、Webサイトへアクセスするまでには、 DHCP・DNS・NATがそれぞれ異なる役割を担当します。

PCが外部サービスへ通信できるまで

📨 1．DHCP IPアドレス・GW・DNS情報を取得

🔎 2．DNS ホスト名からIPアドレスを取得

🌐 3．NAT 内部アドレスを外部通信用に変換

DHCP

通信設定を準備する

PCへIPアドレス、サブネットマスク、デフォルトゲートウェイ、 DNSサーバーなどの情報を配布します。

DNS

通信先を調べる

www.example.comのような名前から、実際に通信するときに使用するIPアドレスを調べます。

NAT

アドレスを変換する

社内で使用するプライベートIPアドレスを、インターネット側で使用するアドレスへ変換します。

DHCP・DNS・NATだけを見ればよいわけではありません。

VLAN、デフォルトゲートウェイ、ルーティング、ACL、ファイアウォール、物理リンクなどに問題があっても似た症状になります。そのため、前回までに学んだレイヤー2・レイヤー3の確認も必要です。

症状から最初に疑う場所を決める

障害対応では、すべての設定を最初から確認するのではなく、 利用者の症状から原因候補を絞ることが重要です。

症状	最初に疑う場所	主な確認内容
IPアドレスを取得できない	DHCP	DHCPサーバー、スコープ、DHCPリレー、VLAN
169.254.x.xになっている	DHCP	DHCP応答を受信できているか
デフォルトゲートウェイへpingできない	L2／L3	VLAN、ARP、IP設定、ポート、GW
外部IPには通信できるが名前では失敗する	DNS	DNSサーバー設定、DNS到達性、問い合わせ結果
社内通信はできるが外部IPへ通信できない	ルーティング／NAT	デフォルトルート、NAT対象、変換テーブル
NAT変換エントリが作成されない	NAT設定	inside/outside、ACL、NATルール、対象通信
一部端末だけ外部通信できない	DHCP／NAT／端末	配布設定、NAT対象範囲、個別IP設定

「名前で通信できない」と「IPで通信できない」は分けて考えます。

IPアドレスを直接指定すれば通信できる場合、ルーティングやNATよりもDNSを優先して確認できます。

共通の障害切り分け手順

DHCP・DNS・NATが関係しそうな障害では、次の順序で確認すると原因を絞りやすくなります。

端末のIP設定を確認する IPアドレス、サブネットマスク、デフォルトゲートウェイ、 DNSサーバーが想定どおり設定されているか確認します。
デフォルトゲートウェイへ通信できるか確認する ここで失敗する場合、DNSやNATより先に、 VLAN、ARP、IP設定、物理接続などを確認します。
外部のIPアドレスへ通信できるか確認する 名前を使用せず、IP通信そのものが成立するかを確認します。
DNSで名前解決できるか確認する nslookupなどを使って、 DNS問い合わせに正常な応答が返るか確認します。
NAT変換が作成されているか確認する 外部通信を発生させながら、 NATテーブルや変換カウンターを確認します。
必要に応じてパケットを取得する コマンド結果だけで判断できない場合は、 DHCP・DNS・NAT装置の内外でパケットを比較します。

実務で重要な考え方

「通信できないからDNSを再起動する」「NATがおかしそうだから設定を入れ直す」といった対応は避けます。まず正常な地点と異常な地点の境界を見つけてから設定を確認します。

DHCP障害の切り分け

DHCP障害では、最初に 端末が正しいIPアドレス情報を取得できているか を確認します。

DHCPの正常な流れを確認する

DISCOVER DHCPサーバーを探す

OFFER 利用可能なIPを提示

REQUEST 利用するIPを要求

ACK IPの利用を確定

DHCP障害では、 DORAのどこまで進んでいるかを見ることで原因候補を絞れます。

端末側で確認する

ipconfig /all

Windows端末では、特に次の項目を確認します。

IPv4アドレス
サブネットマスク
デフォルトゲートウェイ
DHCPサーバー
DNSサーバー
リース取得日時・有効期限

正常: 想定したサブネットのIPアドレスを取得している

異常例: 169.254.x.x、別VLANのアドレス、GWやDNSが空欄

DHCPを再取得する

ipconfig /release


ipconfig /renew

再取得を行いながら、DHCPサーバーやパケットキャプチャー側で DISCOVER、OFFER、REQUEST、ACKを確認すると効果的です。

DHCPサーバー側で確認する

Cisco IOS系ルーターをDHCPサーバーとして使用している場合の代表例です。

show ip dhcp binding


show ip dhcp pool
show running-config | section dhcp

確認項目	見るポイント
DHCPプール	対象ネットワークが正しいか
空きアドレス	払い出し可能なIPが残っているか
default-router	正しいデフォルトゲートウェイを配布しているか
dns-server	正しいDNSサーバーを配布しているか
binding	対象端末へアドレスが払い出されているか

DHCPリレーを使用している場合

DHCPサーバーがクライアントと別ネットワークにある場合、 DHCPリレーが必要な構成があります。

Cisco IOS系では、クライアント側インターフェースに設定された ip helper-addressなどを確認します。

show running-config interface Vlan10


show ip interface Vlan10

DHCP DISCOVERは通常ブロードキャストから始まるため、ルーターを越えた先のDHCPサーバーへそのまま届くとは限りません。サーバーが別サブネットにある場合は、リレー設定とサーバーまでのルーティングも確認します。

DHCP障害でよくある原因

DHCPプール枯渇

利用可能なIPアドレスがなく、新しい端末へ払い出せない状態です。

DHCPリレー設定ミス

リレー先IPが誤っている、または対象VLANに設定されていないケースです。

VLAN不一致

クライアントが想定外のVLANへ所属し、別のDHCP範囲へ入っているケースです。

配布オプションの誤り

IPは取得できても、デフォルトゲートウェイやDNSサーバーが誤っているケースです。

「IPを取得できた＝DHCPは完全に正常」とは限りません。

IPアドレスだけでなく、サブネットマスク、GW、 DNSサーバーなどの配布内容も確認してください。

DNS障害の切り分け

DNS障害を疑う前に、 IPアドレスを直接指定した通信が成功するかを確認します。

DNS障害を疑う典型例

IPアドレスでは通信できるのに、ホスト名やFQDNを使用すると通信できない。

まずDNSサーバー設定を確認する

ipconfig /all

DHCP環境では、DNSサーバーのIPアドレスも DHCPから配布されていることがあります。

そのためDNS障害に見えても、実際にはDHCPで誤ったDNSサーバーを配布している 場合があります。

DNSサーバーまで到達できるか確認する

ping <DNSサーバーIP>

ping応答の有無だけでDNSサービスの正常性を断定することはできませんが、 DNSサーバーへのIP到達性を確認する材料になります。

nslookupで直接問い合わせる

nslookup www.example.com

特定のDNSサーバーへ問い合わせる場合は、次のように指定できます。

nslookup www.example.com <DNSサーバーIP>

結果から原因を考える

状態	考えられること
正常にIPアドレスが返る	基本的なDNS名前解決は成功している
タイムアウト	DNSサーバーへの到達性、FW、UDP/TCP 53、DNSサービスを確認
NXDOMAIN	問い合わせた名前が存在しない、または名前が誤っている可能性
SERVFAIL	DNSサーバー内部や上位DNSへの問い合わせで問題が発生している可能性
別のIPが返る	DNSレコード、キャッシュ、参照DNSの違いなどを確認

「DNSかどうか」を切り分ける考え方

IP設定を確認 正しいDNSサーバーが設定されているか確認します。
DNSサーバーへの経路を確認 サーバーまでIPとして到達できるか確認します。
nslookupで問い合わせ ブラウザなどのアプリケーションとは切り離して、 DNS問い合わせだけを確認します。
問い合わせと応答をパケットで確認 Queryが送信され、Responseが戻っているか確認します。

DNSについては、中級編「22. DNS障害の切り分け」と「35. DNS通信をパケットで確認する」でも詳しく解説しています。

NAT障害の切り分け

NAT障害では、 外部通信を発生させたときに変換エントリが作成されているか が重要な確認ポイントです。

ただし、その前にデフォルトルートや外部インターフェースが正常であることも確認します。

まずルーティングを確認する

show ip route


show ip route 0.0.0.0

NATはアドレスを書き換える機能であり、パケットの転送先そのものを決める機能ではありません。外部への経路がなければ、NAT設定が正しくても通信できません。

NAT変換テーブルを確認する

show ip nat translations

外部通信を発生させながら確認し、内部アドレスに対応する変換エントリが作成されるかを見ます。

NAT統計を確認する

show ip nat statistics

製品・OSによって表示内容は異なりますが、 NAT対象インターフェース、変換数、ヒット数などを確認できる場合があります。

inside / outsideを確認する

Cisco IOS系のTraditional NATでは、インターフェースに設定された ip nat insideと ip nat outsideを確認します。

show running-config interface GigabitEthernet0/0


show running-config interface GigabitEthernet0/1

NAT対象を判定するACLを確認する

PATなどでACLを使ってNAT対象の内部アドレスを指定している場合、通信元サブネットがACLに含まれているか確認します。

show access-lists


show running-config | include ip nat

典型的な障害例

VLAN10のPCだけ外部通信できない状況で、 NAT用ACLにVLAN20のネットワークしか登録されていない場合、 VLAN10のパケットはNAT対象にならず、 show ip nat translationsにも期待する変換が作成されません。

NAT障害でよくある原因

inside / outsideの指定ミス

内部側・外部側インターフェースの役割が NAT設定と一致していない状態です。

NAT用ACLの不足

新しいVLANを追加したものの、 NAT対象ACLへネットワークを追加していないケースです。

外部経路がない

NAT変換以前に、デフォルトルートやISP側への経路が存在しないケースです。

戻り通信が処理できない

FW、ACL、ルーティング、NAT状態などの問題で、応答パケットが端末まで戻らないケースです。

NATテーブルをクリアするコマンドは、稼働中セッションへ影響する可能性があります。本番環境では、影響範囲と作業手順を確認せずに実行しないでください。

NAT単体の詳細は、「23. NAT障害の切り分け」もあわせて確認してください。

WiresharkでDHCP・DNS・NATを確認する

コマンドだけで原因を特定できない場合は、実際のパケットを確認すると「要求は送られているか」「応答は戻っているか」を判断できます。

DHCP

DISCOVER、OFFER、REQUEST、ACKがどこまで確認できるかを見ます。

udp.port == 67 || udp.port == 68

DNS

Queryが送信され、対応するResponseが戻っているかを確認します。

dns

NAT

NAT装置の内側と外側で取得し、送信元IPアドレスが変換されているか比較します。

ip.addr == 対象IP

DHCP：DISCOVERしか見えない場合

クライアントからDISCOVERは出ているのに OFFERが戻っていなければ、次の場所を疑います。

DHCPサーバーが停止している
DHCPリレーが設定されていない
リレー先IPが誤っている
サーバーまでのルーティングに問題がある
ACLやファイアウォールでDHCP通信が遮断されている
DHCPプールに空きがない

DNS：QueryはあるがResponseがない場合

DNS Queryが送信されているにもかかわらず Responseが返らない場合は、 DNSサーバーへの到達性、FW、DNSサービス、戻り経路などを確認します。

NAT：内側では見えるが外側では見えない場合

NAT装置へ内部パケットが到着しているのに、外側へパケットが出ていなければ、 NATルール、ルーティング、ACL、FWなど NAT装置内部の処理を重点的に確認できます。

パケット解析の目的は大量のパケットを眺めることではありません。 「どこまでは到達していて、どこから先が存在しないか」 を確認するために使います。

DHCP・DNS・NAT障害でよくある切り分けミス

いきなりDNSを疑う

Webサイトが開けないだけでDNS障害と判断せず、まずIP設定とIP通信を確認します。

pingだけで判断する

pingの結果だけでは、 DHCP、DNS、NAT、アプリケーションの正常性をすべて判断できません。

NAT設定だけを見る

NAT変換前にルーティングやACLで失敗している可能性もあります。通信経路全体を確認します。

IPを取得したらDHCP正常と判断する

GWやDNSサーバーなど、 DHCPで配布されたその他の情報も確認します。

設定変更から始める

正常状態の証跡を残さずに変更すると、原因と修正効果の区別が難しくなります。

複数障害の可能性を無視する

DHCPのDNS配布値が誤っており、さらにNAT設定も不足しているなど、複数の問題が同時に存在する場合もあります。

調査結果を根拠とともにまとめる

原因を特定したら、「直りました」だけで終わらせず、 症状・確認結果・原因・対応を整理します。

障害報告の例

事象：
VLAN10に所属するPCからインターネットへ接続できない。

確認結果：
DHCPによるIP・GW・DNS取得は正常。デフォルトゲートウェイへのpingも成功。外部IPへの通信は失敗し、ルーター上で対象PCのNAT変換エントリが生成されていなかった。

原因：
NAT対象を指定するACLへVLAN10のネットワークが登録されていなかった。

対応：
NAT対象ACLへVLAN10を追加し、外部通信およびNAT変換を確認した。

報告するときの4項目

何ができなかったか
どこまでは正常だったか
異常を確認した根拠は何か
どの対応で復旧したか

「NATが原因でした」だけでなく、「GWまでは正常、外部IP通信失敗、NAT変換なし、 NAT対象ACLから該当サブネットが欠落」と説明できると、調査の根拠が伝わります。

理解度チェック

次の6問に答えてください。答えを見る前に、どの機能を最初に疑うか考えてみましょう。

問題1．PCのIPアドレスが169.254.x.xになっています。最初に確認すべきものはどれですか。

NAT変換テーブル
DHCPによるアドレス取得
DNSレコード
WebサーバーのHTTPS設定

解答を見る

正解：B

Windows端末がDHCPなどから有効なIPv4設定を取得できていない可能性があるため、 DHCP通信や端末のIP設定を確認します。

問題2．外部IPアドレスには通信できますが、ホスト名を使用すると接続できません。最初に重点的に確認すべき機能はどれですか。

DNS
STP
EtherChannel
MACアドレステーブルのエージング

解答を見る

正解：A

IP通信が成立しているため、名前からIPアドレスを得るDNS処理を優先して確認します。

問題3．DHCPでIPアドレスを取得できました。これだけでDHCPは完全に正常と判断できますか。

解答を見る

正解：判断できません。

IPアドレスだけでなく、サブネットマスク、デフォルトゲートウェイ、 DNSサーバーなどの配布値も確認する必要があります。

問題4．外部通信を発生させても show ip nat translationsに対象端末の変換が表示されません。確認すべき項目を2つ挙げてください。

解答を見る

例：

NAT対象ACLに端末のサブネットが含まれているか
inside / outsideの指定が正しいか
NATルールが存在するか
対象パケットがNAT装置まで到達しているか

問題5．DHCP DISCOVERは確認できますが、 DHCP OFFERが確認できません。どこを確認しますか。

解答を見る

DHCPサーバー、DHCPプール、DHCPリレー、サーバーまでのルーティング、ACL・FWなどを確認します。クライアントからの要求は出ているため、その先で応答が生成・返送されない原因を調べます。

問題6．障害切り分けで、 DNSやNATを確認する前にデフォルトゲートウェイへの通信を確認する理由を説明してください。

解答を見る

ゲートウェイまで通信できなければ、 VLAN、ARP、端末IP設定など、 DNS・NATより手前の処理に問題がある可能性が高いためです。通信経路を順番に確認することで不要な調査を減らせます。

実践演習：3台のPCの障害原因を切り分ける

次のオフィスネットワークで、 3台のPCからそれぞれ異なる障害申告がありました。

演習構成

💻 クライアントLAN PC-A／PC-B／PC-C

🔀 ルーター DHCPリレー・ルーティング・NAT

☁️ サーバー／インターネット DHCP・DNS・外部Web

PC-A

IPv4 Address  : 169.254.31.25


Subnet Mask   : 255.255.0.0
Default GW    :
DNS Servers   :

パケットキャプチャーでは、 PC-AからDHCP DISCOVERは送信されていますが、 OFFERは確認できません。

PC-Aで最初に確認する場所と理由を書いてください。

PC-Aの解答を見る

DHCP系を確認します。

PC-AからDISCOVERは出ているため、 DHCPサーバー、DHCPリレー、サーバーまでの経路、 DHCPプールなどを確認します。

PC-B

IPv4 Address  : 192.168.10.22


Subnet Mask   : 255.255.255.0
Default GW    : 192.168.10.1
DNS Servers   : 192.168.10.53

Default GWへのping : 成功
外部IPへの通信      : 成功
nslookup            : タイムアウト

PC-Bで最初に確認する場所と理由を書いてください。

PC-Bの解答を見る

DNS系を確認します。

IP通信は成立しているため、 DNSサーバー192.168.10.53への到達性、 DNSサービス、UDP/TCP 53の通信、 DHCPで配布されたDNSサーバー値などを確認します。

PC-C

IPv4 Address  : 192.168.30.25


Subnet Mask   : 255.255.255.0
Default GW    : 192.168.30.1

Default GWへのping : 成功
外部IPへの通信      : 失敗

Router# show ip route 0.0.0.0
S* 0.0.0.0/0 via 203.0.113.1

Router# show ip nat translations
（PC-Cに対応するエントリなし）

NAT ACL:
permit 192.168.10.0 0.0.0.255
permit 192.168.20.0 0.0.0.255

PC-Cの原因候補を書いてください。

PC-Cの解答を見る

NAT対象ACLに192.168.30.0/24が含まれていないことが原因候補です。

PC-Cはゲートウェイまで通信でき、ルーターにはデフォルトルートもあります。しかしNAT変換エントリが生成されず、 NAT対象ACLにも192.168.30.0/24がありません。

実環境では設定変更前に、 NATルールとACLの関連付け、対象インターフェース、実際のパケット到達も確認します。

課題4．3台の調査結果を報告する

上司へ30秒程度で報告するつもりで、 PC-A・PC-B・PC-Cの状況をまとめてください。

PC-Aは＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿。
PC-Bは＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿。
PC-Cは＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿。

報告例を見る

PC-AはDHCP DISCOVERまでは確認できていますが、 OFFERを受信できていないため、DHCPサーバーまたはリレー経路を調査しています。

PC-BはIP通信自体は正常ですがDNS問い合わせがタイムアウトしているため、 DNSサーバーへの通信とサービス状態を確認しています。

PC-Cはゲートウェイとデフォルトルートは正常ですがNAT変換が生成されておらず、 NAT対象ACLから192.168.30.0/24が欠落していることを確認しました。

自分の言葉で説明する課題

後輩から「インターネットにつながらないとき、 DHCP・DNS・NATのどれから確認すればよいですか？」と聞かれました。 30秒程度で説明してください。

まず＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿。

説明例を見る

まず端末がDHCPなどから正しいIPアドレス、ゲートウェイ、 DNSサーバーを取得できているか確認します。次にゲートウェイと外部IPへの通信を確認し、 IP通信ができるのに名前だけ解決できなければDNSを調べます。外部IP通信自体が失敗する場合はルーティングやNATを確認し、 NAT装置では変換エントリが生成されているかを確認します。