はじめに
Maple Yard では週末イベントの準備をしています。参照デスクはすでにネットワーク設定を自動で受け取っています。新しいゲスト端末 2 台にも同じサービスが必要ですが、ルーターや固定デスクに予約されたアドレスを使ってはいけません。
小さな DHCP アドレス範囲を設定し、両クライアントに実際のリースを取得させ、受信したゲートウェイと DNS 経由でイベントのプログラムをダウンロードします。必要なのは基本的な端末入力と、名前の付いたタブの切り替えだけです。プログラミングや DHCP 管理の経験は不要です。
サーバー設定は Network Desk、クライアントのコマンドは Guest A と Guest B、稼働中のノードの観察は Network Map を使います。これらは同じカーネルを共有する、分離された Linux ネットワークノードです。ディレクトリとネットワーク状態は別々です。タブを開いたり再接続したりしてもコースはリセットされません。
新しい端末のアドレス範囲を用意する
このステップでは安全な動的アドレス範囲を選び、DHCP サーバーから提供できるようにします。まず Network Map を開きます。reference カードの Request programme を選択してください。Maple Yard のプログラムが表示されるはずです。これは既存の正常動作例であり、まだあなたが作った成果ではありません。
IPv4 アドレスは、このネットワーク上の端末を識別します。/24 は 10.77.0.10/24 のように使われ、10.77.0 で始まるアドレスが同じローカルサブネットに属することを表します。ゲートウェイは別サブネットにあるプログラムサーバーへ通信を運びます。DNS は programme.event.test のような名前をアドレスに変換します。アドレスを受け取るだけでは、ほかの設定も役立つとは確認できません。
Network Desk に切り替えます。この端末の開始ディレクトリは /home/labex/project/event-network です。pwd は現在のディレクトリを、cat はテキストファイルを表示します。
pwd
cat devices.tsv
MAC アドレスは、この用意されたネットワークにおける端末のリンク層の識別情報です。IPv4 アドレスや読みやすいタブ名とは異なります。参照デスクは 10.77.0.10、ルーターと DNS は 10.77.0.1 を使います。これらの固定アドレスは変更しません。ゲスト範囲は 10.77.0.100 から 10.77.0.109 までで、両端を含みます。マスクは 255.255.255.0 で、同じ /24 を表します。
編集可能なサーバーファイルを読みます。
cat dhcp.conf
conf-file 行は用意された参照サービスを読み込みます。この行は残してください。dhcp-range は最初と最後のアドレス、サブネットマスク、リース期間を指定します。リースは一時的な割り当てです。2h は 2 時間を意味し、永久に所有するわけではありません。
次のヒアドキュメントで、小さなファイル全体を書き込みます。> は以前の内容を置き換えます。引用符で囲んだ 'CONF' によりブロックは文字どおりに扱われます。最後の CONF は行頭から単独で記述してください。ブロック全体をコピーします。
cat > dhcp.conf <<'CONF'
conf-file=/opt/labex/event-network/server-base.conf
dhcp-range=10.77.0.100,10.77.0.109,255.255.255.0,2h
CONF
--test は別のサーバーを起動せずに構文を確認します。--conf-file は使用するファイルを選びます。
dnsmasq --test --conf-file=dhcp.conf
dnsmasq: syntax check OK. が表示されるはずです。エラーが出たら cat で保存済みファイルを読み、上のブロックに戻して再確認してください。構文エラーが分かっている状態で、動作中のサービスを再起動してはいけません。
sudo はこの 1 つの管理コマンドを実行します。systemctl restart は変更後の設定を、event-dhcp というコース用サービスに読み込みます。
sudo systemctl restart event-dhcp
正常な再起動は通常何も表示しません。ゲストのリースを要求する操作ではありません。サーバーが提供できる内容は準備できましたが、クライアントからの要求が必要です。この最初のラボでは、dnsmasq が用意された自分のローカルアドレスを既定のゲートウェイと DNS として通知します。次のラボでは、明示的なサーバーオプションでこれらを制御する方法を学びます。
各ゲストにリースを要求させる
このステップでは実際の DHCP 要求で新しいクライアント 2 台を接続します。Guest A に切り替えます。これは分離されたクライアントの管理者シェルで、すでに専用作業ディレクトリにいます。eth0 はコース内のリンクであり、プラットフォームのインターフェースではありません。これらのコマンドを Network Desk で実行しないでください。
dhclient は提供された ISC DHCP クライアントです。このコースでは変更していないローカルコピーと、受信したオプションだけを分離ノードに適用するフックを使います。アドレスを作り上げたり、プラットフォームのリゾルバーを変更したりはしません。-4 は IPv4、-v はやり取りの表示を選び、-1 はサーバーが応答しなければ今回の取得試行を終了します。-cf client.conf は提供された設定を選びます。-pf client.pid と -lf client.leases は、このクライアントのプロセスとリース状態を専用ディレクトリに保存します。用意されたリースファイルは最初は空で、クライアントが実際に受け取ったリースを書き込みます。これらの準備済みファイルを残してください。
次を 1 行で実行します。
dhclient -4 -v -1 -cf client.conf -pf client.pid -lf client.leases eth0
DHCPDISCOVER、DHCPOFFER、DHCPREQUEST、DHCPACK を確認します。最初のやり取りでは、クライアントがサーバーを探し、提案を受け取り、その提案を要求して確認を受けます。既存リースがあると、後のやり取りは短くなる場合があります。最後の bound to 10.77.0... は割り当てられたアドレスを示します。具体的なゲストアドレスや更新時刻は、範囲内で変わることがあります。
ip -4 addr show は選択したインターフェースの IPv4 アドレスを表示します。
ip -4 addr show dev eth0
10.77.0.100–10.77.0.109 のいずれかに /24 が付いていれば期待どおりです。
Guest B に切り替えます。こちらにも独自のディレクトリとクライアント状態があります。同じ完全なコマンドを実行します。
dhclient -4 -v -1 -cf client.conf -pf client.pid -lf client.leases eth0
ip -4 addr show dev eth0
両方のアドレスが範囲内にあり、互いに異なる必要があります。No DHCPOFFERS received が出たら、まず正しいタブか確認し、Network Desk に戻って dhcp.conf を読み、構文を確認して event-dhcp を再起動します。まだ待機しているクライアントだけで取得を再試行してください。入力ミスを直すためにリースファイルを削除したり VM をリセットしたりする必要はありません。
Network Map のページを再読み込みします。2 つのゲストカードに実際のアドレスが表示されるはずです。この観察でリースを要求したり修復したりすることはありません。
受信した設定でプログラムを取得する
このステップでは各クライアントが受信した設定を使えることを確認し、実際のプログラムファイルを保存します。まず Guest A を開きます。
ip route show default はローカルサブネット外への通信に使うゲートウェイを表示します。/etc/resolv.conf はこのクライアントの DNS リゾルバーを示します。
ip route show default
cat /etc/resolv.conf
ゲートウェイが 10.77.0.1、インターフェースが eth0、DNS が nameserver 10.77.0.1 であることを確認します。用意されたルーターは DNS も提供します。プログラム本体は別サブネットにあるため、両方の設定が必要です。
curl は HTTP リソースを要求します。--noproxy '*' はローカル演習で外部プロキシを使わないようにします。引用符により * は文字どおりになります。-f は HTTP エラーを失敗として扱い、-s は進捗表示を隠し、-S はエラーを引き続き表示します。--max-time 5 は待ち時間を 5 秒に制限します。-o programme.txt は応答のバイト列を現在のクライアントディレクトリに保存します。
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://programme.event.test:8080/programme.txt
cat programme.txt
期待される内容は次のとおりです。
MAPLE YARD | Weekend programme
10:00 Welcome desk opens
11:00 Bicycle repair
13:00 Seed exchange
15:00 Community workshop
Guest B に切り替え、独立して受信した設定を調べます。
ip route show default
cat /etc/resolv.conf
こちらでもプログラムをダウンロードして読みます。
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://programme.event.test:8080/programme.txt
cat programme.txt
Could not resolve host は名前解決の問題を示します。接続タイムアウトは経路やゲートウェイの問題かもしれません。Connection refused は選択した宛先のそのポートに、接続を受け付けるサービスがないことを意味します。HTTP 応答が成功してもリソースが違う場合があるため、プログラムの全項目を読みます。
アドレスがあっても要求に失敗する場合は、ゲートウェイと DNS を上の値と比べます。クライアント設定を手動で割り当てず、正しいサーバーファイルに戻って対応します。リースを解放して取り直す必要があれば、-r はそのクライアントの現在のリースを解放し、以前のクライアントプロセスを終了します。
dhclient -4 -v -r -cf client.conf -pf client.pid -lf client.leases eth0
続けて、学習済みの取得コマンドを使い、ダウンロードをやり直します。これらの復旧操作は影響を受けたゲストのタブだけで実行してください。
最後に Network Map を再読み込みします。両ゲストと参照デスクで Request programme を選びます。3 台すべてが完全なプログラムを返す必要があります。保存ファイルと実際の要求により、サーバー設定が正しそうに見えるだけでなく、本当に使えることを確認できます。
各カードの IPv4 アドレス、ゲートウェイ、DNS を比較し、ボタン下のプログラム応答を読みます。ゲストへの具体的な割り当ては、この例と異なる場合があります。
まとめ
固定端末を除外する範囲を選び、互いに異なる実際の DHCP リースを取得し、適用済みゲートウェイと DNS を読み、両クライアントで完全なプログラムをダウンロードしました。参照デスクも正常に保ちました。
これは現在の学習 VM 内での一時的な設定です。再起動後の永続性、公開インターネットへの接続、すべての DHCP クライアントとの互換性を保証しません。次のガイド付きラボでは、新しい独立環境で端末予約と設定の復旧を学びます。
