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

Squid и почтовый траффик

Доброго времени суток всем!

 

Почитав информацию из интернета, стало понятно что прокси сервер squid нельзя привязать к почте. Внутри нашей компании поставлен сервер под управлением FreeBSD с прокси-сервером squid. Всё работает замечательно, пока тема не касается почтовых агентов. Интересует вопрос, вообще как сделать проброс портов для почтовых программ, тоесть нужно открыть 25 и 110 порты (какими средствами?). Я так полагаю это сделать можно включив нат, но вот в чем появляется проблема - открываем порты, и соответственно подсчет трафика уже не будет объективным, так как squid не сможет анализировать почтовый трафик, а ведь его при определенных значениях может существенно набежать. Вопрос заключается в том, как решить данную проблему? Тоесть посчитать трафик http и smtp одним целым? возможно ли такое?

Share this post


Link to post
Share on other sites
Если вы считаете траффик squid-ом, подсчет у вас уже необьективный

Необъективный в плане того что не сертифицированный билинг. Или хотите сказать что данные подсчитанные например юзергейтом и squid имеют существенные отличия? Как я понимаю необъективный подсчет в плане того что нельзя выставлять по squid`у счета, это понятно, а вот например если внутри организации для ограничения количества трафика пользователям считать, разве необъективен будет?

Share this post


Link to post
Share on other sites

я начал качать 600 метровый файл, скачал 500 метров и оборвал закачку. С вероятностью 95% сквид докачает файл до конца и посчитает мне 600 метров. Это если утрированно

Share this post


Link to post
Share on other sites

Обычно делают транспарент прокси, а трафик считают любым колеектором.

Share this post


Link to post
Share on other sites
я начал качать 600 метровый файл, скачал 500 метров и оборвал закачку. С вероятностью 95% сквид докачает файл до конца и посчитает мне 600 метров. Это если утрированно

А не надо утрировать.

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

А сквид в зависимости от настроек может докачивать себе в кеш.

 

Вопрос заключается в том, как решить данную проблему? Тоесть посчитать трафик http и smtp одним целым? возможно ли такое?

Прокси бывают не только HTTP ... - есть и SOCKS.

 

Но даже у HTTP прокси есть "method CONNECT" - куда можно "впихнуть" много чего , в том числе и "почту".

 

Но это уже будет не так красиво и тривиально и несёт в себе много угроз. ИМХО.

 

 

Share this post


Link to post
Share on other sites
Или хотите сказать что данные подсчитанные например юзергейтом и squid имеют существенные отличия? Как я понимаю необъективный подсчет в плане того что нельзя выставлять по squid`у счета, это понятно, а вот например если внутри организации для ограничения количества трафика пользователям считать, разве необъективен будет?

Прокси - посредник.

И трафики пользователь-посредник и посредник-сервер и обратно далеко не одинаковы.

Убедится легко на любом proxy checker (http://checker.samair.ru/).

 

Выйдите через прокси и и без "посредника" и сравните.

 

Или хотите сказать что данные подсчитанные например юзергейтом и squid имеют существенные отличия?

Не путайте Proxy и NAT.

И тем более не сравнивайте класический прокси и чудо у которого в одном "флаконе" ... и "бантик" сверху. ИМХО.

 

http://www.usergate.com.ua/

"Продукт підтримує усі відомі TCP/UDP протоколи - HTTP, FTP, POP3, SMTP, ІMAP4, Telnet, ІRC, NNTP і ІCQ."

 

http://www.squid-cache.org/

Squid is a caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. It reduces bandwidth and improves response times by caching and reusing frequently-requested web pages. Squid has extensive access controls and makes a great server accelerator. It runs on most available operating systems, including Windows and is licensed under the GNU GPL.

Share this post


Link to post
Share on other sites

Если обьективно squid не учитывает IP/TCP заголовки. Кроме того может сказаться т.н. "negative-caching effect", когда сквид вытянет юзеру 100 Мб, а на самом деле сквид для такого юзера вытянул с инета 130Mb. И т.п. и т.д.

Share this post


Link to post
Share on other sites
Если обьективно squid не учитывает IP/TCP заголовки.

Не понял фразы.

 

Кроме того может сказаться т.н. "negative-caching effect", когда сквид вытянет юзеру 100 Мб, а на самом деле сквид для такого юзера вытянул с инета 130Mb. И т.п. и т.д.

"Процесс" управляем и контролируем.

И забыли сказать, что остальным эти 130Mb будет отдавать из кеша.

И те кто пользуется кеширующим прокси , в котором возможен, данный ефект

обычно ведут статистику и видят разницу и ефективность.

 

Разница в процентах общего трафика и из кеша по отношению к мизерным случаям обрыв+докачка в кеш

идёт в разы. Даже с дефолтными утановками этого параметра.

 

Мне тяжело представить "организацию для ограничения количества трафика пользователям"

где кешируют сотнями Мб. ИМХО.

 

Share this post


Link to post
Share on other sites

ну у меня squid спокойно кеширует yum update для centos серверов ;)

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

