Экономим немного трафика на сервере в Amazon EC2
Продолжим эксперименты с нашим сервером в облаке Amazon EC2. Для тех, кто не понял, о чём сейчас речь, надо для начала прочитать две (первую и вторую) предыдущие статьи. Некоторые моменты, подробно описанные ранее, будут опущены. Если сомневаетесь, не забыли ли чего, ещё раз перечитайте уже опубликованные материалы. В этой же заметке будет рассказано о том, как немного сэкономить трафик, а заодно и некоторое количество нервов при работе с нашим сервером в облаке Amazon EC2. Но для начала надо решить, так ли уж необходимы эти дополнительные настройки. Ситуация двоякая. С одной стороны, Amazon EC2, как и любой порядочный облачный сервис, считает буквально каждый чих пользователя. То есть внимательно следит за потреблением каждого из ресурсов сервера, которые в нашем случае вовсе не бесконечны. В первую очередь это ограничения по объёму передаваемого трафика, а заодно и количество дисковых операций. Остальные ресурсы выдаются с гораздо большим запасом. С другой стороны, трудно предсказать, сколько именно трафика удастся сэкономить. Легко может получиться так, что затраченные усилия будут превышать потенциальную выгоду. Так что решать вам.
Каким образом можно уменьшить потребление трафика? В нашем случае простейшим вариантом будет установка прокси-сервера. А точнее, сразу двух — кеширующего и сжимающего. Работать мы будем исключительно с данными, передаваемыми по протоколу HTTP и 80-му порту. Во-первых, именно такой трафик превалирует при работе в Сети. Во-вторых, кешировать или сжимать другие данные (например, мультимедиа) в нашем случае либо бессмысленно, либо накладно. В-третьих, далеко не все программы могут корректно работать даже через прозрачные прокси. Недостатком такого метода будет небольшое увеличение задержки при открытии сайтов, а также тот факт, что некоторые особо въедливые веб-сервисы не допускают до «царского тела» посетителей, которые используют прокси.
Впрочем, в нашем случае можно достаточно гибко настроить всю эту систему. Например, полностью отказаться от кеширующего прокси. Или сделать так, чтобы при подключении через IP-over-DNS трафик проходил через цепочку прокси (хотя бы через сжимающий), а в случае с обычным VPN (PPTP) — шёл напрямую. Также цепочка прокси может оказаться полезной, если у вас медленное подключение к Сети или используется помегабайтная оплата трафика. В качестве кеширующего прокси мы будем использовать классику жанра, а именно Squid. Для сжатия же вполне подойдёт Ziproxy. Таким образом, схема подключения к Сети будет выглядеть так: Веб-браузер ↔ Ziproxy ↔ Squid ↔ Интернет. Вся остальная информация будет пускаться в обход цепочки прокси-серверов.
⇡#Настройка Squid
Сначала установим и настроим Squid. Для этого в PuTTY откроем консоль удалённого сервера и введём команду
и тут же на всякий случай остановим его демон
Теперь надо сделать резервную копию исходного конфигурационного файла командой
Всё, можно приступать непосредственно к настройке прокси-сервера:
Файл конфигурации Squid — это такая огромная «портянка» сплошного текста весом под 200 килобайт. По настройке этого прокси-сервера можно написать целую диссертацию, а для освещения всех вопросов тонкого тюнинга Squid потребуется научный труд в трёх томах. Если говорить серьёзно, то ничего страшного в этом объёмистом файле нет. Процентов девяносто в нём занимают подробные комментарии с примерами к каждому описываемому параметру. В нашем случае будет достаточно немножко отредактировать стандартный (рекомендованный) файл конфигурации Squid, внеся в него пару изменений.
Squid базируется на так называемых списках контроля доступа (ACL — Access Control List). Описание каждого списка начинается с директивы acl, потом идёт название списка, затем тип и значение. К спискам применяются правила доступа, например http_access. Каждое правило начинается с названия типа, затем указывается действие (например, запрет или разрешение), его параметры и объект (список или что-то другое), к которому оно применяется. Есть также просто параметры, такие как http_port. Все списки, правила, параметры считываются и применяются в том порядке, в котором они записаны. Поэтому сначала прописываются разрешающие правила, а потом запрещается всё остальное. Вот такая сложная на первый взгляд, а на самом деле довольно простая идеология.
По умолчанию доступ к Squid по HTTP разрешён только с той машины, на которую он установлен. Чтобы исправить это, надо добавить строку «http_access allow localnet» перед строкой «http_access deny all». Таким образом мы разрешили доступ к серверу с IP, которые входят в список localnet. Так как мы знаем, что соединяться с сервером мы будем через PPTP или IP-over-DNS, то можно отредактировать этот список, внеся в него только нужные нам подсети и закомментировав (убрав) ненужные:
Делать это необязательно, можно обойтись стандартной конфигурацией. А вот следующий параметр надо обязательно поправить:
Это указание серверу, на каком интерфейсе и порту принимать запросы от пользователей, а также указание его типа. В нашем случае это будет IP 127.0.0.1 (доступ только с локальной машины), порт 8080, тип — прозрачный (transparent). Если вы не планируете использовать перед кеширующим прокси сервер Ziproxy, то этот параметр лучше привести к такому виду:
Также после установки и отладки Squid полезно заменить строку
Это отключит ведение лога Squid, а значит, не будет расходоваться лимит на операции ввода-вывода, хотя с точки зрения безопасности это не самый лучший вариант. В конце статьи будет дана ссылка на архив с готовыми конфигурационными файлами из нашего примера и инструкция по копированию их на сервер. Если же вы всё-таки решили самостоятельно отредактировать файл в nano, то вот маленький совет. Для поиска нужной директивы нажмите Ctrl+W, введите TAG: имя_директивы (например, TAG: http_port) и нажмите Enter. Останется только промотать вниз описание соответствующего параметра и внести изменения. Не забудьте сохранить файл после редактирования. Если будет желание и уверенность в своих силах, то можно поискать в Сети инструкции по тонкой настройке кеша Squid и попробовать его настроить. Только делать это надо осторожно.
⇡#Настройка Ziproxy
Ziproxy получает запрос от клиента, запрашивает данные у нужного сайта, получает их, «на лету» сжимает в Gzip и уже в заархивированном виде передаёт обратно. Практически все современные браузеры поддерживают сжатие Gzip. Устанавливаем и сразу же останавливаем демон Ziproxy, а заодно и сохраняем исходный файл настроек:
Отредактировать конфигурационный файл можно привычной командой
Настройки нужно привести к примерно такому виду (здесь, как и ранее, дается укороченная версия файла, без комментариев и прочего «мусора»):
Разберём некоторые параметры. В Port указывается номер порта, на котором будут приниматься запросы. В NextProxy и NextPort заносится IP-адрес и порт вышестоящего прокси-сервера. В нашем примере это Squid (см. опцию http_port). Если не планируется использовать Squid или любой другой прокси после Ziproxy, то эти строчки надо закомментировать (поставить # в начале). Следующие две опции лучше не трогать. ZiproxyTimeout — это время ожидания ответа от удалённого сервера в секундах. Этот параметр можно не менять или уменьшить, например до 60 секунд. Вряд ли сервер, не ответивший через минуту, ответит через полторы. В MaxSize указывается максимальный размер обрабатываемого файла в байтах. Можно поэкспериментировать с его значением, но тут есть одна особенность. Если сильно уменьшить этот параметр, то сервер начнёт пропускать без сжатия небольшие файлы вроде картинок. Если переборщить, то увеличится время ожидания, так как Ziproxy придётся сначала выкачать весь файл, пережать его и уже потом отдать клиенту.
Следующие три параметра оставляем в покое и переходим к Process*. Из названия пунктов понятно, что серверу разрешено сжимать, а что нет. ProcessHTML* — экспериментальная опция. Если вёрстка страниц будет «ломаться», то её надо будет отключить. В ImageQuality указывается в процентах качество изображений JPG и PNG от лучшего к худшему, до которого они будут сжиматься. К статье также будет приложен этот файл настроек, но вы можете отредактировать его и вручную. Выше приведены только базовые опции сжатия трафика. В Ziproxy есть ряд экспериментальных функций, которые можно включить. Но они не всегда корректно и стабильно работают.
Сохраняем файл после редактирования и запускаем прокси:
Если потом надо будет что-нибудь поправить в настройках, то не забывайте после этого перезапускать демоны:
⇡#Настройка маршрутизации
Надо сделать так, чтобы все запросы на 80-й порт шли через прокси-сервера, а остальные данные пропускались мимо:
Можно по-разному настроить маршрутизацию. Если мы хотим, чтобы трафик не сжимался, то вместо порта 3128 указываем 8080 (см. выше нужную настройку Squid для этого случая). 192.168.244.0 и 172.16.15.0 — это подсети для соединений VPN и IP-over-DNS из предыдущих статей. Если, к примеру, нет желания использовать прокси-цепочку при подключении через PPTP, то тогда пропускаем первые две строчки. Также не забываем добавить и сохранить эти строки в /etc/rc.local командой
Если впоследствии надо будет подкорректировать настройки маршрутизации, то придётся удалить соответствующие строки из /etc/rc.local и выполнить следующие команды:
⇡#Заливка файлов на сервер
Скачиваем программу WinSCP, устанавливаем и запускаем её. Жмём справа на кнопку New и попадаем в диалог настройки нового соединения. В поле Host name указываем DynDNS-имя сервера (в нашем примере это был amazec2.dyndns-ip.com), Port number оставляем равным 22, в User name вбиваем ubuntu, в Private key file выбираем наш файл ppk-ключа. Protocol настраиваем, как на скриншоте ниже. Теперь жмём Save, выбираем любое имя для нашего соединения, сохраняем его и жмём Login.
Скачиваем архив с примерами конфигурационных файлов, распаковываем и копируем их в папку /home/ubuntu/ на удалённом сервере. В консоли выполняем следующие команды:
Переходим к разделу «Настройка маршрутизации» (см. выше) и выполняем предложенные инструкции. Всё, прокси-сервера готовы к работе. Попробуйте поработать в таком режиме. Если что-то будет не устраивать, то можно подкрутить настройки, как в примерах выше. В крайнем случае можно избавиться от Squid и Ziproxy командами
⇡#Вместо постскриптума
В ходе работы с сервером выявилась одна маленькая неприятность — журнал авторизации (/var/log/auth.log) за пару дней успел вырасти до каких-то неимоверных размеров. При беглом осмотре журнала нарисовалась вот такая картина:
Какие-то бодрые товарищи пытались банальным брутфорсом (перебором логинов и паролей) получить доступ к SSH. Не то чтобы это редкая ситуация, напротив, подобное встречается сплошь и рядом. Однако удивила настойчивость этих товарищей и, скажем так, недальновидность. Нам-то ничего особенно не грозит, так как авторизация происходит в SSH с помощью ключа. Но факт всё равно неприятный. Много трафика они не отъели, однако из-за ошибок авторизации возросло количество записей в соответствующий файл, а значит и число операций с диском. Чтобы избежать подобных ситуаций в будущем, достаточно выполнить пару несложных действий: