Оглавление
Настройка основных сервисов
После загрузки войдем в систему под именем суперпользователя root. Выполним некоторые настройки, после которых наш сервер уже будет пригоден к использованию (хотя намеченные задачи выполнять еще не будет). Во-первых, добьемся возможности вводить с консоли русские буквы. Для этого введем команду:
# pw usermod root -L russian
Естественно, чтобы увидеть результат изменения параметров входа пользователя в систему, нужно из нее выйти:
# logout
…и вновь войдем в нее под именем root.
Готово. Теперь мы можем писать по-русски. И сразу небольшой сюрприз для тех, кто привык к графическим интерфейсам ОС. Переключение на русскую раскладку клавиатуры происходит не по Alt+Shift, как в Windows, и не по Command+Space, как в Mac OS X, а с помощью Caps Lock. Все равно эта клавиша по назначению используется весьма нечасто (а заодно появляется индикатор включенной раскладки).
Утилита pw предназначена для управления пользователями и группами. В данном случае мы меняем у пользователя (user-mod[ify]) с именем root класс входа (L[ogin class]) на russian, указывая таким образом, что суперпользователь у нас предпочитает работать с русским языком. Для любопытныхзнательных подскажу, что классы описываются в файле /etc/login.conf.
Еще мы можем отключить вывод сообщений на консоль root’а. Когда система будет работать «на автопилоте» без монитора, они станут совершенно бесполезными. Если что понадобится — можно прочесть в соответствующем логе (log-file — файл протокола). Естественно, отключать или не отключать и отключать сразу сейчас или по окончании процесса настройки — дело ваших личных предпочтений.
# ee /etc/syslog.conf
В этом файле нужно закомментировать (т.е. поставить в самом ее начале знак #) всего одну строку:
*.err;kern.warning;auth.notice;mail.crit /dev/console
Кстати, обратите внимание: подсказки и прочие элементы интерфейса редактора ee теперь написаны по-русски.
Следующий наш шаг — перенос временного каталога /tmp. Изначально он находится в корневой файловой системе, однако под эту систему мы отвели довольно маленький раздел диска, где при определенном стечении обстоятельств места может и не хватить. Поэтому создадим каталог /var/tmp (помните? /var у нас сделан отдельным разделом). Укажем на него, создав в корневой системе символическую ссылку вместо предварительно удаленного каталога:
Использованные ключи команды удаления rm обозначают, что мы хотим удалить каталог и все его содержимое (файлы и каталоги) рекурсивно. Вообще к команде удаления в Unix-подобных системах нужно подходить с большой внимательностью. Если не поставить ключ -i, она всю свою работу сделает абсолютно «молча» (никаких Вам «Вы действительно хотите отправить этот файл в Корзину? Вы действительно хотите почистить Корзину?»; сразу — и навсегда).
# rm -R /tmp
# ln -s /var/tmp /tmp
SSH
Обычно компьютер, выполняющий ответственные функции, прячут подальше от «шаловливых ручек», а зачастую используют без монитора и клавиатуры. Однако при этом тут же возникает проблема, как им управлять. Что ж, обеспечим удаленный доступ с помощью SSH (Secure SHell — протокол, специально предназначенный для безопасного — т.е. с использованием шифрования передающихся данных — управления удаленным компьютером). Клиенты SSH стандартно входят во все Unix/Linux (включая Mac OS X), есть несколько таких программ и для Windows. На сервере же все необходимые функции обеспечивает демон sshd.
Демон (англ. daemon) — в системах Unix (Linux) — программа, работающая в фоновом режиме без прямого взаимодействия с пользователем.
Откроем конфигурационный файл sshd, используя уже знакомый редактор ee:
# ee /etc/ssh/sshd_config
Раскомментируем строки (т.е. удалим значок # в начале каждой из них):
Port 22 Protocol 2
Чтобы была возможность подключаться, используя аутентификацию по паролю, изменяем строку
# PasswordAuthentication no
на
PasswordAuthentication yes
Выходим из редактора с сохранением изменений и перезапускаем sshd:
# killall -HUP sshd
До сих пор мы работали от имени суперпользователя, а это, вообще говоря, нехорошо. Подключиться же к удаленному компьютеру, используя учетную запись root, вообще не удастся. Поэтому сейчас необходимо создать пользователя административной группы (она называется wheel). Такой пользователь может с помощью команды su временно «становится рутом». Допустим, его имя — admin. В этом случае команда будет выглядеть так:
# pw useradd admin -c "Admin" -L russian -g wheel -d /home/admin -s /bin/csh
Здесь: «Admin» — «полное имя» пользователя; wheel — группа; /home/admin — домашний каталог; /bin/csh — командный процессор (мне нравится csh, но можно использовать и другой).
Теперь зададим пароль для вновь созданного пользователя (как обычно, его придется набрать дважды):
# passwd admin
Наконец, создадим домашний каталог:
# mkdir -p /usr/home/admin
# ln -s /usr/home /home
# chown -R admin /home/admin
NTP
Запустим некоторые полезные для локальной сети сервисы. Во-первых, сделаем так, чтобы только наш сервер-шлюз синхронизировал часы по внешнему серверу NTP (Network Time Protocol), а все машины локалки обращались бы уже к нему. Для этого мы настроим демон ntpd, создав файл /etc/ntp.conf следующего вида:
server europe.pool.ntp.org server europe.pool.ntp.org server europe.pool.ntp.org server europe.pool.ntp.org server europe.pool.ntp.org driftfile /var/db/ntp.drift restrict 10.0.1.0 mask 255.255.255.0 nomodify notrap
Естественно, в параметре restrict указываем адрес/маску локальной сети (мы же не собираемся обслуживать что-то вне ее!).
Повторенная несколько раз строка «server europe.pool.ntp.org»— не ошибка, а указание на пул серверов времени (т.е. нескольких «параллельно используемых» серверов).
Параметр driftfile указывает файл, где хранится смещение частоты системных часов. Знание его позволяет компьютеру поддерживать достаточно высокую точность, даже если он оказался временно отключенным от Интернет. Этот файл необходимо создать:
# touch /var/db/ntp.drift
Теперь сделаем так, чтобы программы для синхронизации часов запускались при загрузке компьютера. Для этого добавим к файлу /etc/rc.conf следующие строки:
# ----------- Network Time Protocol -------- ntpdate_enable="YES" ntpdate_flags="-b europe.pool.ntp.org europe.pool.ntp.org europe.pool.ntp.org" ntpd_enable="YES" ntpd_flags="-c /etc/ntp.conf -l /var/log/ntpd.log -p /var/run/ntpd.pid"
DNS
Следующая служба, которую полезно иметь внутри локальной сети — DNS. Она будет работать в режиме кэширующего DNS-сервера, т.е. однажды запрошенное доменное имя в дальнейшем будет преобразовываться в IP-адрес уже без обращения к внешним серверам. Нам необходимо сделать две вещи. Во-первых, создать файл локальной зоны. В этом поможет уже готовый сценарий командного процессора:
# sh /var/named/etc/namedb/make-localhost
Во-вторых, настроим собственно DNS-сервер. Для этого служит файл /var/named/etc/namedb/named.conf, он должен выглядеть примерно так:
options {
directory "/etc/namedb";
pid-file "/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
forward first;
forwarders {
212.45.0.3; // DNS-сервер провайдера
212.45.2.5; // DNS-сервер провайдера
208.67.222.222; // DNS-сервер OpenDNS (на всякий случай)
208.67.220.220; // DNS-сервер OpenDNS (на всякий случай)
};
query-source address * port 53; // поскольку у нас есть proxy
version "DNS";
};
zone "." {
type hint;
file "named.root";
};
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "master/localhost.rev";
};
// RFC 3152
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"
{
type master;
file "master/localhost-v6.rev";
};
Пересборка ядра. Firewall. NAT
Следующий важный этап подготовки нашей системы — включение firewall и NAT. Для этого придется пересобрать ядро ОС. Звучит страшно, но, на самом деле, в мире Unix-подобных ОС это совершенно обычная операция. При установке мы получаем некое универсальное ядро, способное загрузиться практически на любой возможной конфигурации. Однако, с одной стороны, там много избыточного, а с другой стороны, некоторые функций, необходимые в конкретной ситуации, отключены.
Чтобы настроить систему под наши, вполне определенные, задачи, следует «построить» новое ядро, которое и будет в дальнейшем использоваться вместо GENERIC. Во-первых, сделаем копию конфигурационного файла GENERIC и назовем его, к примеру, MyKern:
# cd /usr/src/sys/i386/conf
# cp GENERIC MyKern
В файл MyKern вносим необходимые изменения. Во-первых, изменяем строку
ident GENERIC
на
ident MyKern
Во-вторых, добавим строку
maxusers 64
(это условное значение, по которому рассчитываются внутренние таблицы; вообще говоря, можно использовать значение «0», положившись на автоматически рассчитываемые параметры).
Кроме того, нам потребуется указать следующие опции (из-за которых все и затевалось):
options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL_FORWARD options IPDIVERT
При желании можно попробовать несколько оптимизировать ядро под свое «железо», закомментировав часть строк файла (что именно, на мой взляд, там достаточно понятно, а если непонятно — имеется документация).
Теперь компилируем новое ядро:
# config MyKern
# cd ../compile/MyKern
# make depend
Теперь можно выпить кофе… или сходить пообедать 😉 Процесс достаточно долгий. По окончании, если не было сообщений об ошибках (а их, если все вписано правильно, и не должно быть), даем следующую команду:
# make
Можно снова заняться каким-нибудь другим делом — этот этап тоже долгий. Но зато, когда он закончится (без ошибок — их опять-таки появиться не должно, но… всякое бывает), можно будет устанавливать новое ядро:
# make install
Ну, вот. Поддержка файрвола в ядре есть. А для его настройки используется файл /etc/rc.firewall. Создадим файл с нужными нам правилами, предварительно переименовав имеющийся (чтобы сохранить его на всякий случай):
# mv /etc/rc.firewall /etc/rc.firewall.default
# ee /etc/rc.firewall
#! /bin/sh
################### rc.firewall ###################
fwcmd="/sbin/ipfw"
uports="1025-65535"
services="smtp,pop3,imap,http,https,domain,ssh,ftp"
echo -n "Starting firewall..."
${fwcmd} -f flush
####################################################
# внешний сетевой интерфейс
oif="de0"
# нач. адрес - 192.168.4.129, маска - 255.255.255.192
onet="192.168.4.128/26"
# IP-адрес внешнего интерфейса
oip="192.168.4.131"
# внутренний сетевой интерфейс
iif="xl0"
# локальная сеть: 10.0.1.1-10.0.1.254, маска - 255.255.255.0
inet="10.0.1.0/24"
# IP-адрес внутреннего интерфейса
iip="10.0.1.1"
####################################################
${fwcmd} add pass all from any to any via lo0
${fwcmd} add deny all from any to 127.0.0.0/8
${fwcmd} add deny ip from 127.0.0.0/8 to any in via ${oif}
#
# === Stop private networks from outside ===
#
# У нас несколько необычная конфигурация: «внешняя»
# сеть является приватной сетью класса C.
# В нормальной ситуации следующие две строки нужно
# раскомментировать:
# ${fwcmd} add deny ip from 192.168.0.0/16 to any in via ${oif}
# ${fwcmd} add deny all from any to 192.168.0.0/16 out via ${oif}
#
${fwcmd} add deny ip from 172.16.0.0/12 to any in via ${oif}
${fwcmd} add deny all from any to 172.16.0.0/12 out via ${oif}
${fwcmd} add deny ip from 10.0.0.0/8 to any in via ${oif}
${fwcmd} add deny all from any to 10.0.0.0/8 out via ${oif}
#
#
# Следующие строки нам потребуются после установки Squid,
# поэтому пока их закомментируем:
# ============== Transparent Proxy ==================
# ${fwcmd} add allow all from ${inet} to 10.0.1.1 80 in via ${iif}
# ${fwcmd} add fwd 127.0.0.1,3128 tcp from ${inet} to any 80,8080 in via ${iif}
# ============ End Transparent Proxy ===============
#
#
#
# === filter only external traffic ===
${fwcmd} add allow all from ${inet} to any in via ${iif}
${fwcmd} add allow all from any to ${inet} out via ${iif}
#
# === NAT ===
${fwcmd} add divert natd all from ${inet} to any out via ${oif}
${fwcmd} add divert natd all from any to ${oip} in via ${oif}
#
#
###
${fwcmd} add pass tcp from any to any established
${fwcmd} add pass ip from ${oip} to any out xmit ${oif}
#
# --- DNS ---
${fwcmd} add pass udp from ${oip} ${uports} to any domain out xmit ${oif}
${fwcmd} add pass udp from any domain to ${oip} ${uports} in recv ${oif}
${fwcmd} add pass udp from any domain to ${inet} ${uports} in recv ${oif}
${fwcmd} add pass udp from ${oip} to any 53 keep-state
${fwcmd} add pass udp from any to ${oip} 53 keep-state
${fwcmd} add pass udp from ${iip} to ${inet}:${imask} 53 keep-state
${fwcmd} add pass udp from ${inet}:${imask} to ${iip} 53 keep-state
${fwcmd} add pass udp from ${oip} to any 123 keep-state
${fwcmd} add pass udp from any 123 to ${oip} keep-state
${fwcmd} add pass udp from ${iip} 123 to ${inet}:${imask} keep-state
${fwcmd} add pass udp from ${inet}:${imask} to ${iip} 123 keep-state
#
# --- ICMP (ping etc) ---
#${fwcmd} add deny icmp from any to any frag
${fwcmd} add allow icmp from any to any
#
#${fwcmd} add allow icmp from any to me icmptypes 0,3,4,11,12 in
#${fwcmd} add allow icmp from any to ${inet} icmptypes 0,3,4,11,12 in recv ${oif
}
#${fwcmd} add allow icmp from me to any icmptypes 3,8,12 out
###
${fwcmd} add pass tcp from ${oip} ${uports} to any ${services} out xmit ${oif}
###
${fwcmd} add deny log logamount 700 tcp from any to ${oip} in recv ${oif} setup
${fwcmd} add deny all from any to any
###
echo "Done!"
#
############ END #############
Осталось указать, что при запуске системы следует включать firewall и NAT. Как вы уже, вероятно, поняли, для этого нужно дописать соответствующие строки в файл /etc/rc.conf:
firewall_enable="YES" # при необходимости/желании можно «открыть» # firewall_type="OPEN" # firewall, раскомментировав эту строчку firewall_script="/etc/rc.firewall" # и закомментировав эту natd_enable="YES" natd_interface="de0"
Итак, теперь торжественный момент. Перезагружаем систему:
# shutdown -r now
А теперь пробуем подсоединиться к своему серверу удаленно — с другого компьютера сети. Если мы используем Mac OS X или Linux, все необходимое у нас уже есть, достаточно просто открыть Терминал (на Маке лучше воспользоваться не стандартным, а бесплатной утилитой iTerm — она гораздо легче настраивается на корректную работу с русскими буквами) и набрать
$ ssh <имя_пользователя>@<IP_сервера>
В нашем случае:
$ ssh admin@10.0.1.1
Затем в ответ на появившийся запрос укажем пароль.
Пользователям Windows придется установить дополнительную утилиту — SSH-клиент (например, Telneat или PuTTY; первый из них предпочитает О.Островерх, второй — я)
Заметьте, что для выполнения большинства административных задач необходимы права суперпользователя. Чтобы «стать root’ом», следует набрать короткую команду
$ su
Естественно, компьютер затребует при этом ввод пароля суперпользователя.
Постоянно работать от имени root’а, как уже было замечено, неправильно. Поэтому, выполнив задачи, для которых без его прав не обойтись, будем снова «становиться самими собой»:
# exit
Для окончания удаленного сеанса будем использовать команду
$ logout
Для проверки работоспособности шлюза воспользуемся командой ping (результат наверняка не совпадет с моим, главное, чтобы он был):
$ ping -c 5 www.yandex.ru PING www.yandex.ru (77.88.21.11): 56 data bytes 64 bytes from 77.88.21.11: icmp_seq=0 ttl=56 time=13.068 ms 64 bytes from 77.88.21.11: icmp_seq=1 ttl=56 time=18.085 ms 64 bytes from 77.88.21.11: icmp_seq=2 ttl=56 time=13.922 ms 64 bytes from 77.88.21.11: icmp_seq=3 ttl=56 time=21.465 ms 64 bytes from 77.88.21.11: icmp_seq=4 ttl=56 time=26.112 ms --- www.yandex.ru ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 13.068/18.530/26.112/4.845 ms
(Если что-то не заладилось, пингуем компьютер локальной сети, потом шлюз провайдера…)
Следующий этап проверки — такие же пинги, но уже с локального компьютера (в Mac OS X/Linux из другого окна Терминала; в Windows — из командной строки DOS). Если в результате получен примерно такой результат, как показано ниже, наш шлюз успешно настроен и уже может быть запущен в работу.
$ ping -c 5 www.ru PING www.ru (194.87.0.50): 56 data bytes 64 bytes from 194.87.0.50: icmp_seq=0 ttl=55 time=11.073 ms 64 bytes from 194.87.0.50: icmp_seq=1 ttl=55 time=17.107 ms 64 bytes from 194.87.0.50: icmp_seq=2 ttl=55 time=13.78 ms 64 bytes from 194.87.0.50: icmp_seq=3 ttl=55 time=11.197 ms 64 bytes from 194.87.0.50: icmp_seq=4 ttl=55 time=23.407 ms --- www.ru ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 11.073/15.312/23.407 ms
