Техинфо
Установка VPN Linux-сервера.
Требования: создать линукс-сервер, который должен работать как vpn сервер
для сотрудников компании, работать как вторичный MySQL сервер для безопасных
издевательств над базой, поддерживать apache и php опять же для разработки
html и php страниц. Ну и может еще что что по мелочи.
Требования к надежности: Если упадет, компания без проблем будет работать
дальше. Будут лишь неудобства. Поэтому никаких RAID контроллеров для дисков
и памяти, дублирования блоков питания и PCI Hot Swap не надо.
Исходные материалы исходя из требований: обычная асусовская мамка, PIII-700,
512 памяти, 80Гб жесткий диск, CDROM, 2 сетевые карты, все это собрано в
обычном корпусе с хорошим блоком питания и подключено к UPS. В качестве
дистрибутива выбран ASPLinux 7.3
Этап 1. Установка сервера.
Эта процедура настолько широко расписана, что особо распространяться не о чем.
Разбил жесткий диск на два раздела. Один, на 512Мб, отдал под swap, все
оставшееся отдал под /. Выбрал серверную установку и выбор пакетов. Отключил
ненужное, расставил адреса для сетевых карт, установил загрузчик. В общем,
ничего особенного и сколько-нибудь выдающегося.
В конце этого этапа вы должны получить установленный Linux сервер, который
смотрит одной сетевой картой (или еще чем) в интернет, другой - в локальную
сеть.
Этап 2. Обновление программного обеспечения.
Ни для кого ни секрет, что со времени выпуска дистрибутива были найдены
ошибки, выпущены обновления для пакетов и так далее и тому подобное.
Для начала выкачаем все новое, что есть для 7.3:
wget -m ftp://ftp.asplinux.ru/pub/i386/updates/7.3/i386/
Конечно, некоторые эстеты могут возразить - ведь есть же версии пакетов
для i686 и так далее. Но тут у меня пока только один резон - я не заметил
сколь-ко нибудь больших отличий, а памяти у меня на сервере не куча
гигабайт и нагрузка не сверхвысокая, чтобы использовать именно PIII
оптимизацию.
Конечно, совершенно не обязательно выкачивать это раз за разом. Можете взять
эти пакеты где-нить в другом месте - это уже не суть важно.
cd ftp.asplinux.ru/pub/i386/updates/7.3/i386/
Вводим очень страшную с первого взгляда команду:
rpm -Uhv apache-1.3.27-2asp.i386.rpm mm-1.1.3-11.i386.rpm
bind-9.2.1-1.7x.2asp.i386.rpm bind-utils-9.2.1-1.7x.2asp.i386.rpm
mod_ssl-2.8.12-2.i386.rpm modutils-2.4.18-3.7x.asp.i386.rpm
cpp-2.96-113asp.i386.rpm opensll* dev-3.3-4.2asp.i386.rpm
php-4.1.2-7.3.6asp.i386.rpm gcc-2.96-113asp.i386.rpm glibc*
iptables-1.2.7a-3asp.i386.rpm kernel-2.4.18-19.7asp.i386.rpm
kernel-utils-2.4-8.13.7.3asp.i386.rpm wget-1.8.2-4.73.i386.rpm
libstdc++-2.96-113asp.i386.rpm xinetd-2.3.7-4.7x.i386.rpm
MAKEDEV-3.3-4.2asp.i386.rpm
Этой командой я обновил все, что более новее, чем установлено в моей системе.
rpm -Uhv * не подойдет из-за того, что в обновлениях лежат не только серверные
пакеты. Да, очень может быть, что к тому моменту, когда вы будете
обновлять сервер, версии пакетов будут еще более новыми, так что не ошибитесь.
В общем, главное тут - обновить то, что у вас стоит и будет использоваться.
Так как мы обновили ядро, то необходимо поправить /etc/lilo.conf
(или каким вы загрузчиком пользуетесь) на предмет новых версий ядра и initrd.
Перезаписываем загрузчик, что бы при следующей перезагрузке уже загрузиться
с новым ядром.
Этап 3. Долой все лишнее.
Этот этап самый сложный для начинающих, поэтому они могут его пропустить.
Дело все в том, что современные дистрибутивы, как бы их не просили, по
умолчанию запихивают очень много лишнего для текущих задач. С одной стороны,
это хорошо - всегда все под рукой будет. А с другой - как-то неправильно
держать на сервере, который не будет печатать никогда, cups.
Я обычно открываю две сесии к серверу: в одной делаю
rpm -qa > list; less list для просмотра установленных пакетов,
а во второй сессии удаляю или смотрю описание для заинтересовавшего
меня пакета.
После удаления всех "левых" и ненужных мне в данной конфигурации пакетов,
я смотрю по ntsysv, что пускается и отключаю ненужные сервисы типа
sendmail (на 25м порту он висеть не будет, но сервисы, типа cron, почту
посылать будут)
Этап 4. Настройка того, что осталось.
Первым делом я правлю /etc/aliases, что бы вся почта на root сыпалась туда,
куда надо. Затем, что бы изменения вступили в силу, запускаю newaliases.
Затем проверяю /etc/hosts, /etc/sysconfig/network на соответствие реальным
значениям.
Затем правлю /etc/resolv.conf
[root@vpn root]# cat /etc/resolv.conf
nameserver 172.16.0.10
nameserver 127.0.0.1
Первый сервер в списке - это DNS сервер в локальной сети, который по
умолчанию разбирается со всеми именами. Вторая строчка - это локальный
DNS, поднятый в кеширующем режиме. Зачем я это сделал? Хоть DNS трафик
и не большой, но лишнее гонять не охота. Таким образом, все DNS запросы
собираются в одном месте. На тот же случай, если по какой-то причине не
будет связи, будет использоваться локальный DNS.
Затем я поправил /etc/named.conf на предмет того, что бы bind не принимал
запросы со всех запущенных интерфейсов. Это делается просто: в секции
options просто добавляем одну строчку:
listen-on { 127.0.0.1; };
Теперь при перезагрузке bind будет сидеть только на lo.
Теперь очередь apache: правим httpd.conf в районе директив BindAddress и
Listen, что бы httpd не глядел наружу - ибо на нем будут крутиться тестовые
версии и к ним совсем не следует давать доступа снаружи.
Все. Можно для пущей уверенности перезагрузить сервер что бы поглядеть, что
все, что надо, поднимается так, как надо и в нужной последовательности.
В моем случае все загрузилось хорошо и замечательно.
Смотрим:
[root@vpn root]# netstat -npl|grep LIST
tcp 0 0 172.16.0.250:80 0.0.0.0:* LISTEN 1136/httpd
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 688/named
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 709/sshd
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 688/named
tcp 0 0 172.16.0.250:443 0.0.0.0:* LISTEN 1136/httpd
[root@vpn root]#
Как видим, наружу должен смотреть только один ssh. Причин не доверять нет,
но на всяк случай проверим с удаленного хоста с помощью nmap:
(The 1541 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
В общем все. Первоначальная настройка сервера закончена. Можно устанавливать
и настраивать все необходимое для реальной работы.
Этап 5. Установка VPN сервера.
Берем и ставим pptpd-1.1.2, входящий в комплект ASPLinux. Проверяем по
ntsysv, что сервис pptpd запускается по умолчанию.
Внимательно смотрим на файл /etc/pptpd.conf и редактируем его.
Я поправил следующие строки
option /etc/ppp/options.pptpd
Здесь будут храниться настройки PPP для PPTP
localip 172.16.0.250
remoteip 172.16.0.230-249
Это я указал диапазон адресов, который будет назначаться VPN клиентам.
Больше ничего не менял.
Теперь возьмем файл /etc/ppp/options.pptpd
lock
mtu 1490
mru 1490
ipcp-accept-local
ipcp-accept-remote
lcp-echo-failure 3
lcp-echo-interval 5
deflate 0
auth
+chap
-pap
proxyarp
ms-dns 172.16.0.10
+chapms
+chapms-v2
nobsdcomp
nodeflate
nodefaultroute
+mppe-40
+mppe-128
+mppe-stateless
В принципе тут все понятно, кроме строчек mppe-40 и mppe-128. Они включают
вообще какое-либо шифрование (mppe-40) и разрешают 128 битное шифрование
(mppe-128).
Ну вот теперь можно и запустить pptpd: /etc/init.d/pptpd start
Все должно запуститься без проблем. Если что-то не то, то включайте debug
в обеих файлах и разбирайтесь. У меня практически все сразу с первого раза
заработало.
Прописываем в файле /etc/ppp/chap-secrets логины и пароли в виде
логин * пароль *_или_конкретный_ip_для_клиента
Тут необходимо сделать маленькое лирическое отступление: как VPN клиенты
будут выходить в интернет? Потому что после поднятия VPN реальное соединение
с интернет "замаскируется" и просто так посмотреть страничку уже не
получится ...
Здесь мы уходим в область настройки файрволла и роутинга, что само по себе
легко потянет на отдельную статью. Ниже я приведу лишь САМОЕ необходимое,
что я включаю в файл, отвечающий за файрволл.
echo 1 > /proc/sys/net/ipv4/ip_forward
Эта строчка отвечает за включение пересылки пакетов. Без нее клиент получит
адрес и все - никуда не уйдет и не выйдет.
Случай 1. Клиент выходит наружу через VPN сервер. Тогда просто даем строчку:
iptables -t nat -A POSTROUTING -s 172.16.0.0/24 -j MASQUERADE
(172.16 - это внутреняя подсеть). Этой командой я включил маскарадинг
ip адресов. Подробнее - читайте iptables-tutorial и прочую документацию
Случай 2. VPN сервер стоит отдельно от главного роутера.
Здесь мы воспользуется так называемым source based policy routing.
echo 200 multik >> /etc/iproute2/rt_tables
Добавляем таблицу роутинга
ip rule add from 172.16.0.249 table multik
добавляем ip адрес в таблицу роутинга (172.16.0.249 я назначил для себя в
chap-secrets)
ip route add default via 172.16.0.10 dev eth1 table multik
Говорим, что бы все, что попадает в таблицу роутинга multik, отправлялось
не по обычному маршруту, а на 172.16.0.10 (роутинг-сервер в моей сети).
ip route flush cache
Принимаем изменения в силу. За разьяснениями обращайтесь на
http://www.linuxguruz.org/iptables/howto/2.4routing-4.html.
Теперь берем первую попавшуюся под руки Win2000 или WinXP, говорим создать
VPN соединение, указываем адрес VPN сервера, вводим логин с паролем и
наслаждаемся всеми преимуществами VPN.
Этап 6. Установка MySQL и прочего.
Тут я писать ничего не буду, потому что установку и настройку MySQL, apache,
php и прочего я описывал раза три точно в разных вариациях. ;-)
(с) 2003 Вячеслав Калошин multik@multik.ru
Отдельное спасибо Александру Каневскому kad@asplinux.ru за помощь.
Для размещения своего сайта в Интернете вам понадобится компания компания, предоставляющая услуги хостинга. Обратите внимание на компанию Good-host.net, которая на протяжении уже 3 лет предлагает дешёвый хостинг с возможностью выбора панели управления!
<<< Назад
Перепечатка и копирование материалов с сайта запрещены!
|
|