組込みLinuxのDHCPクライアントとサーバーの製品要件
組込み機器が既存ネットワークから自身のIPv4設定を取得する場合はDHCPクライアントが必要です。下流の機器や初期設定用スマートフォンに設定を割り当てる場合はDHCPサーバーが必要です。ゲートウェイでは、明確に分けたインターフェース上で両方が必要になることがあります。Linuxイメージにパッケージを追加したりデーモンを選んだりする前に、対象インターフェース、設定管理者、障害時の動作を製品要件に記載してください。
本記事は組込みLinux製品のIPv4 DHCPを対象とします。IPv6ルーター広告とDHCPv6は別途設計が必要です。以下の設定と受入試験は設計例・提案であり、Obeitaの導入実績に基づく測定結果ではありません。
設置時のネットワーク構成から始める
「DHCP対応」には、互いに異なる複数の解釈があります。工場のスイッチにつながるセンサーは通常クライアントです。保守用アクセスポイントは技術者のスマートフォンだけにアドレスを配る場合があります。ルーティングゲートウェイはWANアドレスを取得しながら、独立したLANに設定を配布できます。一方、ブリッジは既存サーバーにクライアントのブロードキャストを転送するだけかもしれません。そのブリッジに別のサーバーを置くと、ブロードキャストドメイン全体に影響します。
| 製品の役割 | アドレス割当 | 記録する判断 |
|---|---|---|
| 工場ネットワーク端末 | 上流側のクライアント | サブネット、リース、DNS方針はIT部門が管理 |
| ローカル初期設定AP | 設定用インターフェースのサーバー | ローカル専用か、インターネット転送も提供するか |
| ルーティングゲートウェイ | WANクライアントとLANサーバー | 独立サブネットと明示的な転送方針 |
| 透過ブリッジ | 既存サーバーが接続クライアントに配布 | 管理アドレスとブロードキャスト境界 |
Linux名だけでなく物理ポートにもラベルを付けます。基板変更、USBアダプター、ドライバー更新で列挙順が変わる可能性があります。コネクター、MACアドレス、ブリッジ/VLAN所属、ネットワークの役割の対応をリリース資料に残してください。
最初のリース取得後の動作を定義する
初回割当は通常、Discover、Offer、Request、Acknowledgementで進みます。その後は有効期間、更新、再バインドの動作があり、期限切れリースを有効な設定として使い続けてはいけません。これらの遷移はRFC 2131に定義されています。受入試験はコールドブート成功で終わらず、その後の遷移まで対象にします。
アプリケーションに見える状態を、リンク利用不可、設定取得中、アドレス有効、ローカルネットワーク到達可能、アプリケーション接続先到達可能に分けてください。DHCP確認は設定取得を示しますが、DNS、インターネット、MQTTサービスの動作確認ではありません。画面と診断ログで区別できる情報を持たせます。
デフォルトルートやDNS設定を受け入れるか、どの識別情報を送るか、予約割当に対応するかはネットワーク管理者が決めます。サブネットマスク、ルーター、DNSサーバーなどの期待値をRFC 2132に照らして記録してください。現場ITとの合意なしに特定アドレスへの依存を設けないようにします。
複数インターフェースではルート優先順位とDNS管理主体を定義します。同じインターフェースを二つのネットワーク管理プログラムが扱うと、互いのアドレスを上書きし得ます。異なるインターフェースで有効なリースを得ても、意図しないデフォルトルートが入ることがあります。一つのインターフェースにつき管理主体を一つにし、セルラーマネージャー、固定アドレスの保守ポート、コンテナーブリッジと併せて試験します。
サーバーを許可されたセグメント内に限定する
設定サーバーは、インターフェースに予定のローカルアドレスが設定されてから起動します。待受インターフェースを限定し、工場側上流にOfferが出ないことを確認してください。全インターフェース待受と意図しないブリッジの組合せは、未許可のDHCPサーバーを生みます。ファイアウォールは追加の境界であり、正しいインターフェース管理の代用ではありません。
アドレス配布、ルーティング、DNS転送、NATは分けて定義します。スマートフォンがアドレスを得ても、ゲートウェイがインターネットを提供できるとは限りません。ローカル専用設定では、スマートフォンが「インターネット接続なし」と判断した際のアプリの接続方法を決めます。キャプティブポータルがあっても、文書化した手動アクセス経路を確認してください。
次のdnsmasq例は専用設定セグメントに配布し、デフォルトルーターとDNSサーバーを通知しません。br-setupに192.168.77.1/24を別途設定済みで、他のDHCP提供セグメントと接続せず、書込み可能なリースディレクトリーが存在することが前提です。導入版のdnsmasqマニュアルでオプションを確認してください。実験室での出発点であり、完全なネットワーク・セキュリティ設定ではありません。
# Dedicated local commissioning interface only
interface=br-setup
bind-interfaces
port=0
dhcp-range=192.168.77.20,192.168.77.60,255.255.255.0,10m
dhcp-option=3
dhcp-option=6
dhcp-leasefile=/data/dhcp/setup.leasesインターネット転送が必要なら別要件とし、適切なルーター/DNSオプションを指定します。動的生成インターフェースでは、バインドが正しいままだと仮定せずデーモンの起動・再起動を試験します。下流と上流のサブネットが重複しないことを確認し、重複時には管理された変更手順を用意してください。
競合、アドレス枯渇、識別情報の永続性を決める
プール容量は同時クライアント数、未失効の古いリース、初期設定中の入替わりを含めて設計します。スマートフォンはプライベートWi-Fiアドレスを使う場合があり、同じ端末が永続的に同じMACを使うとは限りません。不正な大量要求を制限し、プールが埋まった際の作業者向け表示を決めます。
サーバーのリースを再起動後も保持するか決めてください。リースデータベース消失が即座に競合を起こすとは限りませんが、安全なアドレス再利用の判断材料は変わります。想定の永続化方針で保存し、既存クライアントが接続したまま再起動を試験します。一つのDHCP障害のために全設定を安易に消してはいけません。
IPv4アドレス重複には明確な障害表示と復旧方針が必要です。RFC 5227はARPによる競合検出を説明しています。実際のクライアント/サーバースタックの実装を確認し、競合パケットを保存してください。ping成功だけでは、別ホストが同じアドレスに断続的に応答している状態を見逃します。
故障を中心とした受入試験表を使う
| 故障注入 | 観測項目 | 提案する合格条件 |
|---|---|---|
| 起動時にサーバー不在、後で復旧 | 再試行間隔、CPU、アプリ状態 | 資源使用が有界で、合意した時間内に自動取得 |
| 短い試験リースで更新、その後全応答を遮断 | 更新、再バインド、期限切れ遷移 | 期限切れリースをアプリが使用せず、復旧後に機器再起動不要 |
| DHCPがルーターまたはDNSを変更 | ルート、リゾルバー、既存接続 | 新設定が反映され、アプリ方針に従い再接続 |
| クライアント稼働中のサーバー再起動 | リースDBと重複割当 | 試験対象集団に重複割当なし |
| プール枯渇または固定アドレスとの競合 | ログと作業者向け応答 | 具体的障害表示と、無関係な設定を壊さない規定復旧 |
| WANと設定APの同時動作 | 両インターフェースのキャプチャ | 設定用Offerが指定セグメント内に限定 |
時間閾値は設置要件と対応リース値から選びます。各結果にリース期間、ファームウェア、デーモン設定、ルーター型番、クライアントOSを記録してください。サーバー試験は対応するスマートフォン・PC系列で繰り返します。一台のPCでの成功だけでは、モバイル初期設定の裏付けとして不十分です。
最初に欠けた遷移から調査する
許可された実験環境で、インターフェースごとにキャプチャします。次は診断コマンド例です。名前や利用可能なツールはイメージにより異なります。
ip -br link
ip -4 address show dev eth0
ip -4 route show
tcpdump -ni eth0 -vv 'udp port 67 or udp port 68 or arp'Discoverがなければインターフェース、プロセス、設定管理主体を調べます。DiscoverのみならVLAN、サーバー、中継、フィルターを疑います。確認を受けたのにアドレスが使えなければ、クライアントフックやネットワークマネージャー統合を調べます。有効アドレスで名前解決が失敗するならDNS、DNSが正常でサービスが失敗するならアプリを診断します。時刻とトランザクションIDを残し、プロジェクト外への共有前にクライアント識別情報を伏せてください。
構成を納品範囲に落とし込む
Obeitaの機器接続サービスはインターフェースの役割とネットワーク受入条件の整理に利用できます。納品済みRK3528ネットワークゲートウェイ事例は異なるEthernet経路とLAN/WANの提案を示しますが、お客様のネットワークでDHCPを検証済みという意味ではありません。
評価にはコネクター/VLAN図、クライアント規模、現場DHCP制約、ローカル設定要件、現行イメージをご用意ください。「DHCP対応」を納品チェック項目にする前に、設定管理主体、エラー表示、キャプチャ方法、試験表を合意します。
