Идеология виртуализации. Построение виртуальных сетей. Распределенный офис. Распределенная почтовая система.
Эта заметка идет в продолжение двух статей, выложенных на http://www.opennet.ru по принципам построения корпоративного сервера на базе FreeBSD. В комментариях к первым двум статьям были замечания - что это не «корпоратив» - эта статья - именно о «корпоратизации».
Первая статья - собственно о сервере: http://www.opennet.ru/base/net/unix_server_short.txt.html - это описание того что надо делать если есть необходимость подключения организации к Интернет. Вторая статья - о почтовой системе - как настроить систему защиты от СПАМа для всего офиса. http://www.opennet.ru/base/net/mcafee_freebsd.txt.html . Можно много говорить - и так можно - и так… Но нужно останавливаться и делать. И в первой статье и во второй описаны практически работающие реализации, проверенные во многих инсталляциях и прошедших длительное время обкатки.
Итак, организация подключилась к Интернет. Организация маленькая. Есть вышестоящая. Или наоборот: в центральной конторе поставили сервер. Подключили к Интернет. Что делать дальше ? Надо подключать филиалы. Надо организовывать централизованную почтовую систему.
Если организация уж очень маленькая - Вам будет достаточно одного сервера. Если число пользователей внутри одного офиса больше, допустим, 15-20, то есть смысл поставить как минимум 2 сервера, разделив сервисы, предоставляемые пользователям, между этими двумя серверами с основной целью - повышения безопасности подключаемого офиса. Мы говорим об одной площадке, объединенной сетью с пропускной способностью 10 Мб и больше, то есть это может быть и 2 здания, основное - наличие Ethernet канала/сети между всеми участниками. В правильном варианте необходимо устанавливать сервер внешних ( в сторону Интернет) коммуникаций и внутренний сервер, предоставляющий пользователями необходимые сервисы.
Теперь задачу расширяем. А что нам делать если площадок 2 или больше. А расстояние - нереальное для прокладки кабеля для прямого Ethernet коннекта ? В этом случае необходимо подключение второй (третьей и т.д.) площадки к Интернет-провайдеру. Варианты подключений. Могут быть следующие - центральный офис - с получением от провайдера реального IP адреса. Все остальные офисы - можно и в «серых» сетях. Для проверки функционирования и реальности выданного провайдером IP - идем в Google ищем ссылку для «traceroute test». Вы получите кучу ссылок - из них надо найти что-то зарубежное и проверить доступность (проходимость) до адресов Вашего провайдера или до Вашего - если вы уже поставили сервер. Нормальными можно считать следующие параметры - менее 100 мс - очень недурственный канал (если это случаем не у вас по городу вся задержка). 300-500 мс - есть о чем думать. Или канал идет через спутник или он перегружен. Более 500 мс - «а что такому провайдеру еще надо что-то платить ?» - нормально вы работать не будете. Это сейчас 500. Как начнет работать - будет еще веселее. В принципе для спутникового канала временные параметры следующие - 350 мс - проход в одну сторону, 350 - ответное подтверждение, итого для полностью спутникового канала - 700 мс. Это объясняет скачки в 350-370 мс между рядом стоящими хостами в трейсе.
Как организовать взаимодействие между площадками - строить VPN. Строить туннель через который будут маршрутизироваться ваши внутренние сети. Самое простое - поставить комплект устройств Zyxel или DLink и их настраивать. Можно. Настроите. Это удобно - не морочите себе голову, сразу работает. В принципе - хорошее решение. Подводные камни следующие - какой производительности необходимо устройство ? Надежно ли оно работает ? Какие гарантийные обязательства продавца ? А что о нем пишут в Форумах? Насколько «четко» и «ясно» работает техподдержка на сайте производителя ? Насколько она дает содержательные ответы ? И дает ли она их ? Почему возникают эти вопросы ? Потому что по большому счету мы покупаем «кота в мешке». Для подобного подхода самая рациональная политика - «взять на тестирование». Оставить продавцу залог и поставить устройство в реальном окружении при реальных нагрузках. Иногда много будете удивлены.
Наш путь другой - чисто «софтовое» решение - на FreeBSD. Причина очень простая - меньше надо требовать денег на оборудование, большая свобода в сервисах на одну коробку. Более ясно понимаем что делает система. Общая схема - в центральном офисе (то есть в том офисе в котором мы имеем реальный IP) ставим VPN и конфигурируем его как сервер. В удаленных офисах тоже ставим VPN и конфигурируем его как клиент. Если так случилось, что реальный IP - в филиале - тоже не страшно - поставим серверный комплект там.
Идем в /usr/ports/net/vtun
make
make install
Нарисуем файлик /etc/rc.vtund
Это файл запуска сервера туннелирования
/usr/sbin/ppp -background
sleep 1
/usr/local/sbin/vtund -s -f /usr/local/etc/vtund.conf
/sbin/natd -f /usr/local/etc/natd.conf -n ed0
Теперь сам файл конфигурирования сервера /usr/local/etc/vtund.conf
options {
port 43456; # Рабочий порт туннелирования
timeout 30; # Таймаут линка
# Пути к некоторым програаммам
ifconfig /sbin/ifconfig;
route /sbin/route;
}
# Рабочий конфиг туннеля (серверная часть)
vpn2005 {
pass #MyPawwWord#; # Пароль коннекта
type tun;
device tun0;
proto udp;
compress no;
encr no;
speed 0;
persist yes;
keepalive yes;
up {
# Есть коннект - что делаем ?
# Назначаем IP
ifconfig "tun0 192.168.252.9 192.168.252.10 netmask 255.255.255.252";
# Добавляем маршруты для сетей
route "add -net 192.168.41.0 192.168.252.10 -netmask 255.255.255.0";
};
}
То есть мы делаем туннель с адресами 192.168.252.9 с одной стороны и 192.168.252.10 с другой. Так как используется только 2 адреса - маска 255.255.255.252. Все маршруты, которые будем потом прописывать для необходимых сетей - прописываем через гейтвеи на концах туннеля 192.168.252.10 или 192.168.252.9. В первом офисе - сеть 192.168.40.0.24, во втором - 192.168.41.0. Дополнительно первый офис имеет под боком расположенные сети 192.168.43.0/24 и 192.168.60.0/24
После запуска сервера (смотри файл rc.vtun) должны получить соответствующий процесс ожидания коннекта (по ps -ax)
265 ?? IWs 0:00.00 vtund: waiting for connections on port 43456 (vtund)
Теперь - клиент:
Тоже файл /etc/rc.vtun
/usr/sbin/ppp -background
sleep 1
/usr/local/sbin/vtund vpn2005 194.34.67.89 -f /usr/local/etc/vtund.conf
И файл конфигурации сервера-клиента /usr/local/etc/vtund.conf
#
# VTun - Virtual Tunnel over TCP/IP network.
# Copyright (C) 1998-2000 Maxim Krasnyansky <max_mk@yahoo.com>
#
#
options {
port 43456; # Connect to this port.
persist yes; # Persist mode
timeout 30; # General timeout
# Path to various programs
ppp /usr/sbin/pppd;
ifconfig /sbin/ifconfig;
route /sbin/route;
# firewall /sbin/ipchains;
}
# TUN example. Host 'cobra'.
vpn2005 {
pass #MyPawwWord#; # Password
type tun;
device tun0;
proto udp;
compress no;
encr no;
speed 0;
keepalive yes;
up {
# Connection is Up
# Назначаем IP и с клиентской стороны прописываем нужные сети, доступные с серверной стороны
ifconfig "tun0 192.168.252.10 192.168.252.9 netmask 255.255.255.252";
route "add -net 192.168.40.0 192.168.252.9";
route "add -net 192.168.43.0 192.168.252.9";
route "add -net 192.168.60.0 192.168.252.9";
};
}
Запускаем клиента - получаем примерно такое:
14995 ?? S< 16:23.14 vtund: vpn2005 tun tun0 (vtund)
Некоторые дополнительные разъяснения
Настроив виртуальный линк .между vpn2005 нашими внутренними офисами можем начинать строить более серьезную инфраструктуру:
Почтовые сервера
Данная часть не описывает полную настройку почтового сервера. Рассматриваются исключительно вопросы распределения обслуживания.
По большому счету все можно сделать на одном сервере. И прием почты (Sendmail). И раздачу почты (Qpop). И общие директории (Samba). И много всего другого хорошего. Но из удаленного офиса будет очень скучно ожидать прихода на локальный компьютер письма объемом в пару мегабайт. Или доступа к файлу на скорости засыпания. Для этого нам необходимо поставить один сервер - принимающий всю почту, проверяющий ее на Спамуозность и вирусосодержание и отправляющий ее поближе к абонентам - доставим на локальные сервера в тех подсетях где находятся эти абоненты. Что может быть использовано в виде «локальных серверов» - начиная от того, что разместить «сервер почтового клиентского доступа» на самом VPN сервере. После настройки DNS - он будет иметь свое имя и IP адрес. На него и будем отправлять почту с центрального почтового сервера:
Для Sendmail на центральном сервере создаем файл aliases - пример должен находиться в директории /etc/mail
Что-то в таком духе:
postmaster: root
daemon: root
Допустим мы имеем 3 сервера -
Пользователи фиксированы в своих офисах - основное место чтения почты - свои локальные сервера
Добавляем наши сервера и пользователей.
/etc/mail/aliases
user1: user1@server_for_user1-user20.domauin.ru
user2: user2@server_for_user1-user20.domauin.ru
user21: user21@server_for_user21-user51.domain.ru - его отправляем уже на свой сервер
Теперь более сложная задача - обобщенные имена - например, для секретарей - office, или для бухгалтеров - acct_dep
office: user1@server_for_user1-user20.domauin.ru,
user21@server_for_user21-user51.domain.ru - то есть сразу на двоих одновременно
acct_dep user8@server_for_user1-user20.domauin.ru,
user28@server_for_user21-user51.domain.ru то же на двоих одновременно
directoru@server_for_user21-user51.domain.ru - уведомление директору
После написания подобного файла - даем команду newaliases - перестраиваем базу алиасов
Что еще надо сделать - пользователи должны отправлять свою почту на свои локальные сервера и оттуда она централизованно должна отсылаться - куда ? - пропишем на центральном сервере возможность использования его как почтового Релея локальными серверами. То есть предоставим возможность локальным серверам отправлять почту сначала на центральный сервер, а потом пускай уж центральный сервер выгружает ее в Интернет. Одна из причин - внешнее представление имени сервера, имеющего «серые» адреса может быть таким, что оно не будет рассматриваться как допустимый для отправки «нормальной» не «СПАМ» почты. Перестрахуемся. Альтернатива - слать на релей провайдера.
Пишем файл /etc/mail/relay-domains
И в него заносим всех свои локальные сервера, которым мы будем разрешать работать через центральный сервер
server_for_user1-user20.domauin.ru
server_for_user21-user51.domain.ru
Дальнейшие направления деятельности и информация к размышлению:
В любом случае - надо иметь под руками Интернет и знать несколько адресов:
B. Yasynetskyy
M.Yasynetska