web-dev-qa-db-ja.com

Linux DHCPサーバーオプション43ベンダーカプセル化オプション、フォーマット/エンコードする方法？

私は、ネットワークにDHCPサービス（およびその他のさまざまなサービス）を提供するIPCopファイアウォールボックスを持つ小規模ビジネスのネットワークを管理しています。 IPCopのDHCPサーバーはdhcpdのように見え、IPCopは構成ファイルを編集するためのWebベースのフロントエンドを提供します。

Vendor-encapsulated-optionsオプションを使用して、DHCPオプション66と67の特定の値を特定のベンダークラス識別子に送信しようとしています。 DHCPオプション66/67および43/60をサポートする一部のVoIP電話の自動設定が目的です。

電話を自動構成するために、オプション66 tftp-server-nameと67 bootfile-nameを取得することに成功しました。ただし、これらのオプションはグローバルであり、すべてのDHCPクライアントに送信されます。自動設定情報を電話にのみ送信するために、vendor-class-indentifierおよびvendor-encapsulated-options DHCPオプションを試してみたいと思っています。これはおそらく中小企業のネットワークにとってはやり過ぎだと思いますが、これは私の知識を広げるためのものです。

そのため、そこにあるいくつかの情報を読み始めましたが、vendor-encapsulated-options文字列内でオプション66/67をエンコードする方法を理解できません。
ここに関連するRFCがあります... http://tools.ietf.org/html/rfc2132#section-8 セクション8.4そして、dhcpdのmanページは http ：//www.daemon-systems.org/man/dhcp-options.5.html 「ベンダーカプセル化オプション」の下

これらのドキュメントは、オプションがHEX形式でエンコードされることを示唆しているようですが、vendor-encapsulated-optionsオプションのmanページの例を見てください...

The value of this option can be set in one of two ways.  
The first way is to simply specify the data directly,  
using a text string or a colon-separated list of hexadecimal values.  
For example:  
       option vendor-encapsulated-options
           2:4:AC:11:41:1:
           3:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31:
           4:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63;

そのロットをHEXからASCIIにデコードしてみると、次のようになります。
????A?????????sundhcp-server17-1????????/export/root/i86pc
それで、フォーマット/エンコーディングを正しく理解していないと確信しています。

これがIPCopのdhcpd.confからの私の抜粋です。

subnet 192.168.1.0 netmask 255.255.255.0 #GREEN
{
        range 192.168.1.30 192.168.1.200;
        option subnet-mask 255.255.255.0;
        option domain-name "domain.com";
        option routers 192.168.1.1;
        option domain-name-servers 192.168.1.1;
        option ntp-servers 192.168.1.1;
        option netbios-name-servers 192.168.1.3;
        default-lease-time 43200;
        max-lease-time 172800;
        option vendor-encapsulated-options "hello";
        option vendor-class-identifier "snom320";
        option vendor-class-identifier "snom821";
        option bootfile-name "voipsettings/firstboot.xml";
        option tftp-server-name "http://username:[email protected]";
} #GREEN

DHCP要求でVoIP電話（Snom）から送信された値ごとにベンダークラス識別子を設定しています。 bootfile-nameとtftp-server-nameは、vendor-encapsulated-optionsでエンコードしようとしているオプション（66/67）です。
Snomのwikiにガイドがあります...
http://wiki.snom.com/Networking/DHCP/Options#Auto_Provisioning_Options
（謝罪、私の評判が低すぎて質問に2つ以上のリンクを投稿できない）
そのwikiは、ベンダークラス識別子を「nオクテットの文字列」としてエンコードする必要があることを示唆しているようです
さらに、そのWiki記事で提供されているベンダーカプセル化オプションの例も、HEXからASCIIに変換すると意味不明な結果を返します。だから私がここで理解していない重要なことがある。

これらのDHCPオプションを適切にフォーマット/エンコードする方法の概要を誰かに教えてもらえますか？

linuxdhcp-serverdhcp-option
6
batfastad

DHCPオプション43は少し奇妙な獣です。ベンダーは必要に応じてそれを処理できます。オプション番号がDHCPオプション番号と一致することを期待するベンダーもいれば、そうでないベンダーもあります。

基本構造は、オプションIDの1バイト、オプションデータの長さ（n）の1バイト、そして実際のオプションデータのnバイトです。

Dhcp-optionsの例を見てみましょう。読みやすくするために、戦略的な場所に改行を入れています。実際には、彼らが構成した設定はこれだけです：

02:04:AC:11:41:01:03:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31:04:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63;

あなたが探しているものがわからなければ、これはかなり読みにくいです。パーツを分解してみましょう：

  • バイト1、0x02。これは、このブロックがオプション番号2の構成であることを示しています。どのように解釈されるかはベンダー次第です。
  • バイト2、0x04。これは、オプション2のデータが次の4バイトを占めることを示しています。
  • バイト3〜6、0xAC114101。これらの4バイトは実際のデータです。デコードしようとしたときに見たように、それは読み取り可能なデータではありません。
  • バイト7、次のオプションブロックの開始、0x03。チェーン全体が最初からやり直します。これは、次の構成がオプション3用であることを示しています。
  • など、3つのセクション

Snom wikiページからの別の例：

42:0c:68:74:74:70:3a:2f:2f:74:65:73:74:00:43:12:73:6e:6f:6d:2f:73:65:74:74:69:6e:67:73:2e:70:68:70:00;
  • バイト1、0x42。オプションコード66の場合、16進数の42は66です。
  • バイト2、0x0c。 12バイトの長さ。
  • バイト3-14、0x687474703a2f2f7465737400。これはhttp://testで、最後にnullバイト（0x00）が付いています。なぜそこにあるのかわからない。
  • バイト15、0x43。オプション67。
  • バイト16、0x12。 18バイトの長さ。
  • バイト17〜34、0x736e6f6d2f73657474696e67732e70687000。 snom/settings.php。繰り返しになりますが、最後のヌルバイト。

したがって、オプション66としてhttp://phone.example.comを、オプション67としてphonesettings.txtを使用して、オプション43を作成する必要があるとします。

  • バイト1、オプションコード66、0x42
  • バイト2、長さhttp://phone.example.comで24バイト、したがって0x18
  • バイト3-26、データ。 0x687474703a2f2f70686f6e652e6578616d706c652e636f6d
  • バイト27、オプションコード67、0x43
  • バイト28、長さ17バイトのphonesettings.txt、つまり0x11
  • バイト29〜45、データ。 0x70686f6e6573657474696e67732e747874

したがって、次の完全な構成文字列：

42:18:68:74:74:70:3a:2f:2f:70:68:6f:6e:65:2e:65:78:61:6d:70:6c:65:2e:63:6f:6d:43:11:70:68:6f:6e:65:73:65:74:74:69:6e:67:73:2e:74:78:74;

それが機能しない場合は、例のように、データ文字列の最後にnullバイトを追加して（それに応じて長さフィールドを増やします）、各オプションの最後または偶数バイトのいずれかにnullバイトが必要になる場合があります。各オプションの長さ。これがオプション43のマイナス面です。

11
Shane Madden

これは、間違いなくオプション43を設定するための最も気難しい方法です。代わりに、ISCの「ベンダーオプションスペース」構文を使用して、設定内容を人間が読み取って間違いを回避できるようにする必要があります。

option space db;
option db.db-server code 1 = ip-address;
option db.loginid code 2 = text;
option db.db-name code 3 = text;

ジャン=イヴ・ビシュー

3
jyb

ローカルカプセル化を使用することを忘れないでください。

option space Cisco;
option Cisco.wlc code 241 = array of ip-address;
option local-encapsulation code 43 = encapsulate Cisco;
option Cisco.wlc 10.7.3.6, 10.7.3.2;
2
Per Mejdal Rasmussen