UTM5 + Динамические IP
UTM5 + Динамические IP
Хотим уйти от ната, для этого хотим взять /19 блок IP'ов и раздавать динамически. У кого такая схема работает - поделитесь плз конфигами =)
У нас трафик считается тупо по жестко прописанному в услуге Ip-адресу, сейчас, видимо, придется поднимать нормальный аккаунтинг на freeradius + микротик-ВПН...
В общем, кто использует сходную схему - поделитесь плз конфигами freeradius и возможными подводными камнями
p.s. А трафик, надеюсь, будет по прежнему считаться netflow, или только из радиус-данных? =)
У нас трафик считается тупо по жестко прописанному в услуге Ip-адресу, сейчас, видимо, придется поднимать нормальный аккаунтинг на freeradius + микротик-ВПН...
В общем, кто использует сходную схему - поделитесь плз конфигами freeradius и возможными подводными камнями
p.s. А трафик, надеюсь, будет по прежнему считаться netflow, или только из радиус-данных? =)
Re: UTM5 + Динамические IP
Куча сумбура, а толку нольwingman писал(а):Хотим уйти от ната, для этого хотим взять /19 блок IP'ов и раздавать динамически. У кого такая схема работает - поделитесь плз конфигами =)
У нас трафик считается тупо по жестко прописанному в услуге Ip-адресу, сейчас, видимо, придется поднимать нормальный аккаунтинг на freeradius + микротик-ВПН...
В общем, кто использует сходную схему - поделитесь плз конфигами freeradius и возможными подводными камнями
p.s. А трафик, надеюсь, будет по прежнему считаться netflow, или только из радиус-данных? =)
Во-первых, получить /19 сейчас не так просто, RIPE потребует объяснений, куда вам столько.
Сколько у вас юзеров? Неужели только повторное использование адресов (а иначе зачем нужна динамика) при блоке в 8000 адресов может решить проблему?
Re: UTM5 + Динамические IP
Пардон, попытаюсь яснее выразитьсяВитька писал(а):Куча сумбура, а толку нольwingman писал(а):Хотим уйти от ната, для этого хотим взять /19 блок IP'ов и раздавать динамически. У кого такая схема работает - поделитесь плз конфигами =)
У нас трафик считается тупо по жестко прописанному в услуге Ip-адресу, сейчас, видимо, придется поднимать нормальный аккаунтинг на freeradius + микротик-ВПН...
В общем, кто использует сходную схему - поделитесь плз конфигами freeradius и возможными подводными камнями
p.s. А трафик, надеюсь, будет по прежнему считаться netflow, или только из радиус-данных? =)
Во-первых, получить /19 сейчас не так просто, RIPE потребует объяснений, куда вам столько.
Сколько у вас юзеров? Неужели только повторное использование адресов (а иначе зачем нужна динамика) при блоке в 8000 адресов может решить проблему?
Во-первых, проблема для нас сейчас не в получении дополнительных IP-адресов, к счастью. Своя АСка есть уже, либо расширим её на /19, либо делается запрос AS+PI-блок /20 на любое другое юрлицо, а юрлицо уж точно не проблема =)
Во-вторых, юзеров у нас порядка 10к живых, плюс сейчас подключаем два городка, откуда ожидается вал подключений.
В-третьих, перефразирую "безсумбурно" свои вопросы:
Использует ли кто-нибуть выдачу динамических реальников в связке с UTM5+freeradius?
Если да - не поможете ли примерами конфигов raddb/sql.conf и описанием подводных камней?
-
- Сообщения: 1612
- Зарегистрирован: Пт ноя 10, 2006 15:23
динамикой лучше не пользоваться, много граблей. Учет трафика можно теоретически вести по радиусу(по стоп пакету) но радиус должен быть родной. Лучше откажитесь от динамики и всем раздавайте сразу белые адреса =). Жестко привязанные к абоненту.
По поводу граблей - ищите на этом форуме. То память у ядра утекает, то еще что. Если вязать это с фрирадиусом, то нужен еще урфа клиент, который будет биллингу сообщать, какой адрес привязан клиенту. Конструкция врядли будет шустрой и сможет держать большие нагрузки.
По поводу граблей - ищите на этом форуме. То память у ядра утекает, то еще что. Если вязать это с фрирадиусом, то нужен еще урфа клиент, который будет биллингу сообщать, какой адрес привязан клиенту. Конструкция врядли будет шустрой и сможет держать большие нагрузки.
Омг, этого я и боялся... Урфа-то есть, но такая схемка выглядит идиотизмом.. Что, совсем ни у кого нет положительного опыта с утм?)mikkey finn писал(а):динамикой лучше не пользоваться, много граблей. Учет трафика можно теоретически вести по радиусу(по стоп пакету) но радиус должен быть родной. Лучше откажитесь от динамики и всем раздавайте сразу белые адреса =). Жестко привязанные к абоненту.
По поводу граблей - ищите на этом форуме. То память у ядра утекает, то еще что. Если вязать это с фрирадиусом, то нужен еще урфа клиент, который будет биллингу сообщать, какой адрес привязан клиенту. Конструкция врядли будет шустрой и сможет держать большие нагрузки.
А какой билд УТМ, и радиус от УТМа, или фри?Crown писал(а):Настроен пул, но 256 адресов в динамике для физиков, NAT для физиков и юриков, чтобы не тратить адресацию на абонентов, кому нужно больше одного логина. Для юриков выдаются белые статические адреса. Всё настроено и работает с штатными средствами UTM5.
UTM5-2.1.006,wingman писал(а):А какой билд УТМ, и радиус от УТМа, или фри?Crown писал(а):Настроен пул, но 256 адресов в динамике для физиков, NAT для физиков и юриков, чтобы не тратить адресацию на абонентов, кому нужно больше одного логина. Для юриков выдаются белые статические адреса. Всё настроено и работает с штатными средствами UTM5.
FreeBSD 7.1,
Radius от UTM5.
В качестве NAS также сервер на FreeBSD 7.2, mpd5, PPPoE. Ранее была Cisco AS5350, но из-за сложности управления, в связи с дефицитом знающих кадров и меньшей её функциональностью, был сделан уклон в сторону FreeBSD.
8ядерный ксеон с 8гигами оперативки под софт
2x C720x NPE-G2 + 3825 на резерве для VPN NAS
каталист 6905 на бордер
на серваке CentOS 5.3 + MySQL 5.0.45-7.el5 + apache 2.2.3-22.el5.centos.2
utm006 core+radius+rfw
на цисках задан пул ип адресов из которого выдаются белые ип адреса типа так
ip local pool mainpool 95.xxx.xxx.1 95.xxx.xxx.254
между бордером и впн NAS поднят eigrp для маршрутизации выданных белых адресов абонентам
в UTM создаем тариф с думя услугами
Коммутированный доступ - где указываем название пула - mainpool
Передача IP-трафика - для помегобайтчины
в обоих услугах выставляем Динамическое распределение IP-адресов
ну в общем и все...
2x C720x NPE-G2 + 3825 на резерве для VPN NAS
каталист 6905 на бордер
на серваке CentOS 5.3 + MySQL 5.0.45-7.el5 + apache 2.2.3-22.el5.centos.2
utm006 core+radius+rfw
на цисках задан пул ип адресов из которого выдаются белые ип адреса типа так
ip local pool mainpool 95.xxx.xxx.1 95.xxx.xxx.254
между бордером и впн NAS поднят eigrp для маршрутизации выданных белых адресов абонентам
в UTM создаем тариф с думя услугами
Коммутированный доступ - где указываем название пула - mainpool
Передача IP-трафика - для помегобайтчины
в обоих услугах выставляем Динамическое распределение IP-адресов
ну в общем и все...
все он ловит, и в отчёте по Vpn сессиям показываетAndrewE писал(а):Как биллинг узнает какой IP был выдан клиенту при подключении?
Насколько я помню utm5-radius не ловил выданые NASом IP.
зачем? там просто указывается пул адресов заведенных ранееAndrewE писал(а): при подключении тарифа клиента в услугу доступа в Интернет прописываете фейковые IP?
to bear: Вы вот в эту темку не отпостите своё ИМХО
viewtopic.php?t=7361