По большому счету вы не можете ограничить число пользователей стандартным образом, за каждым пользователем может быть целая подсеть с nat'ом.
Более того пользователь может присвоить себе адрес руками. Можно ограничить возможности такого пользователя( на разном оборудовании по разному ), но разделяемую среду он все равно отъест.
В каждом конкретном случае кол-во пользователей лимитируется по разному, как и разделяемый ресурс.
В проводных сетях это защиты от ddos и настройка qos, в этой же зоне авторизация устройств( хотя бы по мак адресам ) и более сложные механизмы авторизации типа 802.11x, плюс vlan( тоже от части отвечает за разделяемую среду ). В беспроводных отказы в авторизации, максимально кол-во пользователей задается уже на оборудовании, плюс минимально допустимые уровни сигнала, балансировка клиентов по точкам доступа, технологии beamforming и т.п.
Адрес пул для dhcp обычно задается подсетями. Если вам это не подходит, то следует очень серьезно подумать по чему именно, поскольку все остальное работает по подсетям и изголяться там с диапазонами адресов не очень удобно, а иного и просто невозможно. Скорее всего вы делаете ошибку в сегментировании сети, хотя возможно это и сознательное упрощение, но всегда надо понимать почему именно так.
Можно даже особо не ходить. У вас есть микротик куда все сведено. Вешаем каждый downlink на отдельный порт и поднимаем на нем dhcp клиент. Можно так даже на длительное время сделать, если есть риск, что устройство сейчас off-line.
Дальше поймали герлянду на которой dhcp. Если в ней все свичи управляемые, каждый в отдельный vlan и повторяем операцию.
super-guest,
1. Лучше если hap lite продолжит раздавать ip без проводным клиентам. Оставляете ему dhcp только для этих нужд. На проводные интерфейсы ему dhcp отключаете.
2. Для проводных клиентов поднимаете dhcp на hex.
При этом беспроводный интерфейс и проводный нельзя объединять в мост.
Если вам нужно объединить в мост. Оставляете dhcp только на hex.
Роутер не обязательно должен быть dhcp, а dhcp роутером.
super-guest, если в него удалит молния, без грозозащиты у вас в любом случае умрет все сеть соединенная проводами. Как минимум оба микротика.
Плюс зачем вам сеть без интернета? Что вы в ней собрались делать?
Тут есть спорный момент, провайдер обычно блокирует абонента с задолженностью, т.е. де факто абонент не может использовать услуги связи по вине провайдера( поскольку провайдер его заблокировал ), а следовательно услуга ему не предоставлена, а следовательно абонент не должен ее оплачивать.
Лучше ID записи все же добавить. Во первых могут возникнуть проблемы с некоторыми orm, во вторых дальше нам нужно будет знать кто и когда это тэг добавил, появятся колонки типа datetime и user, дальше надо будет знать, что тэг удален, т.е. у нас появиться признак актуальности, а значит изменить первичный ключ таблицы, и т.д. Так что лучше его сразу сделать.
vkapas: VPN это в некотором смысле частный случай шлюза. Если нет необходимости аутентифицировать клиентов или шифровать трафик можно обойтись без него.
vkapas: Колокейшен( colocation ), это размещение своего оборудование на узле "провайдера", т.е. вы ставите шлюз не у себя, а у провайдера, оптику к вам тянуть не надо. Аналогично можно поставить linux в облаке( напимер digitalocean ) и настроить шлюз на нем, а все клиенты будут подключены к нему. Это аналог vpn но самостоятельно.
Игорь Кривинцов: Ваш метод не позволяет разделить проблемы на различных участках канала связи. По вашей диагностики, это может быть проблема сервера, проблема на пути между вашим портом и портом сервера, проблема микротика, проблема настройки микротика, проблема между микротиком и клиентом, например в свиче, да даже проблема потери пакетов из-за плох обжатой вилочки.
vvchumanov: Возможно я не достаточно полно понимаю данный механизм в микротике, но при заблокированном порте таких записей в логе быть не должно. Конечно нельзя исключать атаку на внутренний порт снаружи, она так же возможна, но я таких ботов не встречал и сильно зависит от настроек устройства. В любом случае правило общее для любых сервисов, максимально сокращаем площадь атаки, остальное закрываем максимально надежными методами, там где можем баним по ошибкам, если не можем мониторим логи и принимаем меры руками. Следует понимать, любой открытый сервис это цель для атаки, как правило для бот атаки, это "норма".
alexdora: У вас не работает бесшовное переключение между ip в пределах одного драйвера, насколько я понял. Это фича несколько иного уровня, обычно такие проблемы решают за пределами астериска, например на роутерах или с помощью kamailio.
Астер нормально работает с несколькими ip адресами, особых проблем там нет. Такая схем это имхо бессмысленно. Проще внешних пользователей завернуть на VPN, благо многие ip телефоны умеют это из коробки, тогда и проблема NAT решиться сама собой, плюс система станет на порядок безопаснее, сколько денег теряют люди выставившие атс в интернет голой попой уже не один десяток статей найдется.
Более того пользователь может присвоить себе адрес руками. Можно ограничить возможности такого пользователя( на разном оборудовании по разному ), но разделяемую среду он все равно отъест.
В каждом конкретном случае кол-во пользователей лимитируется по разному, как и разделяемый ресурс.
В проводных сетях это защиты от ddos и настройка qos, в этой же зоне авторизация устройств( хотя бы по мак адресам ) и более сложные механизмы авторизации типа 802.11x, плюс vlan( тоже от части отвечает за разделяемую среду ). В беспроводных отказы в авторизации, максимально кол-во пользователей задается уже на оборудовании, плюс минимально допустимые уровни сигнала, балансировка клиентов по точкам доступа, технологии beamforming и т.п.
Адрес пул для dhcp обычно задается подсетями. Если вам это не подходит, то следует очень серьезно подумать по чему именно, поскольку все остальное работает по подсетям и изголяться там с диапазонами адресов не очень удобно, а иного и просто невозможно. Скорее всего вы делаете ошибку в сегментировании сети, хотя возможно это и сознательное упрощение, но всегда надо понимать почему именно так.