Настройка PPPoE в Ubuntu, когда ADSL-модем настроен как bridge

Оставим в стороне вопросы типа «А не проще ли было настроить модем роутером и не мучиться?». Так было нужно. Цель — средствами консоли (ну не нравится мне network-manager!!!) настроить PPPoE соединение, автоматически стартующее при загрузке компьютера.

Настройка производилась по статье с сайта официальной документации Ubuntu. Стаья расположена по адресу:

https://help.ubuntu.com/community/ADSLPPPoE

Вводная — модем, как и сказано в заголовке статьи, настроен в режиме bridge, в него вписаны значения VPI и VCI, выданные провайдером. Модем подключен кабелем в сетевую плату eth0 компьютера, на котором установлен дистрибутив Ubuntu desktop 12.04.

Итак, запускаем терминал, и в нем вводим команду:

sudo pppoeconf

Вариантов дальнейшего развития может быть два. Первый — неудовлетворительный: пакет pppoeconf не установлен. В таком случае его можно например, поискать и скачать с сайта пакетов Ubuntu  и установить «руками». Также, пакет может присутствовать на том диске, с которого вы устанавливали Ubuntu. Добавьте его в число источников ПО и затем выполните установку.

Второй вариант — благоприятный, пакет pppoeconf  установлен. В таком случае запустится программа настройки PPPoE подключения. Самый первый скрин работы программы в данной заметке не приведен — в нем программа проводит сканирование сетевых адаптеров на предмет наличия модемов. ВАЖНО: на момент запуска программы модем должен быть (а) включен, (б) подключен к линии и (в) подключен к компьютеру! Иначе, программа сообщит, что модемов не найдено и завершит свою работу.

После того, как модем найден, программа выдаст предупредительное сообщение:

С учетом того, что мы все-таки пришли сюда, чтобы настроить новое (а может быть и перенастроить старое) подключение, СОГЛАШАЕМСЯ — щелкаем «ДА».

Следующее сообщение программы поинтересуется, хотим ли мы использовать некие предлагаемые ей дополнительные опции подключения:

В моем случае (равно как и в 99% остальных), эти дополнительные опции будут вовсе не лишними. Желающие подробнее узнать о сути этих параметров могут (как и предлагается системой) почитать man (8) pppd, ну или ознакомиться с его переводом на русский язык в интернете. Соглашаемся, щелкаем «ДА» и перходим к следующему шагу.

Программа предложит вам ввести имя пользователя:

В этом поле вам нужно ввести тот логин (имя пользователя), который вам выдал провайдер. Будьте внимательны, не допускайте ошибок. Также, дополнительно обращаю внимание ваше внимание на регистр букв, «User» и «user» — это РАЗНЫЕ логины!

Следующий пункт — ввод пароля:

Введите пароль вашей учетной записи, который вам выдал провайдер. Опять же, снова напоминаю и о внимательности, и о регистре букв!

Следующий вопрос — об автоматическом добавлении адресов  DNS-серверов провайдера в список к «уже имеющимся в системе», после того, как устанавливается подключение:

СОГЛАШАЕМСЯ! Без этого мы рискуем получить неработающую систему. (Или вы наизусть помните все IP-адреса интересующих вас серверов? 🙂 )…

Следующее диалоговое окно программы предложит установить для ADSL-подключения  размер MTU равным 1452 байтам:

Тоже соглашаемся. Программа сообщит, что все параметры, необходимые для подключения настроены, и поинтересуется, хотите ли вы, чтобы ADSL-подключение устанавливалось автоматически при загрузке компьютера:

Отвечаем «ДА», но при этом пусть вам «на ум пойдет», что на самом деле этого БЕЗ ДОПОЛНИТЕЛЬНЫХ «телодвижений», увы происходить не будет! Об этом также сказано и в той статье с сайта Ubuntu, ссылку на которую я приводил выше. Переживать не стоит, ниже мы еще «поколдуем», чтобы впоследствии все было ОК.

В следующем окне программа предложит установить соединение прямо сейчас:

