Перейти до

FreeBSD, isc-dhcp44-relay + isc-dhcp44-server на одном компе


Рекомендованные сообщения

Доброго всем дня.

Стояла себе сетка з раздачей адресов по DHCP c FreeBSD  сервака через isc-dhcp44-server и всё работало. Захотелось раздавать адреса не в соответствии с МАС адресами клиентов, а в соответствии с сетевым интерфейсом, через который клиент подключен независимо от его MAC адреса. Для этого понадобилось установить isc-dhcp44-relay, который умеет снимать имена интерфейсов с входных запросов и передавать их DHCP серверу. И тут вылезла проблема. Если isc-dhcp44-relay и isc-dhcp44-server находятся на физически разных компах, то всё работает без проблем. Однако, держать отдельно специальный комп только под isc-dhcp44-server как-то не хочется, хотелось бы всё это впихнуть на один комп и вот тут - никак. Эти два продукта одной фирмы садятся в сетевой стек очень глубоко, на уровне BPF и пытаются одновременно занять одни и те-же ресурсы. Попытка поместить isc-dhcp44-server в Jail и даже в виртуальную машину тоже успеха не принесла. Попытки заменить на продукты других разработчиков пока не дали работоспособной конфигурации тоже. Кто-то сталкивался с такой задачей? Есть хоть какая-то возможность совместить оба продукта ISC на одном FreeBSD компе? Или, возможно, есть другое рабочее решение для раздачи IP адресов клиентам не по MAC-ам, а по интерфейсам подключения с помощью одного FreeBSD компа?

Спасибо.

Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 58
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Ну зачем это писать? Вы пробовали? Вы читали что я выше писал? Каждый экземпляр садится НА ВСЕ адреса. Запуск второго экземпляра невозможен. Привязка к интерфейсам на это никак не в

1 час назад, Baneff сказал:

Доброго всем дня.

Стояла себе сетка з раздачей адресов по DHCP c FreeBSD  сервака через isc-dhcp44-server и всё работало. Захотелось раздавать адреса не в соответствии с МАС адресами клиентов, а в соответствии с сетевым интерфейсом, через который клиент подключен независимо от его MAC адреса. Для этого понадобилось установить isc-dhcp44-relay, который умеет снимать имена интерфейсов с входных запросов и передавать их DHCP серверу. И тут вылезла проблема. Если isc-dhcp44-relay и isc-dhcp44-server находятся на физически разных компах, то всё работает без проблем. Однако, держать отдельно специальный комп только под isc-dhcp44-server как-то не хочется, хотелось бы всё это впихнуть на один комп и вот тут - никак. Эти два продукта одной фирмы садятся в сетевой стек очень глубоко, на уровне BPF и пытаются одновременно занять одни и те-же ресурсы. Попытка поместить isc-dhcp44-server в Jail и даже в виртуальную машину тоже успеха не принесла. Попытки заменить на продукты других разработчиков пока не дали работоспособной конфигурации тоже. Кто-то сталкивался с такой задачей? Есть хоть какая-то возможность совместить оба продукта ISC на одном FreeBSD компе? Или, возможно, есть другое рабочее решение для раздачи IP адресов клиентам не по MAC-ам, а по интерфейсам подключения с помощью одного FreeBSD компа?

Спасибо.

 

разнести их по разным интерфейсам же

хз, можно ли дхцп сервер вынести в lo0, но если прокатит - вас ждет успех

либо на пустой бридж посадить

Ссылка на сообщение
Поделиться на других сайтах
5 минут назад, l1ght сказал:

разнести их по разным интерфейсам же

хз, можно ли дхцп сервер вынести в lo0, но если прокатит - вас ждет успех

либо на пустой бридж посадить

Они оба по интерфейсам не разводятся и чисто на lo0 не садятся, а сразу тупо пытаются сесть на 0.0.0.0/0:67 вне зависимости от настроек. Естественно, сразу у обоих это не получается. Можно посадить сервер на порт, отличный от 67, тогда запускаются оба. Но тогда непонятно, как заставить релей передавать запросы юзеров на нестандартный порт сервера. Ещё идеи есть?

