mstsc

Совместными усилиями решили задачу. Мануал добавлен на вики. http://wiki.ubilling.net.ua/doku.php?id=mgdefauth Отправлено с моего iPhone используя Tapatalk

Как в конфигурации радиуса прописать гостевой пулл для неизвестных пользователей?

А есть примеры реализации 2 варианта? Насколько далеко такая схема работы от штатных средств Ubilling? Отправлено с моего iPhone используя Tapatalk

Спасибо за детальное разъяснение. Однако тема про другое. Изначальный вопрос стоит в следующем: При использовании связки Ubilling + DHCP сервер на устройстве Mikrotik возможно ли авторизовать абонента ориентируясь на Remote- и ID Circuit-ID?

Если все настроено ориентируясь на опцию - новый мак получит IP абона и без вопросов заработает. Само собой есть тонкости. 1. Новый мак не получит сессию пока виза старого мака не закончится. 2. При появлении двух маков на порту это тоже превращается для DHCP в проблему. Отправлено с моего iPhone используя Tapatalk

Если я внесу opt82 руками в биллинг меня, как потребителя это устраивает. Если возможна автоматизация, Парсинг данных в том формате как сейчас это происходит для мак адресов - это уже перделки-свистелки. Основная проблема DHCP на микротике увязать с биллингом применяя опцию Отправлено с моего iPhone используя Tapatalk

Мак свича доступа - константа. Даже в масштабной сети их не так много. Порт тоже совершенно предсказуемое значение будь то ethernet дырка или S/N онушки. Для радиуса эти данные нужно генерировать только в том случае, если они внесены руками в карточку абонента. В иных случаях - гостевой диапазон. К вопросу где увидеть фактические Agent-Remote-Id Agent-Circuit-Id у не авторизованного абона. DHCP сервер микротика в Leases показывает эти данные.

Agent-Remote-Id Agent-Circuit-Id вполне однозначно идентифицируют абонента, если, конечно, вы не пытаетесь через один порт авторизовать десяток человек. Попросту такая схема позволяет игнорировать конечный MAC адрес абона и позволяет безболезненно менять оборудование с сохранением IP. Вопрос безопасности такой схемы давайте опустим. Настройки устройств доступа позволяют избавляться от возможных проблем вроде два мака на порту и прочее.

Само собой понятно, что на уровне конфигурации радиуса можно организовать авторизацию, однако не затрет ли мне эти параметры сам Ubilling при регенерации базы? Плюс, если взаимодействие пользователя происходит только между NAS сервером и радиусом - мы даже факт появления нового оборудования в биллинге не будем видеть. В мануале упоминается UHW_MLG. Один из пунктов в его описании "Ваш NAS/BRAS шлет radius accounting." Более менее развернутого описания нет. Не мой ли это случай? Значения выглядят как и должны. И микротик эти данные передает без искажений и проблем. Если у Вас есть факт "корявости" работы этой связки, опишите в деталях. Я видел работающий вариант такой реализации на Abills. Тот же микрот, та же опция. rad_recv: Access-Request packet from host 10.1.2.7 port 44330, id=18, length=153 NAS-Port-Type = Ethernet NAS-Port = 2207434909 Calling-Station-Id = "1:70:5a:b6:db:18:14" Called-Station-Id = "server_B" User-Name = "70:5A:B6:DB:18:14" User-Password = "" Agent-Remote-Id = 0x63656e7472616c5f3635 Agent-Circuit-Id = 0x30303032 NAS-Identifier = "MK" NAS-IP-Address = 10.1.2.7

