Jump to content
Калькуляторы

Посоветуйте как организовать шлюз с шейпингом.

Планируется сеть, около 1000 пользователей (40 отделов с кол-вом ПК от 10 до 60), IP серые.

Необходимо обеспечить выход в Интернет всем отделам, на скоростях от 5 до 20 Mbit (на отдел), + доступ к файлопомойке и web серверу.

Внешний канал < 100 Mbit.

 

Посоветуйте в каком направлении начать копать?

Примерно представляю себе так:

 

post-54780-1277982131_thumb.jpg

 

- L2 на доступе - Dlink 3526, по вилану на отдел.

- L3 в центральном узле сети - коммутатор доступа Cisco Catalyst 35xx.

- Кэширующий dns, proxy сервер.

- Система учета трафика и выделения нужной полосы пропускания на отдел (Биллинг)

 

 

Как лучше делать шлюз/шейпер? на отдельной железке? Или на PC?

Или коммутатор доступа Cisco Catalyst 35xx сможет выступать в качестве шлюза/шейпера, если к нему прикрутить radius и биллинг с PC?

 

 

Share this post


Link to post
Share on other sites

Ваш L3 не умеет NATить, при серых IP это необходимо. Ставить тазик с FreeBSD/Linux и шейпить-натить на нем или аппаратный маршрутизатор при желании (Cisco/D-Link/etc зависит от политики).

Если есть управляемый порт - сделайте привязку IP-MAC-порт и делайте чистый IPоE.

Или классика - шлюз с PPTP/PPPoE доступом.

Биллинг - при необходимости. Судя по словам "отдел" - нужна статистика для руководства режимного объекта. Достаточно будет netflow.

 

По организации сети: на отдел - VLAN, терминировать вланы на вашем L3. Отдельный Vlan для серверов и для внутреннего интерфейса Интернет-маршрутизатора. ACLями резать доступ между вланами типа отделу модно видеть себя и серверы с интернетом но не другие отделы. Выделить админов в отдельный влан. Им разрешить видеть всех. Подумать выделить отдельно руководство и запретить к ним весь доступ.

Как-то так.

Сразу видно узкое место - 100Мбит/с аплинки от доступа.

 

Будут вопросы - в личке подробнее напишу. Просто это стандартный подход и сто раз разжевано.

Edited by yakuzzza

Share this post


Link to post
Share on other sites

>Если есть управляемый порт - сделайте привязку IP-MAC-порт и делайте чистый IPоE.

 

В корпоративной сети IP-MAC-порт нафиг надо? IP адреса серые, экономить их не надо. Влан на отдел и сетка /24, чтоб не париться с мелкими сетками малого размера. Адреса давать по dhcp, включить dhcp snooping на доступе, ну ещё сделать ограничение в несколько маков на порту доступа на всякий случай.

IP-MAC-Port нужно делать от злобных кул-хацкеров, которые пытаются помешать нормальной работе оборудованию провайдера.

 

Share this post


Link to post
Share on other sites

Решение на вырост. ***ов везде хватает.

 

Если говорим про корпоратив то: открыть только 80 порт, пропускать весь трафик ч-з ASA/PIX и ISA от MS с фильтрацией трафика, черными списками и антивирусной проверкой.

Отето я понимаю коПРоратив ;)

Share this post


Link to post
Share on other sites

Я понимаю как через тазик пропустить трафик, что dhcp snooping надо делать, это все понятно. Я с кошками дел не имел ни разу, а требуют центральный узел коммутации чтобы был на оборудовании cisco, и ессессно экономически обоснованно (без излишеств).

Подскажите пожалуйста какую модель лучше использовать в качестве центрального коммутатора?, я так понимаю что аппаратный шейпер + nat, будет работать надежнее чем программный на linux, на сервере будет крутится linux с биллингом (собираем статистику по трафику, добавляем новых пользователей, выделяем полосу пропускания в интернет для отделов), далее каким-то образом будут добавятся правила в шейпер сколько и какому вилану дать полосы. И если делать по гигабиту до отдела, что лучше на доступ ставить?.

Если сие уже где-то было разжевано, ткните пожалуйста где почитать, в короткие сроки надо все переварить, а с чего начать...

