1, 2, 3, 4, 5, продолжаем «шлюзовать»…

В своей прошлой заметке я описал создание шлюза на базе компьютера с Linux (а точнее — с установленным на нем дистрибутивом Ubuntu). Та процедура на самом деле была лишь первым шагом «глобального плана». Этот шаг позволил нам создать самый простой шлюз, который при подключении к нему пользователей автоматом присваивает им IP-адреса и «выпускает» их в интернет. Пришло время второго шага — установим на наш шлюз прокси-сервер.

Вводные

Собственно, исходными данными нам послужит информация из первой заметки. Итак, у нашего шлюза в соответствии с приведенными в первой заметке инструкциями:

• Есть сетевая плата eth0, которой он подключен в интернет (интерфейс WAN).
• Есть сетевая плата eth1, к которой подклдючаются компьютеры клиентов (интерфейс LAN).
• Сетевой плате eth1 присвоен IP адрес 192.168.100.1
• На интерфейсе eth1 запущен сервер dnsmasq, который динамически присваивает компьютерам клиентов адреса в диапазоне 192.168.100.50 — 192.168.100.250, а также обслуживает их DNS-запросы.

«Откуда взялись» и «как настроились» эти вводные — смотрите в первой заметке, повторяться я не буду. Если же в вашем случае вводные данные будут иными, откорректируйте приведенные ниже инструкции в соответствии с собственными значениями.

SQIUD — установка

Установка прокси сервера SQUID на дистрибутиве UBUNTU выполняется очень просто — всего-навсего одной командой:

sudo apt-get install squid3

Тут надо сделать совсем маленькое отступление о том, почему в команде написано squid3, а не просто squid. Согласно информации с официального сайта, у Squid есть две стабильные ветки программы — 2-я и 3-я. Если у дистрибутива Ubuntu дать команду установить пакет squid, а не squid3, то в итоге будет установлена 2-я версия. Лично я предпочел поставить 3-ю. А уж как вам больше нравится — решайте сами.

В ответ на введенную команду Ubuntu скачает и установит Squid. Сразу же после установки он будет и запущен. Но в базовом виде его настройки нас не устраивают. Поэтому, самое время сделать следующее:

Настройка SQUID

Исходные параметры, с которыми в систему был установлен и запущен Squid, нам немного не подходят. Поэтому, в консоли вводим команду

sudo nano /etc/squid3/squid.conf

В указанном редакторе (nano) откроется файл конфигурации сервера Squid.

Еще одно отступление. В этой (равно как и в предыдущей) заметке рассматривается только самый необходимый минимум, так сказать «функциональный базис». После выполнения приведенных рекомендаций вы получите работающий шлюз. НО, полное раскрытие всех возможностей допустим того же Squid не было задачей, да и не возможно в выбранном формате (записи в блоге). В этом вам поможет (наиболее полно и максимально) естественно, документация, написанная авторами программы, которую можно легко найти на сайте разработчиков.

Итак, пройдемся по тем настройкам, которые добавил или изменил лично я.

Первым делом я нашел вот такую строку:

acl localhost src 127.0.0.1/32

и под (хотя можно и над) ней добавил еще одну — следующего содержания:

acl localnet src 192.168.100.50-192.168.100.250

В данном случае, добавленная мной строка создает (назовем его так) «шаблон» (жаждущие пеедантизма в формулировках могут прочесть это) с именем localnet (имя при желании вы вольны придумать свое собственное), который указывает, что под этот «шаблон» попадают данные (пакеты), источником (src) которых являются IP-адреса в диапазоне от 192.168.100.50 до 192.168.100.250 (см. выше наши «Вводные» — это именно тот диапазон, который наш шлюз присваивает компьютерам клиентов).

Затем я нашел в файле следующую строку — вот такую:

http_access allow localhost

и опять же под ней добавил еще одну:

http_access allow localnet

Эта запись разрешает нашему серверу прокси обрабатывать запросы, поступающие от тех компьютеров, которые удовлетворяют созданому ранее «шаблону» localnet (естественно, если вы дали приведенному выше «шаблону» свое собственное имя, то тогда и тут тоже укажите именно его). Тут есть еще одно ВАЖНОЕ ЗАМЕЧАНИЕ — добавленная вами строка ОБЯЗАТЕЛЬНО ДОЛЖНА БЫТЬ ВЫШЕ (раньше) строки «http_access deny all»!

Далее в файле я нашел строку

http_port 3128

и изменил ее саму — дописав в конец слово «transparent«. В итоге строка стала выглядеть следующим образом:

http_port 3128 transparent

Этим самым я указал, что мой Squid будет работать в режиме т.н. «прозрачного» прокси, т.е. клиенты даже не будут подозревать о его существовании. И им не нужно будет в своих браузерах прописывать использование прокси-сервера. Они будут просто «ходить в интернет» как обычно, а Squid, как тот Штирлиц — писать все 🙂 …

В принципе, приведенных выше изменений (с учетом того, что я просто НЕ ТРОГАЛ остальные базовые настройки) вполне достаточно для нашего случая. Но, я сделал еще одно — нашел и отредактировал строку, указывающую, на каком языке Squid будет выводить сообщения об ошибках. В итоге строка стала выглядеть следующим образом:

error_directory /usr/share/squid3/errors/Russian-1251

В результате, пользователи (клиентские компьютеры) будут получать сообщения об ошибках (например о недоступности сайта или еще чем-то) на русском языке. А вдруг, это им поможет 😉 ..

Ну чтож, сохраняем изменения и выходим из редактора (Ctrl + X). Чтобы задействовать внесенные в настройки параметров изменения, перезапускаем сервер Squid командой:

/etc/init.d/squid3 restart

Все. Кеширующий прокси-сервер Squid работает. Осталось сделать последний шаг — трафик клиентских компьютеров завернуть непосредственно в него. И в этом нам поможет…

Настройка файервола

Как было сказано выше, «минимализ — наше все». По этому, приведенный ниже скрипт правил файервола так и сделан — в нем прописан необходимый минимум. А минимум этот, как написано вот в этом HOWTO действительно весьма аскетичен! Как говорили в небезызвестной советской комедии — «Достаточно одной таблетки!». А в нашем случае — всего одной строчки, которая в приведенном ниже скрипте выделена синим цветом:

        #!/bin/sh
        WAN="eth0"
        LAN="eth1"

        iptables -F INPUT
        iptables -F FORWARD
        iptables -F OUTPUT

        iptables -P INPUT ACCEPT
        iptables -P OUTPUT ACCEPT
        iptables -P FORWARD ACCEPT

        iptables -A INPUT -i $WAN -p tcp --dport 22 -j ACCEPT

        iptables -t nat -A PREROUTING -i $LAN -p tcp --dport 80 -j REDIRECT --to-port 3128
        echo "1" > /proc/sys/net/ipv4/ip_forward

Как было сказано выше, «синее» правило заворачивает запросы, приходящие на интерфейс, определенный как переменная LAN (которая в скрипте равна eth1 — интерфейсу, к которому, согласно нашей «Вводной» подключаются клиенты) на порт 3128 (а это тот порт, на котором слушает наш Squid). В итоге клиенты автоматом получают доступ в интернет через наш прокси.

В скрипте есть еще две строки, выделенные красным — они не нужны для работы собственно шлюза, а открывают доступ к ssh-консоли шлюза. Если вам не нужно такое — просто удалите эти строки.

Что делать со скриптом, и как автоматизировать его запуск при загрузке компьютера — уже было описано мной в прошлой заметке. В данном случае сделайте все то же самое — скрипт сохраните в виде файла, файл сделайте исполняемым, выполните и пропишите его например в тот же файл /etc/network/interfaces (естественно, вместо того, что там был указан ранее). Если же приведенный скрипт правил файервола вам покажется недостаточным, можете использовать иной, например, тот, который приведен вот в этой заметке, ну или напишите свой собственный…

И вот собственно после того, как вы запустили на исполнение приведенный выше скрипт, пришло время подключить в шлюзу клиентский компьютер. У компьютера в настройках сети нужно включить использование DHCP-клиента (т.е. говоря терминами Windows — «Получить адрес автоматически» и «Получить адрес сервера DNS автоматически»). Компьютер должен автоматом получить от шлюза нужные данные — свой адрес, адрес шлюза и адрес сервера DNS. После этого можно запускать на компьютере браузер и отправляться в интернет…

А на шлюзе для проверки можно запустить вот такую команду:

sudo tail -f /var/log/squid3/access.log

И наблюдать нечто наподобие такого:

192.168.100.85 - - [12/Apr/2011:13:16:08] "GET http://www.cyberforum.ru/images/buttons/lastpost.gif HTTP/1.1" 304 375 TCP_IMS_HIT:NONE
192.168.100.85 - - [12/Apr/2011:13:16:08] "GET http://www.cyberforum.ru/images/icons/icon11.gif HTTP/1.1" 200 1503 TCP_HIT:NONE
192.168.100.85 - - [12/Apr/2011:13:16:08] "GET http://www.cyberforum.ru/images/statusicon/thread_hot_new.gif HTTP/1.1" 304 375 TCP_IMS_HIT:NONE
192.168.100.85 - - [12/Apr/2011:13:16:08] "GET http://www.cyberforum.ru/images/misc/multipage.gif HTTP/1.1" 304 375 TCP_IMS_HIT:NONE
192.168.100.85 - - [12/Apr/2011:13:16:08] "GET http://www.cyberforum.ru/images/icons/icon5.gif HTTP/1.1" 304 375 TCP_IMS_HIT:NONE
192.168.100.85 - - [12/Apr/2011:13:16:08] "GET http://www.cyberforum.ru/images/misc/paperclip.gif HTTP/1.1" 200 747 TCP_HIT:NONE
192.168.100.85 - - [12/Apr/2011:13:16:08] "GET http://www.cyberforum.ru/images/icons/icon4.gif HTTP/1.1" 304 375 TCP_IMS_HIT:NONE
192.168.100.85 - - [12/Apr/2011:13:16:08] "GET http://www.cyberforum.ru/images/icons/icon7.gif HTTP/1.1" 304 375 TCP_IMS_HIT:NONE
192.168.100.85 - - [12/Apr/2011:13:16:08] "GET http://www.cyberforum.ru/images/icons/icon1.gif HTTP/1.1" 304 375 TCP_IMS_HIT:NONE
192.168.100.85 - - [12/Apr/2011:13:16:08] "GET http://www.cyberforum.ru/images/icons/icon9.gif HTTP/1.1" 304 375 TCP_IMS_HIT:NONE
192.168.100.85 - - [12/Apr/2011:13:16:08] "GET http://www.cyberforum.ru/images/icons/icon2.gif HTTP/1.1" 200 1501 TCP_HIT:NONE

Как видим, лог Squid-а нам все показывает — «кто, куда, зачем и почем»…

PS. Ну вот, опять до вирусов не добрались…