Subnets.ru

Всем день добрый! Имеется сеть, построенная на основе КТВ. Изначально была плоской, сейчас сеть разбита на подсети (vlan 100 - vlan 126), "гирлянды" постепенно перестраиваются в человечный вид.. В ядре (рис. сейчас..) 3 x D-Link 3612-G, 1 x D-Link 3612, 1 x D-Link 3627-G. На них собираются пользовательские vlanы (синие точки - шлюзы для пользователей в каждом влане), между коммутаторами настроен OSPF (связь коммутатор-коммутатор в отдельном влане, сеть /30). Но сейчас сделано немного криво, так как все вланы проброшены до DHCP сервера. Все пользователи авторизуются на сервере (впн, авторизация по ип), который выполняет в себе несколько функций (он же НАТ, он же шейпер, он же биллинг и т.д.)... он же узкое место в сети; поэтому сейчас полностью перестраиваем всю эту схему (рис. что хочется). От решения "все в одном" отказались и разные сервисы разносим на разные машины (PC-роутеры).
Что хочется изменить:
1) вынести все сервера из дефолтного влана;
2) отделить юридеских лиц также в отдельные вланы;
3) добавить избыточные линки между коммутаторами в ядре, для этого избавиться от проброса всех вланов до DHCP (если я правильно понимаю DHCP option 82 мне в помощь?);
4) выдавать пользователям только белые ип-адреса, отказаться от НАТа в новой схеме;
5) учесть возможность работы 2-х и более НАСов, учитывая, что ip-адреса будут пользователям выдаваться статически (не из пула)
6) получить номер AS, поднять BGP, чтоб хоть как-нибудь балансировать нагрузку на каналы и иметь возможность резервирования.
Сейчас главный вопрос, это тестирование всей схемы, которую хочется, в тех условиях, что имеется...
Как сэмулировать соединение от 2-х провайдеров на бордере?
Сразу извиняюсь, что объясняюсь нечетко, прошу сильно не пинать:))
Буду благодарен за любые высказывания и пожелания, т.к. опыта немного, поэтому некоторые нюансы мог не учесть.

YaEvgen писал(а):для этого избавиться от проброса всех вланов до DHCP (если я правильно понимаю DHCP option 82 мне в помощь?);

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

YaEvgen писал(а):Как сэмулировать соединение от 2-х провайдеров на бордере?

BGP соединение ? ну никто же не мешает тебе эмулировать провайдеров
поставь две quagga, будет тебе два провайдера
поставь себе 3 виртуальные машины и эмулируй между ними что угодно

dlink`и я бы заменил на каталисты, или поставил бы хотя бы один каталист 3560G, на который и сгрузил бы маршрутизацию внутри локалки
как я понимаю твои длинки ещё дышат, потому что трафик у сетки небольшой пока

radius я бы тоже на отдельную машину вынес, что бы при падении NAS`а, на котором стоит radius, не пострадали юзеры второго NAS`а

избавился бы от netflow, на больших скоростях он тупо начинает пропускать пакеты, ipaccctd или ng_ipacctd хорошие считалки (Сбор статистики по трафику на FreeBSD при помощи ng_ipacct)

YaEvgen писал(а):4) выдавать пользователям только белые ип-адреса, отказаться от НАТа в новой схеме;

я бы не стал этого делать, это может тебе добавить кучу головной боли: спам, вирусы и т.п.
незащищенный фаиром и антивирусом комп юзера с реальником БОЛЬШОЕ зло

YaEvgen писал(а):5) учесть возможность работы 2-х и более НАСов, учитывая, что ip-адреса будут пользователям выдаваться статически (не из пула)

ну по нарисованной тобой схеме это получится без проблем

а "АСР" это что ? Автоматизированная Система Расчетов ?

а что у тебя гоняет OSPF ?

NAS`ы держат подключения PPTP или PPPoE ?

дополнил свой пост выше

root писал(а):ну если ты собираешся выдавать IP-адреса юзерам основываясь на инфе с какого коммутатора и с какого порта пришел юзер, то да, option 82
если по просто по макам, то достаточно включить релей DHCP

