ipFobos Опубликовано 11 декабря, 2009 · Жалоба Доброго времени суток всем! Почитав информацию из интернета, стало понятно что прокси сервер squid нельзя привязать к почте. Внутри нашей компании поставлен сервер под управлением FreeBSD с прокси-сервером squid. Всё работает замечательно, пока тема не касается почтовых агентов. Интересует вопрос, вообще как сделать проброс портов для почтовых программ, тоесть нужно открыть 25 и 110 порты (какими средствами?). Я так полагаю это сделать можно включив нат, но вот в чем появляется проблема - открываем порты, и соответственно подсчет трафика уже не будет объективным, так как squid не сможет анализировать почтовый трафик, а ведь его при определенных значениях может существенно набежать. Вопрос заключается в том, как решить данную проблему? Тоесть посчитать трафик http и smtp одним целым? возможно ли такое? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 11 декабря, 2009 · Жалоба Если вы считаете траффик squid-ом, подсчет у вас уже необьективный Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ipFobos Опубликовано 11 декабря, 2009 · Жалоба Если вы считаете траффик squid-ом, подсчет у вас уже необьективный Необъективный в плане того что не сертифицированный билинг. Или хотите сказать что данные подсчитанные например юзергейтом и squid имеют существенные отличия? Как я понимаю необъективный подсчет в плане того что нельзя выставлять по squid`у счета, это понятно, а вот например если внутри организации для ограничения количества трафика пользователям считать, разве необъективен будет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martin74 Опубликовано 11 декабря, 2009 · Жалоба я начал качать 600 метровый файл, скачал 500 метров и оборвал закачку. С вероятностью 95% сквид докачает файл до конца и посчитает мне 600 метров. Это если утрированно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 11 декабря, 2009 · Жалоба Обычно делают транспарент прокси, а трафик считают любым колеектором. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Валентин. Опубликовано 11 декабря, 2009 · Жалоба я начал качать 600 метровый файл, скачал 500 метров и оборвал закачку. С вероятностью 95% сквид докачает файл до конца и посчитает мне 600 метров. Это если утрированно А не надо утрировать. После обрыва в лог попадёт строчка о скачивании 500 метров. А сквид в зависимости от настроек может докачивать себе в кеш. Вопрос заключается в том, как решить данную проблему? Тоесть посчитать трафик http и smtp одним целым? возможно ли такое? Прокси бывают не только HTTP ... - есть и SOCKS. Но даже у HTTP прокси есть "method CONNECT" - куда можно "впихнуть" много чего , в том числе и "почту". Но это уже будет не так красиво и тривиально и несёт в себе много угроз. ИМХО. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Валентин. Опубликовано 11 декабря, 2009 · Жалоба Или хотите сказать что данные подсчитанные например юзергейтом и 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 12 декабря, 2009 · Жалоба Если обьективно squid не учитывает IP/TCP заголовки. Кроме того может сказаться т.н. "negative-caching effect", когда сквид вытянет юзеру 100 Мб, а на самом деле сквид для такого юзера вытянул с инета 130Mb. И т.п. и т.д. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Валентин. Опубликовано 12 декабря, 2009 · Жалоба Если обьективно squid не учитывает IP/TCP заголовки. Не понял фразы. Кроме того может сказаться т.н. "negative-caching effect", когда сквид вытянет юзеру 100 Мб, а на самом деле сквид для такого юзера вытянул с инета 130Mb. И т.п. и т.д. "Процесс" управляем и контролируем. И забыли сказать, что остальным эти 130Mb будет отдавать из кеша. И те кто пользуется кеширующим прокси , в котором возможен, данный ефект обычно ведут статистику и видят разницу и ефективность. Разница в процентах общего трафика и из кеша по отношению к мизерным случаям обрыв+докачка в кеш идёт в разы. Даже с дефолтными утановками этого параметра. Мне тяжело представить "организацию для ограничения количества трафика пользователям" где кешируют сотнями Мб. ИМХО. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martin74 Опубликовано 12 декабря, 2009 · Жалоба ну у меня squid спокойно кеширует yum update для centos серверов ;) Пару лет назад пытался использовать транспарент прокси в сети, заворачивая туда весь 80 порт клиентского трафика... Даже 30-40% кешировалось. Но вот как каналы выросли - затраты на прокси себе не оправдывают. Мне сейчас даже страшно представить transparent прокси, которая потянет весь гигабит внешнего канала ;) А главное - зачем ;) Прятать всех пользователей за один ип - неинтересно, у меня для маскарада /23 сетка отдана.... wccp прикручивать не к чему... Собственно я это все к чему - сквид имеет место жить в маленькой сетке. Но даже там я бы не рассчитывал на него, как на единственный способ доступа в инет... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 13 декабря, 2009 · Жалоба Не понял фразы.Посмотрите в код сквида. Он считает полезные данные в TCP, но не учитывает IP и TCP заголовки. "Процесс" управляем и контролируем.И забыли сказать, что остальным эти 130Mb будет отдавать из кеша. Попытайтесь понять для начала суть процесса. А суть заключается в том, что если клиент принимает данные медленнее чем сервер сквида, то при обрыве закачки клиентом, траффик находящийся в TCP буферах на прием и отправку будет безвозвратно потерян, ну и плюс несовершенность алгоритмов. Чего только стоит функция с помощью которой сквид избегает RST пакетов, вычитывание в /dev/null сокета.Кеширование тут не при чем, кеширование хорошо, но траффик должен считаться не прокси сервером. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Валентин. Опубликовано 13 декабря, 2009 · Жалоба Посмотрите в код сквида. Он считает полезные данные в TCP, но не учитывает IP и TCP заголовки. Я через цепочку проксей используя "method CONNECT" настроил обновление FreeBSD ... - что при этом он учитывает что не учитывает ... Попытайтесь понять для начала суть процесса. А суть заключается в том, что если клиент принимает данные медленнее чем сервер сквида, то при обрыве закачки клиентом, траффик находящийся в TCP буферах на прием и отправку будет безвозвратно потерян, ну и плюс несовершенность алгоритмов. Чего только стоит функция с помощью которой сквид избегает RST пакетов, вычитывание в /dev/null сокета. Я так понял вы о кеше не говорили и в буферах 30мб потеряли. Кеширование тут не при чем, кеширование хорошо, но траффик должен считаться не прокси сервером. Провайдер настроил на клиента пинговалку и выставил счёт ... И кстати я ничего не говорил кто и как должен считать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ipFobos Опубликовано 14 декабря, 2009 · Жалоба Тоесть получается считать траффик при помощи squid нельзя, так как разбег между данными посчитанными squid и в итоге представленным счетом провайдера может составлять огромную разницу? так я понял? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Валентин. Опубликовано 15 декабря, 2009 · Жалоба Тоесть получается считать траффик при помощи squid нельзя, так как разбег между данными посчитанными squid и в итоге представленным счетом провайдера может составлять огромную разницу? так я понял? squid в лог запишет реальний размер закачанного файла, который далеко не равняется "трафику" squid из инета для этого файла. Как и далеко не равняется "трафику" squid-юзер для этого файла. Как и далеко не равны "трафики" squid-юзер и squid-инет и запись в логах для этого файла. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 24 декабря, 2009 · Жалоба Автору. 1. Статистика полученная анализом лог файлов сквида и любого прокси - приблизительная. Пригодна реально только чтобы смотреть кто смотрел много порнухи, кто много исдел а одноглазниках, кто много качал, а кто вируса схватил. Все объёмы весьма приблизительные, хотя соотношения потреблдения между юзерами нареканий как правило не возникают. Хотите считать полностью весь траффик - считайте по netflow по IP или дополнительно впн поднимайте и там по радиусу или нетфлоу. Простой пример: клиент запрашивает файл размером 50 байт. Сквид считает 50 байт. Он не считает заголовков, которых ещё байт на 50 или больше. Плюс заголовки IP, TCP. Особенно заголовки начинают ощущаться когда кто то играет в игры за натом, в играх много мелких пакетов, и запросто набегает разница в два раза. Для прокси это тоже справедливо. 2. Зачем вас считать почту!? Ограничьте доступ только до корпоративной почты или поднимите у себя сервер, который будет выгребать почту и раскладывать в ящике на вашем сервере. А ещё лучше взять безлимит, дать юзерам нат, прокси сделать прозрачным и забыть о подсчёте трафика, только если для общей статистики чисто из любопытства. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
