253 подписчика

Установка и настройка системы распределения трафика на базе Linux.

22 октября 202122 окт 2021

38 мин

Оглавление

Этап 1. Общая подготовка сервера.
Этап 2. Настройка прокси-сервера.
Этап 3. Настройка фаервола.

Здравствуйте!

В этой статье я хочу рассмотреть установку и настройку системы контроля и распределения доступа интернет трафика. Также, коснусь темы соединения двух офисов через openvpn. Операционную систему для этого буду использовать Fedora 13 — это один из самых популярных дистрибутивов Линукса.

Этап 1. Общая подготовка сервера.

Наша система будет состоять вот из этих основных компонентов:
- Samba
- Squid
- ClamAV
- C-icap
- Apache
- MySQL
- SAMS
- Iptables
- NetAMS
- OpenVPN

Машину для этого я выбрал достаточно простую: Intel E4500/Intel BLKDQ45CB/1Gb DDR2-6400/два WD2500JS, соединённых в raid1.
Приступим к установке. На этапе, когда установщик попросит указать имя машины, укажем, к примеру router.mydomain.domain, где mydomain.domain — это название вашего домена Active Directory. Далее, когда установщик будет спрашивать о том, какое дисковое пространство использовать, выбираем «всё пространство». И, если нужно что-то изменить, то ставим галку «просмотр и изменение разбиения разделов». Я под раздел /home выделил 50Gb, под swap — 2Gb, а всё остальное — под корневой раздел. После сохранения изменений на диск, выберем только нужные нам пакеты для установки. Лишнее уберём.

Итак:

В графических средах снимаем все галки. Иксы нам не нужны.
В приложениях тоже снимаем все галки.
Программирование — там ничего не отмечено по умолчанию. Так и оставляем
Серверы — тут отметим следующее:
- База данных MySQL
- Веб-сервер
- Сервер службы каталогов
Базовая система:
- Основные
- Поддержка оборудования
- Системные средства. Но зайдём внутрь и оставим галки лишь на тех компонентах, которые нам могут понадобиться:
- mc
- ntp
- openvpn
- samba-client
- yum-utils
Языки не отмечаем никакие.

Ждём, пока система установится. Заходим в систему под рутом. Первое, что нам надо сделать — это получить доступ к сети. Для этого откроем консольный файловый менеджер midnight commander:

mc

Заходим в каталог /etc/sysconfig/network-scripts. Я предполагаю, что на вашей машине присутствует, как минимум, две сетевые карты. Одна вставлена в PCI слот, а другая интегрирована в материнскую плату. Если это так, то, обычно, файл ifcfg-eth0 будет для сетевой карты PCI-ного слота, а файл ifcfg-eth1 будет для интегрированной сетевой карты. Соответственно, интернетовский шнур будет воткнут в PCI-сетевуху, а шнур локальной сети — в интегрированную сетевуху. Пропишем адреса для обеих сетевых карт.

Поставим курсор на файл ifcfg-eth0 и нажмём F4. Откроется текстовый редактор, встроенный в mc. Приводим файл примерно к такому виду:

DEVICE=eth0
HWADDR=xx:xx:xx:xx:xx:xx # mac-адрес сетевого интерфейса
ONBOOT=yes
IPADDR=xxx.xxx.xxx.xxx # ваш ip-адрес
NETMASK=255.255.255.xxx # ваша маска сети
GATEWAY=xxx.xxx.xxx.xxx # ваш шлюз
DNS1=xxx.xxx.xxx.xxx # ваш DNS-сервер
DNS2=xxx.xxx.xxx.xxx # ваш альтернативный DNS-сервер

Правим файл ifcfg-eth1:

DEVICE=eth1
HWADDR=xx:xx:xx:xx:xx:xx # mac-адрес сетевого интерфейса
ONBOOT=yes
IPADDR=192.168.1.100 # ваш ip-адрес
NETMASK=255.255.255.0 # ваша маска сети
DNS1=192.168.1.200 # ваш DNS-сервер
DNS2=192.168.1.201 # ваш альтернативный DNS-сервер
SEARCH="mydomain.domain" # ваш локальный домен Active Directory
DOMAIN="mydomain.domain" # ваш локальный домен Active Directory

После того, как прописали адреса и сохранили файлы ifcfg-eth0 и ifcfg-eth1, наберём в командной строке:

ntsysv

Откроется консольный редактор автоматического запуска сервисов. Нам нужно снять крыж с NetworkManager и поставить крыж возле network. Сохраняем и перезагружаемся. После перезагрузки, нам надо отредактировать файл /etc/resolv.conf. Приведём его вот в такой вид:

search maydomain.domain
nameserver xxx.xxx.xxx.xxx # IP-адрес вашего локального DNS-сервера
nameserver xxx.xxx.xxx.xxx # IP-адрес вашего альтернативного локального DNS-сервера
nameserver xxx.xxx.xxx.xxx # IP-адрес DNS-сервера вашего провайдера

И, на всякий случай, даём команду:

chattr +i /etc/resolv.conf

чтобы запретить любую модификацию этого файла.
Затем, нужно попробовать обновить систему. Важно! Сначала надо обновить сам менеджер пакетов yum! На практике встречалось, что обновление может не пойти, пока не обновишь сам yum. Итак, делаем:

yum -y update yum

И вот только после этого запускаем обновление всей системы:

yum -y update

После успешного обновления надо перезагрузить систему.

Теперь, стоит отметить один важный момент, который касается настройки вашего локального DNS-сервера. У меня их два, и подняты они на двух контроллерах домена Windows server 2008 R2. В свойствах каждого сервера надо настроить пересылку на DNS-сервера провайдера тех запросов, которые не может обработать ваш локальный DNS-сервер. DNS-сервер провайдера нужно поставить в самый верх:

Теперь, пришло время немного подстраховаться на некоторые случаи жизни. Поскольку, наш сервер будет напрямую «смотреть» в интернет, то желательно запретить заходить на него под суперпользователем через ssh. Откроем файл /etc/ssh/sshd_config, в нём раскомментируем и отредактируем строчку:

PermitRootLogin no

Сохраним файл. Теперь, через ssh мы на сервер сможем зайти только под любым обычным пользователем. Кстати, давайте его и создадим:

useradd admin
passwd admin

Мы добавили пользователя admin и назначили ему пароль.

Вторая подстраховка, которую необходимо сделать — это посадить сервер на ИБП и настроить его автовыключение при низком заряде батареи. Для этого мы возьмём ИБП APC Back-UPS ES 525 и программу Apcupsd. Будем считать, что вы уже подключили ИБП к серверу через USB-интерфейс. Теперь, устанавливаем Apcupsd:

yum -y install apcupsd

Для настройки Apcupsd я воспользовался вот этой статьёй. Итак, после установки программы, отрываем файл /etc/apcupsd/apcupsd.conf и правим там лишь некоторые строчки:

BATTERYLEVEL 10
# уровень заряда батареи, при котором сервер начнёт выключаться

MINUTES 8
# оставшееся время работы батареи, меньше которого сервер начнёт выключаться
NISIP 127.0.0.1

Наберём команду ntsysv и отметим в меню apcupsd, чтоб этот сервис запускался при запуске сервера. После этого, можно продолжать, не опасаясь проблем с электричеством.

Мы будем рассматривать случай, когда сервер будет использоваться в сети с доменом Active Directory. Для этого, нам нужно ввести сервер в домен. А для этого нам понадобится SAMBA. Проверьте, чтоб у вас были установлены следующие пакеты:

samba
samba-client
samba-common
samba-winbind
samba-winbind-clients

Если таковые установлены, то приступим к следующему шагу приготовления сервера к вводу в домен. Нам нужно открыть некоторые порты на фаерволе, который называется iptables. Находим файл /etc/sysconfig/iptables и приводим его вот к такому виду:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 137 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 138 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 139 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 445 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 631 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 631 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

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

service iptables restart

Также, нам нужно перевести в разрешающий режим систему принудительного контроля доступа SELinux. Находим файл /etc/selinux/config , находим в нём строчку SELINUX=enforcing и меняем её на SELINUX=disabled.

Далее, чтобы потом избежать кое-какие проблемы с самбой, настроим синхронизацию времени с контроллерами домена. Найдём файл /etc/ntp.conf, а в нём найдём строки:

server 0.fedora.pool.ntp.org
server 1.fedora.pool.ntp.org
server 2.fedora.pool.ntp.org

и заменим их на строчки, в которых серверами NTP будут указаны контроллеры домена:

server 192.168.1.200
server 192.168.1.201

Сохраняем и включаем демон ntpd в автозагрузку:

chkconfig ntpd on

И сейчас надо перезагрузить систему.

Ну вот, теперь можно настраивать самбу. Сам я пользовался вот этой статьёй. Тем не менее, здесь мы это ещё раз всё рассмотрим пошагово. Для начала, отредактируем файл /etc/krb5.conf. Его нужно привести в аналогичный вид:

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = true
renew_lifetime = 7d
default_realm = MYDOMAIN.DOMAIN

# У меня в домене присутствует два контроллера домена (с адресами 192.168.1.200 и 192.168.1.201).
# Если у вас он всего один, то лишнее уберите.
[realms]
mydomain.domain = {
kdc = 192.168.1.200
kdc = 192.168.1.201
admin_server = 192.168.1.200
admin_server = 192.168.1.201
default_domain = mydomain.domain
}

[domain_realm]
.mydomain.domain = MYDOMAIN.DOMAIN
mydomain.domain = MYDOMAIN.DOMAIN

И не забывайте соблюдать регистр, когда будете подставлять свои значения для контроллеров домена и названия домена.
Далее, находим файл /etc/samba/smb.conf и приводим его в аналогичный вид:

[global]
log file = /var/log/samba/log.%m
socket options = TCP_NODELAY SO_SNDBUF=8192 SO_RCVBUF=8192
null passwords = yes
interfaces = eth1
hosts allow = 192.168. 127.0.0.1
winbind uid = 50-99999999
winbind gid = 50-99999999
auth methods = winbind
winbind enum groups = yes
winbind enum users = yes
winbind use default domain = yes
name resolve order = hosts wins bcast lmhosts
case sensitive = no
dns proxy = no
server string = Linux
netbios name = router
password server = 192.168.1.200 192.168.1.201
realm = MYDOMAIN.DOMAIN
client signing = yes
local master = no
domain master = no
workgroup = MYDOMAIN
debug level = 2
security = ads
dos charset = 866
max log size = 50
os level = 0

Опять же, не забываем про регистр.
Последний файл, который нам надо подправить, это /etc/nsswitch.conf. Находим в нём следующие строчки:

passwd: files
shadow: files
group: files

И правим их до такого вида:

passwd: files winbind
shadow: files
group: files winbind

После того, как мы отредактировали все конфигурационные файлы, нам надо запустить/перезапустить и включить в автозапуск некоторые демоны (сервисы). Для начала, набираем команду ntsysv. Поставим звёздочку напротив демонов nmb, smb и winbind. Таким образом, мы включили эти демоны в автозапуск. А сейчас запустим/перезапустим их вот такими командами:

service smb restart
service nmb restart
service winbind restart