уточню вопрос, сейчас dhcp работает по следующему принципу ->рис. 1
то есть решение принимается на основе влана, в добавок к ip, mask, gateway и dns, пользователь получает 2 маршрута: сетки 10.20.0.0/16 и 10.10.0.0/16 через шлюз абонента. Сеть 10.20.0.0/16 охватывает все подсети пользователей (полученные разбиением этой сетки на подсети /22) - это пользователям для dc-хаба, сетка 10.10.0.0/16 добавляется, чтоб у них не пропадал доступ к днсам, впн-серверу и другим серверам (т.к. авторизовываются они по впн) а также в этой подсетке в дефолтном влане болтаются абоненты, ранее подключенные к др. провайдеру (мы начали работать через него, как агенты), которые авторизуются по pppoe, они тоже активные пользователи dc-хаба.
А сейчас хочется избавиться от проброса до dhcp всех вланов, но чтоб он выдавал на адреса на основании номера vlana. Кого мне сделать relay-агентом? Будет ли коммутатор пересылать запросы на сервер DHCP и корректно передавать всю конфигурацию ip пользователю, если у DHCP будет находиться в подсети A(vlan x), управление коммутатором в подсети В(vlan y), а пользователь должен получить ip из подсети C(vlan z)?

root писал(а):dlink`и я бы заменил на каталисты, или поставил бы хотя бы один каталист 3560G, на который и сгрузил бы маршрутизацию внутри локалки
как я понимаю твои длинки ещё дышат, потому что трафик у сетки небольшой пока

дополню картину, в сети около 1500(наших пользователей)+500(другого провайдера), авторизация pptp (в будущем, поддержка l2tp), сейчас в он-лайне максимум 500-600 пользователей, трафик через нас(он же биллинг, он же нат...) порядка 20 kpps.
я правильно понимаю, что в первую очередь лучше поменять d-link3612, который на схемах под номером 5?
чтобы вы посоветовали вместо 3028, к которому сейчас подключены большинство серверов (dns, web, dc, мониторинг, почта, ntp, ftp, в будущем туда переместится DHCP:), возможно VoD и игровые сервера)? все эти сервера хочу сделать в отдельный влан, и эту подсетку выдавать пользователям по DHCP.

root писал(а):а что у тебя гоняет OSPF ?

по ospf сейчас идет трафик между абонентами (хаб) и от абонентов к серверу авторизации и др. серверам

root писал(а):radius я бы тоже на отдельную машину вынес, что бы при падении NAS`а, на котором стоит radius, не пострадали юзеры второго NAS`а

root писал(а):

YaEvgen писал(а):5) учесть возможность работы 2-х и более НАСов, учитывая, что ip-адреса будут пользователям выдаваться статически (не из пула)

ну по нарисованной тобой схеме это получится без проблем

второй нас планируется к запуску только после получения AS и в следствии-ухода с подсетей провайдеров и перевода всех абонентов на PI адреса, полученные у регистратора. вот здесь, как мне кажется начнутся проблемы, потому что я не понимаю каким образом border будет понимать, кому он должен отправить пакет nas1 или nas2, если адреса статически привязаны к учетным записям абонентов.
насчет radius поправлюсь (накосячил): сервер радиуса как раз находится на АСР (автоматизированная система расчетов, он же биллинг:))-отсюда и проблемы с непониманием насчет работы 2-х nas'ов (псевдо-распределение нагрузки будет засчет DNS)

root писал(а):избавился бы от netflow, на больших скоростях он тупо начинает пропускать пакеты, ipaccctd или ng_ipacctd хорошие считалки (Сбор статистики по трафику на FreeBSD при помощи ng_ipacct)

nas как раз собран на FreeBSD, netflow собирается через mpd (то есть только для авторизованных по впн) и просто хранится на втором жестком для соблюдения закона, в биллинге netflow не используется, там как раз все собирается средствами радиус-аккаунтинга.

root писал(а):

YaEvgen писал(а):4) выдавать пользователям только белые ип-адреса, отказаться от НАТа в новой схеме;

я бы не стал этого делать, это может тебе добавить кучу головной боли: спам, вирусы и т.п.
незащищенный фаиром и антивирусом комп юзера с реальником БОЛЬШОЕ зло

К сожалению, таков выбран путь, и обратного точно не будет. Во-первых, для маркетологов, это скорее плюс, такая мода среди конкурентов (вам БЕСПЛАТНО дается белый ИП-адрес, подключайтесь к нам:)), потом, по опыту столкнулись, что так проще и быстрее определить пользователя, который как-то гадит (раньше проблематично было решить такие проблемы, т.к. nat используется динамический и для каждого нового запроса выдавал разный ip, а потом приходит письмо от аплинка с жалобой на пользователя с ip таким-то, и его уже не вычесть), для фильтрации спама пользователям блокируется 25 порт (не панацея, но количество жалоб уменьшилось), на коммутаторах доступа - ACL, к тому же через биллинг будет пользователю добавлена возможность выбора и подключения антивируса через личный кабинет (заметили нездоровую активность, предупредили пользователя, возможно отключили временно, посоветовали воспользоваться антивирусом за 30-60 рублей в месяц на выбор). И еще один сомнительный плюс, в том, что не будет лишней нагрузки на сервер авторизации и на меня, чтоб его настраивать и администрировать.

root писал(а):

YaEvgen писал(а):Как сэмулировать соединение от 2-х провайдеров на бордере?

BGP соединение ? ну никто же не мешает тебе эмулировать провайдеров
поставь две quagga, будет тебе два провайдера
поставь себе 3 виртуальные машины и эмулируй между ними что угодно

Я, наверно, неправильно сформулировал вопрос. В принципе уже разобрался, я имел ввиду следующую ситуацию: сейчас до тестовых пользователей я пробросил кусок PI сетки с.с.с.0/25 (анонсирована провайдером 2) через border на nas1. на внешнем интерфейсе nas1 EN1 (см. рисунок "что хочется..") прописал серый ип из сетки /30, шлюзом для него указал EB0 (внутр. для бордера). Для авторизации по ip на EN0 добавил адрес из сети с.с.с.0/25. Далее также, как и border c nasом, связал внешний интерфейс border'a EB1 и один из локальных интерфейсов действующего АСР(биллинг+шлюз+впн-сервер), разрешил в фаерволле все пакеты от сети с.с.с.0/25 - тест прошел успешно.
А я хотел добавить еще один линк между border'ом (EB2) и действующим АСР и пробросить несколько адресов из подсети, выданной первым провайдером (а.а.а.0/24), - "эмулируя" второго провайдера:) если я правильно разобрался, то на border'е мне просто создать две таблицы маршрутизации для каждого провайдера. Если нет, то поправьте меня.

YaEvgen писал(а):сейчас dhcp работает по следующему принципу

то что он у тя сейчас так работает я понял

YaEvgen писал(а):то есть решение принимается на основе влана
....
А сейчас хочется избавиться от проброса до dhcp всех вланов, но чтоб он выдавал на адреса на основании номера vlana.

тогда тебе нужно включать option 82, с её помощь можно получать номер влана из которого пришел запрос
вот тут я приводил dhcpd.conf и пример настроек свича Dlink, DHCP выдает адрес на основе порта коммутатора
выдавать по влану тоже реально, вот пример:

Код: Выделить всё

class "comp-vlan400"{
    match if (binary-to-ascii(10, 16, "", substring(option agent.circuit-id, 2, 2))="400");
}
shared-network mynet {
     subnet 10.XXX.XXX.0 netmask 255.255.255.0 {
              option routers 10.XXX.XXX.1;
             pool {
                        range 10.XXX.XXX.10 10.XXX.XXX.254;
                        allow members of "comp-vlan400";
             }
     }
}

YaEvgen писал(а):Кого мне сделать relay-агентом?

как это ког, свичи конечно

YaEvgen писал(а):я правильно понимаю, что в первую очередь лучше поменять d-link3612, который на схемах под номером 5?

да, сделать его центральным роутером для локалки, пусть он внутри всем заправляет

YaEvgen писал(а):чтобы вы посоветовали вместо 3028, к которому сейчас подключены большинство серверов (dns, web, dc, мониторинг, почта, ntp, ftp, в будущем туда переместится DHCP:), возможно VoD и игровые сервера)?

ну если по уму, то в CORE уровне все бы махнуть на каталисты (3560G или 3750G), хорошая железка с большими возможностями (с определенной прошивкой конечно) за приемлимые деньги
если железка без роутинга то каталист 2960 например, ну или на худой конец Dlink DES-3526

YaEvgen писал(а):по ospf сейчас идет трафик между абонентами (хаб) и от абонентов к серверу авторизации и др. серверам

правильно ли я понимаю что default gateway или GW для выдаваемых клиенту маршрутов являются железки с номерами 2,3,4 ?

YaEvgen писал(а):потому что я не понимаю каким образом border будет понимать, кому он должен отправить пакет nas1 или nas2, если адреса статически привязаны к учетным записям абонентов.

а чего тут монимать ? два статик роута и все дела. NAS смотрит на Border дефолтом, а ты берешь и выделяшь для каждого NAS`а свою подсеточку реальников и роутишь их с Border`а на NAS`ы

YaEvgen писал(а):отсюда и проблемы с непониманием насчет работы 2-х nas'ов (псевдо-распределение нагрузки будет засчет DNS)

ах вот оно в чем дело, теперь понял. т.е. ты хочешь чтобы юзер мог подключиться к любому NAS`у. Я то подумал, что у юзера будет четко прописан NAS к которому подключаться.
ну тогда тебе между Border и NAS`ами тоже придется поднимать какой либо протокол динамической маршрутизации. Только так Border будет знать какой адрес на каком NAS тусует.
Но я бы так не делал, не очень надежная схема получается, да и распределение нагрузки весьма косвенное. В подобных случаях я как раз не люблю динамику, её сложно спрогнозировать.

YaEvgen писал(а):nas как раз собран на FreeBSD, netflow собирается через mpd (то есть только для авторизованных по впн) и просто хранится на втором жестком для соблюдения закона, в биллинге netflow не используется, там как раз все собирается средствами радиус-аккаунтинга.

понятно, вообщем аккаутинг два раза, ясно.
а ты хоть раз смотрел совпадают ли данные из файлов с тем что показывает Radius ?

YaEvgen писал(а):раньше проблематично было решить такие проблемы, т.к. nat используется динамический и для каждого нового запроса выдавал разный ip

ну а кто тебе мешает перенастроить ? и четко натить одну серую сетку в один реальник
и логи по трафику нуна всегда собирать ДО процесса NAT, тогда по логам трафика зная дату и dst ип можно всегда найти кто гадил и с какого серого адреса это было

