Client IP設定

このページで学ぶこと

• 使用中Interface Identification
• 実状態 IPv4 Address
• 実状態 IPv6 Address
• Prefix Verification
• Default Gateway Verification
• DNS Server 設定
• 実状態 vs 設定方式
• Windows ipconfig /all
• Windows DHCP Enabled
• macOS Network 確認情報
• Linux ip addr / ip route
• Linux 割り当て方式 / nmcli
• IPv4 Link-Local / APIPA
• IPv6 Link-Local Only
• 期待 vs 実際 Client設定

1. 期待値と実際の設定を比較する

単に、

IPアドレスが表示された

だけでは不十分です。

重要なのは、

期待値

と

実際値

です。

例えば、

期待値が、

IPv4
192.168.10.0/24

ゲートウェイ
192.168.10.1

DNS
192.168.10.53

アドレス割り当て
DHCP

なのに、

クライアントが、

IPv4
169.254.18.20

ゲートウェイ
なし

DNS
なし

なら、

明確な不一致があります。

2. 最初に使用中インターフェースを特定する

クライアントには、

Ethernet

Wi-Fi

VPNアダプター

仮想アダプター

Bluetoothネットワーク

ループバック

など、

複数のインターフェースが存在することがあります。

そのため、

正しいアドレスを探す

前に、

実際に通信へ使っている
インターフェースはどれか

を確認します。

3. 正しい設定が別インターフェースにあっても意味がない

例えば、

Ethernet
192.168.10.25/24

Wi-Fi
169.254.20.40/16

と表示されていても、

実際にクライアントがWi-Fiで接続しているなら、

確認対象は、

Wi-Fiインターフェース

です。

Ethernet側に正しいアドレスが残っていても、

現在のWi-Fi接続状態を説明しません。

4. インターフェース状態とIP設定を対応付ける

確認するときは、

インターフェース名

インターフェース状態

アドレス

プレフィックス

ゲートウェイ

DNS

を同じインターフェース単位で読みます。

例えば、

Ethernet
Media disconnected

Wi-Fi接続済み
192.168.10.25/24

なら、

現在見るべきなのはWi-Fi側です。

5. クライアントIP設定の基本確認項目

このページでは主に、

インターフェース

IPv4アドレス

IPv6アドレス

プレフィックス・サブネットマスク

デフォルトゲートウェイ

DNSサーバー

アドレス割り当て方式

を確認します。

これらを、

1項目ずつ独立して確認

するのではなく、

最終的に、

期待設定との
組み合わせ

として判断します。

6. IPv4アドレスと所属ネットワークを確認する

例えば、

期待ネットワークが、

192.168.10.0/24

なら、

192.168.10.25/24

はそのネットワークに属します。

一方、

192.168.20.25/24

なら、

期待ネットワークとは異なります。

7. IPアドレスだけで正否を判断しない

例えば、

192.168.10.25

というアドレスが正しく見えても、

プレフィックスが、

/16

なら、

期待する、

/24

とは異なります。

したがって、

アドレス
と
プレフィックス

をセットで確認します。

8. IPv4ではプレフィックスが同一サブネットかどうかの判断に影響する

IPv4クライアントは、

IPv4アドレス

サブネットマスク・プレフィックス長

を利用して、宛先が同一サブネットかどうかを判断します。

そのため、

誤ったプレフィックスは、

アドレスそのものが正しくても
通信へ影響する

可能性があります。

9. IPv4ではサブネットマスク表示にも対応する

Windowsでは、

サブネットマスク
255.255.255.0

のように表示される場合があります。

これは、

/24

に相当します。

したがって、

192.168.10.25
255.255.255.0

なら、

192.168.10.25/24

として読みます。

10. プレフィックス不一致の例

期待値：

192.168.10.25/24

実際値：

192.168.10.25/16

なら、

ホストアドレスは同じでも、

プレフィックスの不一致

です。

このページでは、

IPアドレスが合っているから正常

とは判断しません。

11. デフォルトゲートウェイを確認する

リモートネットワークへ通信するクライアントは通常、

デフォルトゲートウェイ

を必要とします。

例えば、

クライアント
192.168.10.25/24

ゲートウェイ
192.168.10.1

という構成を期待するなら、

クライアントのデフォルトゲートウェイが、

192.168.20.1

では不一致です。

12. IPv4のデフォルトゲートウェイは通常同一サブネット内にある

例えば、

クライアント
192.168.10.25/24

なら、

通常のEthernet・Wi-Fiクライアントネットワークでは、

ゲートウェイも、

192.168.10.0/24

内に存在することを期待します。

例えば、

192.168.10.1

です。

13. ゲートウェイが空欄の場合も確認する

クライアントに、

IPv4アドレス
192.168.10.25

サブネットマスク
255.255.255.0

デフォルトゲートウェイ
空欄

という状態があれば、

ローカルサブネット内だけ

リモートネットワークへは
デフォルトルートがない

可能性があります。

このページではまず、

ゲートウェイ設定が
期待どおり存在するか

を確認します。

14. IPv6のデフォルトルーターはリンクローカルの場合がある

IPv6では、デフォルトルーターとして、

fe80::...

のようなリンクローカルアドレスが表示されることがあります。

これは、

デフォルトルーターがリンクローカル
=
異常

という意味ではありません。

IPv6ではルーターのリンクローカルアドレスをネクストホップとして使用できるため、IPv4と同じ感覚で誤設定と判断しないことが重要です。

15. DNSサーバーアドレスも確認する

クライアントは通常、

DNSサーバーアドレス

を保持しています。

例えば、

期待値：

DNS
192.168.10.53

実際値：

DNS
192.168.20.53

なら、

DNS設定の不一致です。

16. DNS設定確認と名前解決試験を分ける

このページでは、

どのDNSサーバーが
クライアントへ設定されているか

を確認します。

一方、

example.comを
実際に名前解決できるか

という試験は、

ページ034とページ035の接続トラブルシューティング側で扱います。

したがって、

DNSアドレスが正しい

=
名前解決が必ず成功する

とはまだ判断しません。

17. 静的設定とDHCPを区別する

クライアントアドレス設定には、

代表的に、

静的設定

DHCP

があります。

確認すべきなのは、

現在見えているアドレス

だけではなく、

クライアントがどの方法で
アドレスを取得する設定か

です。

18. 実際のアドレスと設定方式は別の情報

例えば、

クライアントに、

192.168.10.25

が設定されていても、

そのアドレスだけを見て、

静的設定

または

DHCP

を必ず判定できるとは限りません。

同じIPv4アドレスは、

静的設定

DHCPリース

のどちらでも存在し得ます。

19. 「DHCP Enabled」は設定方式を見る情報

Windowsの、

ipconfig /all

では、

アダプターごとに、

DHCP Enabled

を確認できます。

例えば、

DHCP Enabled. . . . . . : Yes

なら、

そのアダプターはIPv4設定を、

DHCPによって取得する設定

であることを確認できます。

20. 「DHCP Enabled: Yes」でも正常にリース取得済みとは限らない

重要なのは、

DHCP Enabled
Yes

が、

DHCP設定モード

を示す情報だということです。

これは単独では、

有効なリースを
正常取得できた

ことまで保証しません。

例えば、

DHCP Enabled
Yes

IPv4
169.254.x.x

という組み合わせもあり得ます。

21. Windowsではipconfig /allを中心に確認する

Windowsクライアントでは、

ipconfig /all

が主要な確認コマンドです。

代表的には、

アダプター名

DHCP Enabled

IPv4アドレス

サブネットマスク

IPv6アドレス

デフォルトゲートウェイ

DNSサーバー

などを確認できます。

22. Windows出力はアダプター単位で読む

例えば、

Ethernet adapter Ethernet:

   Media State . . . . . . . : Media disconnected

と、

Wireless LAN adapter Wi-Fi:

   IPv4 Address. . . . . . . : 192.168.10.25

が同時に表示される場合があります。

そのため、

アドレスだけ検索する

のではなく、

どのアダプターの情報か

を確認します。

23. Windows ipconfig /allの基本例

Wireless LAN adapter Wi-Fi:

   DHCP Enabled. . . . . . . . . : Yes
   IPv4 Address. . . . . . . . . : 192.168.10.25
   Subnet Mask . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . : 192.168.10.1
   DNS Servers . . . . . . . . . : 192.168.10.53

期待値が、

DHCP

192.168.10.0/24

ゲートウェイ
192.168.10.1

DNS
192.168.10.53

なら、

表示された設定は期待値と整合します。

24. Windowsではアドレスだけでなく全項目を確認する

次の状態を考えます。

IPv4
192.168.10.25

サブネットマスク
255.255.255.0

ゲートウェイ
192.168.10.254

DNS
192.168.10.53

期待ゲートウェイが、

192.168.10.1

なら、

IPv4アドレス
正しい

プレフィックス
正しい

DNS
正しい

ゲートウェイ
誤り

です。

25. WindowsでDHCPを期待するのに「DHCP Enabled: No」の場合

期待値：

アドレス割り当て
DHCP

実際値：

DHCP Enabled
No

なら、

現在のアドレス値が一見正しくても、

設定方式が期待と異なる

と判断できます。

26. Windowsで静的設定を期待するのに「DHCP Enabled: Yes」の場合

期待値：

静的設定

実際値：

DHCP Enabled
Yes

なら、

実際の設定方式

が期待値と異なります。

このページでは、

たまたま正しいアドレスを取得した

だけで正常とは判定しません。

27. IPv4リンクローカルアドレスを確認する

IPv4リンクローカルには、

169.254.0.0/16

の範囲があります。

Windowsでは、DHCPなどから期待するIPv4設定を取得できない場合に、APIPAによって169.254.x.xのアドレスが自動設定されることがあります。

企業ネットワークでDHCPによる通常のIPv4アドレスを期待しているのに169.254.x.xが表示された場合は、期待する設定を取得できていない重要な手掛かりになります。

28. APIPAはWindowsの自動プライベートIPアドレス割り当て

APIPAは、Automatic Private IP Addressingの略です。

WindowsクライアントがDHCPによるIPv4自動取得に設定されている一方で、期待するDHCPアドレスを取得できなかった場合、

169.254.x.x

が自動設定されることがあります。

このアドレスを確認したら、DHCP設定と実際の取得結果を分けて確認します。

29. 169.254.x.xだけでDHCPサーバー故障と断定しない

例えば、

169.254.15.20

を見つけても、

原因を即座に、

DHCPサーバー障害

と断定しません。

可能性には、

クライアント側設定

物理リンクや無線リンク

VLANやネットワーク経路

DHCPリレー

DHCPサーバー

などがあります。

このページでは、

期待するアドレスを取得していない

というクライアント実状態までを識別します。

30. このページではDHCPメッセージ交換を深掘りしない

このページで必要なのは、

DHCP設定なのか

実アドレスは何か

期待アドレスと一致するか

です。

Discover

Offer

Request

ACK

の詳細な手順は、

ページ036以降で扱います。

31. APIPAでもローカル通信が完全に不可能とは限らない

169.254.0.0/16はIPv4リンクローカル用の範囲です。

そのため、

169.254.x.x
=
NICが完全に動作していない

とは限りません。

ただし、企業ネットワークで192.168.10.0/24など別のIPv4ネットワークを期待しているのに169.254.x.xしかない場合は、期待設定との不一致です。

32. IPv6アドレスも実状態を確認する

IPv6では、1つのインターフェースに複数種類のアドレスが存在することがあります。

代表例は、

リンクローカル
グローバルユニキャスト
ULA

です。

したがって、単に「IPv6アドレスがある」と見るのではなく、期待する種類のIPv6アドレスを持っているかを確認します。

33. IPv6リンクローカルアドレスを確認する

IPv6インターフェースでは、

fe80::/10

のリンクローカルアドレスが使用されます。

リンクローカルアドレスは、同一リンク内の通信や近隣探索などで利用されるため、その存在自体は通常の状態です。

34. リンクローカルが存在すること自体は障害ではない

例えば、

fe80::1234:5678:abcd:ef01

が表示されても、

IPv6障害

とは判断しません。

IPv6では、

リンクローカルアドレスが通常存在します。

35. 「IPv6リンクローカルのみ」が重要になる場面

期待値：

グローバルIPv6アドレス
2001:db8:10::/64

実際値：

fe80::...
のみ

なら、

期待するIPv6アドレス割り当てが
成立していない可能性

があります。

重要なのは、

リンクローカルがあること

ではなく、

期待するグローバル・ULAアドレスが
ないこと

です。

36. IPv6リンクローカルのみでも常に異常とは限らない

ネットワーク要件が、

リンクローカルのみ

なら、

リンクローカルのみでも正常な場合があります。

したがって、

fe80::しかない
=
必ず障害

ではありません。

このページでは常に、

期待値と実際値

で判断します。

37. IPv6プレフィックスも確認する

期待値：

2001:db8:10::25/64

実際値：

2001:db8:10::25/56

なら、

アドレス部分が同じように見えても、

プレフィックスの不一致

です。

IPv4と同様、

アドレス
と
プレフィックス

で確認します。

38. IPv4とIPv6を別々に確認する

デュアルスタッククライアントでは、

IPv4は正常、IPv6は異常

あるいは、

IPv4は異常、IPv6は正常

という状態もあります。

したがって、

一方のプロトコルが正常
=
クライアントIP設定全体が正常

とは限りません。

39. WindowsではIPv4とIPv6を同じアダプター内で読む

ipconfig /allでは、

同じアダプターに、

IPv4アドレス

IPv6アドレス

Link-local IPv6アドレス

などが表示される場合があります。

そのため、

どのプロトコルの
どのアドレスか

を区別します。

40. macOSではネットワーク設定を中心に確認する

macOSでは、

システム設定

→ ネットワーク

から、

使用中インターフェースについて、

IPアドレス

サブネットマスク・プレフィックス

ルーター

DNS

DHCPと手動設定

などを確認できます。

OSバージョンによって画面名称や配置が多少異なることがありますが、

確認する情報は同じです。

41. macOSでも使用中のネットワークサービスを確認する

例えば、

Ethernet

Wi-Fi

の両方が存在する場合、

現在使用中のネットワークサービスを確認します。

別サービスに設定されたアドレスを見て、

現在の通信を判断しないようにします。

42. macOSでDHCPと手動設定を区別する

macOSではTCP/IP設定から、IPv4の設定方式を確認できます。

代表的には、

Using DHCP

Manually

のように表示されます。

ここでは、現在割り当てられているアドレスだけでなく、DHCPによる自動取得なのか手動設定なのかも合わせて確認します。

43. macOSではCLIからアドレスの実状態も確認できる

macOSではGUIだけでなくCLIからも実状態を確認できます。

例えば、

ifconfig

でインターフェースのアドレスを確認し、

route -n get default

でデフォルトルート情報を確認できます。

このページでは特定のmacOSバージョンの画面名称を暗記するより、必要なクライアント設定情報を取得できることを重視します。

44. macOSでもGUIと実状態を分けて考える

例えば、

GUIで、

Configure IPv4
Using DHCP

となっていても、

実際のアドレスが、

169.254.x.x

なら、

DHCP設定ではある

しかし期待するDHCPアドレスを
取得できていない

と整理できます。

45. Linuxではip addrでアドレスの実状態を確認する

Linuxでは、

ip addr

が基本確認コマンドです。

例えば、

2: eth0:
    inet 192.168.10.25/24
    inet6 fe80::....

から、

インターフェース

IPv4アドレス

IPv4プレフィックス

IPv6アドレス

などを確認できます。

46. Linuxではip routeでルートを確認する

Linuxでは、

ip route

から、

IPv4ルートを確認できます。

例えば、

default via 192.168.10.1 dev eth0
192.168.10.0/24 dev eth0

なら、

デフォルトゲートウェイ
192.168.10.1

インターフェース
eth0

を確認できます。

47. ip addrだけでDHCPか静的設定かを断定しない

ip addrが、

192.168.10.25/24

を表示しても、

そのアドレスが、

静的設定

DHCP

のどちらから設定されたかを、

アドレス値だけで必ず断定できるわけではありません。

48. ip routeだけでも設定方式は確定しない

例えば、

default via 192.168.10.1

というルートは、

静的設定

DHCPによる設定

のどちらでも存在し得ます。

そのため、

実状態

と、

設定方式

を分けて確認します。

49. NetworkManager環境ではnmcliを利用できる

NetworkManagerを使用するLinuxでは、nmcliから接続プロファイルやデバイスの設定を確認できます。

例えば、

nmcli connection show --active

で、現在アクティブな接続を確認できます。

50. アクティブな接続プロファイルを確認する

Linuxクライアントに複数の接続プロファイルが存在していても、確認すべきなのは現在アクティブなプロファイルです。

例えば、

Office
Home
Test

の3つが登録されていても、非アクティブなプロファイルが正しいだけでは現在の接続状態を説明できません。

51. nmcliでアドレス設定方式を確認する

NetworkManagerでは、接続プロファイルの設定方式を確認できます。

例えば、

ipv4.method auto

ならIPv4を自動取得する設定で、

ipv4.method manual

なら手動設定です。

したがって、

ip addr
→ 現在のアドレス状態

nmcli
→ 設定方式

というように、実状態と設定方式を分けて確認できます。

52. IPv6でも設定方式と実状態を分けて確認する