Доброго времени суток! Осваивая функционал КучаГен больше всего привлек вариант описанный в мануале MikroTik DHCP (IP + MAC) http://wiki.ubilling.net.ua/doku.php?id=mgmikrotikdhcp Подходит метод тем, что вся нагрузка ложится на микротик с его весьма гибкими методами маршрутизации между каналами. Траблшутинг при обращении пользователя тоже очень удобен. В ходе тестовой реализации упираюсь в логический тупик. Не ясны два ключевых вопроса: 1. Как выдавать гостевые IP адреса при такой схеме работы, ведь радиус ориентируется только на жесткое совпадение MAC адреса в карточке пользователя. 2. Как задействовать авторизацию на основе Option 82? Микротик без особого труда передает радиусу Remote-ID Circuit-ID но как их обработать в биллинге?

D-Link - traffic segmentation, huawei - port-isolate, cisco - Private VLAN, Eltex - Protected ports.

GSM розетки это уже давно весьма доступно, сам пользуюсь девайсами ОКО. На каждый ящик сигналку конечно не поставить, но вероятность появления отпечатка ноги на лице у таких утырков увеличивает.

у него 225w запас мощности .

Куплю БУ коммутатор для питания камер с поддержкой 802.3af, 802.3at Необходимо: 24 порта размер под юнит . бюджет мощности 400 - 450w. Рассмотрю варианты использования нескольких коммутаторов. (всего планирую задействовать 19 PoE портов) Предпочтительно Cisco, Ubiquiti D-link. Связь ЛС.

Готов приобрести новую или б/у в хорошем состоянии сетевую карту для организации multicast сервера. Желательно два ethernet порта. Примеры моделей которые интересуют: HP NC360T Intel Pro/1000 PT Server Adapter

Доброго времени суток! Планируется организация multicast вещания, под эту задачу подбираем железо. Возник вопрос, насколько критична для этой задачи сетевая карта? На какие особенности устройства следует обратить внимание? Быть может есть специальные решения? Какие конкретно модели сетевых карт посоветуете, опираясь на собственный опыт? Рассматривали следующее варианты: HP NC360T PCI Express Dual Port Gigabit Server Adapter Intel Pro/1000 PT Server Adapter Intel Pro/1000 GT Desktop Adapter Интерфейс PCI / PCIe Желательно 2 порта.

Единственный вариант, это купить микротик за свой счет. Заказчика не переубедить. В начале темы я указал этот нюанс. При наличии микротика - тему я бы не создавал.

Стандартными виндовыми маршрутами не реализовать перенаправление трафика из подсети с которой он пришел в ту же подсеть?

Я сразу уточнил, что реализовать задачу нужно используя имеющееся оборудование. Заказчик после покупки TP-Linkов отказывается признать свою ошибку в выборе устройств, аргументируя: "Работало ведь". Промаркеровать трафик на микротике подключив туда оба канала было бы удобнее конечно. На счет Керио, трафик будет большой. Проблема с двумя каналами проявилась в момент, когда возникла необходимость добавить роль файлового сервера.

Спасибо за ответ, мне знакомо это решение, на одном из серверов установлено KWF. Смущает только одно - решение очень громоздкое. Жалко ресурсов на этот механизм.

Имеется давно организованный сервер терминалов на Windows Server 2003, интернет он получает от маршрутизатора который в свою очередь от провайдера получает белый IP. Возникла необходимость в целях резервирования подключить вторую линию связи. Заказчик подошел к вопросу буквально, провёл вторую линию, поставил второй роутер и вторую сетевую карту. Поскольку на обоих картах был включен DHCP клиент, оба шлюза автоматически получили одинаковую метрику. С обоих роутеров пробросили RDP порт и все "заработало". Однако даже при небольших нагрузках на интернет канал RDP начал обрываться. Детали: Провайдер 1: Роутер TP-Link 740, IP роутера 192.168.0.1 Сетевая карта сервера № 1: 192.168.0.150 Провайдер 2: Роутер TP-Link 740, IP роутера 192.168.1.1 Сетевая карта сервера № 2: 192.168.1.150 Задача: Сделать так, чтоб весь трафик с сервера уходил через провайдера №1, однако чтоб доступ извне к серверу можно было получить через оба интернет канала одновременно. Подскажите, как эту задачу реализовать правильно используя имеющееся оборудование?