Даже 30-40% кешировалось. Но вот как каналы выросли - затраты на прокси себе не оправдывают. Мне сейчас даже страшно представить transparent прокси, которая потянет весь гигабит внешнего канала ;) А главное - зачем ;) Прятать всех пользователей за один ип - неинтересно, у меня для маскарада /23 сетка отдана.... wccp прикручивать не к чему...

 

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

Share this post


Link to post
Share on other sites
Не понял фразы.
Посмотрите в код сквида. Он считает полезные данные в TCP, но не учитывает IP и TCP заголовки.

 

 

"Процесс" управляем и контролируем.

И забыли сказать, что остальным эти 130Mb будет отдавать из кеша.

Попытайтесь понять для начала суть процесса. А суть заключается в том, что если клиент принимает данные медленнее чем сервер сквида, то при обрыве закачки клиентом, траффик находящийся в TCP буферах на прием и отправку будет безвозвратно потерян, ну и плюс несовершенность алгоритмов. Чего только стоит функция с помощью которой сквид избегает RST пакетов, вычитывание в /dev/null сокета.

Кеширование тут не при чем, кеширование хорошо, но траффик должен считаться не прокси сервером.

Share this post


Link to post
Share on other sites
Посмотрите в код сквида. Он считает полезные данные в TCP, но не учитывает IP и TCP заголовки.

Я через цепочку проксей используя "method CONNECT" настроил обновление FreeBSD ... - что при этом

он учитывает что не учитывает ...

 

Попытайтесь понять для начала суть процесса. А суть заключается в том, что если клиент принимает данные медленнее чем сервер сквида, то при обрыве закачки клиентом, траффик находящийся в TCP буферах на прием и отправку будет безвозвратно потерян, ну и плюс несовершенность алгоритмов. Чего только стоит функция с помощью которой сквид избегает RST пакетов, вычитывание в /dev/null сокета.

Я так понял вы о кеше не говорили и в буферах 30мб потеряли.

 

Кеширование тут не при чем, кеширование хорошо, но траффик должен считаться не прокси сервером.

Провайдер настроил на клиента пинговалку и выставил счёт ...

 

И кстати я ничего не говорил кто и как должен считать.

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Тоесть получается считать траффик при помощи squid нельзя, так как разбег между данными посчитанными squid и в итоге представленным счетом провайдера может составлять огромную разницу? так я понял?

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

Как и далеко не равняется "трафику" squid-юзер для этого файла.

Как и далеко не равны "трафики" squid-юзер и squid-инет и запись в логах для этого файла.

 

 

Share this post


Link to post
Share on other sites

Автору.

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

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

Хотите считать полностью весь траффик - считайте по netflow по IP или дополнительно впн поднимайте и там по радиусу или нетфлоу.

Простой пример: клиент запрашивает файл размером 50 байт. Сквид считает 50 байт. Он не считает заголовков, которых ещё байт на 50 или больше. Плюс заголовки IP, TCP.

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

 

2. Зачем вас считать почту!?

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

 

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

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