Ссылка на сообщение
Поделиться на других сайтах
8 минут назад, Baneff сказал:

Они оба по интерфейсам не разводятся и чисто на lo0 не садятся, а сразу тупо пытаются сесть на 0.0.0.0/0:67 вне зависимости от настроек. Естественно, сразу у обоих это не получается. Можно посадить сервер на порт, отличный от 67, тогда запускаются оба. Но тогда непонятно, как заставить релей передавать запросы юзеров на нестандартный порт сервера. Ещё идеи есть?

Запросы передавать на другой порт с помощью фаервола

Ссылка на сообщение
Поделиться на других сайтах
15 минут назад, joker85 сказал:

Запросы передавать на другой порт с помощью фаервола

Интересная мысль, спасибо, попробую с помощью ipfw fwd перенаправить запросы на нестандартный порт.

Ссылка на сообщение
Поделиться на других сайтах
1 час назад, Baneff сказал:

Интересная мысль, спасибо, попробую с помощью ipfw fwd перенаправить запросы на нестандартный порт.

ipfw_or_pf

Ссылка на сообщение
Поделиться на других сайтах
1 минуту назад, joker85 сказал:

ipfw_or_pf

Да, но на этом компе только ipfw используется в даннй момент, не хочется плодить сущности. Как раз сейчас проверяю, о результатах доложусь.

Ссылка на сообщение
Поделиться на других сайтах
3 часа назад, Baneff сказал:

Они оба по интерфейсам не разводятся и чисто на lo0 не садятся, а сразу тупо пытаются сесть на 0.0.0.0/0:67 вне зависимости от настроек. Естественно, сразу у обоих это не получается. Можно посадить сервер на порт, отличный от 67, тогда запускаются оба. Но тогда непонятно, как заставить релей передавать запросы юзеров на нестандартный порт сервера. Ещё идеи есть?

Да херня же, не должно так быть.

Вот правда isc-dhcp4 я в глаза не видел. Но тройка то точно умела на нужный интерфейс падать.

Ссылка на сообщение
Поделиться на других сайтах
8 минут назад, l1ght сказал:

Да херня же, не должно так быть.

Вот правда isc-dhcp4 я в глаза не видел. Но тройка то точно умела на нужный интерфейс падать.

Полностью согласен - херня и так не должно быть. Однако факт налицо:

> sockstat -l
USER     COMMAND    PID     FD PROTO  LOCAL ADDRESS    FOREIGN ADDRESS

dhcpd    dhcpd            60531 8    udp4      *:67                           *:*

Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, joker85 сказал:

Пишите, инстересно узнать

Не, не получается. Пытался завернуть запросы на нестандарный порт по всякому, но дхцп сервер не отвечает на такие попытки.

Ссылка на сообщение
Поделиться на других сайтах
Только что, fet4 сказал:

Поверьте это лучшее что я видел для ipoe.

Верю, но смена оси не обсуждается, не от меня зависит.

Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, Baneff сказал:

Полностью согласен - херня и так не должно быть. Однако факт налицо:

> sockstat -l
USER     COMMAND    PID     FD PROTO  LOCAL ADDRESS    FOREIGN ADDRESS

dhcpd    dhcpd            60531 8    udp4      *:67                           *:*

А конфиг под него как выглядит?

Раньше опция была dhcpd_ifaces

Ссылка на сообщение
Поделиться на других сайтах
34 минуты назад, l1ght сказал:

А конфиг под него как выглядит?

Раньше опция была dhcpd_ifaces

Опция есть, говорит на каких интерфейсах слушать. Но тулза всё равно садится на *:67 без разговоров и это не отключается. В код лезть как-то лениво, видно придётся таки доставить второй комп, может заодно ещё для чего пригодится. Больше идей пока нет.

Ссылка на сообщение
Поделиться на других сайтах

Чем плох релей на коммутаторе? В крайнем случае, микротик?

2 поеделки ISC одновременно на одной машине работать не будут.

Ссылка на сообщение
Поделиться на других сайтах

Если уж очень хочется запустить всё на одной системе, то пользовать релей от ISC на radius или на Perl

