The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Правила PF для DHCPD"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Firewall, Фильтрация пакетов / FreeBSD)
Изначальное сообщение [ Отслеживать ]

"Правила PF для DHCPD"  +/
Сообщение от Аноним (??) on 06-Дек-13, 17:15 
Имеются некоторые непонятки с работой демона ICS-DHCPD и пакетного фильтра pf на FreebSD  9.2-RELEASE amd.
Имеются вот такие правила PF для работы сервера DHCP:
==============================
block all no state
pass in quick on $int_if proto {udp,tcp} from any port 67 to any port 68
pass out quick on $int_if proto {udp,tcp} from any port 68 to any port 67
pass out quick on $int_if proto {udp,tcp} user { dhcpd }
pass out on $int_if inet proto icmp all icmp-type echoreq
==============================
При таких правилах демон dhcpd постоянно валит сообщениями в syslog:
==============================
dhcpd: send_packet: Operation not permitted
dhcpd: dhcp.c:1346: Failed to send 300 byte long packet over fallback interface.
==============================
Если в правилах пакетника "block all" заменить на "pass all" - то dhcpd перестает ругаться.
Что надо прописать pf-у что бы он перестал мешать dhcpd-шнику душить этот fallback интерфейс? Где вообще находится этот fallback, ifconfig его почему-то не показывает, это какой-то скрытый интерфейс что-ли?



Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Правила PF для DHCPD"  +/
Сообщение от михалыч (ok) on 06-Дек-13, 17:41 
> Где вообще находится этот fallback?

Да-да, я тоже хочу знать.
Где эта сволочь?! (С)

Извините, не удержался. ))

Приведите полные конфиги dhcpd.conf, pf.conf, а то начнётся вытягивание клещами нужной информации.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Правила PF для DHCPD"  +/
Сообщение от Аноним (??) on 06-Дек-13, 23:25 
> Приведите полные конфиги dhcpd.conf, pf.conf

Собственно полный конфиг pf.conf в первом сообщении, изначально он был конечно гораздо больше, но что бы локализовать проблему его урезали до такого состояния. Единственно там есть еще несколько строк, хотя они к правилам не относятся и вряд-ли они являются причиной проблемы, но раз надо то вот весь конфиг:
===============================
int_if="re0"

set optimization aggressive
set loginterface none
set block-policy drop
set require-order yes
set fingerprints "/etc/pf/pf.os"
set skip on lo0
set timeout { tcp.finwait 25 }
set timeout { tcp.established 3600 }
scrub in all

block all no state
pass in quick on $int_if proto {udp,tcp} from any port 67 to any port 68
pass out quick on $int_if proto {udp,tcp} from any port 68 to any port 67
pass out quick on $int_if proto {udp,tcp} user { dhcpd }
pass out on $int_if inet proto icmp all icmp-type echoreq
===============================

Вот dhcpd.conf
===============================
option domain-name-servers 192.168.1.1;
default-lease-time 3400;
max-lease-time 7200;
authoritative;
log-facility local7;
subnet 192.168.1.0 netmask 255.255.255.0 {
    option routers 192.168.1.1;
    option subnet-mask  255.255.255.0;
    range 192.168.1.10 192.168.1.20;
}
===============================
ifconfig:
===============================
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
     options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
        ether 08:60:6e:e4:eb:06
        inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet 127.0.0.1 netmask 0xff000000
===============================

В rc.conf опции запуска dhcpd следующее:
===============================
dhcpd_enable="YES"
dhcpd_ifaces="re0"
dhcpd_flags="-s 192.168.1.1"
dhcpd_conf="/usr/local/etc/dhcpd.conf"
dhcpd_withumask="022"
===============================
Опцию "-s 192.168.1.1" добавил уже в конце рабдня, и поможет она или нет пока не проверял, перезапустил демона и ушел домой.


Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Правила PF для DHCPD"  +2 +/
Сообщение от михалыч (ok) on 07-Дек-13, 07:17 
>[оверквотинг удален]
> В rc.conf опции запуска dhcpd следующее:
> ===============================
> dhcpd_enable="YES"
> dhcpd_ifaces="re0"
> dhcpd_flags="-s 192.168.1.1"
> dhcpd_conf="/usr/local/etc/dhcpd.conf"
> dhcpd_withumask="022"
> ===============================
> Опцию "-s 192.168.1.1" добавил уже в конце рабдня, и поможет она или
> нет пока не проверял, перезапустил демона и ушел домой.

