subject:"dhcpd"

Re: isc-dhcpd и static routes

2017-10-04 Пенетрантность Andrey Jr. Melnikov

yakim  wrote:
> Добрый день.

> Есть небольшая проблема. В конфиге dhcp сервера нужно указать 
> статический маршрут и выставить ему определенную метрику.

[...]

> option classless-routes-win code 249 = array of unsigned integer 8;
> option classless-routes-win 24, 192,168,20, 192,168,7,5;

> А вот как сюда еще и метрику вставить, так и не понял.
Никак. Ибо впихнуть 9 байт в "array of unsigned integer 8" в этой вселенной
невозможно.

isc-dhcpd и static routes

2017-10-04 Пенетрантность yakim


Добрый день.

Есть небольшая проблема. В конфиге dhcp сервера нужно указать 
статический маршрут и выставить ему определенную метрику.


С самим добавлением разобрался

Вот часть конфига

option classless-routes code 121 = array of unsigned integer 8;
option classless-routes 24, 192,168,20, 192,168,7,5;

option classless-routes-win code 249 = array of unsigned integer 8;
option classless-routes-win 24, 192,168,20, 192,168,7,5;

А вот как сюда еще и метрику вставить, так и не понял.

Может подскажет кто?


С уважением,

Якимчук Сергей

Re: isc-dhcpd и ddns

2013-11-04 Пенетрантность Eugene Berdnikov

On Mon, Nov 04, 2013 at 10:27:09AM +0400, Victor Wagner wrote:
1. Машина с несколькими интерфейсами. Хочется чтобы она получала одно и
то же имя независимо от того по Wifi она подключена в сети или по
ethernet.

Невозможно по той причине, что к такому имени нужно привязать две записи
TXT, для разных интерфейсов. ISC dhcpd на это явно не рассчитан. Формат
записи TXT (значение MD5 от mac + hostname + ... из запроса) не позволяет
указать, что интерфейс принадлежит какому-то конкретному клиенту.

2. Dual Boot машина. В обоих операционных системах по DHCP отдается
одинаковый hostname. (с точностью до регистра, но это нетрудно
исправить). DHCP отказывается прописывать другой операционной системе
то же имя, говорит имя занято другим клиентом.

Если mac и hostname совпадают, вряд ли есть повод видеть отличия между
клиентами (хотя IETF-овцы и авторы dhcpd могут считать иначе, конечно).

Нужно выяснить, от каких именно полей считается MD5 для составления TXT.
Возможно, отцы вставили туда vendor-id или ещё какую-нибудь хрень,
из-за чего разные операционки конфликтуют... Вообще, непонятно кому
и зачем пришла в голову идея писать в TXT md5-hash и терять при этом
информацию, которая может быть кому-то полезной.
--
Eugene Berdnikov

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131104165148.gb12...@sie.protva.ru

Re: isc-dhcpd и ddns

2013-11-04 Пенетрантность Eugene Berdnikov

On Mon, Nov 04, 2013 at 09:22:19PM +0400, Victor Wagner wrote:
On 2013.11.04 at 20:51:48 +0400, Eugene Berdnikov wrote:

Невозможно по той причине, что к такому имени нужно привязать две записи
TXT, для разных интерфейсов. ISC dhcpd на это явно не рассчитан. Формат

Что значит невозможно? А что, возможности как-нибудь совсем оторвать
создание записи TXT нет?

Через конфиг, наверное, нет. Но через задний сорц всё возможно. :)

Это очевидно, почему. Запись TXT в DNS публичная. Поэтому потенциальный
атакующий не должен иметь возможности, зная эту запись от чужой машины,
подделать её dhcp-запрос. Иначе теряется весь смысл этой самой
TXT-записи. Хотя непонятно что мешает атакующему отсниффить этот самый
DHCP-запрос, он же бродкастный.

Тот, кто может вставить DNS-у update, имеет массу способов навредить,
включая удаление записей и создание новых, вплоть до DoS-атак.
Для этого не нужно подделывать запросы клиента.

