Linux DHCP 伺服器選項 43 供應商封裝選項,如何格式化/編碼?
我為一家小型企業管理網路,該企業有一個 IPCop 防火牆盒,為網路提供 DHCP 服務(以及各種其他服務)。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 選項將自動配置資訊僅發送到電話。我意識到這對於小型企業網路來說可能是矯枉過正,但這一切都是為了拓寬我的知識。
因此,我開始閱讀那裡的一些資訊,但我無法弄清楚如何在供應商封裝選項字元串中編碼選項 66/67。
這是相關的 RFC … https://www.rfc-editor.org/rfc/rfc2132#section-8第 8.4 節 這是 dhcpd 的手冊頁http://www.daemon-systems.org/man/dhcp -options.5.html在“供應商封裝選項”下
這些文件似乎表明這些選項將以 HEX 格式編碼,但是查看 vendor-encapsulated-options 選項的手冊頁範例……
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:password@intranet.domain.com"; } #GREEN
我根據 VoIP 電話 (Snom) 在 DHCP 請求中送出的值設置了供應商類標識符。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 選項?
DHCP 選項 43 有點奇怪。供應商可以按照他們的意願對待它 - 有些人希望選項編號與 DHCP 選項編號匹配,而另一些則不。
基本結構是 1 個字節用於選項 ID,1 個字節用於選項數據的長度 (n),然後是 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
,. 這四個字節是實際數據。正如您在嘗試解碼時看到的那樣,它不是可讀數據。- 字節 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
,。十六進制中的 42 是 66,用於選項程式碼 66。- 字節 2
0x0c
,。長度為 12 個字節。- 字節 3-14
0x687474703a2f2f7465737400
,. 這是最後http://test
一個空字節(0x00
)。不知道他們為什麼在那裡。- 字節 15,
0x43
. 選項 67。- 字節 16,
0x12
. 18 字節長度。- 字節 17-34
0x736e6f6d2f73657474696e67732e70687000
,.snom/settings.php
. 同樣,最後的空字節。因此,假設您需要
http://phone.example.com
使用選項 66 和phonesettings.txt
選項 67 建構選項 43。
- 字節 1,選項程式碼 66,
0x42
- 字節 2,長度為 24 字節
http://phone.example.com
,所以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;
如果這不起作用,請嘗試將空字節添加到數據字元串的末尾(並相應地增加長度欄位),如他們的範例所示 - 他們可能希望每個選項末尾的空字節或偶數字節對於每個選項的長度。這就是選項 43 的缺點——他們可以為所欲為!