Эта заметка идет в продолжение двух статей, выложенных на
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/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)
И файл конфигурации сервера-клиента /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)
Некоторые дополнительные разъяснения
1. Все сделано через туннель на логическом устройстве tun
2. Все дополнительные сети прописываются командой route
3. 194.34.67.89 - это адрес сервера на который приходят запросы от
клиентов. Если все офисы обслуживает один провайдер и он
обеспечивает взаимную видимость своих внутренних сетей - то может
быть достаточно и внутренних сетей провайдера - без предоставления
серверу реального IP адреса, если разные провайдеры - сервер
должен быть виден от клиентов (пингуемым, трассируемым).
4. в данном примере не используется компрессия, не используется
шифрование. В связи с тем, что это для конкретного случая
обеспечено провайдером на канальном уровне - не использовался
канал с реальным выходом в Интернет. Если есть необходимость
включить соответствующие опции - примеры файлов конфигурации
приведены выше. Удостоверьтесь что мощности процессора будут
достаточно для этого. Это уже при практической реализации. В
полях.
5. Для данного примера использован коннект по UDP. Во что это
выливается - при пингах более 100 мс в случае если канал будет
нестабилен - постоянно будет переконнекчивается - надо переводить
всю систему на TCP - это тоже видно в файле конфигурации. Причины
простые - UDP пакет идет без подтверждения о доставке, TCP - с
подтверждениями и попвтками повторного прохождения при потере.
6. Практически система нормально работала пои пингах 250 - 600 мс.
7. Имя файла vtund.conf - лучше оставить именно таким. Когда-то
помнится с этим была проблема - другое имя не воспринималось.
1. В случае построения Windows систем - настраивать AD или в более
старой версии - Domain систему. В одном офисе ставим Primary
Domain Controller, в другом - BackUp Domain controller
2. В случае необходимости настраиваем репликации общих директорий -
это для обеспечения чтения общих для двух офисов документов.
3. Ставим почтовые сервера.
Почтовые сервера
Данная часть не описывает полную настройку почтового сервера.
Рассматриваются исключительно вопросы распределения обслуживания.
По большому счету все можно сделать на одном сервере. И прием почты
(Sendmail). И раздачу почты (Qpop). И общие директории (Samba). И
много всего другого хорошего. Но из удаленного офиса будет очень
скучно ожидать прихода на локальный компьютер письма объемом в пару
мегабайт. Или доступа к файлу на скорости засыпания. Для этого нам
необходимо поставить один сервер - принимающий всю почту, проверяющий
ее на Спамуозность и вирусосодержание и отправляющий ее поближе к
абонентам - доставим на локальные сервера в тех подсетях где находятся
эти абоненты. Что может быть использовано в виде "локальных
серверов" - начиная от того, что разместить "сервер почтового
клиентского доступа" на самом VPN сервере. После настройки DNS - он
будет иметь свое имя и IP адрес. На него и будем отправлять почту с
центрального почтового сервера:
Для Sendmail на центральном сервере создаем файл aliases - пример
должен находиться в директории /etc/mail
Пользователи фиксированы в своих офисах - основное место чтения почты
- свои локальные сервера
Добавляем наши сервера и пользователей.
/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
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
И в него заносим всех свои локальные сервера, которым мы будем
разрешать работать через центральный сервер
Дальнейшие направления деятельности и информация к размышлению:
1. вместо локальных почтовых серверов под FreeBSD могут стоять
большие системы - Domino, MS Exchange и т.д. На них уже можно
построить систему чтения почты с любого рабочего места и
синхронизацию почтовых ящиков где бы пользователь не находился
2. разворачивание Windows-Samba аутентификации
3. связывание почтовых имен и имен Windows-Samba
4. репликации директорий между офисами
В любом случае - надо иметь под руками Интернет и знать несколько
адресов:
* http://www.freebsd.org - это сама FreeBSD
* http://www.opennet.ru - отличное "справочное" место в
Русскоязычном Интернете для системного администратора
* http://www.google.com - без слов - там есть ВСЕ.
B. Yasynetskyy <iasb@yahoo.com.>
M.Yasynetska <marsha@list.ru.>
1037 Прочтений • [Построение виртуальных сетей под FreeBSD (vpn virtual mail tunnel freebsd)] [08.05.2012] [Комментариев: 0]
Vova