Выбираем «ДА»,программа выполнит процедуру подключения. Данное меню также предлагает вам запомнить две команды: pon dsl-provider и poff. Первая из них позволит вам вручную в консоли подключаться к провайдеру. Вторая — отключаться.

Должен дополнительно заметить, что если ранее вы ошиблись при вводе логина и/или пароля, то подключение произойдет как и положено (все будет выглядеть отлично!), но при этом доступ в интернет будет отсутствовать. По крайней мере, у меня именно так и было (я не доглядел в пароле, что одна из букв была введена мной не в том регистре, и в итоге лишние полчаса был вынужден угадывать — «как так, подключение ОК, а интернета нету?!»)…

Последний скрин — сообщение об успешном подключении:

На этом работа программы pppoeconf завершена. С данного скрина вам стоит запомнить команду plog, выводящую лог последнего подключения (надеюсь, команда ifconfig вам итак уже была известна)…

Проверить, что мы успешно подключились, в консоли проще всего такой командой:

ping -c5 google.com

Она позволяет нам сразу увидеть, что все прекрасно — служба DNS определит IP-адрес  для указанного сервера, и начнет пинговать его. Если все Ok, то пинг достигнет цели, и ваш компьютер получит ответы в том же самом количестве.

Автозапуск при загрузке

Как уже было сказано выше, несмотря на то, что мы согласились с тем, что pppoeconf настроит автоматическое соединение с провайдером во время загрузки компьютера, в реальности этого увы не происходит.

Не «рассусоливая» понапрасну много текста, предлагаю просто выполнить следующее. Отредактируйте файл /etc/network/interfaces. Для этого введите команду:

sudo nano /etc/network/interfaces

И приведите файл к следующему содержанию:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet ppp
pre-up iptables-restore < /etc/network/firewall.rules
pre-up /sbin/ip link set dev eth0 up
post-down /sbin/ip link set dev eth0 down

auto dsl-provider
iface dsl-provider inet ppp
pre-up /sbin/ifconfig eth0 up # line maintained by pppoeconf
provider dsl-provider

Данный набор инструкций предполагает, что модем подключен к комьютеру через сетевой адаптер eth0. Если в вашем случае номер адаптера иной, укажите его вместо eth0 во всех строках, где он встречается.

Обращаю внимание на строку выделенную цветом — это необязательная команда. Она дословно означает следующее: перед тем как запустить интерфейс eth0 программа iptables-restore должна загрузить правила файервола из файла /etc/network/firewall.rules. В вашем случае она может быть и излишней, поэтому можете ее и не вписывать в файл /etc/network/interfaces.

Чтобы выйти из редактора, нажмите Ctrl + X, и в ответ на запрос согласитесь с сохранением изменений.

Перезагрузите ваш компьютер.  Время загрузки увеличится. Сначала система выведет такой скрин:

Потом такой:

И лишь потом загрузится. Но по окончании загрузки у вас теперь должно быть уже активно подключение, и компьютер должен иметь доступ в интернет.

Ну и напоследок…

Chillispot и PPPoE

Собственно, все эти манипуляции я проделывал на компьютере, который выступал в роли хотспота. И доступ в интернет предоставлял «тот самый» Chillispot.

Нюансов в настройке в таком случае совсем не много. Во первых, в правилах файервола в качестве WAN-интерфейса нужно указать ppp0, вот так (выделено красным):

EXTIF="ppp0"
INTIF="eth1"

А во вторых, на всякий случай, стоит указать в настройках Chillispot-а (файл /etc/chilli.conf) адрес второго сервера DNS таким образом:

dns2 8.8.8.8

Суть данной перестраховки в том, что «может так статься», что на момент запуска Chillispot-а ADSL-соединение еще не будет установлено, и у компьютера еще не будет адреса(ов) сервера(ов) DNS. В итоге, в работе Chillispot могут наблюдаться проблемы. А так, мы принудительно подставляем вторым адрес одного из публичных  DNS серверов Google, который подстрахует, если вдруг будет недоступен DNS сервер провайдера…

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. Ну вот, опять до вирусов не добрались…

