LINUX.ORG.RU

Принудительное проксирование FTP


0

0

По мотивам недавних изысканий написал небольшую статью, как сделать принудительное проксирвание FTP-соединений с помощью пакетов FROX и SQUID для Linux и FreeBSD. Полезная вещь для корпоративных сетей с интенсивным трафиком.

>>> Статья

anonymous

Проверено: green

Ы-ы-ы-ы .. насчет сквид - "зло" .. ХЗ. Раз кто-то говорил, чо в юнихе графика - от Лукавого и ее поэтому использовать не стоит. Враки это все. Сквида помогает сэкономить по крайней мере у меня в среднем так порядка 13% трафика. А это денежки которые контора за инет платит. Настраивать ее нечего делать - полчаса работы вместе с transparent, delay_pools и прочими фишками. Сюда же и transparent ftp. Зато - не надо бегать по всем рабочим станциям и каждому юзеру проксю прописывать проксю. Если рабочих станций - 5 десятков, то еще ладно, а если 5 сотен ? Тем более юзера сами обычно прописать проксю не умеют. Насчет сценария настройки прокси - так его ж тоже руками везде прописать надо. А если контора территориально очень большая а админ один ? Прикажете в другой город ехать ? А посчитайте сколько 5 сотен юзерей могут в месяц накачать, сколько это будет стоить и сколько можно сэкономить ? Насчет ограничения скорости, количества коннектов .. delay_pools + QoS + iproute2 + firewall. Все вместе и получается просто прекрасно. :) Каждому достаточно чтобы нормально качать , при этом не происходит докачек после обрыва (см. выше, писали уже) и не будет придурка который займет весь канал. И всякие фильмы, музыку, порнуху .. пусть качают, но с черепашьей скоростью. :) А насчет не "зарезать" баннеры, или запретить кеширование - это на сквиде тоже можно сделать. Причем выборочно - кому надо, кому нет. См. acl'ы в конфиге или squidguard. Кошки - они вкусные, только их уметь готовить надо. :) И вообще - сквида - отличная прокся. :) WBR, Burzumie.

anonymous
()
Ответ на: комментарий от anonymous

С моей точки зрения технология проксирования очень полезна тем, что повышает управляемость трафиком, т.к. выводит управление на другой уровент (в модели ISO это уровень 8 уровень -приложений, если я не ошибаюсь). Ни шейпер ни qos не может управлять потоком, разбирая http и ftp запросы и например не пропуская mp3. Администрируя доступ к Интернету для сети в 300 рабочих станций, понимаешь, что без такого управления либо влетишь в счета от провайдера, либо канал просто забьется и "ляжет" (достаточно паре человек пускануть reget в 8 потоков) - и это не пространное рассуждение именно так и происходит. И в сетях такого масштаба всем ставить установки броузера весьма затруднительно, а воспитывать пользователей бесполезно, потому что всетаки системы для них а не они для систем - поэтому я использую принудительное проксирование. Да, плохо когда проксирование используется провайдерами для экономии на кешировании... но тоже проксирование можно применять в корпоративных сетях, повышая эффективность использования Интернета.

Автор статьи.

anonymous
()
Ответ на: комментарий от anonymous


> Ни шейпер ни qos не может управлять потоком, разбирая http и ftp запросы и например не пропуская mp3.

Возьми меня в свою сеть на недельку. Я выкачаю себе mp3 на
десяток сидюков, а заодно покажу тебе на практике, что есть
такое "управление потоком" с помощью прокси. А это есть защита
от дураков и на дураков рассчитанная.

anonymous
()

> Я выкачаю себе mp3 на десяток сидюков
Ну, при нормально настроеной проксе (анализе логов и ip-accounting'е) это ловится в тот же день, а потом шутника "будет наказано" ((C) Star Wars, episode I). :)
Burzumie.

anonymous
()

Интересно как? Ежели, скажем, URL tra-ta-ta.mp3 ? Или секрет? Заранее спасибо :)

SPB_NICK
()

оки :)
тогда читаем всякие доки на предмет:
- настройки показа общей загрузки канала (для примера - тот же mrtg) и ip-accounting'а
ip-accounting на линухе через ipac/ipac-ng или net-acctd
по ним можно будет увидеть что что-то не так
как вариант - сделать проверку по крону - ежели текущий прирост после крайней проверки значительно превышает некоторое среднее - уведомляем админа, если он поленился посмотреть на график
- смотрим regexp'ы, acl'ы и delay_pool'ы в squid'е
подсказка - ими можно запретить и/или ограничить скорость выкачки для этих самых mp3'шек и иже с ними
- настраиваем нечто типа sarg (или sqmgrlog) на предмет показа статистики выкачек. с "турнирными таблицами" по юзерам, хостам, урлам и по чем еще только придумать можно. или пишем такое сами, если то не нравится, это не так уж и долго
- настраиваем transparent proxy (http & ftp)
- настраиваем firewall, чтобы не могли через другие прокся качать
- через iproute2 настраиваем шейпинг канала. чтобы качатели не моглаи закушать весь канал
- хотя бы раз в час посматриваем на статистику :) это не так уж и сложно
все. кто не спрятался - я не виноват ;)
WBR, Burzumie

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.