YaEvgen писал(а):Я, наверно, неправильно сформулировал вопрос.

я не понимаю твоих замутов. в этой схеме у NAS`а deаfault смотрит на Border, у Border должен быть маршрут сетки с.с.с.0/25 на NAS

root писал(а):тогда тебе нужно включать option 82, с её помощь можно получать номер влана из которого пришел запрос
вот тут я приводил dhcpd.conf и пример настроек свича Dlink, DHCP выдает адрес на основе порта коммутатора
выдавать по влану тоже реально, вот пример:

Код: Выделить всё

class "comp-vlan400"{
    match if (binary-to-ascii(10, 16, "", substring(option agent.circuit-id, 2, 2))="400");
}
shared-network mynet {
     subnet 10.XXX.XXX.0 netmask 255.255.255.0 {
              option routers 10.XXX.XXX.1;
             pool {
                        range 10.XXX.XXX.10 10.XXX.XXX.254;
                        allow members of "comp-vlan400";
             }
     }
}

так в том конфиге dhcp-сервер и свич находятся в одной сетке и в одном влане. или мне тоже не париться, а просто тупо добавить dhcp в влан управления коммутаторов и назначить ip из подсети свичей? по поводу shared-network спасибо - это то, что нужно как раз:)

root писал(а):

YaEvgen писал(а):Кого мне сделать relay-агентом?

как это ког, свичи конечно

мне надо на каждом свиче доступа включать dhcp relay и option82 или достаточно включить это все на 36хх? если на доступе, то не возникнет проблем с неуправляемыми хабами и железом, которое не поддерживает данную опцию?

root писал(а):

YaEvgen писал(а):я правильно понимаю, что в первую очередь лучше поменять d-link3612, который на схемах под номером 5?

да, сделать его центральным роутером для локалки, пусть он внутри всем заправляет

центральным для локалки? то есть на него пробросить все пользовательские вланы и в каждом влане поднять интерфейс из пользовательский подсетей, вида 10.20.20.1/22, которые будут для пользователя шлюзом по умолчанию? тогда надо выключать OSPF? или я туплю жестко, или это как-то неэффективно?

root писал(а):правильно ли я понимаю что default gateway или GW для выдаваемых клиенту маршрутов являются железки с номерами 2,3,4 ?

да, правильно, для них шлюзом являются интерфейсы этих железок, (в каждом влане поднят интерфейс вида 10.20.20.1/22, 10.20.24.1/22 и т.д.) а между собой как раз идет обмен по OSPF, на 3612 в дефолте поднят интерфейс 10.10.111.1/16, через него ходят все пакеты от серверов к сетям 10.20.0.0/16

root писал(а):ах вот оно в чем дело, теперь понял. т.е. ты хочешь чтобы юзер мог подключиться к любому NAS`у. Я то подумал, что у юзера будет четко прописан NAS к которому подключаться.
ну тогда тебе между Border и NAS`ами тоже придется поднимать какой либо протокол динамической маршрутизации. Только так Border будет знать какой адрес на каком NAS тусует.
Но я бы так не делал, не очень надежная схема получается, да и распределение нагрузки весьма косвенное. В подобных случаях я как раз не люблю динамику, её сложно спрогнозировать.

именно так, у всех пользователей будет указан один адрес впн-сервера (доменное имя), а днсы будут выдавать по очереди.. основная идея, это не распределение нагрузки, а резервирование: если один из nas'ов делается недоступным, то днсы будут отдавать только рабочий.

root писал(а):

YaEvgen писал(а):nas как раз собран на FreeBSD, netflow собирается через mpd (то есть только для авторизованных по впн) и просто хранится на втором жестком для соблюдения закона, в биллинге netflow не используется, там как раз все собирается средствами радиус-аккаунтинга.

понятно, вообщем аккаутинг два раза, ясно.
а ты хоть раз смотрел совпадают ли данные из файлов с тем что показывает Radius ?

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

root писал(а):

YaEvgen писал(а):Я, наверно, неправильно сформулировал вопрос.

я не понимаю твоих замутов. в этой схеме у NAS`а deаfault смотрит на Border, у Border должен быть маршрут сетки с.с.с.0/25 на NAS

все верно, так оно и есть, но теперь я добавляю еще несколько адресов из сетки другого провайдера а.а.а.0/24 и весь замут в том чтоб если пакет пришел от NAS'а с src из сетки а.а.а.0/24, то отправлялся бы на первый интерфейс border'а EB1, а если src из сетки с.с.с.0/25 - то на EB2.
Просто схема на рисунке ("что хочется") условная, и внешние интерфесы border'а уходят не к провайдерам а к локальным интерфейсам текущего "все в одном".

YaEvgen писал(а):. или мне тоже не париться, а просто тупо добавить dhcp в влан управления коммутаторов и назначить ip из подсети свичей?

именно так
пусть DHCP смотрит в "сетку управления" свичами и общается с ними там

YaEvgen писал(а):мне надо на каждом свиче доступа включать dhcp relay и option82 или достаточно включить это все на 36хх? если на доступе, то не возникнет проблем с неуправляемыми хабами и железом, которое не поддерживает данную опцию?

если у тя сетка не 100% управляемая, то включать нуна там где есть возможность включить и там же где есть возможность определить из какого влана пришел запрос
в твоем случае как минимум на всех железках что етсь на твоей схеме

YaEvgen писал(а):то не возникнет проблем с неуправляемыми хабами и железом, которое не поддерживает данную опцию?

ну они тупо пропустят DHCP запрос через себя, а когда он попадет на управляемое железо он будет перенаправлен на твой DHCP сервер

YaEvgen писал(а):центральным для локалки? то есть на него пробросить все пользовательские вланы и в каждом влане поднять интерфейс из пользовательский подсетей, вида 10.20.20.1/22, которые будут для пользователя шлюзом по умолчанию? тогда надо выключать OSPF? или я туплю жестко, или это как-то неэффективно?

типа того, но:

YaEvgen писал(а):да, правильно, для них шлюзом являются интерфейсы этих железок, (в каждом влане поднят интерфейс вида 10.20.20.1/22, 10.20.24.1/22 и т.д.) а между собой как раз идет обмен по OSPF, на 3612 в дефолте поднят интерфейс 10.10.111.1/16, через него ходят все пакеты от серверов к сетям 10.20.0.0/16

раз у тя так, то так и оставь, при большом трафике такая схема будет работать эффективнее

YaEvgen писал(а):основная идея, это не распределение нагрузки, а резервирование: если один из nas'ов делается недоступным, то днсы будут отдавать только рабочий.

тока один нюанс, служба DNS ничего не знает про доступность сервера и будет выдавать IP лежащего NAS сервера в любом случае

YaEvgen писал(а):тарифы у меня будут только безлимитные, поэтому мне не принципиально если между показаниями radius-аккаунтинга и нетфлоу будут незначительные различия в количестве потребленного трафика.

ясно, тогда не парься

YaEvgen писал(а):все верно, так оно и есть, но теперь я добавляю еще несколько адресов из сетки другого провайдера а.а.а.0/24 и весь замут в том чтоб если пакет пришел от NAS'а с src из сетки а.а.а.0/24, то отправлялся бы на первый интерфейс border'а EB1, а если src из сетки с.с.с.0/25 - то на EB2.

без BGP и собственных адресов у тя тока один выход это PBR, только так ты сможешь по src раскидывать пакеты между провами

YaEvgen писал(а):Просто схема на рисунке ("что хочется") условная, и внешние интерфесы border'а уходят не к провайдерам а к локальным интерфейсам текущего "все в одном".

но потом то появятся BGP и свои адреса, вот тогда PBR можно будет убрать
опять же, можно снять бордер и вместо него поставить каталист он и PBR сделает и BGP сможет поддержать, правда без full-view

root писал(а):если у тя сетка не 100% управляемая, то включать нуна там где есть возможность включить и там же где есть возможность определить из какого влана пришел запрос
в твоем случае как минимум на всех железках что етсь на твоей схеме

YaEvgen писал(а):то не возникнет проблем с неуправляемыми хабами и железом, которое не поддерживает данную опцию?

ну они тупо пропустят DHCP запрос через себя, а когда он попадет на управляемое железо он будет перенаправлен на твой DHCP сервер

С этим вроде все стало понятнее, по крайней мере, в теории. Все остальные вопросы, когда уже буду пробовать и что-то не будет получаться.
неуправляемое железо еще кое-где присутствует, но разумеется только как конечные коммутаторы.

root писал(а):раз у тя так, то так и оставь, при большом трафике такая схема будет работать эффективнее

ок, тогда менять не буду, заменю только сам коммутатор по возможности. а когда с dhcp разберусь, то добавлю "лишние" связи между коммутаторами.

root писал(а):

YaEvgen писал(а):основная идея, это не распределение нагрузки, а резервирование: если один из nas'ов делается недоступным, то днсы будут отдавать только рабочий.

тока один нюанс, служба DNS ничего не знает про доступность сервера и будет выдавать IP лежащего NAS сервера в любом случае

для этого планируется использовать сервак lbnamed, который поддерживает фичу. Если эта схема с 2-мя nas успешно заведется, то потом подробнее отпишусь, что и как.

root писал(а):но потом то появятся BGP и свои адреса, вот тогда PBR можно будет убрать
опять же, можно снять бордер и вместо него поставить каталист он и PBR сделает и BGP сможет поддержать, правда без full-view

Бордер специально покупался для этих требований, в том числе и прием full-view, с перспективой на будущее после получения AS.
А сделать я хочу что-то в этом роде http://lartc.org/howto/lartc.rpdb.multiple-links.html (это при переходе на эту схему, но естественно до перехода на BGP и своих адресов)
а между NAS'ами и border'ом (в случае, когда 2 x NAS'a) какой протокол использовать? OSPF?
И еще вопрос, немного утопичный, как сгенерировать трафик, подобный пользовательскому, чтоб потестировать nas, новый биллинг и border?
Какие еще вопросы есть при переходе на новый биллинг(вообще при смене оборудования в ядре), которые я мог не учесть?