300-тысячная статейка про интернет шлюз

Вводная

Я понимаю, что таких (подобных) инструкций в интернете — целое море. Но вот пришел мой черед искать информацию по данному вопросу — и все-равно немало времени убил на поиски. В принципе, в этой заметке я постараюсь не сильно дублировать информацию, но по максимуму выложу ссылки, которые помогли мне…

Началась моя эпопея со звонка одного знакомого: «А вот можно проверять на вирусы интернет-трафик всего офиса?» Причем, вопрошавший хотел, чтобы эта функция была возложена на какой-нибудь «трехкопеечный» SOHO-роутер, которому родную прошивку заменили на какую-нибудь альтернативную. Пришлось его разочаровать, т.к. те «коробочки» на использование которых собственно и рассчитывал мой знакомый, с такой задачей вряд-ли смогли бы справиться ввиду своей «хилости». Из недорогих (по меркам цен для подобного оборудования) решений были найдены шлюзы серии NetDefend фирмы D-Link. Цена эта, правда, оказалась сопоставима с ценой недорогого нового офисного компьютера (самого системного блока без монитора и манипуляторов). В итоге знакомый сказал «дорого» (и в последствии пропал с горизонта и вовсе), а я решил поискать информацию о том, как сделать это с помощью обычного компьютера, использующего Linux в качестве ОС, и open-source ПО для выполнения поставленных задач.  По мере чтения всего того, что предлагал Google, вырисовывались даже гораздо более интересные перспективы, чем изначальная задача. В итоге и родился этот «сборник цитат», который Вы сейчас и читаете.

Процесс выполнения данной задачи можно разделить на несколько этапов.  Заканчиваю рассусоливать и перехожу к первому:

1. Просто шлюз

«Просто шлюз» нам нужен, чтобы все пользователи офиса (или, допустим, «другие домашние компьютеры») могли легко подключаться к нему и получить доступ в интернет. Кстати, эта первая часть заметки будет очень полезна тем, кто ищет ответ на вопросы типа «Как расшарить интернет под Linux-ом?» и тому подобные.

Итак, у меня был компьютер, работающий под управлением Linux (дистрибутив Ubuntu 9.04). Компьютер был как раз класса того самого «недорогого офисного». Причем справится с задачей может даже б/у компьютер, объявлений о продаже которых предостаточно в любой местной газете. Главное отличие — в нем было установлено две сетевые платы. Первая сетевая плата называлась eth0, и через нее компьютер был подключен в интернет. Вопрос подключения к интернету тут мы рассматривать не будем. Единственное, что примем к сведению, так это адрес платы eth0 — 192.168.1.2 и адрес шлюза, к которому она подключена — 192.168.1.1. Ко второй сетевой плате — она называлась eth1 — я планировал подключать пользователей офиса. Причем, сделать это подключение для пользователей максимально простым. С этой целью на интерфейсе я поднял DHCP-сервер.

Сначала я выставил сетевой плате eth1 фиксированный адрес. Причем, выбрать его нужно таким, чтобы он не попадал в диапазон адресов подсети, к которой относится сетевая плата eth0 (а там, как мы помним, у меня 192.168.1.ххх). В итоге я решил, что пускай у моей платы eth1 адрес будет 192.168.100.1. Чтобы назначить ей такой адрес, я отредактировал файл /etc/network/interfaces, для чего ввел команду:

sudo nano /etc/network/interfaces

В файле этом я дописал следующие строки:

auto eth1
iface eth1 inet static
        address 192.168.100.1
        netmask 255.255.255.0

После чего вышел из редактора, нажав «Ctrl + X». На вопрос о сохранении изменений ответил «Да» (кнопка «Y»). И подтвердил имя файла, не меняя его (кнопка «Enter»). Введенные строки определяют следующее:

  • Интерфейс eth1 автоматически стартует при загрузке (строка «auto eth1«);
  • У интерфейса eth1 будет статический (т.е. фиксированный) адрес (слово «static«)
  • У интерфейса eth1 будет адрес 192.168.100.1
  • Маска подсети на интерфейсе eth1 будет 255.255.255.0

После того, как изменения внесены, нужно либо перезагрузить компьютер, либо просто перезапустить поддержку сети. Лучше второе. Поэтому, просто перезапускаем сеть командой:

sudo /etc/init.d/networking restart

Теперь пришло время установить DHCP-сервер и запустить его на интерфейсе eth1. Для этого вводим команду:

sudo apt-get install dnsmasq

(Подразумевается, что через интерфейс eth0 наш компьютер уже подключен к интернету, и репозитории настроены). По этой команде программа dnsmasq (а это и есть тот самый DHCP-сервер) была загружена и установлена на мой компьютер. Мне оставалось лишь подстроить ее параметры под мои нужды. Для этого я слегка подредактировал файл настроек указанной программы (/etc/dnsmasq.conf), введя команду:

sudo nano /etc/dnsmasq.conf

Файл сам по себе достаточно большой, и настроить в нем можно «ну очень много всего». Для моего простейшего случая оказалось достаточным указать всего два параметра. Первый делом я указал тот интерфейс, на котором сервер собственно и будет работать (слушать DHCP и DNS запросы). Параметр указывается одной простой и доходчивой строкой:

interface=eth1

Второй параметр определяет диапазон адресов, присваиваемых пользователям при их подключении к серверу. В моем случае я ввел следующую строку:

dhcp-range=192.168.100.50,192.168.100.250,12h

Опять же, выходим из редактора и сохраняем изменения.

Эти два указанных мной параметра определили следующее: клиентам, подключающимся к сетевой плате eth1, автоматически будут присваиваться адреса в диапазоне от 192.168.100.50 до 168.100.250, и «срок аренды» составит 12 часов. Обратите внимание, что диапазон выдаваемых адресов, должен принадлежать той подсети, которую мы указали для сетевой платы eth1.

Два слова про «срок аренды». Параметр этот опциональный и указывает — в течении какого времени сервер помнит, что «такой-то» адрес, который был автоматически присвоен «такому-то» клиенту (компьютеру), все еще «принадлежит» ему. Таким образом сохраняется возможность, что один и тот же компьютер будет по возможности получать один и тот же адрес. (Если вдруг это кому-то важно 🙂 )…

Все остальные настройки в файле закомментированы (т.е. либо не используются, либо, там где это необходимо, используются «умолчательные» значения). Они позволяют более тонко настроить сервер под собственные нужды. В том числе например, ЖЕСТКО указать присвоение одному и тому же клиенту всегда одного и того же адреса, а также многое другое. С другой стороны, все перечисленные в файле параметры хорошо прокомментированы (на английском, естественно), на тот случай, если Вы решите настроить сервер именно «более тонко»…

Но вернемся к нашему серверу. После того, как настройка его завершена, перезапускаем сам сервер:

sudo /etc/init.d/dnsmasq restart

С этого момента можно подключать клиентов (компьютеры пользователей) к сетевой плате eth1. Одного (например, второй компьютер в доме) можно подключить и напрямую, а если нескольких, то тогда уже через обычный hub или switch с требуемым числом портов. На компьютерах клиентов, работающих в ОС Windows, в свойствах сетевой платы для протокола TCP/IP нужно указать «Получить IP-адрес автоматически» и «Получить адрес DNS-сервера автоматически». В таком случае компьютер пользователя при подключению к нашему шлюзу будет автоматом настраиваться на то, что основным шлюзом у него будет 192.168.100.1, маска подсети — 255.255.255.0, и адрес ему будет присваиваться один из того диапазона, который мы указали при настройке dnsmasq (то есть, от 192.168.100.50 и до 168.100.250). Для компьютеров клиентов, работающих под управлением ОС Linux, скорее всего вообще не нужно будет ничего настраивать — в большинстве дистрибутивов после установки DHCP-клиент стартует автоматом…

Итак, наши пользователи на автомате успешно подключаются к шлюзу и получают адреса. Все хорошо?! На первый взгляд — да. Первые пару минут… Но потом оказывается, что до полного счастья им не хватает …доступа в интернет! А мы то ведь шлюз делали…

На самом деле, для того, чтобы выпустить наших пользователей в интернет, осталось всего лишь включить функцию NAT (преобразования сетевых адресов). Для этого создадим новый файл настроек файервола, в котором на данном этапе будет всего одна единственная — включить NAT. Чтобы создать новый файл правил (я назвал его fw.rules и разместил в папке /etc/network, а Вы можете придумать и другое имя), введем следующую команду:

sudo touch /etc/network/fw.rules

Теперь откроем новый файл в редакторе:

sudo nano /etc/network/fw.rules

И впишем в него следующее:

        #!/bin/sh
        INET="eth1"
        INETIP="192.168.1.1"

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

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

        iptables -t nat -A POSTROUTING -o $INET -j SNAT --to-source $INETIP
        echo "1" > /proc/sys/net/ipv4/ip_forward

Сохраняем изменения, выходим из редактора. Из того, на что стоит обратить внимание:

  • Строка INET=»eth1″ указывает на сетевой интерфейс (плату) к которой подключены пользователи, которым мы будем предоставлять доступ в интернет.
  • Строка INETIP=»192.168.1.1″ указывает на шлюз, где у нас этот самый интернет и живет (помните, в самом начале я упоминал о том, что «…мой компьютер к интернету подключен сетевой платой eth0 через шлюз 192.168.1.1». Так вот это он и есть….

ПРИМЕЧАНИЕ: Данный файл должен выглядеть несколько иначе, если ваш «шлюз» использует не статический IP-адрес, а получает его динамически по DHCP. В этом случае вам нужно вместо функции SNAT использовать MASQUERADE. В итоге строка

        iptables -t nat -A POSTROUTING -o $INET -j SNAT --to-source $INETIP

должна быть заменена на такую

        iptables -t nat -A POSTROUTING -o $INET -j MASQUERADE

а строку

        INETIP="192.168.1.1"

из скрипта можно удалить вовсе.

Собственно, созданный нами только что файл является набором команд конфигурирования файервола. А раз это набор команд, то его нужно исполнять. По этому, делаем файл исполняемым:

sudo chmod +x /etc/network/fw.rules

…и запускаем его:

sudo /etc/network/fw.rules

Все! Вот теперь наши пользователи наконец-то получили то, чего так желали — доступ в интернет. Осталось лишь сделать так, чтобы наши «правила файервола» запускались автоматически каждый раз при загрузке компьютера. Для этого еще раз отредактируем файл /etc/network/interfaces:

sudo nano /etc/network/interfaces

И впишем в него еще одну строку. В приведенном ниже примере она выделена красным:

auto eth1
iface eth1 inet static
pre-up /etc/network/fw.rules
        address 192.168.100.1
        netmask 255.255.255.0

Сохраняем изменения и выходим из редактора.

В итоге мы получили самый простой шлюз, который при подключении к нему пользователей автоматом присваивает им IP-адреса и «выпускает» их в интернет. Таким образом, первая часть «глобального плана» выполнена. Ах да, я же не сказал — что выполнено и зачем? Помните еще — в самом начале знакомый мой хотел, чтоб шлюз проверял трафик на вирусы? Так вот сам шлюз мы уже сделали. Пользователи из локальной сети к нему подключаются, получают автоматом (по DHCP) все настройки и затем — доступ в интернет. Что нам это дало? Весь трафик нашей локальной сети теперь идет через шлюз, и проверять на вирусы достаточно только трафик самого шлюза, а не каждого клиентского компьютера в отдельности. О самой «борьбе с вирусами» — будет далее, а пока что еще немного ссылок про шлюзы:

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

…Ну а к вирусам мы еще вернемся.

И следующим шагом на этом пути будет установка и запуск прокси-сервера.