Хорошо. Теперь попытаемся включить наш сервер в домен Active Directory. Вводим следующую команду:

kinit Admin@MYDOMAIN.DOMAIN

Где Admin — это учётная имя пользователя AD, имеющего права администратора домена. Если всё нормально, то, к примеру, в моём случае, должно быть типичное линуксовое молчание после ввода пароля. Молчит, значит всё в порядке :) Если же у вас это не так, то вот возможные проблемы на этом этапе:

kinit: krb5_get_init_creds: Client (Admin@MYDOMAIN.DOMAIN) unknown — Надо проверить правильность ввода логина\пароль админа.

kinit: krb5_get_init_creds: unable to reach any KDC in realm (MYDOMAIN.DOMAIN) — Проверьте правильность настроек DNS и конфига krb5.conf

kinit: krb5_get_init_creds: Clock skew too great — Рассинхронизация времени на контроллере домена и клиентом

Итак, если же проблем нет, то выполняем вторую команду:

net ads join -U Admin

Если у вас выйдет сообщение:

Using short domain name — MYDOMAIN
Joined 'SAMBA' to realm 'mydomain.domain'

то значит всё в порядке. Перезагрузимся.

Теперь, давайте проверим, хорошо ли наш SAMBA-сервер чувствует себя в домене. Вводим команду:

wbinfo -t

Вывод должен быть таким:

checking the trust secret via RPC calls succeeded

Проверим пользователей и группы. Эти команды должны вывести список пользователей и групп АД:

wbinfo -u
wbinfo -g

Проверяем аутентификацию в домене:

wbinfo -a user%123

где user — пользователь домена, 123 — пароль. Если ответ:

plaintext password authentication succeeded
сhallenge/response password authentication succeeded

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

id user

Команда должна вывести id пользователя домена и группы, к которым он относится.

Теперь, когда наш сервер в домене Active Directiry, перейдём к следующему этапу:

Этап 2. Настройка прокси-сервера.

Итак, все тесты пройдены, мы в домене, SAMBA настроена правильно — переходим к следующему этапу. Настроим прокси-сервер, который называется squid. Мне в этом помогла вот эта статья. Находим файл /etc/squid/squid.conf и приведём его вот к такому виду:

# TAG: http_port

http_port 192.168.1.100:3128
visible_hostname 192.168.1.100

dns_nameservers xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx
# Здесь нужно указать ДНС-серверы вашего провайдера (через пробел).

hierarchy_stoplist cgi-bin ?
# squid не будет кешировать динамически генерируемые страницы (поисковые сервера, некоторые другие серверы и чаты),
# а будет напрямую перенаправлять запрос серверу

coredump_dir /var/spool/squid
# Указываем куда сбрасывать core

# TAG: cache_mem (bytes)

cache_mem 256 MB
# сколько оперативной памяти сквид может забрать под свои нужды.

maximum_object_size 2048 KB
# максимальный размер объектов, которые будут сохранены на диск.

maximum_object_size_in_memory 1024 KB
# максимальный размер объектов, которые будут сохранены в кэше.

# TAG: cache_dir

cache_dir ufs /var/spool/squid 3096 16 256
# указывает сквиду, где сохранять кешируемые файлы. Указывает отдать под кеш 3096 мегабайт и
# создать 16 и 256 соответственно каталогов 1го и 2го уровня.
# Про каталоги сами все поймёте, когда загляните в место, где у сквида кэш.

# TAG: cache_access_log
# TAG: cache_log
# TAG: cache_store_log
# TAG: ftp_user

# в этих строках мы указываем сколько времени в минутах объект в кеше считается свежим
# и какой процент объектов оставлять с последнего обновления
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320

# TAG: redirect_program
# redirect_program /etc/squid/redirector.sams
# Позже, здесь можно будет указать путь к редиректору.

# TAG: redirector_access

# TAG: auth_param

auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --require-membership-of="MYDOMAIN\\Пользователи домена"
auth_param ntlm children 50
auth_param ntlm keep_alive on

auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic --require-membership-of="MYDOMAIN\\Пользователи домена"
auth_param basic children 50
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off

# TAG: acl

acl manager proto cache_object
# назначить протоколу кеширования объектов название manager

acl localhost src 127.0.0.1/32 192.168.1.100/32
# адрес сервера

acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
# удалённые адреса

acl localnet src 192.168.0.0/16
# адресное пространство локальной сети

acl SSL_ports port 443
acl Safe_ports port "/etc/squid/allowports.txt"
# разрешённые порты

acl CONNECT method CONNECT

# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager

http_access deny !Safe_ports
# Запрет всех портов, кроме разрешённых

http_access deny CONNECT !SSL_ports
# Запрет всех SSL портов, кроме разрешённых

http_access deny to_localhost

# TAG: http_access

http_access allow localhost
# разрешить доступ с сервера

http_access deny all
# запретить всё остальное

# TAG: delay_pools

После этого, создадим в папке /etc/squid файлик allowports.txt и заполним его списком разрешённых портов:

nano allowports.txt

содержимое файла будет таким:

80
8080
443

В будущем, в него можно будет дописать какие-нибудь специфические порты, которые могут использоваться на специфических сайтах.
Чтобы фаервол не препятствовал нам пользоваться сквидом, надо в iptables добавить ещё одно правило, которое откроет порт 3128. Подправим наш файл /etc/systemconfig/iptables:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 137 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 138 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 139 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 445 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 631 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 631 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 3128 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

Перезапустим iptables и пробуем запустить squid:

service iptables restart
service squid start

Если squid запустился, то в конфигурационном файле нет ошибок. Запустим ntsysv и поставим крыж рядом со squid. Теперь он будет стартовать при загрузке, и можно продолжать дальше.

Следующим шагом будет установка программы SAMS. Перед установкой и настройкой, рекомендую прочесть документацию. Готовые пакеты самса можно поискать тут. В своём случае, я пересоберу вот этот пакет под свою систему, выполнив вот такие команды:

yum -y install rpm-build mysql-devel pcre-devel php-gd
wget http://www.nixdev.net/release/sams/packages/Fedora_12/src/sams-1.0.5-91.1.src.rpm
rpmbuild --rebuild sams-1.0.5-91.1.src.rpm

После чего, получу готовый пакет в каталоге /root/rpmbuild/RPMS/i386. И установлю его:

rpm -i sams-1.0.5-91.1.i386.rpm

Однако, для того, чтобы программа работала нормально, надо сделать ещё кое-какие приготовления. Кое-что мне разъяснили на официальном форуме. И кое-что ещё написано тут. Поэтому, приступим всё это делать. Запустим и включим в автозагрузку следующие демоны:

service mysqld start
chkconfig mysqld on
service httpd start
chkconfig httpd on

Отредактируем файл конфигурации php /etc/php.ini. Находим и приводим в соответствующий вид строчки:

safe_mode = On
safe_mode_exec_dir = "/usr/share/sams/bin"

Теперь, находим каталог /usr/share/sams/src, в котором нас интересуют два файла: configtray.php и webconfigtray.php. В этих файлах нам надо найти слово «GetHostName» и заменить его на «GetHostName_».

Для большей безопасности, надо поставить в MySQL пароль на root, т.к., по умолчанию, он отсутствует:

mysql -u root
SET PASSWORD FOR 'root'@'localhost' = PASSWORD('ваш_пароль');

Теперь можно приступить к правке конфига самого SAMS, который лежит в каталоге /etc. Он совсем небольшой и будет выглядеть так:

[client]
SQUID_DB=squidlog
SAMS_DB=squidctrl
MYSQLHOSTNAME=localhost
MYSQLUSER=sams
MYSQLPASSWORD= # пароль на пользователя sams в MySQL
MYSQLVERSION=5.1
SQUIDCACHEFILE=access.log
SQUIDROOTDIR=/etc/squid
SQUIDLOGDIR=/var/log/squid
SQUIDCACHEDIR=/var/spool/squid
SAMSPATH=/usr
SQUIDPATH=/usr/sbin
SQUIDGUARDLOGPATH=/var/log
SQUIDGUARDDBPATH=/var/db/squidguard
RECODECOMMAND=iconv -f KOI8-R -t 866 %finp > %fout
LDAPSERVER=192.168.1.200 # контроллер домена
LDAPBASEDN=mydomain.domain # домен Active Directory
LDAPUSER=admin # имя пользователя, входящего в группу администраторы домена
LDAPUSERPASSWD= # пароль администратора AD
LDAPUSERSGROUP="Пользователи домена" # группа, в которую входят пользователи домена AD.
REJIKPATH=/usr/local/rejik
SHUTDOWNCOMMAND=shutdown -h now
CACHENUM=0

Чтобы мы могли пользоваться web-интерфейсом самса, нам нужно открыть порт 80 на фаерволе. Не буду снова тут приводить весь конфиг. Добавим под правилом для сквида ещё одно правило, открывающее порт 80:

-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT

Не забываем перезапустить iptables. Теперь, открываем браузер, и переходим на страничку самса по адресу http://192.168.1.100/sams/, где 192.168.1.100 — адрес вашего сервера. Жмём кнопку «Run SAMS database installation script». Появятся поля, в которых надо ввести:

MySQL Hostname — адрес хоста c MySQL сервером. У нас это localhost
MySQL login — имя суперпользователя для MySQL. У нас это root
MySQL password — пароль на этого суперпользователя, который мы недавно назначили.
SAMS MySQL user password — пароль на пользователя sams, который создастся этим скриптом.

Жмём «Create database». И если нам крупными буквами вылезет надпись «SAMS databases created», то жмём кнопочку «Starting SAMS webinterface», и добро пожаловать в SAMS! По умолчанию в SAMS зайти под администратором можно, введя логин admin и пароль qwerty, которые, естественно, надо сразу же поменять. Я не буду вдаваться во все особенности и тонкости работы SAMS. Это вам придётся изучить из документации. Я лишь приведу скриншот своих настроек, с которыми самс берёт пользователей из Active Directory.

Дальше уже дело техники: импортировать пользователей из AD, создать списки плохих сайтов, расставить квоты и прочие админские гадости.

Когда сделаете все настройки, то не спешите сразу нажимать кнопку «переконфигурировать squid». Сначала запустите демон sams, который передаст эти настройки сквиду:

service sams start

Этап 3. Настройка фаервола.

Для начала давайте скачаем и установим программу, которая нам существенно облегчит жизнь при прописывании правил в iptables — программу webmin. Перейдём на сайт http://www.webmin.com и скачаем эту программу в виде готового rpm-файла. Затем, установим его:

rpm -i webmin-1.520-1.noarch.rpm

Теперь, нужно подготовить iptables. Найдём файл /etc/sysctl.conf и поправим там одну строчку:

net.ipv4.ip_forward = 1

Также, сделаем вот такую команду:

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

Таким образом мы включили так называемый forwarding пакетов в iptables. Найдём, теперь, файл /etc/sysconfig/iptables-config. В нём тоже приведём соответствующую строчку вот в такой вид:

IPTABLES_MODULES="nf_conntrack_ftp ip_nat_ftp ip_queue"

Эти модули нам будут нужны. Вот теперь можно приступать к настройке Iptables. Вообще, эта программа, сама по себе, является целой наукой. Однако, нам от неё нужно немногое. Нам нужно, чтоб iptables позволяла нашим рабочим станциям пользоваться такими элементарными вещами, как, например, электронная почта и ICQ. Давайте, попробуем это настроить. Откроем файл /etc/sysconfig/iptables и приведём его вот к такому виду:

*nat
:OUTPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
# для ICQ и почты
-A POSTROUTING -p tcp -m tcp -m multiport -o eth0 -j SNAT --to-source <IP-адрес интернет-сетевухи> --dports 5190,110,25
# для FTP
-A POSTROUTING -p tcp -m tcp -o eth0 --dport 21 -j SNAT --to-source <IP-адрес интернет-сетевухи>
# для DNS
-A POSTROUTING -p tcp -m tcp -o eth0 --dport 53 -j SNAT --to-source <IP-адрес интернет-сетевухи>
-A POSTROUTING -p udp -m udp -o eth0 --dport 53 -j SNAT --to-source <IP-адрес интернет-сетевухи>
COMMIT
*filter
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state -i lo --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m state --state ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
# Правилами ниже, мы открываем любой трафик на локальный интерфейс.
# Получается, что с локальной сети к серверу можно будет подключиться по любому порту,
# а вот по внешнему интерфейсу на сервер никто не залезет.
-A INPUT -i eth1 -j ACCEPT
-A INPUT -j DROP
# Правила ниже позволяют нам осуществлять тот самый форвординг, который мы недавно включили.
# Иными словами, благодаря этим правилам, рабочие станции могут «видеть» ресурсы за сервером.
# А вот уже какие адреса и по каким портам они будут «видеть» — это мы уже разрешили теми правилами выше.
-A FORWARD -m state -i lo --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -m state --state ESTABLISHED -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -i eth1 -j ACCEPT
-A FORWARD -i eth0 -j ACCEPT
-A FORWARD -j DROP
COMMIT
*mangle
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT

После того, как вы отредактировали iptables, не забываем перезапустить сам сервис iptables. А после этого, давайте попробуем подключиться к серверу с помощью программы webmin. Открываем любой браузер и вводим http://192.168.1.100:10000, где 192.168.1.100 — локальный адрес вашего сервера. Выйдет запрос логина и пароля. Логином будет root, паролем будет пароль от root. После удачного входа систему нам раскроется нехилый web-интерфейс, с помощью которого можно делать весьма разнообразные манипуляции с сервером. Но нас в нём пока интересует лишь фаервол. Поэтому, в меню слева переходим Networking -> Linux Firewall. Вот здесь то мы и увидим, как в вебмине выглядят правила, которые мы прописали:

Вверху есть переключатель, на котором написано «Packet filtering (filter)». Это означает, что в данный момент нам отображается только таблица filter. Переключим его в «Network address translation (nat)». Теперь нам отобразится таблица nat. И именно здесь мы видим, по каким портам наши рабочие станции смогут «видеть» сеть за сервером:

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

Этап 4. Настройка ВПН между двумя офисами.

Последним шагом в настройке нашего сервера будет настройка VPN-соединения между удалёнными офисами. Для этого, мы также будем пользоваться программой Webmin. Я пользовался, опять же, вот этой статьёй. Проверьте, чтобы были установлены пакеты openvpn и bridge-utils. Потом, нужно будет установить дополнительный модуль для webmin.

Открываем webmin, переходим в левом меню на webmin --> webmin configuration, жмём на значок «Webmin Modules». В поле «From ftp or http URL» вставляем ссылку http://www.openit.it/downloads/OpenVPNadmin/openvpn-2.5.wbm.gz и жмём на «install module». После установки модуля, вы увидите, что появился новый пункт «OpenVPN + CA» в левом меню «Servers». Переходим в него, нажимаем кнопку настройки модуля и приводим настройки вот к такому виду:

Далее, надо сгенерировать сертификат. Заполняем поля примерно вот так:

Жмём «save». После того, как сгенерировался сертификат, нам надо создать ключи для сервера и клиентов. Рассмотрим вариант, что мы объединяем в ВПН два офиса. Если же в сеть будет объединяться более двух офисов, то ключ надо создавать для каждого офиса (клиента) свой. Жмём на значок «Certification Authority List» и генерируем ключи для сервера и для одного клиента:

После этого, снова переходим в самое начало меню «OpenVPN + CA» и там жмём на значок «VPN List», ну а там уже на кнопку «new vpn server». В появившемся окне выставляем настройки примерно так:

Поясню кое-какие пункты:

Bridge device — указывается, как у нас будет называться мост в системе.

Network Device for Bridge — eth1 (интерфейс локальной сети).

IP config for bridge: IP-Address/Gateway — указываем локальный IP адрес и маску нашего сервера, которые установлены на eth1.

IP-Range for Bridge-Clients — диапазон адресов, которые будут выдаваться VPN-клиентам.

Persist/unpersist ifconfig-pool data to file, at seconds intervals (default=600), as well as on program startup and shutdown (option ifconfig-pool-persist) — Эта опция позволяет запоминать серверу ip-адреса, которые присвоились тому или иному клиенту. Таким образом, у клиентов будут постоянные ip-адреса. Это нам позволит настраивать маршруты всевозможными способами.

Because the OpenVPN server mode handles multiple clients through a single tun or tap interface, it is effectively a router (option client-to-client) — позволяет клиентам видеть друг друга.

Encrypt packets with cipher algorithm (option cipher) — метод шифрования трафика между сервером и клиентом.

Don't re-read key files (option persist-key) — не перезапрашивать данные ключа

Don't close and reopen TUN/TAP device or run up/down scripts (option persist-tun) — не закрывать и не рестартовать TAP device при перезапуске соединения.

