0

背景情報:

独自の組み込みLinuxネットワークデバイスのセットがあり、そのうちの1つはDHCPサーバーとして構成され、残りはDHCPクライアントになります。

クライアントデバイスにサーバーデバイスからのDHCPリースオファーのみを受け入れさせ、同じLAN上の他のDHCPサーバーによって提供される他のリースを無視する必要があります。同様に、サーバーデバイスがこのクライアントのセットにDHCP要求のみを提供し、不明なネットワーク環境に表示される可能性のある他のDHCP要求を無視するようにする必要があります。基本的に、DHCPサーバーがすでに存在する可能性のあるネットワーク環境で自分のデバイスにDHCPサービスを提供できる必要があります。

すべてのデバイスには、フィルターとして使用する予定のMACアドレスの前半が同じです。

BusyBoxに含まれているudhcpcとudhcpdを使用しており、ストレージの可用性が限られているため、他のDHCPクライアント/サーバーパッケージをデバイスに追加しないようにしていますが、BusyBoxコードを変更することはできます。

chaddr_filterサーバーが「クライアントハードウェアアドレス(chaddr)」をチェックする必要があるワイルドカードMACアドレスを含むオプションをudhcpd.confに追加することで、DHCPサーバーの制限を実装するのに問題はありませんでした。これは問題なく機能しているようで、サーバーは自分のデバイスにサービスを提供している間、他のデバイスからのDHCP要求をすべて無視します。

DHCPパケットに「サーバーハードウェアアドレス」フィールドがないため、クライアント側のフィルタリングはより大きな課題であることが判明しました。

だからここに私の質問があります:

サーバーのMACをudhcpcクライアントに渡す最良の方法は何ですか?

現在、サーバーのMACを含むDHCPサーバーから渡されるフィールドまたはオプションがないようです(イーサネットレイヤーから読み取ることができるようには見えません)。標準に準拠したままにしておきたいので、この目的で使用できる可能性のあるDHCPオプションを調べています。

「オプション54:サーバー識別子」を使用できることを期待していましたが、RFCではIPアドレスとして定義されています。

サーバーのMACを「オプション60:クラス識別子」または「オプション43:ベンダー固有の情報」のいずれかに配置することを考えていますが、これを実行しない理由はありますか?このためのより良い分野はありますか?

ご提案をお待ちしております。

4

2 に答える 2

1

ウィキペディアから取得

DHCPは、IANAによってBOOTPに割り当てられたものと同じ2つのポートを使用します。サーバーにデータを送信するための宛先UDPポート67と、クライアントにデータを送信するためのUDPポート68です。DHCP通信は本質的にコネクションレス型です。

したがって、ポート68 / udpの着信パケットをクライアントでフィルタリングして、前半が良好なMacアドレスからの着信パケットのみを受け入れることができます。

于 2012-07-27T07:42:52.053 に答える
0

brctl参考までに、ebtablesユーティリティを使用してクライアント上の関心のあるパケットをフィルタリングすることにより、目的の効果を達成することができました。

于 2014-12-30T18:03:14.040 に答える