Да.., блин.
Смотрю и не перестаю удивляться.

Что у вас за "отражатель" такой?
В ifconfig всего один интерфейс re0, но в то же время в dhcpd.conf указываете
option routers 192.168.1.1 это как так? Где второй интерфейс, как трафик пойдёт?

DHCP настраиваете для 10 хостов? Зачем? Шишек набить? Так уже..
Статику пропишите. Но если надо, так надо..

То что вы написали - это хрень.
Читаем:

Разрешить входящий трафик на внутреннем интерфейсе от любых хостов с порта 67 к любым хостам на порт 68
> pass in quick on $int_if proto {udp,tcp} from any port 67 to any port 68

Разрешить исходящий трафик на внутреннем интерфейсе от любых хостов с порта 68 к любым хостам на порт 67
> pass out quick on $int_if proto {udp,tcp} from any port 68 to any port 67

ещё раз читаем и перечитываем, убеждаемся что хрень.
Лезем в /etc/services
bootps           67/tcp    dhcps        #Bootstrap Protocol Server
bootps           67/udp    dhcps        #Bootstrap Protocol Server
bootpc           68/tcp    dhcpc        #Bootstrap Protocol Client
bootpc           68/udp    dhcpc        #Bootstrap Protocol Client

Клиент делает запрос на получение IP-адреса, трафик от него на интерфейсе re0 будет входящий.
Сервер отвечает клиенту, трафик от него на интерфейсе re0 будет исходящий.
Вы с этими in / out заблудились.

Если сомневаетесь, проверяйте так:
# Разрешить входящий и исходящий трафик на внутреннем интерфейсе от любых хостов с порта 67 или 68 к любым хостам с портами 67 или 68
pass $int_if proto { udp tcp } from any port { 67 68 } to any port { 67 68 }

Хотя смысл всего этого.. непонятен.
Ну получил клиент IP-адрес, а дальше что? Ну что он с ним будет делать?
Надо правила выпускающие и принимающие для этих клиентов, получивших свои IP-адреса прописывать дальше.
А у вас интерфейс всего один!

Опять же, прописывать отдельные правила для получения IP-адресов по dhcp ну зачем?
А это зачем?
> set fingerprints "/etc/pf/pf.os"

ОСь клиентов определяете и Windows будете блокировать? ))

То что нужно - нет, а всякой фигни натолкали.

Вот минимальный конфиг, простой как 3 рубля.
# внутренний входящий интерфейс
int_if="re0"

# внешний исходящий интерфейс
ext_if="???"

# петлевой интерфейс
lo0="127.0.0.1"

# локальная сеть
table <network> { 192.168.1.0/24 }

# политика блокирования
set block-policy drop

# не фильтровать трафик на кольцевом интерфейсе
set skip on lo0

# нормализовать входящий трафик
scrub in all

# блокируем всё
block all

# пропустить весь трафик в локальную сеть и из локальной сети
# эти правила будут создавать записи в таблице состояний, благодаря
# дефолтной опции "keep state", которая будет применена автоматически
pass in on $int_if from <network> to any

# выпустить tcp, udp и icmp трафик на внешнем (Интернет) интерфейсе
# tcp соединения буду модулироваться,
# udp/icmp будут отслеживаться по таблице состояний
pass out on $ext_if proto { tcp udp icmp } all modulate state

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Правила PF для DHCPD"  +/
Сообщение от Аноним (??) on 07-Дек-13, 13:16 
> option routers 192.168.1.1 это как так? Где второй интерфейс, как трафик пойдёт?

