[++PPoE]

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

туговат, исправлюсь. Тогда на ASA/PIX rate limit замутить?, я еще в прострации немного по данному пункту.

[Ilya Evseev]

А зачем Вам кеш? Внешний канал забит под завязку или оплата по трафику?

Если ни то, ни другое, то кеш не нужен, а прокся нужна только для реализации AAA.

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

а на CONNECT'ах будет только зря отъедать нагрузку.

 

Зато кэшированием тучи мелких иконок можно сделать загрузку всяких mail.ru гораздо более плавной.

[Ilya Evseev]

А под linux carp можно использовать? он ведь с bsd портирован, не сырой?.

Не нужен здесь carp, достаточно добавить на L3 второй маршрут с увеличенной метрикой.

Если хочется поупражняться, тогда Hearthbeat.

 

DRBD для Netflow, кстати, тоже не сильно нужен, достаточно настроить flow-fanout ;-)

[Ilya Evseev]

Думаю двух серверов хватит, основной по мощнее, и горячий резерв по проще, как то так

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

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

Настроить простой failover проще, чем load-balancing + failover, вот пусть с этого и начнёт.

 

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

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

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

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

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

Как понять, где какой, я уже написал - по статистике среднего количества syn-пакетов tcp/80 на мегабайт трафика.

 

 

прокся нужна только для реализации AAA

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

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

wpad + pac + ntlm спасут отца русской демократии.

 

[++PPoE]

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

Как понять, где какой, я уже написал - по статистике среднего количества syn-пакетов tcp/80 на мегабайт трафика.

Очень интересно, а где можно с подробностями ознакомится?

[Ilya Evseev]

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

Как понять, где какой, я уже написал - по статистике среднего количества syn-пакетов tcp/80 на мегабайт трафика.

Очень интересно, а где можно с подробностями ознакомится?

Пустить весь поток через squid и написать скрипт для анализа /var/log/squid/access_log

или настроить netflow и написать скрипт для анализа вывода flow-cat|flow-print.

20 строк на Perl.

[s.lobanov]

>AAA можно и нужно делать без прокси, т.к. прокся годится не для всех протоколов,

а на CONNECT'ах будет только зря отъедать нагрузку.

 

А что, так много протоколов надо в корпоративе? Надо http, https и ... да вообще-то по большому счёту ничего больше не надо.

Ну если только смотреть под микроском, то:

От icq на работе тоже надо отучаться, не правильно это через сторонние сервера обсуждать коммерческую тайну и т.п., т.е. надо либо поднимать свой jabber-сервер(при этом трафик между ним и сотрудником, естественно, пойдёт не через прокси), ну или если кому-то религия не позволяет использовать xmpp, то есть корпоративная болталка от microsoft.

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

И пожалуй последнее, skype. Ну тут уж по ситуации. Для нормального VOIPа поднимаем что-нибудь у себя внутри сети

Изменено 3 июля, 2010 пользователем s.lobanov

[++PPoE]

Пустить весь поток через squid и написать скрипт для анализа /var/log/squid/access_log

с Perl проблем нет, но каким образом парсинг /var/log/squid/access_log может помочь сформировать правила для iptables? разве в iptables есть средства для работы с урлами?

 

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

mx 10 держать внутри, и еще где нибудь mx 20 завести.

Изменено 4 июля, 2010 пользователем ++PPoE

[Ilya Evseev]

Пустить весь поток через squid и написать скрипт для анализа /var/log/squid/access_log

с Perl проблем нет, но каким образом парсинг /var/log/squid/access_log может помочь сформировать правила для iptables? разве в iptables есть средства для работы с урлами?

У iptables есть модуль string, но я немного про другое.

Из URL надо выделять адреса серверов.

Если на какой-то сервер идёт много запросов на мелкий статический контент,

и этот сервер имеет отдельный IP-адрес,

значит, запросы к этому IP iptables должен заворачивать в Squid.

А если контент в среднем большой или динамический - то должен пропускать напрямую.

[++PPoE]

Ilya Evseev

Здорово! обязательно озадачусь такой схемой.

[++PPoE]

Подскажите пожалуйста, будет ли работать такая схема?

 

1. Dhcp выдает на доступе ip адреса из диапазона 10.0.x.2-254/24, где x номер сети от 1 до 251. Каждая сеть находится в своем вилане n, привязанном по порту и по мак адресу, n лежит в диапазоне 2-252. Адреса dns серверов dns1 10.0.0.4, dns2 10.0.5. Адрес шлюза 10.0.1-251.1

2. Трафик между сетями ограничивается на уровне vlan, согласно политике внутрисетевого доступа.

3. Пакет c internet адресом получателя, пришедший от пользователя на шлюз L3, отправляется в L7, далее пакет натится и уходит в Интернет. Если порт назначения пакета 80, то пакет отправляется на прокси сервер.

4. Traffic shaping реализуется средствами L7.

 

На всякий случай включил в схему резервного провайдера, резервный сервер и ASA 5510 тоже в опциональном статусе (незнаю одобрят или нет), интересует впринципе схема рабочая? или есть ошибки?

 

[yakuzzza]

Рабочая.

Не называйте Асу L7 ;)

Не используйте влан1 вообще. Лучше сразу зашатдаунить.

Дальше только рюшечки.

[Ilya Evseev]

IMHO ASA не нужнa, DGS-3100 желательно заменить на что-то менее кривое.

Остальное можно оставить как есть.

[++PPoE]

IMHO ASA не нужнa

там столько рюшечек ), + high level corporate security style, + управлять ей потом и школьник сможет через веб морду, и от ddos защита.

 

DGS-3100 желательно заменить на что-то менее кривое

буду думать

 

[s.lobanov]

>У iptables есть модуль string, но я немного про другое.

 

Ага, и обычно используют его для того, чтобы зафильтровать какой-то протокол указывая конкретные позиции и "бинарную строку" hex-string. Вы же сами прекрасно знаете, что это работает на каждый отдельный пакет, а не по отношению к фрагментированным по пакетам данным.

[Ilya Evseev]

>У iptables есть модуль string, но я немного про другое.

 

Ага, и обычно используют его для того, чтобы зафильтровать какой-то протокол указывая конкретные позиции и "бинарную строку" hex-string. Вы же сами прекрасно знаете, что это работает на каждый отдельный пакет, а не по отношению к фрагментированным по пакетам данным.

Если не используется http pipelining, "-m state --state NEW" спасёт отца русской демократии.

Не на 100%, но почти.

[pliskinsad]

3750+ ISG с веб авторизацией :)

[true.ru]

DGS-3100 желательно заменить на что-то менее кривое.

подскажите на что можно?

[Ivan_83]

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

Это относилось не к записи в лог, а к фактически TCP тунелю через машину.

1 подключение, 1 сетевой интерфейс реалтек чего то там, всё в гигабитной локалке.

Сервер тоже на Е5300 был, там nginx отдавал, а клиент под виндой, ИЕ8.

 

 

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

Которая последняя в портах фряхи, squid-3.1.4_1, падало даже дома на 1-2 клиентах ходящих через него.

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

 

 

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

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

И аутлук конечно тоже через это работает и при этом никто в обход в инет попасть тоже не может.

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

 

1. ISA2006 + FirewallClient или что там у МС сейчас, притом работает не только браузер/хттп, но и все приложения, и порты обратно прокидывать динамически можно, те любое приложение можно заставить думать что оно запущено на самом сервере и оно будет принимать подключения. + видно какие именно исполняемые файлы лезут и куда - можно вирусы засекать и блочить, или просто отдельным прогам инет отключать или ключать отдельным.

 

2. ВПН - сам не пробовал, но можно поднять IAS (радиус виндовый) с авторизацией в домене, а у клиентов создать впн подключения, в свойствах там есть использовать учётные данные текущей записи. А на самом сервере хоть винда+RRAS хоть фря+мпд5.

[Ivan_83]

wpad + pac + ntlm спасут отца русской демократии.

Игрался я этим, дома.

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

Пришёл к выводу что лучше там отдавать DIRECT всегда и дальше транспарентом работать.

А ежели нужна авторизация - делать редирект на хтмл страницу авторизации.

 

Нет, не спасут.

Для WPAD нужно:

1. либо чтобы комп был в домене и прописывать в свой днс WPAD хост либо чтобы по DHCP всё динамически раздавалось, ещё можно через WINS, GP, ISA+FirewallClient или мне не известными костылями.

2. клиент должен уметь это понимать

 

на практике:

1. не все компы в домене и не всегда, точно также некоторые статикой адреса прописывают, но допустим это фигня ибо сеть наша, wins нужно или самому всем прописывать или он через DHCP приходит и тогда проще сам DHCP использовать, ГП не везде есть, иса куда реже домена встречается и тоже руками придётся прописывать в фаерво клиента адрес исы либо мс предыдущие варианты автоконфига.

2. кроме ИЕ и того что на его движке, WinHTTP, BITS и может чего то ещё от МС я не видел софта который бы умел WPAD

 

 

А что, так много протоколов надо в корпоративе? Надо http, https и ... да вообще-то по большому счёту ничего больше не надо.

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

 

 

 

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

Как понять, где какой, я уже написал - по статистике среднего количества syn-пакетов tcp/80 на мегабайт трафика.

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

Корпоративу столько не съесть, чтобы писюк не перевариал, а если не перевариает то дешевле поставить ещё один за 10-20к руб, чем трахаться со статистикой. Те переходить на схемы 1 прокси на n отделов, и там будет эффект синергии, потому что можно сделать поиск по соседним кешам, в сквиде для этого много есть.

 

Либо ставить первый с много памяти и не кеширущий на диск и размером кешируемого объекта до n килобайт, а дальше прокси который в память не кеширует совсем, но кеширует на диск файлы по больше.

 

 

А в провайдинге кеширование геморой на грани окупаемости.