Share this post


Link to post
Share on other sites

>Подскажите пожалуйста какую модель лучше использовать в качестве центрального коммутатора?, я так понимаю что аппаратный шейпер + nat, будет работать надежнее чем программный на linux, на сервере будет крутится linux с биллингом

 

Сделайте так: терминируйте вланы на центральном L3-коммутаторе в интерфейс-вланах(соответственно и весь внутрикорпоративный трафик будет жить в его пределах), а выход в интернет через NAT(или всё-таки proxy?) и шейпинг делайте на linux. 100мбит внешнего канала это не так много, за то можно будет сделать задёшево прозрачную прокси, заблокровать вконтактики, анонимизаторы и прочее по урлам.

Share this post


Link to post
Share on other sites

Э-э-э.

Тема, кстати, интересная. Расскажу как бы я строил, а другие дополнят подскажут.

Надо определиться с трафиком в сети для начала и с его возможным ростом и еще умножить на два результат.

Потом рисуем схему сети с соблюдением требований к трафику. Далее подбираем необходимое оборудование для нашей сети.

Смотрим какие аплинки будут использоваться (зависит от сети: одно здание, кампус, WAN). Ставим в центр сети L3-коммутатор (может быть несколько в связи с географией).

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

На шлюз Интернет из Cisco учитывая трафик и NAT 29ХХ серия маршрутизаторов.

 

Кстати прочитал вас внимательно и вот что интересно: вы говорите, что аппаратный шлюз надежнее чем программный, при этом используется Linux-сервер с биллингом, который все так же надежен, как и программный роутер ;) Так что это, скажем так, одно из заблуждений.

 

На доступ ставьте... да что угодно из вменяемого, но сразу смотрите в сторону управляемого порта на клиента (коммутаторы доступа от Zyxel/Edge-Core/D-Link/etc).

 

У вас немного в голове каши. Шейпить надо на Интернет-шлюзе. L3 пусть работает на скорости соединения. До шейпера виланы могут и не дойти (если не использовать PPPoE).

 

Cisco шейпит/рейт-лимитит на виртуальных интерфейсах при получении необходимой информации из биллинга в виде cisco AV-Pair.

 

В короткие сроки не переварите. Могу только показать откуда начать рыть - Ciscolab.ru. Там разжеваны основные темы.

Удачи.

Edited by yakuzzza

Share this post


Link to post
Share on other sites
а выход в интернет через NAT(или всё-таки proxy?)
Предполагал что все кроме http через nat, a http заворачивать с цыски в сервер, и прозрачно проксивать, ну и кэширующие DNS тоже внутри держать.

 

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

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

 

На доступ ставьте... да что угодно из вменяемого, но сразу смотрите в сторону управляемого порта на клиента (коммутаторы доступа от Zyxel/Edge-Core/D-Link/etc).
Конечно же управляемый, назовите пожалуйста хотябы несколько вменяемых моделей (24 порта 1Gbit, стекирование, + возможность установки оптических портов) чтобы было от чего отталкиваться.

 

Значит шейпить и натить в моем случае все таки лучше на PC?.

Тогда

NAT 29ХХ серия маршрутизаторов.
мне никчему.

 

В короткие сроки не переварите.
Это правда так сложно? или большой объем инфы? я не совсем новичок, опыт построения небольших сетей (до 100 пользователей) и администрирования web и proxy серверов (в основном linux) у меня есть.

 

Вобще спасибо вам огромное, вы мне очень помогли, потому что думать стало значительно легче.

 

Share this post


Link to post
Share on other sites

Нат вам нужен. У вас серые IP-адреса. Или прокси с двумя интерфейсами: 1 внешний с реальным IP, второй внутренний.

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

Спросите у любого провайдера, что у них бывает, когда падает биллинг: прозрачно все дальше работает или куда-то кто-то клюет. Ой как плохо всем и сразу становится.

Управляемые коммутаторы: рядом куча веток в форуме + опросник, кто что использует на доступе. DES 3200-28, DES 1228/ME, edge-core es3526, Zyxel 2024 для старта. Есть куча других моделей и вендоров.

 