Да пока никак не пойдет, сейчас это всего-лишь тестовый вариант, а уж когда надо будет укажу там адрес реального шлюза и реального ДНС-а.
По большому счету сейчас пофиг какие там значения шлюза и ДНС-ов выдает dhcpd, клиент DHCP все равно подцепляется, а уж пойдет он там дальше или не пойдет - это никак не относится к сообщениям "dhcpd: send_packet: Operation not permitted"

> DHCP настраиваете для 10 хостов? Зачем?

Просто это гостевая точка доступа для приемной (ресепшена), там больше пяти-шести человек не помещается, ну в общем что бы они пока ожидают могли на своих айпадах и айфонах тырнетом попользоваться нахаляву.

> То что вы написали - это хрень.

Да я и не писал, просто взял где-то в гугле рабочий вариант. Видать он не такой уж и рабочий, либо на самом деле у автора там еще были какие-то правила, про которые он не написал.

> Если сомневаетесь, проверяйте так:
> # Разрешить входящий и исходящий трафик на внутреннем интерфейсе от любых хостов
> с порта 67 или 68 к любым хостам с портами 67
> или 68
> pass $int_if proto { udp tcp } from any port { 67
> 68 } to any port { 67 68 }

Спасибо, попробую так как вы написали.

> А это зачем?
>> set fingerprints "/etc/pf/pf.os"
> ОСь клиентов определяете и Windows будете блокировать? ))
> То что нужно - нет, а всякой фигни натолкали.

Да не толкал я это, это в дефолтном pf.conf уже было. Если честно я не знаю - зачем пакетному фильтру эти "отпечатки", если он без них будет работать быстрее - то тады однозначно выкину это к чертям.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Правила PF для DHCPD"  +/
Сообщение от Аноним (??) on 12-Дек-13, 09:40 
Прочитал множество букв по протоколам DHCP/BOOTP, переделал набор правил, и сейчас он такой:
================================================================
block all no state
pass in quick on $int_if proto udp from any to ($int_if) port 67
pass all user { dhcpd } flags any
pass out on $int_if inet proto icmp all
================================================================
Но все равно dhcpd ругается:
================================================================
Dec 11 11:43:02 gate dhcpd: DHCPINFORM from 192.168.1.10 via re0
Dec 11 11:43:02 gate dhcpd: DHCPACK to 192.168.1.10 (00:14:a3:1d:ff:8f) via re0
Dec 11 11:43:02 gate dhcpd: send_packet: Operation not permitted
Dec 11 11:43:02 gate dhcpd: dhcp.c:1346: Failed to send 300 byte long packet over fallback interface.
================================================================
Но при этом все работает, клиенты получают IP и настройки для выхода в тырнет.
Чего не хватает этому мерзкому dhcpd что бы он успокоился и прекратил ругаться на fallback interface?
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Правила PF для DHCPD"  +/
Сообщение от LSTemp (ok) on 14-Дек-13, 08:08 
>[оверквотинг удален]
> При таких правилах демон dhcpd постоянно валит сообщениями в syslog:
> ==============================
> dhcpd: send_packet: Operation not permitted
> dhcpd: dhcp.c:1346: Failed to send 300 byte long packet over fallback interface.
> ==============================
> Если в правилах пакетника "block all" заменить на "pass all" - то
> dhcpd перестает ругаться.
> Что надо прописать pf-у что бы он перестал мешать dhcpd-шнику душить этот
> fallback интерфейс? Где вообще находится этот fallback, ifconfig его почему-то не
> показывает, это какой-то скрытый интерфейс что-ли?

вообще-то PF (как и другой нормальный сетевой фильтр) работает по умолчанию на L3 (без дополнительных модулей). DHCP-же протокол L2-уровня. отсюда плешите.

