Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 49
ip-адрес свитча должен находиться в той же подсети, что и адреса, выдаваемые абонентам.
Не обязательно. Используйте shared-network:
shared-network ISP {
subnet 10.0.0.0 netmask 255.255.255.0
{
#Сеть коммутаторов доступа
range 10.0.0.2 10.0.0.10;
option broadcast-address 10.0.0.255;
option subnet-mask 255.255.255.0;
option routers 10.0.0.1;
}
subnet 10.10.0.0 netmask 255.255.255.0
{
#Сеть клиентов
option broadcast-address 10.10.0.255;
option subnet-mask 255.255.255.0;
option domain-name-servers 10.10.0.1,8.8.8.8;
option routers 10.10.0.1;
class "p5" {
match if binary-to-ascii (10, 8, "", suffix( option agent.circuit-id, 1)) = "5"
and binary-to-ascii(16, 8, ".", option agent.remote-id) = "0.6.c0.a0.bb.48.e5.b0";
}
# собственно выдаем IP классу
pool {
range 10.10.0.5;
allow members of "p5";
}
}
}
freeradius2 также умеет DHCP. Причём можно настройки клиента цеплять из mysql к примеру и не переделывать каждый раз dhcpd.conf и дёргать за ногу демона
1. Начните с того, что обновите прошивку. Firmware Version: Build 4.04.004 — это ОЧЕНЬ старая прошивка. Свежие можно взять тут: forum.dlink.ru/viewtopic.php?f=2&t=92700. Текущая — v4.38.B012. Заводские прошивки глюкавые. Чего не отнять у D-Link, они хотя бы не забрасывают большую часть своих свитчей и продолжают дорабатывать прошивки.
2. IP свитча в пользовательском VLAN — это даже не дыра, а дырища в безопасности.
config dhcp_relay add ipif System xxx.xxx.xxx.xxx — и пакеты на DHCP сервер будут уходить в менеджмент vlan юникастом. Главное, что бы по маршрутизации DHCP-сервер и свитч друг-друга видили. Альтернатива — dhcp_local_relay. Он только добавляет в пакет option 82, пакет дальше идёт бродкастом. Т.е. DHCP-сервер должен быть в этом VLAN.
3. isc-dhcp-server имеет один серьёзный недостаток — если у Вас много записей (а у нормального провайдера их много), то у Вас получится ОЧЕНЬ большой конфиг. Да, его можно формировать скриптом. Но при любом изменении придётся сервис дёргать. Не умеет isc-dhcp-server на лету перечитывать конфиг. Сейчас смотрю в сторону freeradius. Последние версии умеют работать как DHCP-сервер. Со всеми плюшками прямой работы с SQL серверами. (п.с. выше уже написали).
П.С. По настройке — обратитесь в любое представительство D-Link. Благо их много. Консультанты там обычно толковые. Много чего рассказать могут. И семинары бесплатные :)
2. IP свитча в пользовательском VLAN — это даже не дыра, а дырища в безопасности.
config dhcp_relay add ipif System xxx.xxx.xxx.xxx — и пакеты на DHCP сервер будут уходить в менеджмент vlan юникастом. Главное, что бы по маршрутизации DHCP-сервер и свитч друг-друга видили. Альтернатива — dhcp_local_relay. Он только добавляет в пакет option 82, пакет дальше идёт бродкастом. Т.е. DHCP-сервер должен быть в этом VLAN.
3. isc-dhcp-server имеет один серьёзный недостаток — если у Вас много записей (а у нормального провайдера их много), то у Вас получится ОЧЕНЬ большой конфиг. Да, его можно формировать скриптом. Но при любом изменении придётся сервис дёргать. Не умеет isc-dhcp-server на лету перечитывать конфиг. Сейчас смотрю в сторону freeradius. Последние версии умеют работать как DHCP-сервер. Со всеми плюшками прямой работы с SQL серверами. (п.с. выше уже написали).
П.С. По настройке — обратитесь в любое представительство D-Link. Благо их много. Консультанты там обычно толковые. Много чего рассказать могут. И семинары бесплатные :)
config traffic control 1-8 broadcast enable multicast enable unicast disable action drop threshold 64 countdown 5 time_interval 5
#Это спасет от множественных броадкастов, генерируемых клиентами
Хана вашей сетке :)
Вы замеряли сколько в Вашей сети «нормально» бегает бродкаста? В большой сети до нескольких сотен пакетов в секунду. Вы же рубите порт на 64 пакетах за 5 секунд. И дропаете всё что выше. Причём свитч не будет разбираться, что он дропает, полезный бродкаст или нет. Даёте рекомендации без описания, почему и как работает. С этой функцией надо обращаться ОЧЕНЬ аккуратно.
enable loopdetect
config loopdetect ports 1-8 state enable
config loopdetect recover_timer 1200 interval 10 mode port-based
#А это спасёт от петель если уж они образовались
Тут стоит добавить, что НЕ РЕКОМЕНДУЕТСЯ включать этот функционал на магистральных портах :) Только на пользовательских.
Ещё раз о System интерфейса свитча. Он должен быть привязан к отдельному VLAN (в простонародье к менеджмент-VLAN) по 2 причинам:
1. Безопасность. Незачем пользователю видеть IP-управление свитча. Иначе это всегда шанс: перехватить трафик управления, подобрать пароль к свитчу и т.д.
2. Уменьшение нагрузки на CPU свитча. Весть трафик который ip-бродкаст — попадает на проц и обрабатывается им. Вынеся IP управления в другой VLAN — лишаете этот трафик шанса загрузить свитч.
При включенном dhcp_relay и указанной мной выше команде (при правильных настройках), запрос юникастом прекрасно попадает на DHCP-сервер, возвращается и попадает к клиенту. Если у Вас не работало — то только из-за не правильных настроек или словили баг старой прошивки.
В результате у Вас получилась ОЧЕНЬ спорная статься. Те статьи, на которые Вы же ссылаетесь, написаны более правильно, на мой взгляд. Меньше ошибок и глупостей.
Здесь я просто описал принцип на isc-сервере. На практике я писал что у меня freeradius с perl выборкой и snmp правилами для блокировки IP на порту. Где вы увидели у меня IP свитча в пользовательском VLAN? Там vlan c тегом 7 а пользовательский с тегом 10. А если еще и внимательно посмотрите тх свитча то увидите что порты 9-10 это sfp порты и ни как не могут быть пользовательскими.
" Вы же рубите порт на 64 пакетах за 5 секунд" Один порт — один клиент. Вполне достаточно.
«запрос юникастом прекрасно попадает на DHCP-сервер, возвращается и попадает к клиенту. Если у Вас не работало — то только из-за не правильных настроек или словили баг старой прошивки.» Вы напрактике это проверяли? Или это догадки?
" Вы же рубите порт на 64 пакетах за 5 секунд" Один порт — один клиент. Вполне достаточно.
«запрос юникастом прекрасно попадает на DHCP-сервер, возвращается и попадает к клиенту. Если у Вас не работало — то только из-за не правильных настроек или словили баг старой прошивки.» Вы напрактике это проверяли? Или это догадки?
«Тут стоит добавить, что НЕ РЕКОМЕНДУЕТСЯ включать этот функционал на магистральных портах :) Только на пользовательских.»
А вот это в конфиге по вашему тогда что
config vlan VLAN10 add untagged 1-8
# Добавляем туда не тегированные порты 1-8 (абонентские порты)
А вот это в конфиге по вашему тогда что
config vlan VLAN10 add untagged 1-8
# Добавляем туда не тегированные порты 1-8 (абонентские порты)
Кстати, делаете туже ошибку, что и я 1 раз сделал. Кнопка «Ответить» лучше под сообщение, а не глобально :)
Написал большой комментарий и случайно затёр его :) Злой :) Повторюсь.
С VLAN согласен, не доглядел. НО!
Навивает именно на ту мысль, что у Вас менеджмент VLAN и пользовательский — это одно и то же. С учётом тяжело читаемости куска конфига свитча — легко запутаться.
У меня сегмент сети прекрасно работает. Между свитчами и isc-сервером 2 шлюза. Ни каких нареканий. В начале была такая же проблема как и у Вас, но она была в неправильной настройке именно isc-сервера. А именно — использование shared-network. Кстати именно конфига ics Вы и не привели. В примере для Вас с shared-network класс описан так, что он привязывается к порту любого свитча. Приведу свой (маленький кусочек). Может понятнее кому-то будет.
В данном конфиге каждый пользователь привязан к конкретному свитчу (его IP) и порту свитча.
Вообще конфиг на 11 тысяч записей весит около 1 мегабайта. Формируется динамически перловым скриптом.
Готов долго и нудно спорить — но… Думаю бессмысленно. Каждый останется при своём мнении.
Про абонентские порты — это было уже скорее не для Вас, а описание и рекомендация. Для Вас — Вы кинули строки конфигурации вообще фактически без комментариев, почему именно так. Новички воспользуются не задумываясь и наступят на грабли.
Далее.
А DHCP_snoop используете? Очень хорошая штука в паре с dhcp_relay options 82. Тогда ни какие snmp правила для блокировки не нужны :)
Как я уже сказал — на мой взгляд ОЧЕНЬ спорная статья. Я бы сказал — первый блин комом… :)
По поводу радиуса — было бы интересно посмотреть Ваши наработки — как раз этим направлением занимаюсь :)
Написал большой комментарий и случайно затёр его :) Злой :) Повторюсь.
С VLAN согласен, не доглядел. НО!
IP-адрес свитча должен находиться в той же подсети, что и адреса, выдаваемые абонентам.
Навивает именно на ту мысль, что у Вас менеджмент VLAN и пользовательский — это одно и то же. С учётом тяжело читаемости куска конфига свитча — легко запутаться.
Вы напрактике это проверяли? Или это догадки?
У меня сегмент сети прекрасно работает. Между свитчами и isc-сервером 2 шлюза. Ни каких нареканий. В начале была такая же проблема как и у Вас, но она была в неправильной настройке именно isc-сервера. А именно — использование shared-network. Кстати именно конфига ics Вы и не привели. В примере для Вас с shared-network класс описан так, что он привязывается к порту любого свитча. Приведу свой (маленький кусочек). Может понятнее кому-то будет.
Заголовок спойлера
default-lease-time 300;
max-lease-time 600;
authoritative;
ddns-update-style none;
ddns-updates off;
log-facility local7;
deny unknown-clients;
deny bootp;
local-address 172.17.255.99;
option ms-classless-static-routes code 249 = array of integer 8;
if exists agent.circuit-id {
log ( info, concat( " Lease for ", binary-to-ascii (10, 8, ".", leased-address),
" Switch port: ", binary-to-ascii (10, 8, ".", option agent.circuit-id),.
" Switch MAC: ", binary-to-ascii(16, 8, ".", option agent.remote-id)));
}
subnet 172.17.255.0 netmask 255.255.255.0 {
deny unknown-clients;
option routers 172.17.255.253;
}
shared-network "global_net" {
subnet 172.17.254.1 netmask 255.255.255.255 {} # Свитч 1
subnet 172.17.254.14 netmask 255.255.255.255 {} # Свитч 2
subnet 172.17.254.49 netmask 255.255.255.255 {} # и т.д.
#Классы пользователей
class "vishnya" {
match if binary-to-ascii(10, 16, "", substring(option agent.circuit-id, 4, 2)) = "22"
and binary-to-ascii(10, 8, ".", packet(24, 4)) = "172.17.254.1"
and binary-to-ascii(16, 8, ":", substring(hardware,1, 6)) = "0:15:58:71:8f:7c"
;
}
class "sogacheva" {
match if binary-to-ascii(10, 16, "", substring(option agent.circuit-id, 4, 2)) = "23"
and binary-to-ascii(10, 8, ".", packet(24, 4)) = "172.17.254.1"
and binary-to-ascii(16, 8, ":", substring(hardware,1, 6)) = "0:25:22:e2:71:8d"
;
}
class "ers0072" {
match if binary-to-ascii(10, 16, "", substring(option agent.circuit-id, 4, 2)) = "4"
and binary-to-ascii(10, 8, ".", packet(24, 4)) = "172.17.254.14"
and binary-to-ascii(16, 8, ":", substring(hardware,1, 6)) = "f8:d1:11:2:e8:b2"
;
}
#------------------Описания network для 172.17.1.0/24---------------------------
subnet 172.17.1.0 netmask 255.255.255.0 {
allow unknown-clients;
option routers 172.17.1.254;
option domain-name-servers 172.17.100.1, 172.17.100.2;
option ms-classless-static-routes 12, 172,16, 172,17,1,254;
pool{
allow members of "vishnya";
range 172.17.1.144;
}
pool{
allow members of "sogacheva";
range 172.17.1.158;
}
pool{
allow members of "ers0072";
range 172.17.1.48;
}
}
}В данном конфиге каждый пользователь привязан к конкретному свитчу (его IP) и порту свитча.
Вообще конфиг на 11 тысяч записей весит около 1 мегабайта. Формируется динамически перловым скриптом.
" Вы же рубите порт на 64 пакетах за 5 секунд" Один порт — один клиент. Вполне достаточно.
Готов долго и нудно спорить — но… Думаю бессмысленно. Каждый останется при своём мнении.
Про абонентские порты — это было уже скорее не для Вас, а описание и рекомендация. Для Вас — Вы кинули строки конфигурации вообще фактически без комментариев, почему именно так. Новички воспользуются не задумываясь и наступят на грабли.
Далее.
На практике я писал что у меня freeradius с perl выборкой и snmp правилами для блокировки IP на порту.
А DHCP_snoop используете? Очень хорошая штука в паре с dhcp_relay options 82. Тогда ни какие snmp правила для блокировки не нужны :)
Как я уже сказал — на мой взгляд ОЧЕНЬ спорная статья. Я бы сказал — первый блин комом… :)
По поводу радиуса — было бы интересно посмотреть Ваши наработки — как раз этим направлением занимаюсь :)
В примере для Вас с shared-network класс описан так, что он привязывается к порту любого свитча.
Нет. Там всё же есть к мак свитча, но не читабельный. Почему через точку, а не через двоеточие? Зачем оставили первые 2 байта? :) Ладно. Не суть важно. В моём примере виден ещё 1 вариант — использование ip свитча.
Про IP свитча и клиента, я вроде не полный идиот что бы клиентам доступ давать в влан управления. :)
Я как раз DHCP_Snooping и использую у себя, для моих задачь DHCP в L3 не подходит. А правила нужны, можно ручками у себя прописать IP-соседа из одного влана и когда он выключает комп сидеть под его IP. Поэтому при первом запросе в свитче делается жесткая привязка IP+port и делается пометка в базе что правило прописано.
А что конкретно интересует по радиусу?
Я как раз DHCP_Snooping и использую у себя, для моих задачь DHCP в L3 не подходит. А правила нужны, можно ручками у себя прописать IP-соседа из одного влана и когда он выключает комп сидеть под его IP. Поэтому при первом запросе в свитче делается жесткая привязка IP+port и делается пометка в базе что правило прописано.
А что конкретно интересует по радиусу?
Мы наверное о разных DHCP_Snooping говорим. Он есть прямо на свитчах DLink. Пока пользователь не получит IP по DHCP, ни какой другой трафик, кроме DHCP-запросов от него не пройдёт (при максимальных настройках). Когда идёт ответ, свитч запомнит, какой ему ip выдало и привяжет пару mac+ip к порту. А уже DHCP сервер за счёт option 82 сделат, какой ip на какой порт выдать.
Попытка сменить себе после этого ip на какой-то другой — ничего не даст. Новый ip будет заблокирован. При всём желании
В результате надобность в
Попытка сменить себе после этого ip на какой-то другой — ничего не даст. Новый ip будет заблокирован. При всём желании
можно ручками у себя прописать IP-соседа из одного влана и когда он выключает комп сидеть под его IP.не сделаешь. Даже попытка прописать себе свой IP статикой проживёт ровно до истечения lease dhcp-ответа. После этого свитч запомненную информацию скинет. Так что пользователь обязан юзать DHCP. И не пропишет своими кривыми ручками что-то не то.
В результате надобность в
config access_profile profile_id 4 add access_id 1 ip vlan_id $vlanid source_ip 10.5.0.88 port 1 permitотпадает, т.к. это делается динамически.
Поподробнее на этом месте. Кончилась лиза, ну и что дальше. Причем здесь разрешающее правило? Ну не сделал он новго запроса и что измениться, у него IP есть, сеть физически состыкована у сервера тоже IP и кто ему запретит дальше сидеть в интете?
И так. Подробнее. Что делает DHCP_Snoop в связке с IMPB на свичах D-Link (у многих остальных есть аналоги, но тут всё достаточно хорошо отточено уже давно).
Когда эта петрушка включена на порту — от пользователя с порта могут уйти только DHCP-запросы. Любой другой трафик блокируется. Т.е. если пользователь попробовал прописать себе IP руками — он ничего не получит. (В том числе IP соседа).
Дальше. Он запросил IP по DHCP, ему сервер DHCP ответил. Свитч из ответа сервера выдернет для себя пару IP+mac и время на которое выдан, которые отданы этому клиенту и запомнит их для клиентского порта. Т.е. этот клиент сможет работать с этой парой. Начнёт ходит L2 трафик от этого mac и L3 трафик от пары IP+mac. Любые другие mac и ip+mac на клиентском порту будут продолжать блокироваться. Можно ограничить сколько одновременных пар можно будет выучить на порт.
В принципе на этой стадии клиент может попробовать прописать себе свой же IP руками. Но т.к. свитч запоминает, на сколько IP был выдан, то без повторных запросов DHCP со стороны клиента, свитч по истечении этого времени «забудет» пару IP+mac и клиент опять будет заблокирован.
Возможная махинация с прописыванием себе мака соседа блокируется использование option 82, т.е. ты клиента прибиваешь к порту.
Плюсы:
1. Глупости и не правильная настройка со стороны клиента блокируются на ходу. Даже роутер воткнутый в LAN, а не в WAN будет заблокирован, т.к. он не запрашивает DHCP.
2. Большинство атак, махинаций и попыток «воровать» интернет соседа так же заблокированы.
3. Динамическая привязка к твоему биллингу за счёт первоначальной настройки свитча, а дальше всё обслуживается 1 запросом DHCP. Тут надо только, что бы у тебя была привязка пользователя к порту. Кстати можно даже не привязываться к его маку, можно просто именно к порту.
Минусы:
1. Есть глючные клиентские устройства, которые криво работают с DHCP. Например роутеры, которые «забывают» уточнить данные по истечению времени аренды. Обычно (если это не полный китай) лечится обновлением прошивки.
Когда эта петрушка включена на порту — от пользователя с порта могут уйти только DHCP-запросы. Любой другой трафик блокируется. Т.е. если пользователь попробовал прописать себе IP руками — он ничего не получит. (В том числе IP соседа).
Дальше. Он запросил IP по DHCP, ему сервер DHCP ответил. Свитч из ответа сервера выдернет для себя пару IP+mac и время на которое выдан, которые отданы этому клиенту и запомнит их для клиентского порта. Т.е. этот клиент сможет работать с этой парой. Начнёт ходит L2 трафик от этого mac и L3 трафик от пары IP+mac. Любые другие mac и ip+mac на клиентском порту будут продолжать блокироваться. Можно ограничить сколько одновременных пар можно будет выучить на порт.
В принципе на этой стадии клиент может попробовать прописать себе свой же IP руками. Но т.к. свитч запоминает, на сколько IP был выдан, то без повторных запросов DHCP со стороны клиента, свитч по истечении этого времени «забудет» пару IP+mac и клиент опять будет заблокирован.
Возможная махинация с прописыванием себе мака соседа блокируется использование option 82, т.е. ты клиента прибиваешь к порту.
Плюсы:
1. Глупости и не правильная настройка со стороны клиента блокируются на ходу. Даже роутер воткнутый в LAN, а не в WAN будет заблокирован, т.к. он не запрашивает DHCP.
2. Большинство атак, махинаций и попыток «воровать» интернет соседа так же заблокированы.
3. Динамическая привязка к твоему биллингу за счёт первоначальной настройки свитча, а дальше всё обслуживается 1 запросом DHCP. Тут надо только, что бы у тебя была привязка пользователя к порту. Кстати можно даже не привязываться к его маку, можно просто именно к порту.
Минусы:
1. Есть глючные клиентские устройства, которые криво работают с DHCP. Например роутеры, которые «забывают» уточнить данные по истечению времени аренды. Обычно (если это не полный китай) лечится обновлением прошивки.
Сейчас взяли на тест eltex MES1124, ковыряю как замену длинку. Попробовал настроить dhcp snooping c ip arp inspection. Да действительно работает. Весь трафик на порту блокируется пока dhcp-запрос не сделаешь.
Кстати прохождение трафика не зависит не от лизы не от арп таймаута. Прохождение сохраняется пока не погасишь порт.
У DLink отрабатывает чётко. Лиаза закончилась — иди лесом :)
Да, все верно. Почему то на стенде время лизы некоректно определял, сейчас на рабочий сервер свитч поставил, лизу стал правильно определять.
Ещё возможно ты на старой прошивке пробовал. Заводские лучше обновлять на свежие, за редким исключением. Иногда в процессе «починки» или добавления ломают что-нить. Тогда приходится откатываться на предыдущую. Но это редкость и обычно последняя — нормально рабочая.
Продолжаю эпопею об елтексах.
Как я уже говорил впечатление они производят крайне положительное.
На сегодня удалось получить 100% работающий конфиг с авторизацией по opt82.
Необходимо задействовать dhcp snooping + ip arp inspection + ip source guard. Причем обратите внимание что SG нужно включать не только глобально, но и на каждом клиентском интерфейсе.
Отдельно хочется отметить их ТП, крайне адекватные ребята, отвечают быстро и по теме. Мне пока все у них нравиться.
Как я уже говорил впечатление они производят крайне положительное.
На сегодня удалось получить 100% работающий конфиг с авторизацией по opt82.
Необходимо задействовать dhcp snooping + ip arp inspection + ip source guard. Причем обратите внимание что SG нужно включать не только глобально, но и на каждом клиентском интерфейсе.
Отдельно хочется отметить их ТП, крайне адекватные ребята, отвечают быстро и по теме. Мне пока все у них нравиться.
mes1024 настраивал. работает
Вы вероятно вы путаете с авторизацией по протоколы 802.1X xgu.ru/wiki/802.1X_%D0%B8_RADIUS.
Готов долго и нудно спорить — но… Думаю бессмысленно. Каждый останется при своём мнении.
И я даже более того скажу, я злой админ :) у меня еще и вот такие правила, клиентскому броадкасту не выжить:
Заголовок спойлера
expect "#$" { send «create access_profile profile_id 1 profile_name 1 ethernet ethernet_type\n»}
expect "#$" { send «config access_profile profile_id 1 add access_id auto_assign ethernet ethernet_type 0x86DD port all deny\
n»}
#Deny untrast dhcp-server
expect "#$" { send «create access_profile profile_id 2 profile_name 2 ip udp src_port_mask 0xFFFF \n»}
expect "#$" { send «config access_profile profile_id 2 add access_id 1 ip udp src_port 68 port $user_ports permit\n»}
expect "#$" { send «config access_profile profile_id 2 add access_id 2 ip udp src_port 67 port $user_ports deny\n»}
#Allow arp and deny broadcast
expect "#$" { send «create access_profile profile_id 3 profile_name 3 ethernet destination_mac ff-ff-ff-ff-ff-ff ethernet_typ
e\n»}
expect "#$" { send «config access_profile profile_id 3 add access_id 1 ethernet destination_mac ff-ff-ff-ff-ff-ff ethernet_ty
pe 0x806 port $user_ports permit\n»}
expect "#$" { send «config access_profile profile_id 3 add access_id 2 ethernet destination_mac ff-ff-ff-ff-ff-ff ethernet_ty
pe 0x800 port $user_ports deny\n»}
#
expect "#$" { send «create access_profile profile_id 4 profile_name 4 ip vlan 0xfff source_ip_mask 255.255.255.255 \n»}
#expect "#$" { send «config access_profile profile_id 4 add access_id 1 ip vlan_id $vlanid source_ip 10.5.0.88 port 1 permit\
n»}
expect "#$" { send «config access_profile profile_id 4 add access_id 25 ip vlan_id $vlanid port $user_ports deny\n»}
expect "#$" { send «config access_profile profile_id 1 add access_id auto_assign ethernet ethernet_type 0x86DD port all deny\
n»}
#Deny untrast dhcp-server
expect "#$" { send «create access_profile profile_id 2 profile_name 2 ip udp src_port_mask 0xFFFF \n»}
expect "#$" { send «config access_profile profile_id 2 add access_id 1 ip udp src_port 68 port $user_ports permit\n»}
expect "#$" { send «config access_profile profile_id 2 add access_id 2 ip udp src_port 67 port $user_ports deny\n»}
#Allow arp and deny broadcast
expect "#$" { send «create access_profile profile_id 3 profile_name 3 ethernet destination_mac ff-ff-ff-ff-ff-ff ethernet_typ
e\n»}
expect "#$" { send «config access_profile profile_id 3 add access_id 1 ethernet destination_mac ff-ff-ff-ff-ff-ff ethernet_ty
pe 0x806 port $user_ports permit\n»}
expect "#$" { send «config access_profile profile_id 3 add access_id 2 ethernet destination_mac ff-ff-ff-ff-ff-ff ethernet_ty
pe 0x800 port $user_ports deny\n»}
#
expect "#$" { send «create access_profile profile_id 4 profile_name 4 ip vlan 0xfff source_ip_mask 255.255.255.255 \n»}
#expect "#$" { send «config access_profile profile_id 4 add access_id 1 ip vlan_id $vlanid source_ip 10.5.0.88 port 1 permit\
n»}
expect "#$" { send «config access_profile profile_id 4 add access_id 25 ip vlan_id $vlanid port $user_ports deny\n»}
#Deny untrast dhcp-server
expect "#$" { send «create access_profile profile_id 2 profile_name 2 ip udp src_port_mask 0xFFFF \n»}
expect "#$" { send «config access_profile profile_id 2 add access_id 1 ip udp src_port 68 port $user_ports permit\n»}
expect "#$" { send «config access_profile profile_id 2 add access_id 2 ip udp src_port 67 port $user_ports deny\n»}
Это делает dhcp_server filtre
config filter dhcp_server ports 1-25 state enable
Немного проще. :)
В остальных бродкастах не разобрался. арп понял по коментарию, но вообще типы пакетов 0x806 0x800 0x86DD и т.д. не помню, а искать сейчас влому :) Так что ты имел в виду этими записями (что фильтровал, а что пропускал), пока что не понял :)
config filter dhcp_server ports 1-25 state enable
Нет такая запись не подходит, мне нужно разрешить прохождение на 67-port dhcp — запросов иначе на правиле config access_profile profile_id 3 add access_id 2 ethernet destination_mac ff-ff-ff-ff-ff-ff ethernet_ty
pe 0x800 port $user_ports deny весь этот траф погибнет.
0x806 — это арп
0x800 — это обычный траф
0x86DD — это ipv6
Смысл там примерно такой, что убивать весь броадкаст, кроме арп и DHCP-запросов от клиентов. Весь броадкаст гаситься на уровне фреймов.
0x800 — это обычный траф
0x86DD — это ipv6
Смысл там примерно такой, что убивать весь броадкаст, кроме арп и DHCP-запросов от клиентов. Весь броадкаст гаситься на уровне фреймов.
Я видел ваш сервер и как вариант я его рассматривал, но с переписыванием на Си.
Потом я покрутил радиус, попробовал и 3 и 2 версии. 3 отмел сразу, как dhcp практически не работал вываливался. А двойка показал себя не плохо. И по сей день работает без нареканий. Буду признателен если просветите по поводу костыля :) Почему сложилось такое мнение?
Потом я покрутил радиус, попробовал и 3 и 2 версии. 3 отмел сразу, как dhcp практически не работал вываливался. А двойка показал себя не плохо. И по сей день работает без нареканий. Буду признателен если просветите по поводу костыля :) Почему сложилось такое мнение?
а чем перл-то не угодил? он только при старте интерпретируется и висит в памяти. тоже многопоточность умеет. Зато пиши что хочешь от управления файрволами до логирования и rrdb.
Ну на самом деле в самописном сервере ты сам себе хозяин — в этом плане оно может и лучше. А на счет перла, он действительно интерпретируется при загрузке и работает очень быстро. На радиусе этот вопрос не однократно обсуждался. Я сначала как всегда в дебри полез и хотел написать бинарный модуль, потом почитав доки успокоился и оставил все на перле. Так что на перле дейсвительно все нормально работает. Плюсом в нем есть очень интересная функци connect_cached, которая очень помогает при постоянных коннектах к базе.
Что именно в 3 версии вываливалось, если не секрет? И какую именно тестил? Я сейчас 3.0.7 кручу. Достаточно свежая — но это пока что без нагрузки (1-10 клиентов) и с самыми простыми скриптами.
Пока что смотрю на фрирадиус, т.к. он всё равно нужен для аутентификации юзеров. Смысл плодить сущности (отдельный DHCP, отдельный радиус и т.д.), если всё есть в одном.
Пока что смотрю на фрирадиус, т.к. он всё равно нужен для аутентификации юзеров. Смысл плодить сущности (отдельный DHCP, отдельный радиус и т.д.), если всё есть в одном.
Что именно в 3 версии вываливалось, если не секрет? И какую именно тестил? Я сейчас 3.0.7 кручу. Достаточно свежая — но это пока что без нагрузки (1-10 клиентов) и с самыми простыми скриптами.
В домашних условиях работал, но как только я его попытался под нагрузкой запустить приблизительно 4000 юзеров онлайн, вывалился не отработав и часа. Что конкретно было в логах уже не помню. Версия была из гита, но какая точно не скажу, я эти эксперементы почти год назад делал.
Если читали на сайте фрирадиуса, там есть фраза типа: 2-это стабильность, 3- это функционал. Поэтому я не стал упираться и перешел на 2-ую версию.
В домашних условиях работал, но как только я его попытался под нагрузкой запустить приблизительно 4000 юзеров онлайн, вывалился не отработав и часа. Что конкретно было в логах уже не помню. Версия была из гита, но какая точно не скажу, я эти эксперементы почти год назад делал.
Если читали на сайте фрирадиуса, там есть фраза типа: 2-это стабильность, 3- это функционал. Поэтому я не стал упираться и перешел на 2-ую версию.
Это читал. Но взял для начала 3 версию. Посмотрю на сколько она стабильна стала :)
Почти год в продакшене 3й радиус, начинали с 3.0.1, стабильность подводит, зато настроить нужное поведение удалось достаточно быстро. После обновления до 3.0.3 «всё сломалось» — оказалось, что поменялось поведение, пришлось переписывать конфиги (так что больше не обновлялись). Стабильности добились балансировкой запросов на пул из 16 контейнеров с вочдогами.
А почему это в .NET?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Практические аспекты использования DHCP relay+option82