Это полемика, а нужна конкретика. То, что необходимо прописать маршрут это очевидно. Вот как происходит процесс обновления адреса: Как видим проходит DNS запрос на cloud.mikrotik.com, получаем два адреса 81.198.87.240, 91.188.51.139. Если по простому, создаем маршрут на них: В примере "isp2" PPPoE второго провайдера. Однако как быть, если cloud.mikrotik.com изменит IP?

В RouterOS начиная с 6 версии появилась весьма удобная функция в разделе IP/Cloud позволяющая в один клик настроить DDNS. В результате мы получаем имя в формате *.sn.mynetname.net и при смене IP роутера к имени привяжется новый адрес. Функция крайне проста, в связи с этим нет каких либо дополнительных настроек, к примеру при использовании нескольких провайдеров использовать IP резервного канала, который в данный момент не является шлюзом по умолчанию. Как привязать обновление IP/Cloud к второму провайдеру?

Комплект Mikrotik Sleeve30 Kit является дополнительной опцией к антенне mANT30. Производитель заявляет, что помимо физической защиты антенны от налипания снега и прочих жестких погодных условий колпак способен улучшить качество линка точка-точка и снизить влияние на расположенные рядом устройства. Подержав набор в руках хочу поделиться первым впечатлением и практикой сборки. Для сборки потребуется: Собранный Mikrotik mANT30 Распечатанная для удобства инструкция http://i.mt.lv/routerboard/files/sleeve-assembly-instructions-160210090412.pdf Два ключа на 10, один ключ на 7, отвертка, и нож. Советую использовать именно как в моем случае рожковый ключ на 10 и торцевую головку на 10. Значительно ускорит процесс ибо ими затянуть нам предстоит 24 гайки. Щедрые латыши докинут в комплект поставки горсть лишних гаек и шайб, чтоб избежать ошибок при сборке советую сразу разложить комплект на столе согласно инструкции и убрать лишнее. Помимо рассыпухи, основными частями нашего комплекта является 3 металлические части экранирующей юбки (рукава) и фронтальная пластиковая крышка. Как было показано выше в комплект входит герметик, самое время его распечатать. Все стыки мы в первую очередь обезжириваем и силиконим. В сегменте под номером 3 имеется дренажное отверстие. На протяжении всей сборки это и будет нашим ориентиром. В собранной конструкции дренаж должен находиться внизу. Теперь нам нужен ключ на 7, отвертка, шайбы с мягкой прокладкой. Используем их с обоих сторон юбки и не забываем, что во время работы самое главное - это хорошее настроение. После того как юбка состыкована, соединяем её с передней крышкой, для этого обезжириваем место контакта, наносим силикон и совмещаем дренажные отверстия на юбке и крышке. По опыту сборки скажу, чтоб все отверстия сразу совпали следует соединить переднюю крышку с юбкой через отверстия на стыках. Это выравнивает конструкцию. После того, как передняя крышка прикручена, наступает время соединения всей конструкции с антенной. Советую проверить правильность сборки антенны и после нанести силикон на место стыка. Совмещаем дренажные отверстия и вновь в первую очередь закручиваем болты на стыках. Тем, кто не любит жалеть силикон стоит иметь под рукой дополнительный тюбик, мне хватило впритык. Затянув все гайки даем 24 часа силикону высохнуть и можем приступать установке!

Ну с шумы это такое я ее планирую поставить в глуши там кроме меня вообще никого нет) А вот с углом могут быть проблемы. Спасибо К сожалению даже в "глуши" штырь соберет на себя много лишнего. Физические свойства и поведение радиоволны в окружающем мире довольно сложны. Нельзя взять какой-то один параметр и по нему рассчитать дальность беспроводного сигнала, однако в любом случае это могут быть многие и многие километры. 2.4 сифонит от каждого утюга. В добавок к этому сами клиенты будут создавать отражения которые будут светить на антенну со всех сторон. Советую смотреть в сторону сектора.