PS
кпроме этого  - по простому - http://ru.wikipedia.org/wiki/DHCP - все разжевано.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Правила PF для DHCPD"  +/
Сообщение от Аноним (??) on 14-Дек-13, 12:18 
> вообще-то PF (как и другой нормальный сетевой фильтр) работает по умолчанию на
> L3 (без дополнительных модулей). DHCP-же протокол L2-уровня. отсюда плешите.

Да, но почему когда оставляешь одно разрешающее все правило "pass all" - то ругань прекращается? Значит PF как-то что-то все же умудряется заблокировать из этого L2, хотя никаких модулей для L2 я специально не устанавливал.


> по простому - http://ru.wikipedia.org/wiki/DHCP - все разжевано.

Да ничего там не разжевано, там написано что используются порты UDP 67/68, эти порты я уже давно разрешил. Тут именно какая-то шняга зарыта в демоне ics-dhcpd, вот например в той-же педивикии не написано, что перед выдачей IP еще и по icmp надо проверять наличие хоста с таким адресом - а dhcpd это делает. Думаю что мессаджи "Failed to send 300 byte long packet over fallback interface" тоже из той серии: dhcpd имеет какие-то дополнительные свои фишки, которые напрямую не относятся к протоколу DHCP - ведь клиенты адрес таки получают.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Правила PF для DHCPD"  +/
Сообщение от LSTemp (ok) on 14-Дек-13, 13:34 
>> вообще-то PF (как и другой нормальный сетевой фильтр) работает по умолчанию на
>> L3 (без дополнительных модулей). DHCP-же протокол L2-уровня. отсюда плешите.
> Да, но почему когда оставляешь одно разрешающее все правило "pass all" -
> то ругань прекращается? Значит PF как-то что-то все же умудряется заблокировать
> из этого L2, хотя никаких модулей для L2 я специально не
> устанавливал.

а не специально? что подгружено в ядро?

>> по простому - http://ru.wikipedia.org/wiki/DHCP - все разжевано.
> Да ничего там не разжевано, там написано что используются порты UDP 67/68,
> эти порты я уже давно разрешил. Тут именно какая-то шняга зарыта
> в демоне ics-dhcpd, вот например в той-же педивикии не написано, что
> перед выдачей IP еще и по icmp надо проверять наличие хоста
> с таким адресом - а dhcpd это делает. Думаю что мессаджи
> "Failed to send 300 byte long packet over fallback interface" тоже
> из той серии: dhcpd имеет какие-то дополнительные свои фишки, которые напрямую
> не относятся к протоколу DHCP - ведь клиенты адрес таки получают.

там русским по белому описан весь процесс. если Вам этого недостаточно - читайте RFC.

ЗЫ
Ваши потуги открыть порты 67 и 68 ничего не стоят - другой уровень стека. поймите это наконец. и вики еще раз внимательней почитайте. даже если порты не открыты DHCP пробьется ч/з широковещвтельный запрос по L2.


Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

10. "Правила PF для DHCPD"  +/
Сообщение от Аноним (??) on 14-Дек-13, 15:55 
> а не специально? что подгружено в ядро?

kldstat сообщает что подгружен только pf.ko
Само ядро собрано на основе GENERIC, только выкинул оттуда все, что по моему разумению никогда не понадобится. Ничего дополнительно в ядро не вставлял.

> даже если порты не открыты DHCP пробьется ч/з широковещвтельный запрос по L2.

Да как он пробьется-то, если в правилах оставить только "block all" - то совсем ничего не пробивается, даже ICMP, и клиенты тоже не получают адреса по DHCP. Я уж не знаю, на какой уровень глубины стека там распространяется влияние пакетного фильтра PF, но DHCP точно перестает работать с "block all", зачем мне врать - можете сами проверить.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

11. "Правила PF для DHCPD"  +/
Сообщение от co6aka (ok) on 16-Дек-13, 02:50 
Разрешите и входящие icmp пакеты. Они не просто так придуманы. http://ru.wikipedia.org/wiki/ICMP

ЗЫ: Это не ответ на ваш вопрос, но icmp нужен.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