keepalive (A helper directive designed to simplify the expression of **ping** and **ping-restart** in server mode configurations) — контроль за состоянием соединений. В случае если по туннелю не передаются данные, через некоторое время посылается ping, для того чтобы соединение не разрывалось.

Additional Configurations: route 192.168.199.0 255.255.255.0 192.168.1.230 — здесь мы прописали маршрут для того, чтобы сервер мог видеть сетку за клиентом. За клиентом, которому присвоится ip-адрес 192.168.1.230. Мы заранее знаем, что за сервером клиента сеть имеется диапазон адресов 192.168.199.0/24.

Сохраняем. И жмём на надпись «client list»:

Дальше, нажимаем кнопку «new vpn client» и видим окно настроек впн-клиента, в котором ничего менять не нужно. Сохраняем его, как есть. Если же у вас несколько впн-клиентов, то вы должны были создать для каждого из них свой ключ, а в этом окне вам нужно будет сначала выбрать один из этих ключей и создать для него клиента.

После того, как создали клиента, жмём на текст «Export»:

Webmin вам предложит сохранить zip-файл. В этом файле содержится конфиг, сертификат и ключ для вашего клиентского офиса. Его нужно любым доступным способом скопировать на сервер, который будет являться клиентом. И уже там, его надо распаковать и всё содержимое положить в каталог /etc/openvpn. Далее, уже на машине, которая будет сервером openvpn, надо внести правку в вебминовские скрипты bridge_end и bridge_start, которые находятся в каталоге /usr/libexec/webmin/openvpn/br_scripts. В каждом из этих скриптов найдём строчки:

setbr=false
isbr=false
brexists=false
iseth=false
istap=false
isip=false
isnetmask=false
isgw=false
isnamesrv=false

И над ними добавим ещё одну, вот такую строчку:

PATH=$PATH:/usr/sbin/:/sbin/

Сохраним. Это мы сделали для того, чтобы запустился сервис openvpn. И после того, как мы отредактировали скрипты, запустим openvpn на сервере и на клиенте:

service openvpn start

После этого, нам надо будет добавить кое-какие правила в iptables как на сервере, так и на клиенте openvpn. Итак, на сервере, в цепочки INPUT и FORWARD нам надо добавить правила:

-A INPUT -i br0 -j ACCEPT
-A FORWARD -i br0 -j ACCEPT

В webmin они будут выглядеть так:

На клиенте в цепочки INPUT и FORWARD также добавим подобные правила:

-A INPUT -i tap0 -j ACCEPT
-A FORWARD -i tap0 -j ACCEPT

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

Если всё правильно, то обе машины должны пинговать удалённую локальную сеть друг друга, ровно как и рабочие станции удалённых офисов тоже должны обмениваться пингом друг с другом. Не забываем поставить сервис openvpn в автозапуск.
На этом всё! Теперь у нас есть полноценная система распределения, контроля и учёта трафика, а также офисы, соединённые в VPN.

Этап 5. Дополнения + исправление ошибок.

Это продолжение появилось в связи с тем, что в работе рассмотренной выше системы несколько проблем, которые связаны с прокси-сервером. И не только с ним. Но опишу по порядку.

Итак начну с того, что когда я пришёл на новую работу, то решил настроить свой роутер (система распределения трафика — я привык её называть просто роутером) не на i686 системе, а на x86_64, а также дополнил ещё кое-какими фишками. Одна из них — это кэширующий DNS-сервер, который помог не только снизить нагрузку на интернет канал, но и развязал руки ещё кое в чём.

Итак, DNS-сервер BIND (или ещё он имеет название Named), установка:

yum -y install bind bind-utils

после которой надо не забыть про одну тонкость (по крайней мере в федоре она есть): надо сразу дать доступ на каталог /var/named для пользователя и группы named:

chown -R named:named /var/named

Далее, видим, что в каталоге /etc появился конфигурационный файл /etc/named.conf, который я привёл вот к такому виду (отредактированные строчки сопровождены комментариями):

options {
listen-on port 53 { 127.0.0.1; 172.16.1.100; };
// тут я указал, на каких адресах будет доступен мой dns-сервер

// listen-on-v6 port 53 { ::1; };
// IPv6 закомментировал, ибо у меня только IPv4

directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";

allow-query { localhost; 172.16.0.0/23; };
// принимать обычные запросы можно только с самого себя и из локалки

forwarders { 8.8.8.8; 8.8.4.4; };
// Перенаправлять запросы, которые не может обработать сам, на публичные гугловские серверы

recursion yes;
allow-recursion { localhost; 172.16.0.0/23; };
// принимать рекурсивные запросы только от самого себя и из локалки

// dnssec-enable yes;
// dnssec-validation yes;
// dnssec-lookaside auto;
// закомментировал за ненадобностью этого мне.

/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
};

logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};

zone "." IN {
type hint;
file "named.ca";
};