Честно говоря, у меня подобная проблема, и я, к сожалению, ещё не решил её оптимальным, кмк, образом.

Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, joker85 сказал:

понизьте версию по, или стороннее установите с нага возьмете

Пробовал 3-ю версию - аналогично, да и безопасность пострадает, там дыры.С нага и прочее стороннее брал и пробовал, но проблема в том, что всё это потустороннее - это всё DHCP сервера, а рабочий DHCP релей с нужным функционалом по сути наличествует только один, вот этот самый ISC DHCP Relay. Это очень странно, но правильно работать с виланами, а не только с МАС-ами клиентов почему-то может только вот эта поделка. Значит, если мы ставим перед собой задачу все это запустить на одно компе, то первая половина задачи не обсуждается - сначала ставим ISC DHCP Relay. На а дальше всё, тупик. Как я уже говорил этот релей хоть и обеспечивает необходимый функционал, но при запуске сразу и без вариантов биндится на *:67, а после этого уже невозможно на этот комп поставить никакой DHCP сервер, поскольку ему тоже нужно биндиться на 67 порт хотя-бы на один IP адрес, но всё уже тупо занято релеем. Попытки привязать DHCP сервер к другому порту и потом мапить/перенаправлять порты к успеху не привели, возможно я что-то не так делал. Вывод я для себя сделал такой - не хочешь использовать релеи на свичах - ставь второйкомп и разноси физически релей и сервер, всё работает без проблем. Не хочешь ставить второй комп - только схема с релеями на свичах и сервером на компе, тоже работает. А вот первоначальная задача - обойтись одним компом без использования релеев свичей похоже решения не имеет, что обидно конечно.

Ссылка на сообщение
Поделиться на других сайтах
1 час назад, andryas сказал:

Чем плох релей на коммутаторе? В крайнем случае, микротик?

2 поеделки ISC одновременно на одной машине работать не будут.

Похоже, что так, тоже пришёл к такому выводу. Хотелось простоты и однообразия, а релеи на свичах как бы лишние сущности если удалось бы запустит требуемую связку. Свичи разные, с разными системами команд, сегодня одни, а завтра другие и всё это напрягает. Кроме того свич с релеем предполагает определённую ценовую категорию, на дешёвые свичи релеи не ставят, нет функционала. Но делать нечего - не получилось по простому - пойдём по сложному пути. Опять же, если у кого и так есть второй комп под контролем и не нужно доставлять ещё один, то всё прекрасно решается без релеев на свичах. И, если уж на то пошло, таки можно и доставить второй комп, может заодно ещё для чего пригодится.

Ссылка на сообщение
Поделиться на других сайтах
1 час назад, andryas сказал:

Если уж очень хочется запустить всё на одной системе, то пользовать релей от ISC на radius или на Perl

Честно говоря, у меня подобная проблема, и я, к сожалению, ещё не решил её оптимальным, кмк, образом.

Увы, связка на одном компе не выходит никак. После установки релея уже ничто в пару к нему не становится ибо 67 порт занят полностью релеем. По крайней мере у меня так. У кого есть в системе второй физический комп, то проблем нет, разносим и работаем. В моём случае там нет второго физического компа, а значит либо доставляем его специально под эту задачу либо используем релеи свичей, ничего другого я не вижу. Как по мне, доставить второй комп проще. Если решите, то, плиз, дайте знать, интересно всё таки.

Ссылка на сообщение
Поделиться на других сайтах

Кстати, попробовал сейчас такую связку: релей на локальном компе, а сервер на виртуальном серваке, арендованом где-то в облаках за 3.5 евры в мес. Работает. Это, конечно, экстрим, на как вариант на крайняк... Между релеем и сервером идёт простой юникастовый обмен по udp с порта 67 на порт 67 и обратно, никакой магии. Попутно выяснилось, что продукты ISC действительно работают с клиентами через BPF на очень глубоком уровне стека, еще перед всякими файерволами и тому подобным. Запретить там что-то или перенаправить куда-то правилами файервола невозможно, обмен происходит ниже. Говорят так исторически сложилось, слишком древний и слмшком многоплатформенный продукт, получилось как смогли. Но вот с нелокальными ресурсами эта байда работает стандартно, потому физическое разнесение и помогает. Где-то так.