12. "Правила PF для DHCPD"  +/
Сообщение от Аноним (??) on 19-Дек-13, 10:11 
> Разрешите и входящие icmp пакеты. Они не просто так придуманы.
> ... но icmp нужен.

Не нужны входящие icmp на машине, где только DHCP демон работает. На каком-нить шлюзе нужны однозначно, что бы всякие там нидфраги обрабатывать и для прочей диагностики типа трейсроутов и пингов, ну а просто входящие icmp для DHCP - не нужны, нет в RFC никаких упоминаний про это.

В общем проблему решил просто: закоментил в исходниках dhcpd выдачу диагностического сообщения что бы они не засирали логи - и все. Это сообщение вылазит только когда сервер  посылает клиенту DHCPACK в ответ на DHCPINFORM, хрен его знает чем это грозит - но клиенты работают нормально и аренда вроде как продлевается успешно, все адреса шлюзов/днс-ов клиенты получают и проблем у них не наблюдается.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "Правила PF для DHCPD"  +/
Сообщение от LSTemp (ok) on 20-Дек-13, 17:44 
>[оверквотинг удален]
> каком-нить шлюзе нужны однозначно, что бы всякие там нидфраги обрабатывать и
> для прочей диагностики типа трейсроутов и пингов, ну а просто входящие
> icmp для DHCP - не нужны, нет в RFC никаких упоминаний
> про это.
> В общем проблему решил просто: закоментил в исходниках dhcpd выдачу диагностического сообщения
> что бы они не засирали логи - и все. Это сообщение
> вылазит только когда сервер  посылает клиенту DHCPACK в ответ на
> DHCPINFORM, хрен его знает чем это грозит - но клиенты работают
> нормально и аренда вроде как продлевается успешно, все адреса шлюзов/днс-ов клиенты
> получают и проблем у них не наблюдается.

??? причем тут icmp
??? dhcp "на шлюзе" называется dhcp relay. то, что dhcp  - это протокол уровня L2, а шлюз - это уже (как минимум) L3-4 (сеть и транспорт) не напрягает вообще?

продолжайте "проблему решать" в том же духе. удачи.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

15. "Правила PF для DHCPD"  +/
Сообщение от Аноним (??) on 20-Дек-13, 18:33 
> ??? причем тут icmp
> ??? dhcp "на шлюзе" называется dhcp relay.

Причем тут dhcp relay? С чего вы взяли что у меня dhcpd на шлюзе? Я лишь написал что он ОТДАЕТ адрес шлюза, но эта машина - не шлюз, я кажется это уже внятно объяснял выше.


Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

14. "Правила PF для DHCPD"  +/
Сообщение от LSTemp (ok) on 20-Дек-13, 17:51 
>> а не специально? что подгружено в ядро?
> kldstat сообщает что подгружен только pf.ko
> Само ядро собрано на основе GENERIC, только выкинул оттуда все, что по
> моему разумению никогда не понадобится. Ничего дополнительно в ядро не вставлял.
>> даже если порты не открыты DHCP пробьется ч/з широковещвтельный запрос по L2.
> Да как он пробьется-то, если в правилах оставить только "block all" -
> то совсем ничего не пробивается, даже ICMP, и клиенты тоже не
> получают адреса по DHCP. Я уж не знаю, на какой уровень
> глубины стека там распространяется влияние пакетного фильтра PF, но DHCP точно

Вот и узнайте. Доки благо есть на Вашу ОС.

> перестает работать с "block all", зачем мне врать - можете сами
> проверить.

Не буду - не зачем. Вам только Lavr поможет. Бейтесь к нему. Он черту подведет.


Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

16. "Правила PF для DHCPD"  +/
Сообщение от Аноним (??) on 20-Дек-13, 18:40 
> Вот и узнайте. Доки благо есть на Вашу ОС.

