なぜクライアントOS側の確認が必要か

ネットワークのトラブルシューティングでは、ルータ・スイッチ側の設定だけでなく、実際に通信できないと訴えているクライアント端末側のIP設定を確認することが欠かせません。「そもそも正しいIPアドレスが割り当てられているか」「デフォルトゲートウェイ・DNSサーバーの設定は正しいか」といった基本情報は、クライアントOSのコマンドから直接確認できます。CCNAでは、クライアントのIPアドレス、プレフィックス長（サブネットマスク）、デフォルトゲートウェイ、DNSなどを確認し、疎通障害を切り分ける考え方を押さえておく必要があります。WindowsのipconfigやLinuxのipなどの代表的な確認コマンドも関連付けて理解するとよいでしょう。

Windowsでの確認

Windowsでは、コマンドプロンプトからipconfigコマンドを使います。

C:\> ipconfig /all

イーサネット アダプター イーサネット:
   DHCP 有効               : はい
   IPv4 アドレス . . . . . . : 192.168.1.20
   サブネット マスク . . . . : 255.255.255.0
   デフォルト ゲートウェイ  : 192.168.1.1
   DHCP サーバー . . . . . . : 192.168.1.1
   DNS サーバー . . . . . . : 8.8.8.8

ipconfig（オプション無し）だけでも、IPアドレス・サブネットマスク・デフォルトゲートウェイの概要は確認できますが、/allオプションを付けることで、DHCPの有効・無効、DNSサーバーアドレス、MACアドレス（物理アドレス）、DHCPサーバーアドレスなど、より詳細な情報まで確認できます。

macOS・Linuxでの確認

ifconfigコマンド

macOSおよび多くのLinuxディストリビューションでは、伝統的にifconfigコマンドが使われてきました。

$ ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    inet 192.168.1.30 netmask 0xffffff00 broadcast 192.168.1.255
    ether ac:de:48:00:11:22

ip addrコマンド

多くの近年のLinuxディストリビューションでは、ifconfigを含むnet-toolsパッケージが非推奨・非搭載となっており、代わりにiproute2パッケージのipコマンドが標準的に使われますLinuxディストリビューションによってはifconfigコマンド自体が標準ではインストールされていない場合があります。CCNAの出題範囲では、ifconfigとip addrの両方について、それぞれどのOSで一般的に使われるコマンドかを押さえておくとよいでしょう。[1]。

$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    inet 192.168.1.30/24 brd 192.168.1.255 scope global eth0

いずれのコマンドでも、IPv4アドレス・サブネットマスク（またはプレフィックス長）・MACアドレスなどのインターフェイス情報を確認できます。ただし、ifconfig・ip addrのどちらも、デフォルトゲートウェイやDNSサーバーの情報は表示しません。これらを確認するには、それぞれ別のコマンドを使う必要があります。

デフォルトゲートウェイの確認（Linux・macOS）

Linuxでは、ip routeコマンドでルーティングテーブルを表示すると、defaultで始まる行にデフォルトゲートウェイのアドレスが表示されます。

$ ip route
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.30

default via 192.168.1.1の部分が、このホストのデフォルトゲートウェイが192.168.1.1であることを示しています。macOSを含め、netstat -rnコマンドでも同様にルーティングテーブルを確認でき、Destination列がdefaultまたは0.0.0.0になっている行のGateway列から、デフォルトゲートウェイのアドレスを読み取れます。表記はOSやコマンド実装によって異なります。

DNSサーバーの確認（Linux・macOS）

Linuxでは、DNSリゾルバの設定が記述された/etc/resolv.confファイルの内容をcatコマンドで直接確認できます。

$ cat /etc/resolv.conf
nameserver 8.8.8.8

nameserverで始まる行に、設定されているDNSリゾルバのアドレスが列挙されます。ただし、systemd-resolvedなどがこのファイルを管理する構成では、127.0.0.53のようなローカルスタブリゾルバが記載され、実際の上流DNSサーバーは別の設定で管理される場合があります。

macOSでは、scutil --dnsコマンドでDNS設定を確認します。

$ scutil --dns
DNS configuration
resolver #1
  nameserver[0] : 8.8.8.8
  ...

scutil --dnsの出力は、複数のresolverブロックが表示されるなど比較的長くなりますが、各ブロック内のnameserver[0]のような行でDNSサーバーのアドレスを確認できます。resolverブロックはドメインやインターフェイスごとに適用される場合があるため、問い合わせる名前に応じて使用されるDNSサーバーが異なることがあります。

nslookupによる名前解決の確認（Windows・macOS・Linux）

nslookupコマンドは、指定したホスト名の名前解決を実際に試みるコマンドで、Windows・macOSでは通常利用でき、Linuxでもインストールされていれば利用できます。Linuxではディストリビューションや導入パッケージによっては標準でインストールされていない場合があります。また、出力形式はOSや実装によって異なることがあります。

$ nslookup www.example.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Name:   www.example.com
Address: 93.184.216.34

Server行には問い合わせ先のDNSサーバー、Name／Address行には名前解決の結果（実際のIPアドレス）が表示されます。DNSサーバーの設定自体が正しいかどうかにとどまらず、「名前解決が実際に機能しているか」を確認できるコマンドとして覚えておきましょう。

確認すべき主なIPパラメータ

OSの種類によらず、クライアント端末のトラブルシューティングで確認すべき基本的なIPパラメータは共通しています。

  • IPアドレス：端末に割り当てられているIPv4／IPv6アドレス
  • サブネットマスク（またはプレフィックス長）：所属するサブネットの範囲
  • デフォルトゲートウェイ：自分のサブネット外の宛先へ通信する際に、最初に送るルータのアドレス
  • DNSサーバーアドレス：ドメイン名をIPアドレスへ変換する際に問い合わせる先
  • DHCPの有効・無効：DHCPクライアントが有効かどうか。DHCPが有効でもサーバーからリースを取得できない場合は、IPv4リンクローカルアドレス（APIPA）が設定されることがあるため、実際に割り当てられたIPアドレスも併せて確認する

静的設定とDHCP自動取得の見分け方

Windowsのipconfig /allでは「DHCP 有効」の項目で判別できます。値が「いいえ」であれば、そのアダプタのIPv4設定ではDHCPを使用していないことを示します。IPv6の自動設定の有無は、この項目だけでは判断しません。ある端末だけ通信できない場合、まずIPv4アドレスの取得方法を確認し、DHCPで正しくアドレスが払い出されているか、あるいは静的設定に誤りがないかを切り分けることが、トラブルシューティングの基本的な出発点になります。

補足

  1. Linuxディストリビューションによってはifconfigコマンド自体が標準ではインストールされていない場合があります。CCNAの出題範囲では、ifconfigとip addrの両方について、それぞれどのOSで一般的に使われるコマンドかを押さえておくとよいでしょう。 ↩