18 April 2019
Экономный тукс
Денис Колисниченко
Сэкономил - значит заработал. Не даром существуют специалисты, которые целыми днями только и думают, где и на чем можно сэкономить. Правильно, это экономисты. Сегодня мы почувствуем себя на их месте. Мы будем экономить на Linux. Нет, мы не будем долго и скучно говорить о GPL и о том, что можно снести Windows и вместо него поставить Linux. Об этом много говорилось и общие принципы знают все. Мы поговорим о "практической экономии"
"Практическая экономия"
"Практическая" потому что экономить мы будем, применяя свои знания и умения на практике, а не в теории. А экономить есть на чем:
- Системные ресурсы - любой дистрибутив Linux требует меньше системных ресурсов, чем Windows XP/2003
- Установка кэширующего сервера DNS - можем сэкономить на трафике, поскольку всю "грязную" работу будет выполнять не резолвер каждого отдельного компьютера сети, а DNS-сервер нашего провайдера, а наш сервер будет только кэшировать результаты его работы
- Установка собственного DNS сервера - больше не нужно больше платить за поддержку домена. О преимуществах и недостатках этого способа мы поговорим при настройке самого сервера
- Установка прокси-сервера - позволяет существенно сэкономить на трафике, причем экономия будет ощутима, как в масштабах предприятия, так и в масштабах небольшой домашней сети. Кроме того, прокси позволяет забыть о рекламных баннерах, поскольку "вырезает" их из загружаемых страниц еще до их загрузки
Для установки кэширующего DNS- и прокси-сервера тебе совсем не обязательно иметь компьютер с выделенной линией - и DNS, и прокси будут отлично работать на *одной* обычной домашней машине, подключенной к Интернету с помощью модема. Причем эти серверы будут не просто работать, а экономить твои деньги.
Экономим системные ресурсы
Любой дистрибутив Linux требует меньше ресурсов, чем Windows XP, не говоря уже о Windows 2003 Server. Для организации сервера сети (DNS, прокси, шлюз) можно использовать старенький компьютер вроде Celeron 433 Mhz, 192 MB - такой компьютер в Windows XP будет "подтормаживать" даже при работе с Word'ом. А в Linux его можно использовать как в качестве сервера, так и рабочей станции. А это значит, что не нужно покупать дорогой комп для работы под Windows 2003 Server, а можно купить средненький компьютер для рабочей станции (будет работать в Windows XP), а старый комп, который постоянно "тормозил" в Windows можно использовать в качестве сервера, но уже под Linux.
Кэширующий DNS-сервер
Установка DNS-сервера позволяет:
- Сократить время разрешения доменных имен, поскольку свой DNS-сервер будет в нашей сети
- Немного сэкономить трафик
Итак, кэширующий DNS-сервер - дело нужное, поэтому не будем терять времени и приступим к настройке. Установи пакет bind (напомню, что пакет называется bind (Berkley Internet Nameserver Deamon), а сам сервер - named).
установка bind
После установки пакета bind нужно создать файл /etc/named.conf - это основной файл конфигурации named. Создать его можно в любом текстовом редакторе, например, в vi:
# vi /etc/named.conf
options {
directory "/var/named";
};
controls {};
zone "." in {
type hint;
file "named.ca";
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "named.local";
};
редактирование файла /etc/named.conf
Небольшие комментарии:
- Основная директория - /var/named
- Пустой блок controls {} нужен для того, чтобы named не ругался на отсутствие ключа rndc.key, который нужен для программы удаленного управления сервером - rndc. Правда, это несколько некорректно, поскольку для останова сервера нужно будет использовать команду killall named, но для нас это не существенно, поскольку мы не будем часто его останавливать
- Зона "." не поддерживается нашим сервером, тип hint (подсказка) означает, что в файле named.ca находится подсказка о том, где "искать" корневые серверы DNS
- Зона 0.0.127.in-addr.arpa - это локальная зона, она описана в файле named.local
В каталоге /var/named должны быть два файла: named.ca (создается при установке пакета bind) и named.local. Второй файл, чтобы его не создавать вручную, можно взять в каталоге /usr/share/doc/bind-9.2.3/dhcp-dynamic-dns-examples/bind/var/named.
редактирование файла /var/named/named.local
Теперь запустим named:
# named
Проверим, работает ли он:
# ps -ax | grep named
Команда выводит список процессов с именем named - твой named должен быть в списке.
named запущен и работает
Вроде бы все нормально, но на всякий случай, проверим журнал - возможно, сервер запущен с какими-то предупреждениями:
# tail /var/log/messages
журнал: все нормально
Будто бы все работает, но мы еще не сделали самого главного. Нам ведь нужно заставить сервер провайдера собирать для нас всю необходимую информацию. Фактически работать он, а не наш сервер. Для этого в блок options добавь следующие строки:
forward first;
forwarders {
# все запросы будут переадресованы к DNS-серверу провайдера 192.168.99.1
# если с этим сервером возникнет трабла, то локальный сервер поищит ответ
# в своем кэше или обратится к другим DNS-серверам (указываются в /etc/resolv.conf)
192.168.99.1;
};
Параметр forwarders задает заключенный в фигурные скобки список IP-адресов, соответствующих DNS-серверам, которым наш DNS-сервер будет переадресовывать запросы вместо того, чтобы отвечать на них самому. IP-адреса перечисляются через точку с запятой.
Параметр forward может принимать одно из двух следующих значений:
- only - наш DNS-сервер никогда не должен предпринимать попыток обработать запрос самостоятельно;
- first - наш сервер должен пытаться сам обработать запрос, если указанные далее параметром forwarders сервера DNS не были найдены.
Использование параметра forward бессмысленно без использования параметра forwarders. Теперь осталось в файле /etc/resolv.conf прописать IP-адрес собственного сервера DNS. То же самое нужно сделать на всех остальных компьютерах сети.
Конечно, настройка сервера на этом не заканчивается, например, можно прописать, каким клиентам можно использовать сервер, а каким - нет; немного обезопасить его, но основная задача, то есть создание кэширующего сервера, экономящего средства, выполнена. Нужно отметить, что кэширующий DNS-сервер эффективен не только в локальной сети, но и если ты используешь свой компьютер в гордом одиночестве - сайты начнут открываться быстрее, поскольку сервер имен запущен на твоем компьютере.
Домен у себя
Настройка полноценного (а не только кэширующего) сервера DNS немного сложнее настройки кэширующего. Но, прежде чем приступить к настройке собственного DNS-сервера ты должен кое-что осознать. Фактически, это означает перенос к себе своего домена. Предположим, что имеется домен firma.com, за который ты платишь 10 долларов в год. Теперь 10 долларов можно сэкономить, но это только одна сторона медали. Экономя 10 долларов в год, ты будешь платить больше за трафик, поскольку теперь все DNS-запросы к домену firma.com будут перенаправлены к твоему компьютеру. Само собою разумеется, что компьютер теперь нельзя выключать на ночь, поскольку ни Web-сервер, ни почта уже работать не будут. Как видишь, твои расходы увеличатся, поэтому с экономической точки зрения перенос к себе домена целесообразен для дорогих доменов вроде *.tm, *.ua, *.su, за которые нужно платить от 75 до 150 долларов в год. С другой стороны в качестве бонуса ты получаешь большую гибкость - теперь ты и только ты управляешь своим доменом.
Кроме этого, ты получишь еще одно преимущество - DNS-записи будут обновляться практически мгновенно: если до этого приходилось ждать 4-8 часов, то теперь ты сам можешь управлять этим процессом.
В общем, по поводу расходов - решай сам, а мое дело маленькое подсказать, как настроить свой DNS-сервер. Не забудь только предупредить провайдера о том, что теперь ты переносишь домен к себе. Вполне возможно, что провайдер за небольшие деньги (или вообще бесплатно) предложит тебе организовать вторичный DNS-сервер на его стороне (на стороне провайдера). Отказываться не стоит. Строго говоря, должно быть два DNS-сервера: первичный и вторичный. Вторичный используется клиентами, если с первичным трабла, например, перезагружается или вообще загружен работой так, что не может ответить. Вторичный DNS у провайдера - это даже надежнее, чем вторичный DNS у себя - все равно доменом управляет первичный сервер, а вторичный использует те данные, которые ты "прописал". Не бойся, провайдер не будет вмешиваться в дела твоего домена.
Для пущей определенности будем считать, что у нас есть доменное имя firma.com, а также сеть класса С (192.168.1.0). Итак, приступим к настройке. Для начала нужно изменить файл /etc/named.conf:
controls {};
options {
directory "/var/named";
forwarders { ip.addr.prov.dns; };
}
// Прямая и обратные зоны для домена firma.com
zone "firma.com" {
type master;
file "firma.com";
forwarders {};
};
zone "1.168.192.in-addr.arpa" {
type master;
file "1.168.192";
forwarders {};
};
Думаю, особо объяснять ничего не нужно - все и так ясно. Теперь нужно создать файлы прямой и обратной зоны (прямая отвечает за преобразование имен в IP-адреса, а обратная выполняет обратную функцию - это ясно из ее названия). Файл прямой зоны /var/named/firma.com:
firma.com IN SOA ns.firma.com. ns.firma.com. ( 2001042705 ; серийный номер 86400 ; обновлять (1 день) 21600 ; повтор (6 часов) 3600000 ; "срок годности" (5 недель 6 дней 16 часов) 3600 ; минимум (1 hour) ) NS ns.firma.com. localhost A 127.0.0.1 ns A 192.168.1.1 mail A 192.168.1.2 www A 192.168.1.3
Файл обратной зоны /var/named/1.168.192 будет выглядеть так:
1.168.192.in-addr.arpa IN SOA ns.firma.com. ns.firma.com. ( 2001042705 ; серийный номер 28800 ; обновлять (8 часов) 14400 ; повтор (4 часа) 3600000 ; "срок годности" (5 недель 6 дней 16 часов) 86400 ; минимум (1 день) ) NS ns.firma.com. 1 PTR ns.firma.com. 2 PTR mail.firma.com. 3 PTR www.firma.com.
Все конфиги в порядке, теперь можно запускать и тестировать DNS-сервер. Как это сделать, было показано выше.
Squid: прокси-сервер
С помощью прокси-сервера Squid можно очень эффективно управлять ресурсами своей сети, например, кэшировать трафик (http), "обрезать" баннеры, указать, какие файлы можно скачивать пользователям, а какие - нет, также можно указать максимальный объем передаваемого объекта и даже ограничить пропускную способность пользователей определенного класса. Как ты уже понял, Squid - это тема для отдельной статьи, а в этой мы рассмотрим только базовую его настройку. Но, тем не менее, уже после этого можно ощутить экономию трафика, если установить Squid даже в небольшой сети, состоящей всего из 4-5 компьютеров, при условии, что пользователи этих компьютеров работают в одном направлении и часто пользуются одними и теми же ресурсами.
Предположим, что у нас есть небольшая сеть на несколько компьютеров, скажем, на 10 компьютеров. Принципиально особой разницы нет, но количество компьютеров нужно учитывать при вычислении размера кэша Squid. Для 10 компьютеров вполне хватит 1 Гб кэша: получается, по 100 Мб на один компьютер. 100 Мб - это более чем достаточно, это даже больше, чем нужно. Например, по умолчанию та же Опера использует 10 Мб, что вполне хватает для обычного пользователя. 100 Мб хватит для требовательного пользователя, проводящего очень много времени в "паутине" Squid не сложен в настройке, во всяком случае не сложнее Apache и подобных сетевых сервисов. Установи пакеты squid и squidGuard. Первый пакет содержит, собственно, сам прокси-сервер, а во втором пакете находится плагин suidGuard, выполняющий следующие функции:
- ограничение доступа пользователей к отдельным URL, например, можно задать список юзеров, которым разрешен доступ, и список разрешенных URL
- блокирование URL, внесенных в черный список (например, сайты с контентом "для взрослых")
- ограничение доступа к URL на основе регулярных выражений
- замена баннеров пустыми картинками (ясно, что загружаться баннеры тоже не будут)
- различные правила доступа для определенного времени суток, дня недели, даты и т.д.
- разные правила доступа для разных групп пользователей
Как видишь, squidGuard - очень полезный модуль.
squid: автоматический запуск
Сейчас приступим к редактированию основного конфига /etc/squid/squid.conf:
# порт для прослушивания запросов клиентов # задается в формате http_port <порт> или http_port <узел>:<порт> # последний случай подходит, если SQUID запущен на машине с несколькими сетевыми # интерфейсами http_port 192.168.1.1:3128 # адрес прокси провайдера, нужно согласовать с провайдером # cach_peer proxy.your_isp.com # объем оперативки в байтах, который будет используется прокси-сервером (85Мб) # не устанавливай более трети физического объема оперативки, если данная машина # должна использовать еще для чего-либо # можно задать в мегабайтах, но тогда между числом и MB обязательно # должен быть пробел: cache_mem 85 MB cache_mem 87040 # где будет размещен кэш. # первое число - это размер кэша в Мб, не устанавливай кэш на весь раздел # если нужно чтобы он занимал весь раздел, отними от размера раздела 20% и укажи # это значение. Например, если раздел 1024 Мб, то для кэша - только 820 Мб # второе - количество каталогов первого уровня # третье - к-во каталогов второго уровня cache_dir /usr/local/squid 1024 16 256 # максимальный размер кэшируемымого объекта # если размер объекта превышает указанный здесь, то объект не будет сохранен на диске # maximum_object_size 4096 KB # хосты, с которых разрешен доступ к прокси acl allowed_hosts src 192.168.1.0/255.255.255.0 acl localhost src127.0.0.1/255.255.255.255 # разрешенные порты: acl allow_ports port 80 # http acl allow_ports port 21 # ftp # SSL-порты acl SSL_ports port 443 563 # запрещаем все порты, кроме указанных в allow_ports http_access deny !allow_ports # запрещаем метод CONNECT для всех портов, кроме указанных в acl SSL_ports: http_access deny CONNECT !SSL_ports # запретим доступ всем, кроме тех, кому можно http_access allow localhost http_access allow allowed_hosts http_access allow SSL_ports http_access deny all # пропишем пользователей, которым разрешено пользоваться squid (den, admin): ident_lookup on acl allowed_users user dena dmin http_access allow allowed_users http_access deny all
Конечно, это далеко не полный конфиг, но дальше, думаю, ты справишься сам. Чтобы ни у кого не сложилось впечатление, что я легко отделался (только базовой настройкой), чуть-чуть усложним задачу. Список пользователей (точнее узлов), которым разрешен HTTP-доступ, можно задавать в отдельном файле, например:
acl allowed_hosts src "/etc/squid/hosts.txt"
Сам файл /etc/squid/hosts.txt будет выглядеть так:
# Денис 192.168.1.2/255.255.255.255 # Макс 192.168.1.3/255.255.255.255 # Лена 192.168.1.4/255.255.255.255
Отдельный файл использовать удобнее, чтобы не "засорять" основной конфиг. Обрати внимание: права доступа к hosts.txt должны быть такие же, как к squid.conf. Теперь попробуем создать черный список URL:
acl blacklist url_regex games http_access deny blaklist http_access allow all
Данный черный список не пропускает URL, содержащие слово 'games'. По аналогии можно было бы создать отдельный файл и записать в него все "плохие" URL. Заметь, все это мы сделали только средства Squid, не привлекая squidGuard. Запустить squid просто:
# service squid start
Клиентов нужно настроить на порт 3128 (не забудь об этом).
настройка клиентов squid (браузеров)
squidGuard - личный охранник вашего трафика
В предыдущем примере мы заблокировали доступ к любому узлу, в URL которого есть слово 'games'. Ясно, что тут никаких сил не хватит описывать все URL, содержащие запрещенный контент, а именно порно, насилие, рекламу, информацию о наркотиках и тому подобные вещи. Таких узлов в мире очень много.
Тут на помощь приходил squidGuard. Он дополняет Squid базой данных по запрещенным узлам. Ясно, что базу данных нужно периодически обновлять, но зато больше не нужно самому искать узлы с запрещенным контентом и вносить их в список - все уже сделано за тебя.
Существует три основных базы:
- база squidGuard, доступна по адресу https://www.squidguard.org/blacklist/
- база MESD, доступна по адресу https://squidguard.mesd.k12.or.us/blacklists.tgz
- база Dansguardian, ее адрес https://blacklist.dansguardian.org/cgi-bin/download.pl?type=download&file=bigblacklist
Мы будем использовать базу squidGuard, поскольку она поставляется "в комплекте" с самим squidGuard. Данная база охватывает рекламу, порно, сайты посвященные агрессии, наркотикам, азартным играм, насилию и многое другое. Представляешь, сколько трафика сэкономит фирма, если закрыть пользователям доступ ко всем этому? После установки база обычно устанавливается в каталог /usr/share/squidGuard-1-x-x/db.
Если при установке Squid ты установил пакет squidGuard, то теперь можно приступить сразу к настройке. Скопируй файл /etc/squid/squidGuard.conf.sample в файл /etc/squid/squidGuard.conf, чтобы меньше потом пришлось набирать руками.
# Путь к базе и к журналам
dbhome /usr/share/squidGuard-1.2.0/db
logdir /var/log/squidGuard
# Когда работаем (если работать нужно постоянно, правила time можно удалить):
# аббревиатуры для дней:
# s = Вс, m = Пн, t =Вт, w = Ср, h = Чт, f = Пт, a = Сб
time workhours {
weekly s 09:30-12:00 13:00-19:00
weekly m 09:00-12:00 13:00-19:00
weekly t 09:00-11:00 12:00-19:00
weekly w 09:00-12:00 12:00-18:00
weekly h 09:00-13:00 13:00-18:00
weekly f 09:00-12:00 13:30-18:00
weekly a 08:20-13:00 13:30-19:00
}
# Описываем нашу сеть:
# пользователи сети
src lan-users {
ip 192.168.10-192.168.1.254
}
# DMZ, тут же компьютер админа
src main {
ip 192.168.1.1-192.168.1.10
}
# описываем базы запрещенного контента
…
# конфиг в целях экономии драгоценного места я немного сократил - все
# равно вместе с squidGuard поставляется пример этого файла, мы лишь только
#
dest advertising {
domainlist advertising/domains
urllist advertising/urls
# перенаправляем всю рекламу на баннер размером 0х0
redirect https://127.0.0.1/cgi-bin/nulbanner.png
}
…
# описываем ACL-ы
acl {
# админу разрешено все, кроме рекламы
main {
# директива pass разрешает или запрещает контент
# all обозначает весь контект
# если нужно запретить контент, какого-то класса, то перед именем класса контента
# указывается восклицательный знак, например, pass !porn
# none означает, что доступ вообще закрыт
pass !advertising all
# запрещенные запросы перенаправляются на сценарий https://127.0.0.1/cgi-bin/squidGuard.cgi
redirect https://127.0.0.1/cgi-bin/squidGuard.cgi?clientaddr=%a&srcclass=%s&targetclass=%t&url=%u
}
# основное "население" сети
lan-users {
# разрешаем все, кроме указанных со знаком ! классов контента
pass !adult !audio-video !forums !hacking !redirector !warez !ads !aggressive !drugs
!gambling !publicite !violence !banneddestination !advertising all
redirect https://127.0.0.1/cgi-bin/squidGuard.cgi?clientaddr=%a&srcclass=%s&targetclass=%t&url=%u
}
# по умолчанию
default {
pass none
redirect https://127.0.0.1/cgi-bin/squidGuard.cgi?clientaddr=%a&srcclass=%s&targetclass=%t&url=%u
}
}
Думаю, что ничего сложного в файле конфигурации squidGuard нет. Обрати внимание только на то, что на локальном узле должен быть установлен Web-сервер, а в его каталоге cgi-bin установлен сценарий squidGuard.cgi. Пример данного сценария находится в каталоге /usr/share/squidGuard-1.x.x/sample. Отдельно копировать его в каталог /var/www/cgi-bin необходимости нет - это происходит при установке RPM-пакета.
Нам осталось только связать squid и squidGuard. Для этого добавь в файл /etc/squid/squid.conf строки:
redirector_bypass on redirect_program /usr/local/squidGuard/bin/squidGuard # сколько копий squidGuard нужно запускать redirect_children 1После этого нужно перезапустить Squid.
# service squid restart
В файле /var/log/squidGuard/squidGuard.log ты должен увидеть такие строки:
2006-03-19 15:45:14 [9601] squidGuard 1.2.0 started (1034683864.337) 2006-03-19 15:45:14 [9601] squidGuard ready for requests (1034683864.353)
Это говорит о том, что squidGuard запущен и готов к работе.
Надеюсь, что эта статья поможет тебе сэкономить не только время, но и деньги, да и спокоен будешь насчет того, что дети сотрудников, которые пришли "в гости" на работу, не будут смотреть "сайты для взрослых". Если у тебя будут какие-то вопросы, ты всегда можешь их задать на форуме https://dkws.org.ua