Да ладно? Я и не знал, что есть, оказываются, доки на ОС. Спасибо за очень ценный совет, пойду доки искать, ну и заодно попутно изучу исходники dhcpd и pf что бы уж наверняка!

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

18. "Правила PF для DHCPD"  +/
Сообщение от LSTemp (ok) on 11-Фев-14, 05:03 
>> Вот и узнайте. Доки благо есть на Вашу ОС.
> Да ладно? Я и не знал, что есть, оказываются, доки на ОС.
> Спасибо за очень ценный совет, пойду доки искать, ну и заодно
> попутно изучу исходники dhcpd и pf что бы уж наверняка!

Мне смеяться или плакать теперь?


Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

9. "Правила PF для DHCPD"  +/
Сообщение от LSTemp (ok) on 14-Дек-13, 13:51 
>> вообще-то PF (как и другой нормальный сетевой фильтр) работает по умолчанию на
>> L3 (без дополнительных модулей). DHCP-же протокол L2-уровня. отсюда плешите.
> Да, но почему когда оставляешь одно разрешающее все правило "pass all" -
> то ругань прекращается? Значит PF как-то что-то все же умудряется заблокировать
> из этого L2, хотя никаких модулей для L2 я специально не
> устанавливал.

Не из L2. курите вдумчивей. чудес на свете не бывает.


>> по простому - http://ru.wikipedia.org/wiki/DHCP - все разжевано.
> Да ничего там не разжевано, там написано что используются порты UDP 67/68,
> эти порты я уже давно разрешил. Тут именно какая-то шняга зарыта
> в демоне ics-dhcpd, вот например в той-же педивикии не написано, что
> перед выдачей IP еще и по icmp надо проверять наличие хоста
> с таким адресом - а dhcpd это делает. Думаю что мессаджи
> "Failed to send 300 byte long packet over fallback interface" тоже
> из той серии: dhcpd имеет какие-то дополнительные свои фишки, которые напрямую
> не относятся к протоколу DHCP - ведь клиенты адрес таки получают.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

17. "Правила PF для DHCPD"  +/
Сообщение от Аноним (??) on 30-Дек-13, 14:31 
> курите вдумчивей.

решил таки покурить вдумчивей, включил pflog и вот он отловил:
=================================================================================
block in on re0: 192.168.1.16.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
block out on re0: 192.168.1.1.67 > 192.168.1.16.68: BOOTP/DHCP, Reply, length 300
=================================================================================

Непонятно, почему правило
pass all user { dhcpd } flags any
не выпускает 192.168.1.1.67 > 192.168.1.16.68 , возможно тут какая-то таинственная магия вмешивается в процесс и пакеты идут не от dhcpd а от рута, но да черт с ним, переписал правила и теперь они такие:
===========================================
block all no state
pass in quick on $int_if proto udp from any to $int_if:broadcast port 67
pass in quick on $int_if proto udp from any to ($int_if) port 67
pass out quick on $int_if proto udp to any port 68
pass all user { dhcpd } flags any
===========================================
В новом году продолжу наблюдения, может еще что-то придется подкорректировать.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

20. "Правила PF для DHCPD"  +/
Сообщение от ShyLion (ok) on 11-Фев-14, 15:20 
> Непонятно, почему правило
> pass all user { dhcpd } flags any
> не выпускает 192.168.1.1.67 > 192.168.1.16.68 , возможно тут какая-то таинственная магия
> вмешивается в процесс и пакеты идут не от dhcpd а от
> рута

Если я правильно помню, чтобы принимать пакеты на широковещательный адрес, нужен доступ к RAW сокету, а для этого таки нужны рутовые права.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

19. "Правила PF для DHCPD"  +/
Сообщение от ShyLion (ok) on 11-Фев-14, 15:18 
> DHCP-же протокол L2-уровня. отсюда плешите.

DHCP работает поверх UPD протокола - третьего уровня. Советую самому все-таки прочесть RFC или на худой конец википедию. То, что он использует широковещательные запросы от рабочих станций, не делает его протоколом второго уровня.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру