Kiev1.org Карта сайта Файлы Фотографии Киева
  
Реклама:






Разделы
 
 Sysadmin
 Антиглобалисты
 Ереси и секты
 Катастрофы
 Компьютерные новости
 Непроверенное
 О проекте
 О фотогалерее
 Политика и власть
 Православие
 Предприятия Украины
 Протесты Людей против нового мирового концлагеря
 Разное
 Россия
 Старец Паисий 1924-1994
 Стояние за Истину
 Суды в Украине
 Тайна беззакония
 экуменизм


Внимание! Читая пророчества на этом сайте помните что достоверность трудно проверить и все может во времени изменяться - самое главное думать своей головой и не верить легкомысленно всему что говорят, особенно советское телевидение
"О дне же том, или часе, никто не знает, ни Ангелы небесные, ни Сын, но только Отец (Мк. 13, 32)"

Установка VPN Linux-сервера под ASP 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
Принимаем изменения в силу. За разьяснениями обращайтесь на
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 за помощь.



© Vadim Fedorov <fedorov@vadim.org.ua>

2003





 www.rusprav.ru "РУСЬ ПРАВОСЛАВНАЯ" СТОЛП РУССКОГО СТАРЧЕСТВА Светлой памяти Талабского (Залитского) старца протоиерея Николая Гурьянова (1910–2002)


Внимание! Читая пророчества на этом сайте помните что достоверность трудно проверить и все может во времени изменяться
"О дне же том, или часе, никто не знает, ни Ангелы небесные, ни Сын, но только Отец (Мк. 13, 32)"