IPv6でも、現在割り当てられているアドレスと設定方式は別の情報です。

例えば、自動設定を期待しているのに、

リンクローカルアドレスしかない

場合は、期待するグローバルユニキャストアドレスやULAを取得できていない可能性があります。

設定方式と実際のIPv6アドレスを分けて確認します。

53. DNSサーバーはOSごとに表示方法が異なる

Windowsでは、

ipconfig /all

macOSでは、

ネットワーク設定

Linuxでは、

NetworkManagerなどの
クライアント設定

から、

DNSサーバー情報を確認できます。

重要なのはコマンド名を揃えることではなく、

実際のDNS設定

を取得して期待値と比較することです。

54. OSが違っても確認項目は同じ

確認対象は、

同じネットワーク層情報

です。

55. 期待する設定を先に整理する

実状態を確認する前に、可能であれば次の期待値を整理します。

使用するインターフェース
IPv4ネットワーク
IPv6プレフィックス
デフォルトゲートウェイ
DNSサーバー
アドレス割り当て方式

期待値が分からない状態では、表示された値が正しいかどうかを判断できません。

クライアント設定確認の基本は、

期待値を把握する
↓
実際値を取得する
↓
比較する

です。

56. 期待値と実際値の比較表を作る

例えば、次のように整理します。

この例では、デフォルトゲートウェイが期待値と異なります。

表にすると、どの項目が一致し、どの項目が不一致かを切り分けやすくなります。

57. 複数の不一致が同時に存在することもある

例えば、

期待値
IPv4 192.168.10.0/24
ゲートウェイ 192.168.10.1
DNS 192.168.10.53

実際値
IPv4 169.254.22.8/16
ゲートウェイなし
DNS なし

なら、アドレス、プレフィックス、ゲートウェイ、DNSの複数項目が期待値と異なります。

不一致は1つだけとは限りません。

58. クライアント設定確認では最初の異常だけで停止しない

例えば、誤ったデフォルトゲートウェイを見つけても、同時にDNS設定も間違っている可能性があります。

このページでは、

使用中インターフェース
IPv4アドレス
IPv6アドレス
プレフィックス
デフォルトゲートウェイ
DNS
設定方式

を一通り確認し、期待値との不一致をまとめて識別します。

59. 問題パターン1：Windowsの主要確認コマンド

WindowsでアダプターのIP設定全体を確認したい

使用する代表コマンドは、

ipconfig /all

です。

単純な、

ipconfig

より、

DHCP EnabledやDNSサーバーなどを含む、

詳細情報を確認できます。

60. 問題パターン2：使用中アダプターを読む

Ethernetは切断、Wi-Fiにはアドレスとゲートウェイがある

この場合、

現在のクライアント設定を確認する対象は、

Wi-Fiアダプター

です。

別アダプターのアドレスに惑わされません。

61. 問題パターン3：プレフィックスだけが違う

アドレスは同じだがサブネットマスクが異なる

期待値：

192.168.10.25/24

実際値：

192.168.10.25/16

なら、

プレフィックスの不一致

です。

62. 問題パターン4：デフォルトゲートウェイだけが違う

IPアドレスとサブネットマスクは正しいがゲートウェイが違う

期待値：

ゲートウェイ
192.168.10.1

実際値：

ゲートウェイ
192.168.10.254

なら、

ゲートウェイ設定不一致

です。

63. 問題パターン5：DNSだけが違う

アドレス・プレフィックス・ゲートウェイは正しい

期待値：

DNS
192.168.10.53

実際値：

DNS
192.168.20.53

なら、

DNS設定の不一致

です。

この時点では、

名前解決試験までは行いません。

64. 問題パターン6：169.254.x.x

DHCPネットワークで169.254.x.xが表示された

これは、

IPv4リンクローカル・APIPA

として認識します。

期待するDHCPアドレスを取得できていない可能性があります。

65. 問題パターン7：APIPAの意味を過剰解釈しない

169.254.x.xを見つけた

正しい説明は、

期待するIPv4アドレス割り当てが
成立していない可能性がある

です。

単独で、

DHCPサーバーが停止している

と断定するのは早すぎます。

66. 問題パターン8：IPv6リンクローカルのみ

グローバルIPv6を期待しているがfe80::だけ

この場合、

リンクローカル自体は正常

しかし期待するグローバル・ULAがない

と整理します。

67. 問題パターン9：Linuxのアドレスとプレフィックス

LinuxクライアントのIPv4アドレスとプレフィックスを確認する

