Конфигурируем Linux сервер

В интернет через модем.

Выход в интернет

Всё большее распространение получает доступ в интернет по выделенной линии. Часто это ADSL. По выделенной линии всегда организуют коллективный доступ, со своего рабочего места каждый может получить почту и пройтись по WWW. Конечно выделенная линия - это замечательно. Пока не всем организациям это доступно, а иногда и экономически не целесообразно.

Альтернативой может служить, выход в интернет по коммутируемой линии через модем. Для этого в офисе назначают одного или несколько человек для работы с интернет. Этот человек получает всю почту, выходит в WWW и т.д. Он несёт ответственность за счета, которые приходят за пользование сетью, держит в секрете сведения об учётной записи у провайдера. Он сам должен сортировать почту, иногда этот человек ошибается, что-то нужное отправляет в корзину. Лучше если каждый из пользователей сам получал свою почту.

Серединный путь - это коллективный доступ по коммутируемой линии. Имеется программное обеспечение, которое создаёт виртуальный канал связи - соединение по запросу. Для этого вы устанавливаете в сети отдельный компьютер, который является шлюзом в интернет. При попытках соединения с внешней сетью, устанавливается связь через модем по TCP/IP, когда активность прекращается соединение закрывается по тайм-ауту. Такую виртуальную линию можно эффективно использовать для доступа к службе WWW.

На машине-шлюзе в локальной сети устанавливается программа почтового сервера. Этот сервер собирает почту от локальных пользователей, периодически сбрасывает её на сервер провайдера, одновременно забирает почту для локальных пользователей и хранит её у себя. Образуется виртуальный доступ в интернет по протоколу SMTP и POP. У каждого пользователя может быть свой почтовый ящик, содержимое которого синхронизируется с почтовым ящиком на сервере провайдера.

А для работы в интернет по HTTP и FTP протоколу, на машине-шлюзе уставливается кэширующий прокси-сервер, он принимает запросы от клиентов локальной сети, проводит аутентификацию, ведёт статистику.

Я читал восторженные отклики поклонников Windows об одной из таких платных программ. Предлагаю реализaцию подобного сервера на Linux. Всё сам опробовал на ASP LINUX 7.3.

Соединение с ИНТЕРНЕТ из Linux.

В ASP Linux имеется программный пакет ppp-2.4.1-3.asp предназначенный для организации входящих и исходящих соединений по протоколу PPP. С его помощью можно организовать как сервер удалённого доступа, так и клиента. Наличие пакета можно проверить командой с правами root:

rpm -qa / grep "ppp"

Ядро системы должно быть скомпиллировано с поддержкой протокола PPP. В ядре фирменного дистрибутива такая поддержка имеется.

Провайдер может использовать два основных метода аутентификации: "ручная" аутентификация и с использованием PAP или CHAP. Ручная аутентификация устарела, она редко используется. Хотя во многих руководствах, которые мне попадались, приведены примеры подключения к провайдерам, которые используют "ручную" аутентификацию. Достаточно сказать, что в составе документации к пакету ppp, приведён пример сценария подключения такого типа. Аутентификация названа ручной весьма условно, всё подключение можно автоматизировать. С начала, используя терминальную программу, подключаетесь к провайдеру как удалённый терминал. У вас выскакивает строка приглашения. После ввода имени и пароля, становится доступной командная строка на удалённой машине. Теперь вы можете вводить команды на хосте провайдера, например ls. Терминальный доступ - это ещё не соединение по TCP/IP. Теперь вам нужно запустить программу ppp на удалённой машине, а затем на своей. Удалённая машина и клиентская устанавливают соединение по TCP/IP. Теперь вы в сети и можете пинговать, подключаться к WWW и т.д.

Вы можете выяснить, какой тип авторизации поддерживает ваш провайдер, с помощью терминальной программы minicom, которая входит в дистрибутив ASPLinux. Правильно укажите последовательный порт к которому подключен модем, введите команду AT, модем должен откликнуться OK. Лучше создать ссылку /dev/modem на последовательный порт к которому подключен модем, на моей машине /dev/modem -> /dev/ttyS3 , в дальнейшем можно ссылаться на устройство /dev/modem . Теперь ATDP989796, где 989796 - телефон провайдера. Если он поддерживает "ручную" аутентификацию, то после дозвона появится приглашение залогиниться.

Если провайдер использует CHAP или PAP аутентификацию, то после дозвона на экран полезет всякая дрянь. При использовании провайдером ручной аутентификации, вы можете использовать скрипт ppp-on, который входит в состав пакета ppp и пояснения к нему. Вообще, примеры такого подключения я встречал во многих руководствах.

Если провайдер использует CHAP/PAP авторизацию, то задача упрощается. Строго говоря, CHAP и PAP это два разных протокола аутентификации, но настраивается программа ppp одинаково, поэтому для нас различия между PAP и CHAP не играют роли. Файлы настроек находятся в /etc/ppp. Для начала создадим простейшую конфигурацию и подключимся.

Исполняемый файл программы /usr/sbin/pppd. Файл /etc/ppp/options, содержит параметры запуска. Изменяем существующий файл /etc/ppp/options. Вот его содержимое:

connect "/usr/sbin/chat -v 'ABORT' 'BUSY' 'ABORT' 'NO CARRIER' ' ' 'ATZ' 'OK' 'ATDP98999' \ 'CONNECT' ''

/dev/modem

defaultroute

name "yourlogin"

debug

Необходимо внести изменения в файлы /etc/ppp/pap-secrets и /etc/ppp/chap-secrets. Содержимое файла /etc/ppp/pap-secrets:

# client server secret

"yourlogin" * "yourpassword"

Содержимое файла /etc/ppp/chap-secrets:

# client server secret

"yourlogin" * "yourpassword"

Понятно, что подставляете свои параметры учётной записи у провайдера. В параметрах мы указали debug, это позволит нам наблюдать процесс подключения, используя систему syslog. Одна важная деталь, обязательно установите право на чтение и запись для файлов pap-secrets и chap-secrets только для root, иначе pppd не запустится.

На свободной виртуальной консоли введите:

tail -f /var/log/messages

Изменения системного журнала будут отображаться на экране.

На рабочей консоли введите pppd, переключитесь на консоль, где запущен просмотр системного журнала. Процесс соединения как на ладони. Если всё пройдёт успешно, то вы увидите, какой IP-адрес вам назначил провайдер. Введите команду ifconfig и увидите конфигурацию сетевого интерфейса ppp0 вашего соединения. Посмотрите таблицу маршрутизации командой:

route -n

Но это не всё. Провайдер выделяет вам динамический IP- адрес, используя протокол PPP. Но остался невыясненным IP-адрес сервера DNS провайдера, который необходим для работы в интернет. В Windows используется протокол DHCP для получения адреса сервера DNS. В Linux так же можно использовать DHCP, но для этого нужно отдельно настроить клиента DHCP. А можно позвонить в службу технической поддержки провайдера и узнать адреса серверов DNS. Затем прописать их в файле /etc/resolv.conf. Я поступил именно так. Содержимое этого файла:

nameserver 81.91.36.3

nameserver 81.91.36.5

Проверяем работу службы DNS командой:

nslookup www.microsoft.com.

На экране должны появиться IP-адреса Microsoft. Разорвать соединение с интернет можно командой:

killall pppd

Это пробный вариант конфигурации соединения. Теперь приведём более совершенный вариант. В пакете ppp рекомендуют использовать программу chat, входящую в его состав, она используется для организации самого дозвона. В файле /etc/ppp/options, в строке connect , указана эта программа с нехитрыми параметрами. Будем использовать отдельный скрипт для дозвона со списком телефонов в отдельном файле. Скрипт /etc/ppp/redialer, список телефонов /etc/ppp/phones. Ниже приведены тексты обоих файлов. Файл redialer необходимо сделать исполняемым:

#!/bin/sh

# Максимальное количество попыток дозвона

MAX_ATTEMPTS=3

# Задержка между попытками дозвона

SLEEP_DELAY=2s

# Скрипт набора номера

function callnumber

{ TL=$1

chat -v ABORT BUSY ABORT "NO ANSWER" ABORT "NO DIALTONE" ABORT "NO CARRIER" \

ABORT "ERROR" ABORT VOICE ABORT "RINGING RINGING" "" ATZ OK ATM0 OK ATDP${TL} \

CONNECT "" }

# Скрипт перебора телефонных номеров

function callall

{ set `cat /etc/ppp/phones`

while [ $# -ne 0 ]

do

PHONE=$1

callnumber ${PHONE}

if [ $? -eq 0 ] ; then

exit 0

else

shift

fi

done }

# Повторный перебор всех номеров из списка

attempt=0

while : ; do

attempt=`expr $attempt + 1`

callall

if [ "$attempt" = "$MAX_ATTEMPTS" ]; then

exit 1

fi

sleep "$SLEEP_DELAY"

done

Пример файла телефонов /etc/ppp/phones:

171111

640411

653100

Улучшенный вариант файла настроек /etc/ppp/options приведён ниже:

connect /etc/ppp/redialer

lock

defaultroute

/dev/modem

idle 180

crtscts

debug

name "yourname"

После параметра connect указан скрипт дозвона. Параметр idle 180 заставляет ppp разъединять соединение, если оно не будет активным более 180 секунд. Параметр crtscts указывает на аппаратное регулирование скорости обмена с модемом. Параметр defaultroute, устанавливает маршрут по умолчанию во внешнюю сеть.

Но и это ещё не всё. При запуске pppd сразу же происходит дозвон и соединение. Это не совсем то, что нужно. Мы хотели что бы дозвон и соединение происходило при попытках выхода во внешнюю сеть через шлюз. Дополним наш файл /etc/ppp/options рядом операторов:

connect /etc/ppp/redialer

lock

defaultroute

/dev/modem

crtscts

debug

115200

idle 180

user vb076317

demand

maxfail 4

noipdefault

ipcp-accept-local

ipcp-accept-remote

80.80.80.1:80.80.80.2

Оператор demand указывает на режим " соединение по требованию ", следующие четыре оператора сообщают об IP адресах интерфейса ppp0 и адресе маршрута по умолчанию. Теперь при запуске pppd, немедленного соединения с внешней сетью не происходит. Если запустите ifconfig, то увидите, что появился интерфейс ppp0, хотя реальной связи с внешней сетью нет. При запуске команды:

route -n

обнаружите маршрут по умолчанию во внешнюю сеть. Если попробуете пропинговать microsoft.com, то услышите, как модем набирает номер и пытается соединиться с внешней сетью. Мониторинг соединения был описан выше. После того как реальное, а не виртуальное соединение установилось, вы увидите, что содержимое таблицы маршрутизации изменилось. Вместо наших виртуальных IP адресов, локального и удалённого компьютера, которые мы указали в /etc/ppp/options, провайдер динамически выделил реальный IP адрес. При следующем сеансе, этот IP адрес опять изменится. Пока запущен демон pppd, будет дополнительный маршрут во внешнюю сеть и долнительный сетевой интерфейс ppp0. Командой killall pppd , можете завершить работу демона, и интерфейс ppp0 исчезнет.

Для нормальной работы сервера, в конец файла /etc/rc.d/rc.local добавьте строку запуска pppd .

В целях безопасности, проверьте запрет на прямую маршрутизацию из локальной сети в интернет и наоборот. Файл /proc/sys/net/ipv4/ip_forward должен содержать " 0 "

cat /proc/sys/net/ipv4/ip_forward

Если в файле "1 " , то измените на ноль

echo "0" > /proc/sys/net/ipv4/ip_forward

Прямая маршрутизация не нужна, так как HTTP запрос будет приниматься прокси-сервером, анализироваться и перенаправляться. Напрямую IP-дейтаграммы пересылаться не будут

Доступ по протоколу HTTP и FTP.

Для доступа по протоколу HTTP и FTP будем использовать прокси-сервер SQUID. Эта программа действует как посредник между Web-броузерами и серверами Web, к которым они обращаются. Вместо непосредственного подключения к Web-серверу, клиенты подключаются к прокси-серверу. Затем прокси-сервер перенаправляет запросы в интернет. В кэше сервера SQUID хранятся копии Web-страниц, к которым ранее обращались пользователи; после поступления нового запроса сервер проверяет, содержится ли в кэше текущая копия и, если это так, возвращает эту копию из своего кэша вместо того, чтобы обращаться с запросом к исходному узлу.

Этот сервер предоставляет также средства, которые позволяют осуществлять контроль, за доступом пользователей к Web. Ведётся файл журнала, где регистрируются действия пользователей, из него можно формировать статистику по доступу.

В моём дистрибутиве версия squid-2.4.STABLE. Основной файл настроек /etc/squid/squid.conf. Будем перечислять настройки, которые желательно изменить, с пояснениями.

http_port 192.168.1.1:3128

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

icp_port 0

Сервер может быть настроен на обмен данными с другими кэширующими серверами по протоколу ICP(Internet Cache Protocol), в интернет существует целая сеть кэширующих серверов обменивающихся данными по этому протоколу. По умолчанию он слушает порт 3130. В нашей конфигурации эти возможности не используются, поэтому поставили "0", чем их и отключили.

cache_peer proxy.utk.ru parent 3128 0 default

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

cache_mem 6 MB

Параметр задаёт размер кэша в ОЗУ, много устанавливать не надо, наш сервер подключен к медленной линии и не сильно будет нагружен.

cache_dir ufs /var/spool/squid 100 16 256

Паравметр задаёт файловую систему, расположение и размер кэша на диске. В нашем случае его размер 100 мегабайт. Иногда, для увеличения быстродействия, кэш располагают на отдельном устройстве. Если Вы не хотите кэшировать данные из внешней сети, а прямо передавать на броузер клиента, то задайте:

cache_dir null /null

Доступ во внешнюю сеть будет защищён, но без кэширования.

cache_store_log none

Задаёт расположение журнального файла менеджера хранения, можно отключить для экономии ресурсов.

ftp_passive on

Протокол FTP предусматривает 2 режима обмена данными: активный режим и пассивный. При активном режиме, сервер FTP инициирует соединение с клиентом. Это нежелательно с точки зрения защиты, возможность подключения из интернет к компьютерам локальной сети, по возможности исключают. Для этого соответствующим образом настраивают сетевой экран. Если не предполагается защищать шлюз сетевым экраном (брэндмауэром) , то можно установить " off ".

authenticate_program /usr/lib/squid/ncsa_auth /usr/etc/passwd

Задаёт расположение программы аутентификации и файла паролей, проверьте наличие программы ncsa_auth по указанному пути. Прокси-сервер позволяет проводить аутентификацию различными средствами: LDAP, NCSA, MSNT, PAM, SMB, getpwam.

Например, метод MSNT - аутентификация контроллером домена локальной сети, если ваш сервер находится в домене NT, то всякий член домена, будет иметь доступ и к прокси-серверу. Метод NCSA - используется в Web-сервере Apache. Метод SMB - используется в пакете Samba, а PAM использует подключаемые модули аутентификации Linux. Рекомендуется использовать более простой в настройке метод аутентификации NCSA. Чтобы иметь возможность создавать учётные записи пользователей вам потребуется утилита htpasswd, входящая в состав Apache. Если у вас не установлен Apache, то можете извлечь эту программу, из rpm пакета не устанавливая весь пакет. Для извлечения можно использовать встроенные средства файлового менеджера Midnight Commander или утилиту rpm2cpio и cpio. Командой:

htpasswd -c /usr/etc/passwd drt

создаёте файл паролей и учётную запись drt . Программа попросит вас ввести пароль. Будет создан текстовый файл с зашифрованным паролем и именем пользователя. Можете просмотреть его обычным редактором. Для добавления прочих пользователей запустите программу без ключа " -с " . Командой:

htpasswd - - help

можно получить краткую информацию по использованию программы. Удалять и отключать учётные записи можно обычным текстовым редактором.

Если на машине настроена программа Samba, то можно использовать аутентификацию smb. Вместо программы аутентификации ncsa_auth, задайте smb_auth и укажите файл паролей /etc/samba/smbpasswd. Вам нужно иметь или создать пользователей ресурсов Samba. Как их создать - можно узнать в документации по этому пакету.

Дочерние процессы прокси-сервера работают с правами заданными директивой cache_effective_user. По умолчанию задаётся пользователь " squid " . Проверьте, чтобы этот пользователь имел право на чтение файла паролей.

connect_timeout 180 seconds

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

В секции #ACCESS CONTROLS определяются различные списки управления доступом. В дальнейшем эти списки будут использоваться для разрешения и запрета доступа к серверу. У Вас может быть задано несколько списков доступа, но только некоторые из них Вы можете реально задействовать в конкретной конфигурации. Список управления доступом имеет следующий формат:

acl имя тип строка

Имя - это название списка, которое вы сами присваиваете. Тип - это набор предопределённых типов:

dst IP-адрес назначения

src IP-адрес клиента

dstdomain сервер назначения указанный в URL

proto протокол

time время

proxy_auth аутентификация через программу

method метод HTTP запроса

Строка - конкретное значение, задаваемое Вами.

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

acl password proxy_auth REQUIRED

acl all src 0.0.0.0/0.0.0.0

Первый список под именем password определяет множество пользователей прошедших аутентификацию. Второй определяет все клиентские компьютеры.

Далее задаются списки правил. Они работают совместно со списками управления доступом определёнными ранее. Закомментируйте списки правил, записанные в конфигурации по умолчанию. И добавьте строки приведённые ниже:

http_access allow password

http_access deny all

Списки правил действуют в том порядке, в котором записаны. Если запрос удовлетворяет правилу, то условия расположенные ниже, для этого запроса не проверяются. Комбинируя расположение списков правил и списков управления доступом, можно задать сложную систему условий доступа клиентов. Несколько списков управления доступом расположенные в одной строке, работают как логическая операция " И ". Приведём пример. Необходимо чтобы выполнялись запросы от компьютеров локальной сети, в рабочее время и только от пользователей прошедших аутентификацию. Определим два дополнительных списка управления:

acl uptime time M T W H F 8:00-18:00

acl mynet src 192.168.1.0/255.255.255.0

Добавим эти условия к спискам правил:

http_access allow password uptime mynet

http_access deny all

В списках управления доступом, несколько условий в одной строке работают как логическая операция " ИЛИ ". Например, чтобы избирательно задать адреса клиентских компьютеров, можно написать:

acl mynet src 192.168.1.2 192.168.1.4 192.168.1.7

При соединении, проверяется IP-адрес клиента, время в которое был подан запрос и проводится процедура аутентификации. Если хотя бы одно из условией не выполнено, то выполняется следующий список, по его правилам всем клиентам запрещено в доступе и любой запрос под него подпадает, поэтому запрос клиента отвергается.

prefer_direct on

Этот параметр задаёт предпочтение использовать прямое соединение с Web-серверами и если удовлетворительного ответа не получит, то попробует соединиться с прокси-сервером провайдера, который мы определии директивой cache_peer. Соединяться напрямую с некоторыми Web серверами, не всегда удаётся, например, если Ваш собственный прокси-сервер находится за брандмауэром, а правила этого брандмауэра не разрешают соединение с портом 8001, на котором работает Web-сервер. Можно и отключить опцию, тогда сервер будет предпочитать запросы к родительскому прокси-серверу провайдера.

В конфигурационном файле SQUID очень много параметров, мы указали те, которые наиболее важны для нашего применения.

В интернет-броузерах следует настроить подключение через прокси-сервер. Указать адрес сервера в локальной сети и порт по умолчанию 3128.

У вас в локальной сети машина с работающимими pppd и Squid, в броузере правильно указан прокси-сервер. Вы набираете URL в броузере и посылаете запрос. Прокси-сервер в ответ на запрос, предлагает ввести пароль и имя пользователя. После чего происходит автоматический дозвон, соединение и загрузка требуемого сайта. Если активность прекратиться, через 3 минуты после последнего запроса, модем повесит трубку. Если вновь появится запрос, то автоматически дозванивается, соединяется и т.д.

Прокси-сервер можно использовать и для подключения к ИНТЕРНЕТ по выделенной линии. Практически ничего не меняется. В дополнение следует заметить, что статистика о доступе к серверу, хранится в файле /var/log/squid/access . Существует целый ряд программ для создания отчётов на основе данных этого файла.

Электронная почта.

Все почтовые программы делятся на два больших класса: серверные и клиентские. Серверы пересылают почту другим серверам по протоколу SMTP(Simple Mail Transfer Protocol), осуществляя маршрутизацию почтовых сообщений подобно маршрутизации IP дейтаграмм. Иногда сообщения передаются несколькими промежуточными машинами, прежде чем попадут на сервер назначения.

Клиентская программа применяется для создания сообщения, пересылки его на почтовый сервер провайдера, получения почты с сервера провайдера и адекватного представления почтового сообщения на экране. Клиентская программа посылает почтовое сообщение по протоколу SMTP, а получает по протоколу POP или IMAP. Обычно провайдеры не позволяют, кому угодно подключаться к своим серверам. Сервер может быть настроен на проверку IP-адреса или имени машины клиента. В последнее время широкое распространение получила аутентификация отправителя сообщения, для отправления почты через такой сервер вам нужно ввести имя и пароль. Поэтому вы не можете напрямую подключиться к какому-нибудь серверу и переслать почту. Сервер вам откажет в доступе. Вам необходимо подключиться к серверу провайдера или другому доверенному серверу, пройти возможную процедуру аутентификации, послать почту, затем он перешлёт всё по назначению. Для выгрузки почты клиентам, существуют отдельные серверные программы работающие по протоколам POP(Post Office Protocol) или IMAP(Internet Mail Access Protocol), они функционируют на почтовых серверах непосредственно работающих с почтовыми клиентами. Для получения почты, аутентификация пользователя используется давно. На рис.1 показано, что для передачи сообщения на сервер клиента B, клиенту A необходимо подключиться к своему доверенному серверу A и передать сообщение по протоколу SMTP. Далее он передаст его, возможно через другие серверы (в нашем случае через промежуточный сервер C). Клиенту B для получения почты, нужно подключиться к своему доверенному серверу B по протоколу POP.

Рисунок 1

В нашей локальной сети будет почтовый сервер, принимающий почтовые сообщения от клиентов по протоколу SMTP и выгружающий её локальным клиентам по протоколу POP. Почтовые сообщения могут пересылаться как между локальными пользователями, так и во внешнюю сеть, смотрите рисунок 2.

Рисунок 2

Локальный почтовый сервер будет передавать на сервер провайдера исходящую почту по протоколу SMTP, а принимать по протоколу POP, так как будто это обыкновенный почтовый клиент.

Почта в Linux.

После установки операционной системы Linux, по умолчанию задаётся имя машины localhost.localdomain. Для нормальной работы почтового сервера требуется задать другое имя, назовём машину gt.localdomain. Можно быть уверенным, что в интернете не найдётся домена localdomain.

Для того чтобы клиенты Windows могли обращаться к серверу по имени, найдите файл hosts на Windows и добавьте строку:

192.186.1.1 gt.localdomain

Конечно, адрес подставьте своего Linux сервера. Проверьте внесённые изменения командой запущенной с Windows:

ping gt.localdomain

Если нет ответа от сервера, то проверьте отсутствие расширений у файла hosts , некоторые редакторы по умолчанию подставляют расширениe txt. Подключение Linux к локальной сети описано во многих руководствах, поэтому здесь мы не будем повторять эту процедуру.

Самый распространённый почтовый сервер для Unix - это sendmail. В ASP Linux он устанавливается по умолчанию. В последнее время пользуется всё большим распространением программа Postfix, как более удобный в настройке, безопасный и надёжный. Удалим sendmail и установим Postfix, теперь он входит во многие дистрибутивы. Моя версия 1.1.10. Лучше не просто не запускать sendmail, а именно удалить с диска.

Чтобы клиенты могли получать почту по протоколу POP, необходимо установить сервер POP. Программа входит в состав пакета imap-2001a-10, проверьте её установку командой:

rpm -qa / grep "imap"

Эти программы должны запускаться при старте системы, запустите ntsysv и отметьте ipop3. Сервер POP запускается через xinetd и оживляется командой:

/etc/rc.d/init.d/xinetd restart

Проверить доступность POP сервера на уровне протокола TCP/IP можно программой клиента telnet имеющейся в Windows, командой:

telnet gt.localdomain 110

По умолчанию POP сервер работает на 110 порту. После подключения, на экране появится что-то вроде:

+OK POP3 gt.localdomain v2001.78rh server ready

Это значит, что POP сервер доступен по сети и ждёт соединений.

В интернете у Вас должен быть почтовый сервер с учётными записями Ваших пользователй. С этого сервера будет забираться почта локальным сервером и на него посылаться. Если такого нет, то можно создать учётные записи на общедоступном бесплатном почтовом сервере, например на rambler.ru или mail.ru. На сайтах этих служб Вы найдёте всю необходимую информацию.

Предположим, что наши пользователи директор и бухгалтер. Тогда создадим учётные записи 2-х пользователей на локальном сервере, bgl и drt (можно командой adduser). У бухгалтера на общедоступном почтовом сервере в домене rambler.ru учётная запись buh@rambler.ru, а у директора учётная запись dir@rambler.ru.

Соответствие учётных записей:

buh@rambler.ru <-> bgl@gt.localdomain

dir@rambler.ru <-> drt@gt.localdomain

Содержимое почтовых ящиков локального и удалённого серверов будет периодически синхронизироваться. Доверенным сервером для локальных пользователей является сервер Linux, их почтовые клиенты настроены на передачу почты через него. Предположим, что бухгалтер решил послать сообщение по адресу bob@mail.ru. Он пересылает сообщение на локальный сервер, сервер смотрит заголовок сообщения и видит, что оно предназначено во внешнюю сеть и отправителем является пользователь bgl. Он меняет адрес отправителя с bgl@gt.localdomain на buh@rambler.ru . Если не изменить адрес отправителя, то почтовый сервер домена rambler.ru не примет сообщение от неизвестного сервера gt.localdomain, да ещё от неизвестного пользователя с учётной записью bgl. На bob@mail.ru дойдёт сообщение с обратным адресом buh@rambler.ru.

А как сообщения c почтовых серверов интернета попадают на локальный почтовый сервер? Для этого служит отдельная программа fetchmail. Cервер Linux соединяется с внешней сетью периодически, через равные промежутки времени и fetchmail извлекает почту с buh@rambler.ru и dir@rambler, и помещает в локальные почтовые ящики соответствующих пользователей. Эта программа поставляется в дистрибутиве ASPLinux в пакете fetchmail-5.9.11-1.asp.

Конфигурирование Postfix.

Postfix - это современный, надёжный почтовый сервер, используемый многими серьёзными провайдерами. Поставляется во многих дистрибутивах Linux. Именно этот сервер и выберем для работы.

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

При получении почты аутентификация используется давно, все распространённые почтовые клиенты поддерживают POP- аутентификацию. Попросту говоря для получения почты нужно ввести имя и пароль. До недавнего времени для передачи почты, аутентификации не требовалось. В настоящее время многие провайдеры вводят SMTP-аутентификацию на свои серверы (например: rambler.ru, mail.ru), это значит, что ваш почтовый клиент должен поддерживать процедуру SMTP-аутентификации, иначе он не сможет передать почту. Эти меры вызваны деятельностью спамеров.

Сервер домена rambler.ru требует SMTP-аутентификацию, поэтому локальный сервер при ретрансляции на rambler.ru должен пройти SMTP-аутентификацию как клиент. Postfix использует библиотеку Cyrus SASL для SMTP-аутентификации. В ASPLinux это три rpm-пакета: cyrus-sasl-1.5.24-25, cyrus-sasl-md5-1.5.24-25, cyrus-sasl-plain-1.5.24-25. Программа сервера Postfix входящая во многие дистрибутивы скомпиллирована с поддержкой библиотеки SASL.

Какие функции должен выполнять наш почтовый сервер для передачи почты в глобальную сеть?

1. Всю почту предназначенную не для локальной сети, передавать на внешний почтовый шлюз smtp.rambler.ru.

2. При передаче сообщений на smtp.rambler.ru, пройти процедуру аутентификации, а значит должен быть настроен как клиент SMTP-аутентификации.

3.При передаче сообщений, переписывать заголовки исходящих сообщений и конверт. Если даже аутентификация прошла успешно, сервер smtp.rambler.ru не примет сообщение от неизвестной машины gt.localdomain и незнакомого пользователя. Адресат, получив сообщение, по заголовку сможет определить обратный адрес отправителя. Многое зависит от настроек сервера провайдера, насколько строгие правила передачи почты он установил. Входящее сообщение может анализироваться и в случае несоответствия отвергаться.

4.Не пытаться пересылать сообщения немедленно, а ставить в очередь.

5.Не обращаться лишний раз к DNS .

Чтобы заставить так работать Postfix, необходимо изменить главный файл настроек /etc/postfix/main.cf.

Начнём с общих настроек, добьёмся, чтобы наш сервер принимал и передавал сообщения в локальной сети.

#INTERNET HOST AND DOMAIN NAMES

myhostname = gt.localdomain

Думаю, тут пояснения не требуются.

# RECEIVING MAIL

inet_interfaces = all

С каких интерфейсов принимается почта, возможны не принципальные варианты.

mydestination = $myhostname, localhost.$mydomain

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

# TRUST AND RELAY CONTROL

mynetworks = 192.168.1.0/24 , 127.0.0.0/8

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

# ALIAS DATABASE

alias_maps = hash:/etc/postfix/aliases

Расположение файла псевдонимов. Этот файл позволяет перенаправлять почту в различные ящики. С его помощью можно создавать списки рассылки. Если хотите чтобы почта root перенаправлялась на обычную учётную запись, измените этот файл :

# CHANGE THIS LINE to an account of a HUMAN

root : alex

Так можно перенаправить почту root на имя alex .

Теперь Postfix готов для приёма и передачи сообщений внутри локальной сети. Проверить доступность сервера с клиентской машины, можно обычным клиентом telnet для Windows. Команда:

telnet gt.localdomain 25

Но предварительно отключите демона pppd, если он запущен. Зачем это нужно, я объясню позже. На экране должно появиться что-то вроде:

220 gt.localdomain ESMTP Postfix

Теперь настройте программу почтового клиента. Создайте две учётные записи: drt@gt.localdomain и bgl@gt.localdomain. Для передачи и приёма почты по POP и SMTP протоколам укажите сервер gt.localdomain. Передайте тестовое сообщение с одной записи на другую. Решить возникшие проблемы поможет анализ файла журнала /var/log/maillog. Можете предварительно очистить журнал:

cat /dev/null > /var/log/maillog

а затем переслать сообщение.

Займёмся настройкой для передачи сообщений во внешнюю сеть. Пересылка всей почты наружу, на smtp.rambler.ru:

# INTERNET OR INTRANET

relayhost = smtp.rambler.ru

Локальный сервер как клиент SMTP-аутентификации:

smtp_sasl_auth_enable = yes

smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

Добавьте эти строки в конце /etc/postfix/main.cf. Не путайте директиву smtp_sasl_auth_enabled , с директивой smtpd_sasl_auth_enabled . Вторая директива разрешает аутентификацию Postfix , когда он принимает почту, а не передаёт.

Создайте текстовый файл /etc/postfix/sasl_passwd:

rambler.ru dir:pAsswordDir

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

postmap /etc/postfix/sasl_passwd

Для переписывания заголовков, в секции #ADDRESS REWRITING вставьте:

sender_canonical_maps = hash:/etc/postfix/sender_canonical

Создадим текстовый файл, по содержимому которого у некоторых исходящих сообщений будут переписываться заголовки отправителей. Файл /etc/postfix/sender_canonical:

bgl@gt.localdomain buh@rambler.ru

drt@gt.localdomain dir@rambler.ru

Создадим индексированный файл:

postmap /etc/postfix/sender_canonical

В версии 2.0 , добавлена дополнительная функция, отклонение почты для неизвестных локальных пользователей, в небольшой сети использовать её нецелесообразно, можно отключить, задав строку с пустым параметром:

# REJECTING MAIL FOR UNKNOWN LOCAL USERS

local_recipient_maps =

Заставим сервер ставить в очередь сообщения для внешней сети.

Добавим строку в конец основного файла настроек:

defer_transports = smtp

Запретим ненужные обращения к службе имён. Добавим строку в конец файла настроек:

disable_dns_lookups = yes

Но это ещё не всё. Со службой имён придётся повозиться. Многие сетевые программы делают попытки разрешения имён компьютеров, которые к ним обращаются, даже если их об этом не просят. Сервер telnet при попытке подключиться к нему, начнёт обращаться к службе разрешения имён. Если запущен демон pppd и указан маршрут во внешнюю сеть, а он должен быть указан, если всё правильно настроено, то начнётся дозвон к провайдеру и соединение с сервером DNS. После ожидания ответа на запрос, сервер telnet всё же выдаст приглашение на вход, хотя и со значительной задержкой. Но ненужный звонок будет совершён. Даже если вы пропишете IP адрес клиента локальной сети в /etc/hosts и правильно зададите последовательность поиска в /etc/host.conf /etc/nsswitch.conf , сервер упорно лезет в ИНТЕРНЕТ. Наверно радикальным средством была бы перекомпилляция. Поэтому для удалённого управления компьютером, лучше использовать службу ssh . При подключении клиента, сервер не пытается разрешить имя и напрасных звонков не делает. Есть хороший клиент для Windows - PuTTY . Отлично поддерживает Linux .

Аналогично себя вёл и Postfix. Ему необходимо определить IP адрес шлюза smtp.rambler.ru. Мы сами с помощью утилиты nslookup определим его и занесём в /etc/hosts. Этот адрес может меняться, поэтому было бы разумно по чаще его обновлять, либо использовать кэширующий сервер DNS. Но сервер всё же продолжает делать попытки обращаться к службе DNS ИНТЕРНЕТА, при соединении с 25-м портом сервера. Он пытается определить имя клиентской машины локальной сети, чтобы занести в файл журнала.

Каждый почтовый сервер в процессе работы читает и записывает файлы на диск компьютера. Получив контроль над таким сервером, взломщик может изменить конфигурацию программ, обеспечивая себе базу для дальнейшего проникновения в систему. Уменьшить возможности злоумышленника можно, ограничив сферу действия сервера подмножеством файловой системы компьютера. Это подмножество файловой системы называется поддеревом chroot. Если сервер выполняется в пределах такого поддерева, то важные системные файлы будут не доступны для взломщика, даже если он сможет использовать сервер в своих целях.

Этот приём используется в сервере Postfix. Его поддерево /var/spool/postfix. Там находятся копии важных системных файлов: localtime, services, resolv.conf. Файл resolv.conf копируется скриптом инициализации при запуске. Чтобы Postfix заработал как надо, необходимо скопировать в эту же директорию файлы /etc/hosts, /etc/nsswitch.conf и /etc/host.conf. В nsswitch.conf и host.conf задаётся соответствующий порядок разрешения имён. В файл hosts заносятся адреса и имена всех компьютеров локальной сети, с которых может передаваться почта. Теперь при попытках соединения с 25-м портом сервера, обращения к DNS ИНТЕРНЕТА не происходит, даже если запущен демон pppd.

Проверим работу. Создадим тестовое сообщение и передадим его с учётной записи bgl@gt.localdomain на dir@rambler.ru. Сервер должен принять сообщение и поставить в очередь. Обращения в ИНТЕРНЕТ не должно происходить при запущенном pppd. Содержимое очереди можно проверить командой:

mailq

Удаляется сообщение:

postsuper -d номер_сообщения

Номер сообщения определяется командой mailq. В дальнейшем, в планировщике поставим задание на периодическую передачу всех сообщений из очереди в ИНТЕРНЕТ.

Конфигурирование fetchmail.

При организации работы локального сервера мы должны не только отправлять, но и принимать почту из ИНТЕРНЕТА. Конфигурирование и отладка fetchmail много проще Postfix. Создайте файл /etc/fetchmailrc , с правами на чтение и запись только пользователя root. Вот его текст:

set postmaster "root"

set logfile "/var/log/fetchmail.log"

poll pop3.rambler.ru proto pop3 user buh pass buhgalter , is bgl here smtphost gt.localdomain

poll pop3.rambler.ru proto pop3 user dir pass pAsswordDir , is drt here smtphost gt.localdomain

Параметр set postmaster указывает программе sendmail, чтобы все нераспознанные сообщения направлялись пользователю root. Вторая строка указывает расположение журнального файла, на первых порах он может быть важен для диагностики проблем.

Важно понимать, что fetchmail опрашивает POP - сервер провайдера, извлекает почту, устанавливает соединение с локальным сервером Postfix по протоколу SMTP и загружает в него почту. Поэтому для нормальной работы fetchmail, Postfix должен тоже работать. Необходимо знать имя POP сервера своего провайдера. В третьей строке даётся команда опросить сервер pop3.rambler.ru, используя протокол pop3, почтовый ящик пользователя dir с паролем director и загрузить на машину gt.localdomain в ящик пользователя drt. Если у пользователя несколько внешних почтовых ящиков, то можно забирать с них почту и загружать в единственный, локальный почтовый ящик.

Комплексная настройка почтовых служб.

Опишем органиацию работы почтового шлюза, без доступа к WWW. Такое решение делает доставку службы более надёжной.

Как уже ранее замечалось, почтовый сервер ставит в очередь сообщения для внешней сети. Необходимо периодически передавать накопленную почту в интернет и загружать входящую почту. Ранее описывалась настройка соединения по запросу. Если работа с WWW не нужна, то для почтовой службы целесообразней использовать обычное подключение. Как только запускается служба pppd , происходит дозвон и соединение. Затем загружаются почтовые сообщения на локальный сервер из серверов интернета и пересылаются накопленные в очереди локального сервера. Когда эти операции закончатся, соединение разрывается. Содержимое файла /etc/ppp/options для этого случая:

connect /etc/ppp/redialer

lock

defaultroute

/dev/modem

idle 180

crtscts

debug

name "yourname"

Для решения этой задачи нужно создать скрипт /etc/ppp/ip-up.local и задать право на выполнение. Он автоматически запускается при установке соединения по IP протоколу. Точнее, запускается скрипт /etc/ppp/ip-up , а уже из него вызывается ip-up.local . Вставим в него команды для обмена накопившейся почтой и разрыва соединения. Ниже приведён полный текст:

#!/bin/bash

# echo "запускаю доставку почты из сервера провайдера"

/usr/bin/fetchmail -t 20 -a -v -f /etc/fetchmailrc

# очищать очередь пока не опустеет

while mailq / grep -v 'Mail queue is empty$' > /dev/null 2>&1

do

/usr/sbin/sendmail -q

sleep 5

done

# echo "закончил доставку, разрываю соединение"

/usr/bin/killall pppd > /dev/null 2>&1

exit 0

Команда /usr/bin/fetchmail -t 20 -a -v -f /etc/fetchmailrc запукает доставку входящей почты. Условием выхода из цикла является сообщение команды mailq . Для правильной работы, точно задайте строку, с единственным пробелом между словами. С интервалом в 5 секунд передаётся накопленная почта в очереди. Соединение по запросу больше подходит для работы по HTTP и FTP протоколам, интерактивно открывается соединение и автоматически закрывается.

Пошлите тестовое сообщение с учётной записи bgl@gt.localdomain на dir@rambler.ru. Посмотрите состояние очереди с сообщениями. Удалите символы комментариев со строк с командами echo в тексте скрипта, для наблюдения хода выполнения. Запустите pppd и посмотрите состояние очереди. Почтовые сообщения иногда задерживаются на серверах провайдеров при сбоях и перегрузке. Подождав некоторое время, опять запустим команду pppd, чтобы получить посланное ранее сообщение. Почтовым клиентом получим наше тестовое сообщение с локального сервера с учётной записи drt@gt.localdomain.

Чтобы получать и передавать почту каждые полчаса с 8 утра до 18 вечера, добавим в файл /etc/crontab строку:

0,30 8-18 * * * root /usr/sbin/pppd

Планировщик cron должен быть запущен.

Почта и WWW.

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

Для этих целей служит скрипт pings . Он создаёт реальное, а не виртуальное соединение с внешней сетью и когда оно установлено, запускает команды загрузки входящей почты и передачи накопленной. Скрипт пингует DNS сервер провайдера и когда получает отклик, запускает команды работы с почтой. Вот его текст:

#!/bin/bash

#посылает пинги к первому серверу DNS провайдера

#это вызывает обращение к pppd и соединение с провайдером

#когда пинги будут достигать цели, запускается программа доставки и передачи почты

COUNTER="1"

LINK="0"

#определяем IP адрес DNS сервера из файла /etc/resolv.conf

IP=`sed -n 's/^ *nameserver *//p' /etc/resolv.conf/sed -n 1p`

# echo "$IP"

until [ "$COUNTER" -eq "20" ]

do

ping -c 1 "$IP" > /dev/null 2>&1

LINK=$?

if [ "$LINK" = "2" ] ; then

# echo "Ошибка сети, нет маршрута"

exit 1

fi

#echo $LINK" попыток "$COUNTER

if [ "$LINK" = "1" ] ; then

# echo "запускаю доставку почты"

/usr/bin/fetchmail -a -t 20 v -f /etc/fetchmailrc

# очищать очередь пока не опустеет

while mailq / grep -v '^Mail queue is empty$' > /dev/null 2>&1

do

/usr/sbin/sendmail -q

sleep 5

done

# echo "закончил доставку"

exit 0

fi

COUNTER=`expr $COUNTER + 1`

sleep 10

done

exit 1

Команда /usr/bin/fetchmail -a -t 20 -v -f /etc/fetchmailrc запукает доставку входящей почты. Командой /usr/sbin/sendmail -q передаётся почта, накопленная в очереди. Затем с интервалом в 5 секунд делаются попытки передачи накопленной почты. Зачем этот скрипт нужен, если у нас соединение по запросу? Дело в том, что некоторые сетевые службы могут несработать, время дозвона может меняться в некоторых пределах, через некоторый интервал ожидания служба может прервать процесс соединения. Соединение по запросу больше подходит для работы по HTTP и FTP протоколам, интерактивно открывается и автоматически закрывается.

Пошлите тестовое сообщение с учётной записи bgl@gt.localdomain на dir@rambler.ru. Посмотрите состояние почтовой очереди с посланным сообщением. Удалите символы комментариев со строк с сообщениями echo в тексте скрипта pings для наблюдения хода выполнения, и запустите комаду pings. Посмотрите состояние очереди. Запустим команду pings, чтобы загрузить почту с сервера провайдера, в сервер локальной сети. Почтовым клиентом получим наше тестовое сообщение с локального сервера с учётной записи drt@gt.localdomain.

Добавим в файл /etc/crontab строку:

0,30 8-18 * * * root /usr/sbin/pings

Нужно заметить, что некоторые провайдеры запрещают отклик своих серверов на ping дейтаграммы. Предварительно проверьте, откликаются ли DNS серверы провайдера.