Я администрирую сеть для малого бизнеса, в котором есть брандмауэр IPCop, который предоставляет сети DHCP-сервисы (и различные другие сервисы). Сервер DHCP в IPCop выглядит как dhcpd, а IPCop предоставляет веб-интерфейс для редактирования файла конфигурации.
Я хочу использовать опцию vendor-encapsulated-options для отправки конкретных значений для опций DHCP 66 и 67 определенному идентификатору класса vendor. Целью является автоконфигурация некоторых телефонов VoIP, которые поддерживают параметры DHCP 66/67 и 43/60.
Мне уже удалось получить параметры 66 tftp-server-name и 67 bootfile-name для автоматической настройки телефонов. Но, конечно, эти параметры являются глобальными и отправляются всем клиентам DHCP. Я хочу поэкспериментировать с параметрами DHCP-идентификатора vendor-class-indentifier и vendor-encapsulated-options, чтобы отправлять информацию об автоматической настройке только на телефоны. Я понимаю, что это, вероятно, перебор для сети малого бизнеса, но это все, чтобы расширить мои знания.
Итак, я начал читать некоторую информацию, которая там есть, и я просто не могу понять, как кодировать параметры 66/67 в строке параметров, инкапсулированных поставщиком.
Вот соответствующий RFC ... http://tools.ietf.org/html/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
Поэтому я уверен, что неправильно понимаю формат / кодировку.
Вот мой фрагмент из dhcpd.conf IPCop
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. Имя загрузочного файла и имя-tftp-сервера - это параметры (66/67), которые я хочу закодировать в параметрах, инкапсулированных поставщиком.
У Snom есть руководство по их вики здесь ...
http://wiki.snom.com/Networking/DHCP/Options#Auto_Provisioning_Options
(Извините, моя репутация слишком низка, чтобы размещать> 2 ссылки в вопросе)
Эта вики, кажется, предполагает, что мне нужно закодировать идентификатор класса поставщика как «строку из октетов»
Кроме того, примеры опций, инкапсулированных поставщиком, приведенные в этой статье вики, также возвращают тарабарщину при преобразовании из HEX в ASCII. Итак, есть кое-что важное, чего я здесь не понимаю.
Может ли кто-нибудь дать мне представление о том, как правильно форматировать / кодировать эти параметры DHCP?
Вариант 43 DHCP-сервера - немного странный зверь. Поставщики могут относиться к нему как угодно - некоторые ожидают, что номера опций будут совпадать с номерами опций DHCP, другие - нет.
Базовая структура - это 1 байт для идентификатора опции, 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;
Что довольно сложно читать, если вы не знаете, что ищете. Давайте разберемся по частям:
0x02
. Это говорит о том, что этот блок настроен для опции № 2. Как это интерпретировать, зависит от поставщика.0x04
. Это говорит о том, что данные для варианта 2 займут следующие 4 байта.0xAC114101
. Эти четыре байта - фактические данные. Как вы видели, когда пытались его расшифровать, это нечитаемые данные.0x03
. Вся цепочка начинается заново, это говорит о том, что следующая конфигурация предназначена для варианта 3.Другой пример со страницы вики snom:
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;
0x42
. 42 в шестнадцатеричном формате - это 66, для кода опции 66.0x0c
. Длина 12 байт.0x687474703a2f2f7465737400
. Это http://test
с нулевым байтом (0x00
) в конце. Не уверен, почему у них это там есть.0x43
. Вариант 67.0x12
. Длина 18 байт.0x736e6f6d2f73657474696e67732e70687000
. snom/settings.php
. Снова нулевой байт в конце.Итак, допустим, вам нужно построить вариант 43 с http://phone.example.com
как вариант 66 и phonesettings.txt
как вариант 67.
0x42
http://phone.example.com
, так 0x18
0x687474703a2f2f70686f6e652e6578616d706c652e636f6d
0x43
phonesettings.txt
, так 0x11
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 - они могут делать все, что хотят!
Это, безусловно, самый дурацкий способ настройки параметра 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;
Жан-Ив Бизио
Не забудьте использовать локальную инкапсуляцию:
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;