Это не сложно. Просто надо сесть, все изучить и осмыслить. Что и зачем конкретно делать я примерно уже вам в предыдущих постах набросал.

Share this post


Link to post
Share on other sites
Если говорим про корпоратив то: открыть только 80 порт, пропускать весь трафик ч-з ASA/PIX и ISA от MS с фильтрацией трафика, черными списками и антивирусной проверкой.
Откатинг :)

 

Отсеет секретарш и начальных пользователей от случайного просмотра порнухи вне контакта/мейла/глазников.

От вирусов или от прозрачного туннелирования траффика не поможет ничего, кроме отключения от сети.

 

MS ISA - тот ещё писец.

У неё раз в год (у меня маленькие были нагрузки) хитро калечился вебкеш, после чего некоторые сайты глючили, всякий раз диагностировалось отключением кеша, лечилось пересозданием.

Но так сходу догадаться что сайт глючит из за кеша очень трудно.

И под нагрузкой МС рекомендует отключать там в первую очередь кеш :)

 

 

а требуют центральный узел коммутации чтобы был на оборудовании cisco, и ессессно экономически обоснованно (без излишеств)
Пусть сами обосновывают что циска лучше длинка/писюка %)

 

Прокси если ставить на такой поток то только прозрачный. Тюнить придётся. Может статься что придётся отказаться от дискового кеша и кешировать только мелочь в памяти.

 

Нужна отказоустойчивость - ставьте два-три-пять серверов на обычных писюках и делайте или балансировку или горячий резерв, это всяко лучше цисок и одного бредового сервера по надёжности.

Share this post


Link to post
Share on other sites

Ну-ну. Верю каждому вашему слову.

Share this post


Link to post
Share on other sites
Прокси если ставить на такой поток то только прозрачный. Тюнить придётся. Может статься что придётся отказаться от дискового кеша и кешировать только мелочь в памяти.
думаете отдельный ssd raid под кэш squid не спасет? + побольше оперативки под мелочь. В крайнем случае агрессивность кэширования уменьшить.

 

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

post-54780-1278119037_thumb.jpg

Edited by ++PPoE

Share this post


Link to post
Share on other sites
Планируется сеть, около 1000 пользователей (40 отделов с кол-вом ПК от 10 до 60), IP серые.

Необходимо обеспечить выход в Интернет всем отделам, на скоростях от 5 до 20 Mbit (на отдел), + доступ к файлопомойке и web серверу.

Внешний канал < 100 Mbit.

...

Как лучше делать шлюз/шейпер? на отдельной железке? Или на PC?

Или коммутатор доступа Cisco Catalyst 35xx сможет выступать в качестве шлюза/шейпера, если к нему прикрутить radius и биллинг с PC?

При заявленных параметрах всё, что нужно для выхода в Интернет,

т.е. NAT, шейпинг, счётчик трафика, биллинг, прокси, DNS, антиспам и т.д.

сможет беспроблемно работать на одном компьютере за $400.

Share this post


Link to post
Share on other sites

ПК за 400 баксов и 1000 пользователей в сети.

Я бы прекращал практику экономии. Она никому не нужна, а в случае вылета вашего ПК за $400 по голове вы получите.

Брать аппаратный маршрутизатор или добротный сервер под функции шлюза. В случае сервера обязательно RAID1 или 10 2 БП.

В обоих случаях ИБП обязателен.

 

Можно если бюджет позволит взять 2 сервера и построить кластер (связка FreeBSD+CARP будет хорошо работать).

 

Я вот не понимаю вообще какой смысл кеширующего прокси на скоростях до 100 мебагит - получим только лишние тормоза и еще 1 точку отказа.

Убрать вообще проксирование - это лучшее решение. Статистику собирать по netflow.

Share this post


Link to post
Share on other sites

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

использовать под любые некритичные задачи и подключать только при отказе первого.

 

RAID нафиг не нужен, достаточно ежедневного rsync для файлов и репликации

master-slave для баз. Можно drbd для netflow, если хочется потуг на СОРМ ;-)

 

То же самое касается carp/pfsync. Можно, но только если нечем занять второй сервер, своё время, и нет риска схватить uTP-флуд.

Load balancing на таких потоках не нужен, а fail-over можно делать и чем-нибудь попроще.

