Один интернет на всех: ставим прокси и учимся считать трафик

Модемный сеанс уходит. Не у всех и не сразу, но у нашего типичного клиента - торговая контора, 15-20 человек, один-два сервера - всё чаще появляется выделенная линия: либо xDSL, либо что-то проводное от местного провайдера. Постоянное подключение. Это удобно. Это дорого. И это немедленно порождает проблему, которую никто не ждал: что делать, когда интернет один, а хотят его все.

Раньше было просто. Бухгалтер набирал модемом, качал что надо, вешал трубку. Следующий - сел, набрал, скачал. Очередь формировалась сама собой через физическое ограничение. Теперь канал открыт постоянно, и в него одновременно смотрят пятнадцать человек. Кто-то открывает почту, кто-то лезет на сайт поставщика, кто-то случайно оставил какой-нибудь Download Master качать дистрибутив на ночь - а утром выясняется, что канал всю ночь был занят и половина дневной квоты улетела.

Именно с квотой главная боль. Провайдер даёт фиксированный объём трафика в месяц, дальше - либо доплачивай, либо скорость режется до неприличия. А сколько ушло вчера - загадка. Кто скачал - вопрос без ответа.

Прокси как точка контроля

Задача решается через прокси-сервер. Схема прямая: весь HTTP-трафик из офиса идёт не напрямую наружу, а через одну машину. Эта машина всё пишет, всё считает, при желании кеширует повторные запросы, и именно она решает, кому и что разрешить.

Мы в основном ставим Squid на Linux. Он бесплатный, стабильный, с нормальной документацией. Конфиг с нуля пишется за час, и дальше уже под конкретику.

Что настраиваем первым делом.

Логирование всего. access.log растёт быстро, но именно он потом отвечает на вопрос «куда ушли мегабайты». По нему же видно, кто и в какое время что тянул.

ACL по IP или по логину. Разбиваем сеть на группы. Бухгалтерия - один список разрешённых сайтов, менеджеры - другой, айтишник - почти без ограничений. Это не тотальный контроль, это просто порядок. Без него первый же человек с битторрентом или качалкой съедает всё.

Блокировка диапазонов портов. Прямые соединения на нестандартные порты через прокси не ходят по определению, но если стоит ещё и фаервол на шлюзе - дополнительно закрываем всё лишнее. Peer-to-peer в 2002 году уже есть, и он прожорлив.

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

Считать трафик - это не паранойя

Первые пару недель после запуска прокси клиенты смотрят на статистику как на откровение. Выясняется, что 40% дневного трафика - это несколько человек, которые привыкли качать «чуть-чуть» в рабочее время. Выясняется, что кто-то оставил браузер на новостном сайте с автообновлением каждые минуту. Выясняется, что антивирус на нескольких машинах обновляется независимо и каждый тянет полную базу отдельно.

Мы разбираем эту статистику с клиентом и расставляем приоритеты без скандалов. Антивирус переводим на централизованное обновление - один скачал, остальные берут с шары. Автообновления браузеров расписываем на ночное окно. Качалки объясняем, зачем лучше держать на одной выделенной машине и только в нерабочее время.

Звонки «интернет тормозит, провайдер плохой» после этого сокращаются. Не исчезают - канал всё равно не резиновый, - но уже понятно, кто и что его грузит прямо сейчас.

Что не решает прокси

Честно говорит: HTTPS через прокси в таком режиме не инспектируется, он проходит туннелем. Это пока не критично, потому что HTTPS у большинства сайтов не основной протокол, но объём такого трафика уже не считается корректно. Ещё прокси не помогает против прямых TCP-соединений, которые идут в обход - для этого нужен нормальный фаервол на шлюзе, и лучше это делать в связке.

Squid сам по себе тоже не панацея от перегруза. Когда канал реально узкий, а пользователей много - нужно либо расширять полосу, либо договариваться с людьми про культуру использования, либо и то и другое. Прокси помогает найти узкое место и не платить за него вслепую.

Регламент важнее конфига

Мы заметили, что половина работы - не технический конфиг, а короткий документ: кому что разрешено, что запрещено и почему. Если правила есть только в squid.conf, то при любом конфликте начинаются разборки - «а я не знал». Если есть одна страница, которую подписали при выдаче доступа, - разговор другой.

Работаем с клиентами, у которых канал под нашим обслуживанием, именно так: сначала фиксируем политику, потом кладём её в конфиг. Не наоборот.

Про то, что важно хранить и как - там была похожая история: технически всё правильно, но без регламента ничего не работает. С интернетом одна и та же мысль. Прокси поставить - час работы. Договориться, кто качает что и когда - иногда дольше.