По этой причине следует принимать апдейты только от dhcpd, идентифицируя
его по ip-шнику или ключу. На практике, правда, не всё так сладко... :(
--
Eugene Berdnikov

Re: isc-dhcpd и ddns

2013-11-04 Пенетрантность Eugene Berdnikov

On Mon, Nov 04, 2013 at 11:44:28PM +0400, Victor Wagner wrote:
On 2013.11.04 at 23:01:11 +0400, Eugene Berdnikov wrote:

Речь идет о том, чтобы возможность ПРОЧИТАТЬ запись TXT не добавляла
информации, необходимой для подделки dhcp-запроса. Поэтому туда и не
кладут в открытом виде ни Mac-адрес, ни dhcp-client-id.

Пока мне не покажут реалистичную схему атаки с использованием поддельных
dhcp-запросов, я буду считать это всё досужими фантазиями. На практике
намного важнее вопрос защиты от ОТВЕТОВ, т.е. от левых dhcp-серверов.
--
Eugene Berdnikov

Re: isc-dhcpd и ddns

2013-11-04 Пенетрантность Mike Mironov

04.11.2013 10:27, Victor Wagner пишет:

Коллеги,

Имеется вот такой вопрос:

Вот есть локальная сеть, обслуживаемая isc-dhcpd. В ней также есть
DNS-сервер (bind9).

Возникла мысль средствами dhcpd прописывать в DNS имена и адреса машин,
получивших адреса по dhcp, благо некоторое время назад isc-dhcpd этому
научился. Используется update схема interim.

Но isc-dhcpd очень параноидален в смысле того, что не рискует
переписывать записи в DNS если не уверен что старая запись написана им
же. Для этого он вместе с A-записью генерирует TXT-запись, содержащую
MD5 DHCP-запроса, и переписывает A-запись только в том случае если MD5
нового запроса совпадает с содержимым этой записи.

...

Вот как добиться от isc-dhcpd доверия посылаемым клиентами именам,
или на что заменить isc-dhcpd вообще, или хотя бы в части ddns?
Пользовательских скриптов, вызываемых при выдаче адреса клиенту у dhcpd,
в отличие от dhclient и openvpn по-моему нет.

У меня для достижения данных целей включено
update-conflict-detection false;
update-optimization false;

Re: как должен работать ddns + dhcpd + bind?

2013-07-15 Пенетрантность Hleb Valoshka

On 7/15/13, Владимир Скубриев vladi...@skubriev.ru wrote:

Давно не настраивал подобную связку, поэтому особенно не помогу.

zone example.lab. {

Тут разве не должно быть в верхнем регистре имя зоны?

host pandora {
hardware ethernet 00:21:91:ef:8b:35;
fixed-address 192.168.128.73;
}

Знаете, мне кажется, что будет проще прописать статические адреса в
DNS, и в fixed-address вместо ip указывать доменное имя.

У пары записей я вручную удалил TXT запись, с надеждой что зона
обновиться. Но увы это ни к чему не привело.

Конечно, теперь dhcpd не считает их своими, поэтому не будет их трогать.

Зачем нужна TXT запись вообще и на что её наличие может повлиять?

Это маркер, что эти записи добавлены dhcpd.

но это не всегда помогает например для другого хоста это не помогает.
хост pandora ниже по логу (FAILED: Has an address record but no DHCID,
not mine.)

Нет TXT

Но вот чуть выше самая интересная запись этот загадочный
localhost.localdomain.example.lab откуда named его берет ?

В мане для dhcpd есть пример как добавить отладочный лог для named,
где-то в самом конце.

Bind создает файлы jnl - зачем ?

Фактически, там и находится актуальное состояние зоны.

Какой у dhcpd должен быть доступ к ним ?

Никакого.

Можно ли удалять jnl файлы и на что они влияют в моем случае?

Лучше этого не делать. Можно много чего поломать.

DHCPD хранит выданные аренды

/var/lib/dhcp# ls -l
total 12
...
-rw-r--r-- 1 dhcpd dhcpd 2484 Jul 14 17:05 dhcpd.leases
-rw-r--r-- 1 dhcpd dhcpd 2484 Jul 14 17:05 dhcpd.leases~

на что выданные аренды будут влиять ?

На работу самого DHCPD, очевидно же.

нужно ли их чистить если не работает dns update?

Нет.

Re: как должен работать ddns + dhcpd + bind?

2013-07-15 Пенетрантность Владимир Скубриев

On 15.07.2013 12:36, Hleb Valoshka wrote:

On 7/15/13, Владимир Скубриев vladi...@skubriev.ru wrote:

Давно не настраивал подобную связку, поэтому особенно не помогу.

zone example.lab. {

Тут разве не должно быть в верхнем регистре имя зоны?

Посмотрел на старом сервере в нижнем регистре. По идее не влияет.

host pandora {
hardware ethernet 00:21:91:ef:8b:35;
fixed-address 192.168.128.73;
}

Спасибо за хороший совет. Я подумаю на счет такого варианта.

Т.е. получается:
1. Мы будем привязывать к mac адресу имя хоста а НЕ IP адрес к MAC
Очень интересно получается. Правда пока что то такая схема
полностью не умещается в голове. А какие минусы это нам дает?
Помню даже в win ad там привязка идет от DHCP, который в свою
очередь обновляет записи в DNS ( там кстати периодически приходилось
чистить обратную зону от старых PTR записей, если у компьютера менялся IP)

2. IP адрес будет фигурировать только в DNS - это большой плюс.
3. Как же тогда обновление ?
4. Может есть статья где именно так делают ?

У пары записей я вручную удалил TXT запись, с надеждой что зона
обновиться. Но увы это ни к чему не привело.

Конечно, теперь dhcpd не считает их своими, поэтому не будет их трогать.
dhpcd считает запись своей только если есть TXT запись - а какая ему по
фиг или нет ? У себя то он где её хранит ? Или он вычисляет из неё какие
то нужные параметры и на основе этих параметров определяет можно ли её
обновить ?

Есть подозрение (пока только начинаю понимать технику), что dhcpd
обновляет только то, что он сам добавил ?
Какие условия для этого ему необходимы - только наличине TXT записи или
же наличие+соответствие TXT записи каким то параметрам ?

При обновлении зоны прямой и обратной что ищет в ней dhcpd ? Т.е. по
чему конкретно он находит запись, которую надо обновить ?

Зачем нужна TXT запись вообще и на что её наличие может повлиять?

Это маркер, что эти записи добавлены dhcpd.

Нет TXT
Эта ошибка говорит о том, что запись существует, но он не определил
DHCID (нет записи TXT), соответственно он не будет обновлять запись. Да?

Но вот чуть выше самая интересная запись этот загадочный
localhost.localdomain.example.lab откуда named его берет ?

В мане для dhcpd есть пример как добавить отладочный лог для named,
где-то в самом конце.

Bind создает файлы jnl - зачем ?

Фактически, там и находится актуальное состояние зоны.
А когда изменения вносятся в сам файл /etc/bind/db.example.lab ? После
перезапуска ? Или как вообще.

Какой у dhcpd должен быть доступ к ним ?

Никакого.

Понятно т.е. это чисто bind-а файлы, в которых последние изменения зоны.

Можно ли удалять jnl файлы и на что они влияют в моем случае?

Лучше этого не делать. Можно много чего поломать.

Т.е. они по сути начали создаваться (файлы jnl) после того, как
заработало обновление dns. До этого их поидее не было

DHCPD хранит выданные аренды

/var/lib/dhcp# ls -l
total 12
...
-rw-r--r-- 1 dhcpd dhcpd 2484 Jul 14 17:05 dhcpd.leases
-rw-r--r-- 1 dhcpd dhcpd 2484 Jul 14 17:05 dhcpd.leases~

на что выданные аренды будут влиять ?

На работу самого DHCPD, очевидно же.

нужно ли их чистить если не работает dns update?

Нет.

Спасибо огромное! Тут без товарищей не разобраться.

--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор

Скубриев Владимир
~~~
Россия, Ростовская область, г. Таганрог

тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru

Re: как должен работать ddns + dhcpd + bind?

2013-07-15 Пенетрантность Hleb Valoshka

On 7/15/13, Владимир Скубриев vladi...@skubriev.ru wrote:
zone example.lab. {
Тут разве не должно быть в верхнем регистре имя зоны?
Посмотрел на старом сервере в нижнем регистре. По идее не влияет.

Лучше свериться с манами.

Т.е. получается:
...
3. Как же тогда обновление ?

А никак или вручную. Оно вам кровь из носу?

4. Может есть статья где именно так делают ?

Не знаю. Это из практики. Возможно есть в манах.

Последнее. Но как именно он это значение вычисляет не скажу.

Есть подозрение (пока только начинаю понимать технику), что dhcpd
обновляет только то, что он сам добавил ?

Да.

Какие условия для этого ему необходимы - только наличине TXT записи или
же наличие+соответствие TXT записи каким то параметрам ?

Последнее.

Видимо, имя + A/PTR + TXT.

Эта ошибка говорит о том, что запись существует, но он не определил
DHCID (нет записи TXT), соответственно он не будет обновлять запись. Да?

Да.

Bind создает файлы jnl - зачем ?
Фактически, там и находится актуальное состояние зоны.
А когда изменения вносятся в сам файл /etc/bind/db.example.lab ? После
перезапуска ? Или как вообще.

У rndc есть ключик специальный.

И это, когда у вас работают динамические обновления, нельзя править
файлы зон (/etc/bind/db.example.lab и т.п.). Т.е., сливаете jnl с
файлом, отключаете ddns, и только потом правите. Но это так, на
будущее.

Re: как должен работать ddns + dhcpd + bind?

2013-07-15 Пенетрантность Владимир Скубриев

3. Как же тогда обновление ?

А никак или вручную. Оно вам кровь из носу?

Я вот тут подумал и вот какой вывод сделал о минусах использования
данной схемы:

1. Если админ поменяет ip адрес хоста в DNS, то данные о хосте будут
некоторое время (до обновления аренды клиентской машиной) не верны.

Предположим в сети появился хост с mac адресом 00:00:00:00:00:aa
В конфигурации dhcpd прописано этому mac ( 00:00:00:00:00:aa ) выдать ip
(который резолвится из имени данного хоста ) 192.168.128.8

Хосту выданы настройки и все бы ни чего, но админ решил поменять имя хосту.

Залез на сервер и поменял его в DNS (при нашей схеме) на IP 192.168.128.9

Теперь при запросе имени этого хоста dns будет возвращать новый IP
клиента 192.168.128.9. Но ведь клиент еще работает со старым IP (8-ым).

Вот тут и получается неувязочка.

Хотя с другой стороны до идеально верной конфигурации сети остается
ровно столько, сколько осталось носить старый IP этому клиенту + время
жизни DNS записи.

При ближайшей пере конфигурации клиента ему будет выдан новый IP,
который будет соответствовать настроенному DNS.

2. В случае смены хостом IP адреса его придется менять не только в
прямой зоне просмотра но и в обратной.

Это можно не много упростить, генерируя файлы зон через специальный
скрипт. В моем у случае на ruby так как мы используем chef.

Что тоже вполне логично и оправданно.

Единственное что в данной конфигурации заставляет задуматься, так это
то, что не получится сделать идеально правильную систему.
Логически (с точки зрения работы службы разрешения имен) правильней
использовать динамическое обновление.
Оно не приводит систему в нерабочее состояние (не соответствие записи
dns текущему ip клиента хоста, выданному до смены ip в dns ) пусть даже
и в короткие промежутки времени.
Я имею в виду что можно задать срок аренды и время жизни dns
относительно небольшим, например 15 минут и всегда помнить о том, что
при смене ip в DNS конфигурация может быть неправильна на не которое время.

Что скажите ?

--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор

Скубриев Владимир
~~~
Россия, Ростовская область, г. Таганрог

тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru

* Russian - detected
* English

* English

javascript:void(0);

Re: как должен работать ddns + dhcpd + bind?

2013-07-15 Пенетрантность Hleb Valoshka

On 7/15/13, Владимир Скубриев vladi...@skubriev.ru wrote:
 Логически (с точки зрения работы службы разрешения имен) правильней
 использовать динамическое обновление.
 Оно не приводит систему в нерабочее состояние (не соответствие записи
 dns текущему ip клиента хоста, выданному до смены ip в dns ) пусть даже
 и в короткие промежутки времени.
 Я имею в виду что можно задать срок аренды и время жизни dns
 относительно небольшим, например 15 минут и всегда помнить о том, что
 при смене ip в DNS конфигурация может быть неправильна на не которое время.

 Что скажите ?

Вы меняете адреса по 7 раз на день? За день (или какой там у вас TTL),
уменьшили его до 5-10-15 минут, когда все машины уже обновляют адреса
с новым TTL, поменяли адрес и вернули старый TTL. Делов-то.

Re: как должен работать ddns + dhcpd + bind?

2013-07-15 Пенетрантность Владимир Скубриев

On 15.07.2013 16:32, Hleb Valoshka wrote:

On 7/15/13, Владимир Скубриев vladi...@skubriev.ru wrote:

Логически (с точки зрения работы службы разрешения имен) правильней
использовать динамическое обновление.
Оно не приводит систему в нерабочее состояние (не соответствие записи
dns текущему ip клиента хоста, выданному до смены ip в dns ) пусть даже
и в короткие промежутки времени.
Я имею в виду что можно задать срок аренды и время жизни dns
относительно небольшим, например 15 минут и всегда помнить о том, что
при смене ip в DNS конфигурация может быть неправильна на не которое время.

Что скажите ?

Вы меняете адреса по 7 раз на день? За день (или какой там у вас TTL),
уменьшили его до 5-10-15 минут, когда все машины уже обновляют адреса
с новым TTL, поменяли адрес и вернули старый TTL. Делов-то.
Ну спору нет данная схема вполне рабочая. Просто я хотел убедиться, что
правильно понимаю все

--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор

Скубриев Владимир
~~~
Россия, Ростовская область, г. Таганрог

тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru

56 matches

Mail list logo