Т.к. это офисная сеть без WoW, LA2, CS и прочих онлайн-развлечений,

в пределах минуты его всё равно никто не почувствует, да и будет это не каждый месяц.

 

Кстати, наладка сложного решения иногда приводит к бОльшим проблемам при внедрениях, чем примитивные решения - при авариях.

 

Проксирование имеет смысл делать выборочно, смотря на среднее соотношение

объёмов трафика и количества пакетов для tcp/80 по наиболее посещаемым сайтам.

Например, img.mail.ru имеет смысл заворачивать в прокси, а video.mail.ru - вряд ли.

 

Банальности про ИБП топикстартер, уверен, знал и раньше.

Share this post


Link to post
Share on other sites

Примитивное в данном случае что?

Линуксы на писюках или 1 конфиг на циске?

2 циски: 1 роутер, а второй Л3 - куда проще?

Share this post


Link to post
Share on other sites

>думаете отдельный ssd raid под кэш squid не спасет? + побольше оперативки под мелочь. В крайнем случае агрессивность кэширования уменьшить

 

А зачем Вам кеш? Внешний канал забит под завязку или оплата по трафику? Если ни то, ни другое, то кеш не нужен, а прокся нужна только для реализации AAA.

Share this post


Link to post
Share on other sites
Я вот не понимаю вообще какой смысл кеширующего прокси на скоростях до 100 мебагит - получим только лишние тормоза и еще 1 точку отказа.

Убрать вообще проксирование - это лучшее решение. Статистику собирать по netflow.

Смысл очень даже есть, это порядка 800 регулярных пользователей, которые могут решить одновременно все полезть в сеть, смотреть фотки и слушать mp3, прокси немного сгладит роковой час. Не забываем еще про block url, и сбор статистики по пользователям (кто, куда, зачем полез). За лишней точкой отказа следить не сложно, и в случае отказа перенаправить трафик в нужную сторону. По netflow собирать статистику по трафику, а с прокси по урлам.

 

от htb может лучше отказаться в пользу rate-limit на 3750?

 

RAID нафиг не нужен, достаточно ежедневного rsync для файлов и репликации

master-slave для баз.

Думаю эти машины еще под почтовый и веб серверы использовать.

 

То же самое касается carp/pfsync. Можно, но только если нечем занять второй сервер, своё время, и нет риска схватить uTP-флуд.
А под linux carp можно использовать? он ведь с bsd портирован, не сырой?.

 

 

 

А зачем Вам кеш? Внешний канал забит под завязку или оплата по трафику? Если ни то, ни другое, то кеш не нужен, а прокся нужна только для реализации AAA.
Пользователи дневные, в любой момент загрузить канал могут, да и по скорости канала еще неясно пока.

а что такое ААА?

Share this post


Link to post
Share on other sites
а что такое ААА?

Даже не ожидал такого вопроса :)

 

Authentication, Authorization, Accounting

Share this post


Link to post
Share on other sites

Поставить Сервер HP Proliant DL360 G5 Dual-Core 2.00 Bundle (ссылка). Микротик на него и вперед. Шейпит порядка 800-900 pptp клиентов. Нагрузка около 35-60%.

Share this post


Link to post
Share on other sites
думаете отдельный ssd raid под кэш squid не спасет? + побольше оперативки под мелочь. В крайнем случае агрессивность кэширования уменьшить.
Я вообще не думаю на эту тему :)

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

Помимо пропускной способности дисковой подсистемы есть и другие узкие места.

Например та же запись в лог может стать узким местом.

Потом проксирование это пересылка кернел-юзерспей-кернел, у меня на Е5300 гдето 20 мегабайт/сек выходило на одном потоке(коннекте) на встроенном гигабитном реалтеке, те это без кеширования было и без обработок потока - дальше полка проца.

 

 

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

 

 

Проксирование имеет смысл делать выборочно, смотря на среднее соотношение

объёмов трафика и количества пакетов для tcp/80 по наиболее посещаемым сайтам.

Например, img.mail.ru имеет смысл заворачивать в прокси, а video.mail.ru - вряд ли.

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

 

 

прокся нужна только для реализации AAA
Если про интернет через прокси, когда эту прокси нужно прописать руками в настройках, и потом вводить логин/пароль - то это почти всегда "решение через жопу".

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

 

 

 

А ещё сквид падает иногда, сам по себе.

Я в крон закинул запуск раз в минуту, те если упал запустится, если работает то ничего не происходит.

 

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

Пришлось отключить заворот трафика с тех хостов где эти приложения.

 

 

Если уж думать об оптимизации с помощью сквида то ещё хорошо получается резать рекламу/счётчики/..., путём заворота на прозрачный гиф, который как раз nginx выдавать умеет.

Читать интернет приятнее сразу, мелькания и разноцветная хрени не отвлекают и экономия вполне себе - даже кешировать не надо и дальше запрос гнать.

Share this post


Link to post
Share on other sites
Даже не ожидал такого вопроса :)
это я опростоволосился :)

 

Поставить Сервер HP Proliant DL360 G5 Dual-Core 2.00 Bundle (ссылка). Микротик на него и вперед. Шейпит порядка 800-900 pptp клиентов. Нагрузка около 35-60%.

Решение на вырост получится, как только определюсь shaping на PC или rate limit на 3750 будет, так буду думать о серверах, принял к сведению.

 

Помимо пропускной способности дисковой подсистемы есть и другие узкие места.

Например та же запись в лог может стать узким местом.

Потом проксирование это пересылка кернел-юзерспей-кернел, у меня на Е5300 гдето 20 мегабайт/сек выходило на одном потоке(коннекте) на встроенном гигабитном реалтеке, те это без кеширования было и без обработок потока - дальше полка проца.

хм. 20 мегабайт/сек съел лог, а это на сколько подключений? и какая скорость внешнего канала?

В крайнем случае логи можно с ASA/PIX брать, и на резервной машине складывать.

 

Вобще я без кэширующего прокси плохо представляю работу корпоративной сети, даже на небольшом кол-ве клиентов, независимо от скорости внешних каналов, невооруженным глазом видно что просмотр www с кэшем выглядет более комфортно. Оно и понятно <2ms отклик на объект имеющийся в кэше, а HIT попаданий до 80% бывает в отдельных случаях.

 

Может оказаться что балансировать на двух одновременно лучше.

Думал об этом.

 

Если про интернет через прокси, когда эту прокси нужно прописать руками в настройках, и потом вводить логин/пароль - то это почти всегда "решение через жопу".

Полностью согласен )

 

 

А ещё сквид падает иногда, сам по себе.

Я в крон закинул запуск раз в минуту, те если упал запустится, если работает то ничего не происходит.

Чесно говоря у меня такого не наблюдается, не на реверсивных не на прямых, может от кол-ва подключений зависит? А у вас какая версия squid?

Edited by ++PPoE

Share this post


Link to post
Share on other sites

Про Интернет ч-з прокси и связанную с этим жопу не согласен. Простой пример: производственная сеть, домен AD, в политиках настройки IE на прокси-сервер, Squid+AD скручен, аутентификация NTLM (через доменную группу). Так работаем 3 года. Полет нормальный. Админам надо только вкинуть пользователя в доменную группу и все. У пользователя при запуске IE Интернет доступен.

А вы говорите "жопа". Придумайте более легкий способ и чтобы ААА был ;)

 

Сквид очень-очень редко падает. И то больше по дурости.

 

Топикстартеру: последний раз говорю, рейт-лимитить на Л3 (вижу выбрали 3750 - отличный выбор) не надо. Л3 должен роутить и в вашем случае фильтровать трафик. Ограничивать как вам угодно должен шлюз в Интернет, построенный на чем угодно. Хоть FreeBSD/Linux хоть Cisco/Others.

 

---

Удачи.

Share this post


Link to post
Share on other sites

Если уж думать об оптимизации с помощью сквида то ещё хорошо получается резать рекламу/счётчики/..., путём заворота на прозрачный гиф, который как раз nginx выдавать умеет.

счетчикам обычно ставлю override-expire override-lastmod reload-into-ims ignore-no-cache, так он один раз попав в кэш, потом из него только берется. А рекламу резать нельзя, какой-нить отдел своего рекламного блока в инете недосчитается, во визгу будет :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this