zone "server.ru" {
type master;
file "server.ru";
// Полезная фишка, суть которой в следующем: есть у нас один сервак, который в локалке доступен
// под именем serv.mydomain.domain (или просто serv), а извне он доступен по адресу server.ru.
// Люди на него заходят через вэб-интерфейс и поэтому всё время путаются, по какому адресу
// заходить. Данная настройка избавляет от этой проблемы, делая доступным этот сервер по имени
// server.ru как из-вне, так и из локалки. Иными словами, для своего DNS-сервера я сделал свою
// DNS-зону для хоста server.ru. Её содержание я приведу чуть ниже.

zone "_msdcs.mydomain.domain" {
type slave;
file "_msdcs.mydomain.domain";
masters { 172.16.0.107;
172.16.0.108; };
};

zone "mydomain.domain" {
type slave;
file "mydomain.domain";
masters { 172.16.0.107;
172.16.0.108; };
};
// Ещё одна очень полезная фишка — здесь я настроил, чтоб мой роутер был также и вторичным
// уполномоченный DNS-сервером для домена Active directory. Это ему позволит не перенаправлять
// dns-запросы о локальных компах на контроллер домена, а обрабатывать их самостоятельно.

include "/etc/named.rfc1912.zones";

А вот содержание dns-зоны для хоста server.ru (надо сказать, что этот файл должен лежать в каталоге /var/named):

$TTL 3600
$ORIGIN ru.
server 3600 IN SOA router.mydomain.domain. me.mymail.ru. (
2012121200 ; serial
14400 ; refresh
3600 ; retry
2592000 ; expire
600 ; minimum ttl
)
$ORIGIN server.ru.
@ NS router.mydomain.domain.
A 172.16.0.103

Надо заметить, что в этом же каталоге будут лежать и файлы с зонами _msdcs.mydomain.domain и mydomain.domain, которые named скопирует с контроллеров домена.

Когда привели конфиги в порядок, запускаем наш bind (и ставим его в автозагрузку):

service named start
chkconfig named on

А в файле /etc/resolv.conf указываем, чтоб роутер использовал dns-сервером сам себя:

nameserver 127.0.0.1

И это ещё не всё. На контроллерах домена нужно не забыть сделать следующее:

1. в свойствах DNS-сервера указать сервером пересылки наш роутер.
И:

2. в свойствах зон _msdcs.mydomain.domain и mydomain.domain разрешить передачу зоны на наш роутер.

Далее, я обратил внимание, что у меня на роутере системное время отличалось аж на целый час. При этом, я проверил: демон ntpd работает нормально и время синхронизирует успешно. Тут я вспомнил, что Fedora 13 — уже старая система, которая была выпущена ещё до отмены летнего/зимнего времени. А за это отвечает пакет tzdata, который (в тринадцатой федоре) не знает, что у нас отменено летнее/зимнее время. Поэтому мне пришлось его пересобрать из src.rpm-ки от пятнадцатой федоры:

https://archive.fedoraproject.org/pub/archive/fedora/linux/updates/15/SRPMS/tzdata-2012c-1.fc15.src.rpm

Вот пересобранные пакеты под тринаху:

tzdata-2012c-1.fc13.noarch.rpm
tzdata-java-2012c-1.fc13.noarch.rpm

После его обновления, проблема с разницей во времени на час исчезла.

Далее требовалось, чтобы SAMS научился подставлять параметр -i к url_regex. Решение вроде хорошее, но, как выяснилось, его можно осуществить только с помощью правки исходников.

В исходниках самса надо найти файл samsdaemon.c. В этом файле находим строчки 874, 876, 922, и 924. Они будут выглядеть вот так соответственно:

fprintf(fout,"acl _sams_%s url_regex \"%s/%s.sams\"\n",row[1],conf.squidrootdir,row[1]);
printf("acl _sams_%s url_regex \"%s/%s.sams\"\n",row[1],conf.squidrootdir,row[1]);
.............................
fprintf(fout,"acl _sams_%s url_regex \"%s/%s.sams\"\n",row[1],conf.squidrootdir,row[1]);
printf("acl _sams_%s url_regex \"%s/%s.sams\"\n",row[1],conf.squidrootdir,row[1]);

Вот в них то и добавляем наш параметр -i. После чего выглядеть они будут вот так:

fprintf(fout,"acl _sams_%s url_regex -i \"%s/%s.sams\"\n",row[1],conf.squidrootdir,row[1]);
printf("acl _sams_%s url_regex -i \"%s/%s.sams\"\n",row[1],conf.squidrootdir,row[1]);
.............................
fprintf(fout,"acl _sams_%s url_regex -i \"%s/%s.sams\"\n",row[1],conf.squidrootdir,row[1]);
printf("acl _sams_%s -i url_regex -i \"%s/%s.sams\"\n",row[1],conf.squidrootdir,row[1]);

Потом надо пересобрать SAMS. Теперь, он будет создавать правила вот такого вида:

acl _sams_chat url_regex -i "/etc/squid/chat.sams"
acl _sams_porno url_regex -i "/etc/squid/porno.sams"

Но пересобирать было ещё рано. Потребовались ещё кое-какие изменения в исходниках, но об этом немного позже, сначала объясню, почему они потребовались.

Я нашел информацию, что оказывается в squid есть другая прозрачная авторизация, которая работает через kerberos. Её я и решил попробовать. И в этом мне помогла вот эта статья:

http://www.k-max.name/linux/avtorizaciya-autentifikaciya-squid

Сперва наперво, на контроллере домена надо создать keytab-файл и пользователя, с которым он будет ассоциироваться. Пользователь – это самый обычный пользователь без каких-либо особых привилегий. Называться он будет router, и пароль у него будет password.
Напомню, что у меня контроллер домена на Windows server 2008 R2. После того, как создали пользователя, открываем виндовую командную строчку и делаем вот такую команду:

ktpass /crypto ALL /princ HTTP/router.mydomain.domain@MYDOMAIN.DOMAIN /mapuser router /pass password /ptype KRB5_NT_PRINCIPAL /out C:\111\squid.keytab

где параметр /crypto ALL позволяет использовать любой тип шифрования
параметр /princ HTTP/router.mydomain.domain@MYDOMAIN.DOMAIN – это имя службы, с которой будет ассоциирован виндовый пользователь router.
Само собой, что вместо router.mydomain.domain@MYDOMAIN.DOMAIN вы должны подставить имя своего сервера со сквидом и название своего домена AD.
Параметр /ptype задает тип принципала. В значении этого параметра рекомендуется указывать KRB5_NT_PRINCIPAL, т.к. это подходит практически для всех служб.
параметр /out C:\111\squid.keytab – название keytab-файла и путь, куда его положить.

Итак, после выполнения этой команды получим файл C:\111\squid.keytab, который надо скопировать на наш роутер. Я его скопировал в каталог /etc/squid.

Далее, нам надо посмотреть, корректен ли наш keytab-файл. Вводим команду:

klist -e -k -t /etc/squid/squid.keytab

и если видим вот такой вывод:

Keytab name: WRFILE:/etc/squid/squid.keytab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
3 01/01/70 05:00:00 HTTP/router.mydomain.domain@MYDOMAIN.DOMAIN (DES cbc mode with CRC-32)
3 01/01/70 05:00:00 HTTP/router.mydomain.domain@MYDOMAIN.DOMAIN (DES cbc mode with RSA-MD5)
3 01/01/70 05:00:00 HTTP/router.mydomain.domain@MYDOMAIN.DOMAIN (ArcFour with HMAC/md5)
3 01/01/70 05:00:00 HTTP/router.mydomain.domain@MYDOMAIN.DOMAIN (AES-256 CTS mode with 96-bit SHA-1 HMAC)
3 01/01/70 05:00:00 HTTP/router.mydomain.domain@MYDOMAIN.DOMAIN (AES-128 CTS mode with 96-bit SHA-1 HMAC)

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

kdestroy

А потом введём команду:

kinit -k -t /etc/squid/squid.keytab HTTP/router.mydomain.domain@MYDOMAIN.DOMAIN

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

klist

Вывод должен быть примерно таким:

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: HTTP/router.mydomain.domain@MYDOMAIN.DOMAIN

Valid starting Expires Service principal
12/13/12 18:49:22 12/14/12 04:49:22 krbtgt/MYDOMAIN.DOMAIN@MYDOMAIN.DOMAIN
renew until 12/20/12 18:49:22

Кстати, не забудем изменить владельца на keytab-файл:

chown root:squid /etc/squid/squid.keytab

Затем, находим файл /etc/sysconfig/squid и в его конец добавляем две строчки:

KRB5_KTNAME=/etc/squid/squid.keytab
export KRB5_KTNAME

Кстати, я в этом же файле изменил параметр:

SQUID_SHUTDOWN_TIMEOUT=3

чтобы squid перезапускался быстрее, а не выжидал чёрт знает чего...
Ну а в конфиге самого сквида, я заменил ntlm-ную конструкцию:

auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --domain=MYDOMAIN --require-membership-of="\\Пользователи домена"
auth_param ntlm children 100
auth_param ntlm keep_alive on

На новую для авторизации через kerberos:

auth_param negotiate program /usr/lib64/squid/squid_kerb_auth -s HTTP/router.mydomain.domain@MYDOMAIN.DOMAIN
auth_param negotiate children 100
auth_param negotiate keep_alive on

После чего попробовал, как она работает. С первого раза не получилось. Начал выяснять, и оказывается я упустил важный момент: В браузере прокси-сервер должен быть прописан не по IP-адресу (как у меня было), а по fqdn-имени. Т.е. вот в таком виде: router.mydomain.domain. Как только это сделал, то сразу заработало, чем я был очень доволен!

И тут я снова перехожу к SAMS. Дело в том, что если его настроить вот так:

то он начинает заполнять файл с пользователями вот в таком виде:

MYDOMAIN.DOMAIN@user1
user1
MYDOMAIN.DOMAIN@user2
user2
MYDOMAIN.DOMAIN@user3
user3

А надо, чтоб было наоборот: пользователь@ДОМЕН. Да и в логах он ищет именно DOMAIN+user, а не user@DOMAIN.

Тут, как я уже понимал: снова надо править исходники. Наткнулся вот на эту ветку форума:

http://forum.lissyara.su/viewtopic.php?f=3&t=12858#p132898

В которой объясняется, что и где нужно подправить в исходниках самса, чтобы он прописывал пользователей по схеме пользователь@ДОМЕН и видел эту схему в логах сквида. Перекопирую его пост сюда:
Правим в исходниках файл samsdaemon.c. Строки 1886-1908. Меняем местами переменные row2[6] — домен и row2[1] — пользователь. Изменённый код получится вот таким:

for(k=1;k<strlen(SEPARATOR);k++)
{
if(BIGD==1)
{
str2upper((char *)row2[6]);
fprintf(fout,"%s%c%s\n",row2[1],SEPARATOR[k],row2[6]);
if(RREJIK==1&&atoi(row2[10])>0)
fprintf(fout2,"%s%c%s\n",row2[1],SEPARATOR[k],row2[6]);
}
else if(BIGD==-1)
{
Str2Lower(row2[6]);
fprintf(fout,"%s%c%s\n",row2[1],SEPARATOR[k],row2[6]);
if(RREJIK==1&&atoi(row2[10])>0)
fprintf(fout2,"%s%c%s\n",row2[1],SEPARATOR[k],row2[6]);
}
else
{
fprintf(fout,"%s%c%s\n",row2[1],SEPARATOR[k],row2[6]);
if(RREJIK==1&&atoi(row2[10])>0)
fprintf(fout2,"%s%c%s\n",row2[1],SEPARATOR[k],row2[6]);
}
}

Кстати на форуме есть одна опечатка — там он в одном месте забыл поменять row2[6] и row2[1]. После этой правки SAMS записывает пользователей в файл в нужном нам виде.

Теперь логи: в файле demon.c находим строки 209-214 и меняем их с такого вида: