Q

社内ネットワークでDHCPサーバーを使用し,Windowsクライアントへ動的にIPアドレスを付与しています。このクライアントを社外のネットワークに接続するときに障害が発生しています。社外のネットワークにもDHCPサーバーが配備されていますが,IPアドレスの動的割り当てが行われず,サーバーに接続できません。DHCP環境では,ネットワークが変化すれば新しいIPアドレスが自動的に割り当てられると聞いています。今回の現象はどんな原因で発生するのでしょうか。

A

Windowsクライアントでは,接続先のネットワークが変更されてもIPアドレスの再割り当てが行われないことがあります。具体的には,最初に接続していたネットワークと次に接続したネットワークで,デフォルト・ゲートウエイのIPアドレスが同じで,クライアントに対して過去に付与したIPアドレスがいずれのデフォルト・ゲートウエイともpingで通信可能なケースが該当します。

 一般に,TCP/IPネットワークでコンピュータ同士が通信するときには,IPアドレス,サブネット・マスク,デフォルト・ゲートウエイなどが正しく設定されている必要があります。単にデフォルト・ゲートウエイのアドレスが同一でpingによる通信が可能であっても,サブネット・マスクやDNS(ドメイン・ネーム・システム)サーバーなどのアドレスが違えばサーバーと通信できません。

 この障害が発生したときは,新しく接続したネットワークで,IPアドレスの割り当てを強制的に実行して,正しいネットワーク設定を取得してください。例えば,クライアント・マシンのコマンド・プロンプトで「ipconfig /release」および「ipconfig /renew」を実行するとよいでしょう。

Windowsが採用する手順に原因
 今回の事象は,WindowsクライアントがDHCPサーバーからIPアドレスなどを取得する手順の実装方法に原因があります。基本的に動的IPアドレスの割り当ては,以下に示す4つの手順で行われます。この4種類のプロトコルがDHCPの実体です。

・DHCP Discover
・DHCP Offer
・DHCP Request
・DHCP ACK

 原因を理解するために,これらのプロトコルの動作を詳しく説明しましょう。


△ 図をクリックすると拡大されます
図1●Windowsクライアントが初めて起動したときのDHCPの動作
 最初は,Windowsクライアントが初めて起動したケースを例にします(図1)。

 IPアドレスを自動的に取得する設定のWindowsクライアントは,起動時にまずDHCP Discoverを送信してIPアドレスを要求します。送信元アドレスは「0.0.0.0」,送信先は「255.255.255.255」になります。これは,いわゆるブロードキャスト(一斉同報)の通信です。この動作によって,ネットワーク内のDHCPサーバーにWindowsクライアントの存在を通知します。

 次に,DHCP Discoverを受信したDHCPサーバーは,割り当てるIPアドレスを決定します。この際,アドレスの使用状況をpingで確認するようDHCPサーバーに設定していれば,設定された回数のpingが実行されます。使用中であることが確認された場合,別のIPアドレスにて同様の動作を行います。

 割り当てるIPアドレスが決定したら,DHCPサーバーはDHCP Offerでアドレスを送信します。DNSサーバーのIPアドレスなどがDHCPオプションで設定されている場合,このパケットにその内容も記載されます。IPアドレスを割り当てる前ですので,当然,このパケットもブロードキャストで送信されます。

 その後,クライアントはDHCP Requestを送信し,DHCP Offerに応答します。この段階でも送信元アドレスは「0.0.0.0」,送信先は「255.255.255.255」になっています。複数のDHCPサーバーが存在する場合,現在通信対象としていないDHCPサーバーが,IPアドレスのリースを準備していることがあります。このブロードキャストは,それらのDHCPサーバーに,IPアドレスのリースを解放する要求も兼ねています。

 DHCP Requestを受信したDHCPサーバーは,さらにDHCP ACKをブロードキャストし,アドレスが確定したことをクライアントやほかのDHCPサーバーへ知らせます。これにより,Windowsクライアントへ割り当てるIPアドレスが確定し,その使用が可能になります。

 最後にWindowsクライアントは,Gratuitous ARP(自身のMACアドレスを通知するためのARP)を3回送信し,処理を終了します。もしWindowsクライアントのDHCP要求に応答が無い場合,Windows 98/2000以降では,APIPA(自動プライベート・アドレス指定)が使用されます。

ゲートウエイへのpingで判断


△ 図をクリックすると拡大されます
図2●IPアドレスを取得したことがあるWindowsクライアントが再起動でIPアドレスを要求する場合の動作
 続いて,過去にIPアドレスを取得したことがあるWindowsクライアントが,再起動でIPアドレスを要求する場合の動作を説明します(図2)。Windowsクライアントが初めてIPアドレスを取得するときとの違いに注意してください。

 この場合,クライアントはDHCP Discoverではなく,DHCP Requestを送信します。当然,IPアドレスやDHCPオプションは,以前に取得した状態を保持していますが,送信元は「0.0.0.0」,送信先は「255.255.255.255」となっています。なお,これを,INIT-REBOOT状態と呼びます。

 次に,Windows Serverで構築されたDHCPサーバーの場合,DHCP RequestにはDHCP ACKもしくはDHCP NACKで応答します。

 DHCP ACKで応答したときは,IPアドレスの使用が許可されたことを示します。この場合,Windowsクライアントは,要求したIPアドレスの使用許可が下りたと判断し,Gratuitous ARPを3回送信します。それとは逆にDHCP NACKで応答したときは,DHCPサーバーによってIPアドレス要求が棄却されたことを示します。

 問題となるのは,DHCPサーバーから何も応答が無いときです。この場合,Windowsクライアントは,以前に取得したデフォルト・ゲートウエイに対してpingを送信します。デフォルト・ゲートウエイからの応答があれば,ネットワークに変更が無いと判断し,以前に取得したIPアドレスをそのまま使用します。その後の動作は先ほどと同様です。従って,社内ネットワークで使うデフォルト・ゲートウエイのIPアドレスと社外ネットワークのデフォルト・ゲートウエイのIPアドレスが同じだと,クライアントのIPアドレスなどが社外ネットワーク用に更新されない場合があります。


△ 図をクリックすると拡大されます
図3●DHCPの動作をまとめたフローチャート
 DHCPサーバー側がDHCP NACKを送信した場合や,デフォルト・ゲートウエイからのping応答が無い場合,またGratuitous ARPでIPアドレスがコンフリクト(重複)していることを検出した場合などは,WindowsクライアントのIPアドレス要求は棄却されます。その後はWindowsクライアントを初めて起動した際の動作と同じです。

 以上の動作を図3でフローチャート式にまとめたので,参考にしてください(図3)。


NTTデータ先端技術 SE部アシスタント