Ссылка на сообщение
Поделиться на других сайтах
7 минут назад, Baneff сказал:

Говорят так исторически сложилось, слишком древний и слмшком многоплатформенный продукт, получилось как смогли. Но вот с нелокальными ресурсами эта байда работает стандартно

 

Иначе на BSD системах никак не принять широковещалку, насколько я понимаю предмет.

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від a_n_h
      Всем доброго дня и мирного неба!
        После многочисленных экспериментов выяснил, что на последних версиях freebsd  максимум удавалось прокачать до 14 ГБт суммарно трафика со 100% загрузкой процессора. На том-же железе но с установленной freebsd 11.2 прокачивается до 20-ти ГБт суммарно тестового трафика с загрузкой процессора около 50%. 
        Подскажите, что можно убрать или наоборот добавить в систему с freebsd 13,3 для получения аналогичного результата...
    • Від stack-systems
      продам сервера HPE Proliant DL380 Gen10 8SFF 2U 800W Rack - 69000 грн с ндс (цена обсуждаемая)
       
      есть кол-во, новые, в коробках, остаток с проекта
       
      можем доукомплектовать - Intel Xeon 4114 / 16GB / доп. блок питания 800w или по запросу





       
    • Від AvaloncheG
      IBM System x3550 (Type 7978) 1 x Xeon E5335 DDR2 4x1Gb 667MHz - 1200грн.
      IBM System x3650 (Type 7979AC1) 1 x Xeon E5335 DDR2 2x1Gb 667MHz - 1200грн.
      IBM System x3650 M3 (7945L4G) 2 x Xeon 6C X5660 DDR3 16Gb 1333MHz - 5000грн.
      IBM System x3650 M3 (7945L4G) 2 x Xeon 6C X5660 DDR3 48Gb 1333MHz - 6000грн.
      IBM System x3550 M4 (7914E9G) 2 x Xeon E5-2620 DDR3 24Gb 1600MHz - 8000грн.
       
      +380975649269
    • Від mac
      Здається, після оновлення PHP 7.4 до PHP 8.2 feesharvester припинив працювати:
       
      /usr/local/bin/curl "http://127.0.0.1/billing/?module=remoteapi&key={SERIAL}&action=feesharvester" <br /> <b>Fatal error</b>: Uncaught TypeError: Unsupported operand types: string - string in {UBPATH}/billing/api/libs/api.fundsflow.php:570 Stack trace: #0 {UBPATH}/billing/modules/remoteapi/feesharvester.php(22): FundsFlow-&gt;harvestFees('2024-01') ...  
      Невеличке розслідування врешті з'ясувало, що це через наявність пробілу у деяких логінах абонентів. Як так сталося? Тому що інколи був неуважно додан трейлінг пробіл до номеру будинка і цей пробіл потрапив до логіну абоненту. Логін абоненту неможливо змінити ніяким чином штатними засобами. Я не розглядаю створення нового абонента для усунення помілки.

      Був обран такий шлях вирішення проблеми. Заміну функції php explode() знайшов у мережі. Мабуть це станеться в нагоді:

       
      diff api.fundsflow.php.bak api.fundsflow.php.new 559c559 < $eachfee = explode(' ', $eachline); --- > $eachfee = preg_split("~(?<!\\\\)(?:\\\\{2})*'[^'\\\\]*(?:\\\\.[^'\\\\]*)*'(*SKIP)(*F)|\s+~s" , $eachline);  
    • Від FantoM_EscapE
      Хочу перенести свій білінг NODENY із фізичного сервера на віртуальний. Шукаю адміна який зможе допомогти у цьому питанні, так як нашого адміна банально призвали до війська. Вся схема на даний момент робоча, маю доступи до всього. Потрібно проінсталити на новішу версію FREEBSD, бо на моїй 10 річній вже не працюють нові SSL сертифікати. Кого зацікавила дана пропозиція - прошу у приватні повідомлення. обсудимо ціну і строки. або пишіть на будь-який месенджер 0677792091

×
×
  • Створити нове...