Назад | Перейти на главную страницу

Linux DHCP server option 43 vendor-encapsulated-options, как форматировать / кодировать?

Я администрирую сеть для малого бизнеса, в котором есть брандмауэр 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;

Что довольно сложно читать, если вы не знаете, что ищете. Давайте разберемся по частям:

  • Байт 1, 0x02. Это говорит о том, что этот блок настроен для опции № 2. Как это интерпретировать, зависит от поставщика.
  • Байт 2, 0x04. Это говорит о том, что данные для варианта 2 займут следующие 4 байта.
  • Байты 3-6, 0xAC114101. Эти четыре байта - фактические данные. Как вы видели, когда пытались его расшифровать, это нечитаемые данные.
  • Байт 7, начало следующего блока опций, 0x03. Вся цепочка начинается заново, это говорит о том, что следующая конфигурация предназначена для варианта 3.
  • и так далее по 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;
  • Байт 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. Снова нулевой байт в конце.

Итак, допустим, вам нужно построить вариант 43 с http://phone.example.com как вариант 66 и phonesettings.txt как вариант 67.

  • Байт 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 - они могут делать все, что хотят!

Это, безусловно, самый дурацкий способ настройки параметра 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;