[Saab95]

Сейчас работает схема, как на РИС1. Хочется перейти на схему, как на РИС2, чтоб ТИ мог управлять пользователями, подключившимися по PPPоE.

 

IP адреса клиентов PPPoE придется изменить на другие, например 192.168.2.х, т.к. одну и ту же сеть нельзя использовать.

[konst37]

IP адреса клиентов PPPoE придется изменить на другие, например 192.168.2.х, т.к. одну и ту же сеть нельзя использовать.

Это капля в море моего непонимания.

Хорошо, подключившись по PPPoE клиенты получат адрес из сети 192.168.2.0/24.

Как их тогда опознает ТИ? Я не понимаю принципиальной возможности построения такого взаимодействия.

[alibek]

Меньше продаванов слушайте.

Вам предлагают добавить лишнее звено между шлюзом и абонентами, которое ничего полезного не дают (для клиента, для продавца польза конечно есть), за исключением якобы фильтрации сетевого абонентского мусора.

Если биллинг и NAT остаются на ТИ, то микротик тут вообще не нужен.

Все что он дает — это PPPoE-сервер, что в каких-то аспектах удобнее IPoE, но в данном случае бессмысленно.

 

Фактически есть смысл использовать только две схемы:

1. Текущую, когда сервер с TI одновременно является и шлюзом. Минус этой схемы с том, что TI предназначен для небольших масштабов.

2. Шлюзом является специализированное устройство (пусть даже Mikrotik), а TI управляет абонентским доступом на шлюзе, находясь при этом в абонентском сегменте (т.е. за шлюзом).

С TI я сталкивался довольно давно и не уверен, что он подойдет для второй схемы.

Если делать по нормальному, то вторая схема это ISG и RADIUS-сервер.

[alibek]

Как их тогда опознает ТИ? Я не понимаю принципиальной возможности построения такого взаимодействия.

У фанатиков RouterOS из-за простоты применения L3 отключается критическое мышление, поэтому они часто изобретают странные конструкции.

Предлагается следующее.

Пользователи сети получают настройки по DHCP или прописывают их вручную. Например это подсеть 192.168.1.0/24 с локальными ресурсами.

Затем эти пользователи создают PPPoE-подключение для выхода в интернет, при установлении подключения они получают IP-адреса из подсети 192.168.2.0/24 (обычные пользователи) и 192.168.3.0/24 (привилегированные пользователи).

На ТИ создаются пользователи с авторизацией по IP-адресу, IP-адреса используются из подсетей 192.168.2.0/24 и 192.168.3.0/24, на пользователях прописываются тарифы, ограничения и т.п.

 

Обслуживать сеть (предоставлять доступ в интернет) должен либо ТИ, либо МТ. В последнем случае ТИ нужно убрать вообще, авторизацию и управление скоростью должен осуществлять МТ.

Предлагаемый же кадавр из ТИ+МТ нежизнеспособен.

[alibek]

С TI я сталкивался довольно давно и не уверен, что он подойдет для второй схемы.

Вспомнил, в ТИ это называется «режим прослушки».

Если брать второй рисунок из схемы, то порт МТ, в который будет подключаться сервер с ТИ, должен быть отделен от остальной сети (порт нужно вывести из бриджа и создать на нем отдельный интерфейс). МТ будет зеркалировать на этот порт абонентский трафик, ТИ будет его анализировать, определять абонентов и потребление ими трафика, и управлять МТ с помощью snmp или ssh (включать/выключать абонентов).

Вообщем не советую.

[Saab95]

Хорошо, подключившись по PPPoE клиенты получат адрес из сети 192.168.2.0/24.

Как их тогда опознает ТИ? Я не понимаю принципиальной возможности построения такого взаимодействия.

 

На ТИ заведете их под адресами 192.168.2.0, либо, если не хотите трогать базу абонентов, настройте на связку микротика и ТИ адреса 192.168.2.х. Разницы особой нет.

 

Пользователи сети получают настройки по DHCP или прописывают их вручную. Например это подсеть 192.168.1.0/24 с локальными ресурсами.

 

Ага, и получают конфликты IP адресов, кроме всего локалка будет работать независимо от оплаты за интернет, они начнут передавать большие файлы, забивая коммутаторы, а другие будут звонить и ругаться, почему интернет работает медленно.

 

 

Затем эти пользователи создают PPPoE-подключение для выхода в интернет, при установлении подключения они получают IP-адреса из подсети 192.168.2.0/24 (обычные пользователи) и 192.168.3.0/24 (привилегированные пользователи).

На ТИ создаются пользователи с авторизацией по IP-адресу, IP-адреса используются из подсетей 192.168.2.0/24 и 192.168.3.0/24, на пользователях прописываются тарифы, ограничения и т.п.

 

Ну да, сначала IP адреса настроили, потом PPPoE клиента настроить, потом ловить глюки и искать неполадки. При этом имея рассадник вирусов в большой не управляемой локалке.

 

Обслуживать сеть (предоставлять доступ в интернет) должен либо ТИ, либо МТ. В последнем случае ТИ нужно убрать вообще, авторизацию и управление скоростью должен осуществлять МТ.

 

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

 

Предлагаемый же кадавр из ТИ+МТ нежизнеспособен.

 

Эта связка жизнеспособна и многие ее использовали и используют, позволяет отгородить ТИ от сетевого мусора. При такой схеме ТИ не перезагружается и не зависает, + можно сессии и пакеты на микротике порезать.

 

Если делать по нормальному, то вторая схема это ISG и RADIUS-сервер.

 

Вот как раз схему с радиусом не нужно делать на начальных этапах развития сети, особенно на PPPoE, т.к. в случае проблем с биллингом вся сеть перестанет работать - клиенты не смогут авторизоваться. Переход на радиус нужно делать только тогда, когда в работе более 2-х PPPoE терминаторов и большое количество абонентов, более 1000. Во всех других случаях управление по SSH с локальными базами на каждом терминаторе намного лучше. При этом реализуются все основные возможности по управлению - смена тарифного плана, изменение скорости без переподключения, блокировка по превышению лимита, полное отключение доступа.

 

Вспомнил, в ТИ это называется «режим прослушки».

Если брать второй рисунок из схемы, то порт МТ, в который будет подключаться сервер с ТИ, должен быть отделен от остальной сети (порт нужно вывести из бриджа и создать на нем отдельный интерфейс). МТ будет зеркалировать на этот порт абонентский трафик, ТИ будет его анализировать, определять абонентов и потребление ими трафика, и управлять МТ с помощью snmp или ssh (включать/выключать абонентов).

Вообщем не советую.

 

Если текущая версия ТИ умеет отправлять команды по SSH по определенным событиям, то можете настроить эту схему, тогда ТИ спокойно переживет и 200-500 клиентов. Весь трафик пойдет через микротик.

[konst37]

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

Стоит задача приоритезации рабочего трафика (VoIP, терминальные подключения) и избавления от паразитного (обновления Windows, Android и антивирусов).

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

Сейчас подготавливаю переход на схему на рис№2.

Настроил РРРоЕ на микротике, клиент подключается. ТИ не пингуется и не видит трафика от этого подключения. На ТИ авторизируются по МАС-адресу.

На микротике маскарадинг выключен. Подскажите как ТИ увидеть клиента, подключившегося на микротик по РРРоЕ