代表コマンドは、

ip addr

です。

例えば、

inet 192.168.10.25/24

を読みます。

68. 問題パターン10：Linuxのデフォルトゲートウェイ

Linuxクライアントのデフォルトルートを確認する

代表的なコマンドは、

ip route

です。

例えば、

default via 192.168.10.1 dev eth0

なら、192.168.10.1を経由し、eth0を使用するデフォルトルートを確認できます。

69. 問題パターン11：Linuxの設定方式

アドレスがDHCPか手動設定か確認したい

NetworkManager環境では、nmcliからアクティブな接続プロファイルと、

ipv4.method
ipv6.method

などを確認します。

現在のアドレスだけでなく、どの方式で設定されるようになっているかを確認します。

70. 問題パターン12：実際のアドレスだけでは設定方式を断定しない

Linuxで192.168.10.25/24が表示された

ip addrで、

inet 192.168.10.25/24

と表示されても、それだけではDHCP取得か静的設定かを必ずしも判定できません。

設定元や接続プロファイルを別途確認します。

71. 問題パターン13：macOSの設定方式

macOSでクライアントIP設定を確認する

macOSのネットワーク設定では、主に次を確認します。

使用中インターフェース
IPv4アドレス
IPv6アドレス
プレフィックス
ルーター
DNS
DHCPまたは手動設定

現在値と設定方式を合わせて確認します。

72. 問題パターン14：macOSでIPv6とゲートウェイを確認する

IPv6アドレスとルーター情報を確認したい

ネットワーク設定や標準のネットワーク情報から、

IPv6アドレス
プレフィックス
ルーター

を確認します。

IPv6ではリンクローカルのルーターアドレスが表示されることがあるため、fe80::...という値だけで誤設定と判断しません。

73. 問題パターン15：OSごとの確認方法を選ぶ

Windows、macOS、Linuxでクライアント設定を確認する

代表的な確認方法は、

Windows
→ ipconfig /all

macOS
→ ネットワーク設定、ifconfig、route

Linux
→ ip addr、ip route、nmcli

です。

OSごとにコマンドや画面は異なっても、確認する項目は共通しています。

74. 問題パターン16：複数項目を比較する

IPアドレスだけでなくプレフィックス、ゲートウェイ、DNSも確認する

クライアント設定は、

アドレス
プレフィックス
デフォルトゲートウェイ
DNS
設定方式

を組み合わせて判断します。

1項目が正常でも、クライアント設定全体が正常とは限りません。

75. 問題パターン17：正しいインターフェースを選ぶ

複数アダプターにアドレスがある

最初に、現在通信へ使用しているインターフェースを特定します。

非アクティブなアダプターに正しいアドレスが残っていても、現在の通信状態を判断する材料にはなりません。

76. 問題パターン18：IPv4とIPv6のリンクローカルを区別する

IPv4 169.254.x.xとIPv6 fe80::が表示された

169.254.0.0/16
→ IPv4リンクローカル

fe80::/10
→ IPv6リンクローカル

です。

IPv6リンクローカルアドレスは通常存在するため、WindowsのAPIPAと同じ意味として扱わないことが重要です。

77. 問題パターン19：「DHCP Enabled」と実際のアドレスを組み合わせる

Windowsで「DHCP Enabled: Yes」、アドレスは169.254.x.x

この場合、

設定方式
→ DHCPによる自動取得

実際のIPv4状態
→ 169.254.x.xのリンクローカルアドレス

です。

つまり、DHCPを使用する設定ではあるものの、期待するDHCPアドレスを取得できていない可能性があります。

78. よくある誤判断

誤り1：IPアドレスが表示されていれば設定は正常

プレフィックス、デフォルトゲートウェイ、DNS、設定方式も確認します。

誤り2：正しいIPが別アダプターにあるので正常

現在使用中のインターフェースの設定を確認する必要があります。

誤り3：192.168.10.25なら/24に決まっている

プレフィックスは別の情報です。

誤り4：ゲートウェイが存在すれば値は何でもよい

期待するデフォルトゲートウェイと一致しているかを確認します。

誤り5：DNSサーバーアドレスがあるので名前解決は成功する

設定値と実際の名前解決結果は別に確認します。

誤り6：アドレス値から静的設定かDHCPかを必ず判定できる

同じアドレスは静的設定でもDHCPリースでも存在し得ます。

誤り7：「DHCP Enabled: Yes」なら有効なリースを取得済み

これはDHCPを使用する設定であることを示します。正常なリース取得まで保証しません。

誤り8：169.254.x.xならNIC故障

IPv4リンクローカルやAPIPAとしてアドレスが設定されている可能性があります。

誤り9：169.254.x.xならDHCPサーバー故障で確定

クライアント設定、リンク、VLAN、リレー、DHCPサーバーなど複数の原因候補があります。

誤り10：IPv6でfe80::があるのは異常

リンクローカルアドレスの存在自体は通常です。

誤り11：fe80::しかなくても常に正常

グローバルユニキャストアドレスやULAを期待する環境なら不一致です。

誤り12：IPv6のデフォルトゲートウェイがfe80::なら誤設定

IPv6ではルーターのリンクローカルアドレスをネクストホップとして使用できます。

誤り13：Linuxのip addrだけでDHCPか静的設定かを断定できる

ip addrは主に現在のアドレス状態を確認するために使います。設定方式は別途確認します。

誤り14：ip routeはアドレス設定方式を示す

ip routeはルートの実状態を示します。アドレスの設定方式とは別の情報です。

誤り15：非アクティブなプロファイルが正しければLinux設定は正常

現在アクティブな接続プロファイルを確認します。

誤り16：Windowsではすべてのアダプター情報をまとめて読む

アダプター単位で、状態と設定を対応付けて読みます。

誤り17：macOSではGUIしか確認方法がない

GUIを中心に確認できますが、CLIから実状態を確認することもできます。

誤り18：IPv4が正常ならIPv6も正常

IPv4とIPv6は別々に確認します。

誤り19：クライアントIP設定確認の時点で根本原因まで確定する

この段階では、まず期待する設定と実際の設定の不一致を識別します。必要に応じて後続の接続試験やDHCP診断へ進みます。

79. クライアントIP設定の比較表

80. Windowsの確認手順

ipconfig /all
↓
使用中アダプターを特定
↓
DHCP Enabledを確認
↓
IPv4アドレスを確認
↓
サブネットマスクを確認
↓
IPv6アドレスを確認
↓
デフォルトゲートウェイを確認
↓
DNS Serversを確認
↓
期待する設定と比較

ipconfig /allでは複数のアダプターが表示されるため、まず使用中のアダプターを特定してから、そのアダプターの値をまとめて確認します。

81. macOSの確認手順

ネットワーク設定を開く
↓
使用中インターフェースを確認
↓
TCP/IP設定を確認
↓
IPv4とIPv6を確認
↓
プレフィックスを確認
↓
ルーターを確認
↓
DNSを確認
↓
DHCPか手動設定かを確認
↓
期待する設定と比較

必要に応じてifconfigやroute -n get defaultも使い、GUIの設定と実際の状態を対応付けます。

82. Linuxの確認手順

ip addr
↓
アドレスとプレフィックスを確認
↓
ip route
↓
デフォルトルートを確認
↓
アクティブな接続を確認
↓
nmcliなどで設定方式を確認
↓
DNS設定を確認
↓
期待する設定と比較

ip addrやip routeで実状態を確認し、NetworkManager環境ではnmcliなどから設定方式も確認します。

83. OSが違っても確認の考え方は共通

Windows、macOS、Linuxでコマンドや画面は異なりますが、確認する順序は共通しています。

使用中インターフェース
↓
IPv4・IPv6アドレス
↓
プレフィックス
↓
デフォルトゲートウェイ
↓
DNS
↓
設定方式
↓
期待値と実際値を比較

コマンド名そのものより、「何を確認しているか」を理解することが重要です。

84. このページで判断できる範囲

このページでは、例えば次のようなクライアント設定上の不一致を識別できます。

誤ったIPv4アドレス
誤ったIPv6アドレス
誤ったプレフィックス
誤ったデフォルトゲートウェイ
誤ったDNSサーバー
誤った設定方式
APIPA
IPv6リンクローカルのみ

一方、クライアント設定が正しいと分かった後に、実際のパケットがどこで止まっているかまでは、このページだけでは判断しません。

85. 次のページで扱う有線接続の確認

ページ034では、有線クライアントの接続確認として、

リンク状態
デフォルトゲートウェイへの到達性
リモートIPへの到達性
ping
traceroute
DNS名前解決
障害範囲の切り分け

などを扱います。

このページでは、その前提となるクライアント自身のIP設定確認に集中します。

86. 後続ページで扱う無線接続の確認

ページ035では、無線クライアントの接続確認として、

無線アダプター
無線機能
SSID
対応周波数帯
WLANへの接続
セキュリティ方式
認証情報
802.1X
無線診断

などを扱います。

そのため、このページではSSIDの可視性、WPA3設定、アクセスポイントへの関連付けなどを中心には扱いません。

87. 後続ページで扱うDHCPの詳細

ページ036以降では、DHCPv4クライアントとDHCPサーバーの動作として、

DORA
UDP 67と68
DHCPリレー
giaddr
DHCPメッセージ

などを扱います。

このページでは、DHCPを使用する設定かどうか、期待するDHCPアドレスを取得しているかどうかまでを確認します。

88. 最終判断の手順

クライアント接続問題
↓
使用中インターフェースを確認
↓
IPv4アドレスを確認
↓
IPv6アドレスを確認
↓
プレフィックスを確認
↓
デフォルトゲートウェイを確認
↓
DNSサーバーを確認
↓
DHCPか手動設定かを確認
↓
期待値と実際値を比較

ここで不一致があれば、クライアントIP設定上の問題として識別できます。

不一致がなければ、後続ページで到達性、経路、DNS名前解決、無線接続などの確認へ進みます。

89. 最終的に判断できるようにすること

このページでは最終的に、次のことを判断できるようにします。

• 複数のインターフェースから使用中のインターフェースを特定できる
• Windowsでipconfig /allを使ってクライアント設定を確認できる
• WindowsのDHCP Enabledを設定方式として解釈できる
• IPv4アドレスを期待するネットワークと比較できる
• IPv6アドレスを期待するアドレス種別と比較できる
• IPv4のサブネットマスクをプレフィックスとして解釈できる
• 期待するプレフィックスと実際のプレフィックスを比較できる
• デフォルトゲートウェイの有無と値を確認できる
• IPv6のデフォルトルーターがリンクローカルアドレスでも正常な場合があると判断できる
• DNSサーバーアドレスを期待値と比較できる
• DNS設定確認と実際の名前解決試験を区別できる
• 実際のアドレスと静的設定・DHCPという設定方式を別情報として扱える
• 169.254.0.0/16をIPv4リンクローカルとして認識できる
• WindowsのAPIPAをDHCP設定との関係で説明できる
• 169.254.x.xだけでDHCPサーバー故障と断定しない
• IPv6リンクローカルアドレスの存在自体は通常であると認識できる
• グローバルユニキャストアドレスやULAを期待する環境で、IPv6リンクローカルしかない状態を不一致として識別できる
• macOSのネットワーク設定からクライアント設定を確認できる
• Linuxでip addrからアドレスとプレフィックスを確認できる
• Linuxでip routeからデフォルトルートを確認できる
• Linuxでnmcliなどからアクティブな接続とアドレス設定方式を確認できる
• ip addrやip routeだけからDHCPか静的設定かを断定しない
• Windows、macOS、Linuxで同じ確認項目を対応付けられる
• 期待値と実際値の比較から複数の不一致を識別できる
• クライアントIP設定確認と、有線接続・無線接続・DHCPメッセージ診断を分けて考えられる

まとめ

クライアント接続のトラブルシューティングでは、最初にクライアント自身のIP設定を確認します。

重要なのは、表示された値を見るだけでなく、

期待値
と
実際値

を比較することです。

最初に使用中のインターフェースを特定し、次に、

IPv4アドレス
IPv6アドレス
プレフィックス
デフォルトゲートウェイ
DNSサーバー
アドレス割り当て方式

を確認します。

Windowsではipconfig /all、macOSではネットワーク設定やifconfig・route、Linuxではip addr・ip route・nmcliなどを使います。

IPv4で169.254.x.xが表示された場合はIPv4リンクローカルとして認識し、WindowsのDHCPクライアントではAPIPAの可能性を考えます。ただし、169.254.x.xだけでDHCPサーバー故障と断定しません。

IPv6ではfe80::/10のリンクローカルアドレス自体は通常です。一方、グローバルユニキャストアドレスやULAを期待しているのにリンクローカルしかない場合は、期待するIPv6設定を取得できていない可能性があります。

最終的には、

使用中インターフェース
↓
IPv4とIPv6
↓
プレフィックス
↓
デフォルトゲートウェイ
↓
DNS
↓
静的設定かDHCPか
↓
期待値と実際値を比較
↓
クライアント設定の不一致を識別

という順序で確認します。