Денис Фатеев unix:2010

Организация VPN-сети (часть восьмая)

Mon, 22 Nov 2010 08:59:00 +0000

На данный момент мы имеем частную VPN-сеть маршрутизаторов, развернутую поверх каналов провайдера. Осталось настроить маршрутизацию на роутерах, чтобы связать воедино локальные сети филиалов.

Головной филиал (сервер OpenVPN)

В конфигурационном файле сервера OpenVPN (/etc/openvpn/server.conf) добавляем маршруты на сети, находящиеся за роутерами филиалов (это можно сделать в том блоке, где был определён ccd-каталог). Убираем закомментированную строку и прописываем свои значения:

....
# EXAMPLE: Suppose the client
# having the certificate common name "Thelonious"
# also has a small subnet behind his connecting
# machine, such as 192.168.40.128/255.255.255.248.
# First, uncomment out these lines:
client-config-dir ccd
route 192.168.1.0 255.255.255.0
route 192.168.2.0 255.255.255.0
route 192.168.3.0 255.255.255.0
# Then create a file ccd/Thelonious with this line:
#   iroute 192.168.40.128 255.255.255.248
# This will allow Thelonious' private subnet to
# access the VPN.  This example will only work
# if you are routing, not bridging, i.e. you are
# using "dev tun" and "server" directives.
....

Этими директивами мы сообщаем OpenVPN-серверу, что указанные маршруты должны добавляться в системную таблицу маршрутизации при запуске службы и удаляться при остановке.

Включаем внутренний роутинг OpenVPN на сети филиалов. Переходим в каталог /etc/openvpn/ccd и редактируем файлы клиентских настроек, прописывая в каждый из них параметры сети, находящейся за ним.

На примере файла /etc/openvpn/ccd/filial2, должна получится такая картина:

ifconfig-push 10.10.0.5 10.10.0.6
iroute 192.168.1.0 255.255.255.0

Остальные файлы клиентских настроек в этом каталоге (filial3, filial4 и т.п.) – отредактируйте сами по аналогии.

Разрешаем форвардинг пакетов между интерфейсами в iptables (добавляем записи в файл /etc/sysconfig/iptables):

-A FORWARD -i eth1 -o tun0 -j ACCEPT
-A FORWARD -i tun0 -o eth1 -j ACCEPT

Здесь 'eth1' – интерфейс, которым маршрутизатор подключен в локальную сеть.

После внесения указанных изменений необходимо перезапустить openvpn и iptables:

[root@gateway1 ~]# /etc/init.d/openvpn restart
[root@gateway1 ~]# /etc/init.d/iptables restart

На основном маршрутизаторе сети головного филиала необходимо прописать маршруты на сети прочих филиалов, указав шлюзом наш маршрутизатор VPN-сети; либо для всех компьютеров сети назначить наш маршрутизатор шлюзом по умолчанию.

Дочерний филиал (клиент OpenVPN)

На VPN-маршрутизаторе филиала разрешаем форвардинг пакетов между интерфейсами в iptables (добавляем записи в файл /etc/sysconfig/iptables):

-A FORWARD -i eth1 -o tun0 -j ACCEPT
-A FORWARD -i tun0 -o eth1 -j ACCEPT

Здесь 'eth1' – интерфейс, которым маршрутизатор подключен в локальную сеть филиала.

Перезапускаем iptables:

[root@gateway2 ~]# /etc/init.d/iptables restart

Перезапускаем службу openvpn для форсированного переподключения к VPN-серверу:

[root@gateway2 ~]# /etc/init.d/openvpn restart

В локальной сети дочернего филиала на основном маршрутизаторе сети необходимо прописать маршруты на сети прочих филиалов, указав шлюзом наш VPN-маршрутизатор филиала; как вариант, назначить наш маршрутизатор шлюзом по умолчанию для всех машин в сети.

В результате вышеописанных действий, компьютеры сети основного филиала смогут обращаться к компьютерам дочерних филиалов, и наоборот – из дочернего филиала можно подключаться к компьютерам основного.

По умолчанию, каждая клиентская сеть может видеть только сеть основного филиала (а основной филиал «видит» всех клиентов), в большинстве случаев это необходимое условие по соображениям безопасности. Если всё же нужно, чтобы клиентские подсети могли обращаться друг к другу, на стороне OpenVPN-сервера нужно сделать некоторые дополнительные настройки:

Раскомментируем в конфигурационном файле /etc/openvpn/server.conf параметр 'client-to-client' (прочтите его назначение в комментариях);
Разрешаем форвардинг пакетов в iptables (добавляем запись в файл /etc/sysconfig/iptables):

-A FORWARD -i tun0 -o tun0 -j ACCEPT

После внесения изменений не забудьте перезапустить iptables и openvpn:

[root@gateway1 ~]# /etc/init.d/iptables restart
[root@gateway1 ~]# /etc/init.d/openvpn restart

На этом настройка нашей VPN-сети завершена. Проверьте, что компьютеры филиалов могут обращаться по друг к другу по IP-адресу (или по доменному имени, если настроена служба DNS).

В следующей, заключительной части, будут рассмотрены некоторые моменты в настройке, расширяющие функционал и показывающие детали, которые могли остаться «за кадром».

Организация VPN-сети (часть седьмая)

Организация VPN-сети (часть девятая)

linux, vpn, network

Read or add comments to this article

Организация VPN-сети (часть девятая)

Wed, 05 Jan 2011 06:35:00 +0000

Часто задаваемые вопросы:

1) Возможно ли ограничивать доступ к определенным ресурсам с отдельной машины или филиала?

В предыдущих заметках не используется фильтрация по параметрам клиента. С помощью правил iptables можно описать все параметры доступа для вашего конкретного случая; например, закрыть доступ по определенным портам или запретить обращения с/на некоторые IP-адреса. Обратитесь к руководству по iptables для получения дополнительной информации.

2) Почему компьютеры другого филиала не видны в моем «Сетевом окружении»?

Потому, что широковещательные пакеты не ходят через нашу VPN-сеть, и это создает видимость недоступности компьютеров удаленной сети для пользователей. Тем не менее, компьютеры доступны по SMB по IP-адресу или доменному имени, например \\192.168.1.120\. Если по какой-то причине вам нужно, чтобы VPN поддерживала broadcast, используйте режим TAP вкупе с объединением виртуального адаптера OpenVPN и LAN-интерфейса в мост (bridge).

3) Возможно ли организовать доступ удаленных клиентов в VPN-сеть через общедоступные сети (Интернет)?

Если политика безопасности вашей компании разрешает удаленный доступ, то технологически здесь нет никаких препятствий. На пограничном интернет-маршрутизаторе вашей компании обеспечиваете проброс OpenVPN-портов (в зависимости от вашей конфигурации, 1194/udp или 1194/tcp) на машину, которая служит OpenVPN-сервером; создаете ключи и сертификаты для удаленных клиентов. На клиентскую машину нужно установить OpenVPN-клиент (существуют версии под все распространенные ОС, в том числе для Windows) и указать в его конфигурации пару ключ/сертификат для подключения к VPN-серверу.

4) Хотелось бы считать трафик VPN-канала, причем с детализацией по времени и клиентам. Как это сделать?

Решений здесь много; наиболее привлекательным кажется вариант с Netflow (см. пример здесь) или аккаунтинга с помощью RADIUS-сервера. Чтобы облегчить администрирование больших распределенных сетей, возможно, следует подумать о покупке лицензии на OpenVPN Access Server. Недавно на Unixforum-е было обсуждение способов подсчёта трафика.

5) Как в VPN-сети разграничить трафик по приоритетам, ограничить ширину VPN-канала для определенных приложений?

Для системы, интерфейс OpenVPN (tun/tap) ничем не отличается от физических сетевых интерфейсов, поэтому к нему применимы все методы организации управления передачей данных (классы шейпера, очереди и т.п.) Развернутое руководство по настройке шейпинга можно найти здесь.

Для примера, вот несколько реальных конфигураций, действующих в нашей сети:

а) Установка приоритетов передачи трафика (QoS) без гарантирования пропускной способности для каждого из видов трафика (обычно используется в том случае, когда общей ширины канала достаточно и нужно «пропустить» некоторые пакеты впереди остальных, несколько уменьшив задержку при их передаче):

В /etc/sysconfig/iptables задаем правила маркировки нужного нам трафика:

# -- MANGLE table
*mangle
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# All VoIP-traffic with `mark 5`
-A POSTROUTING -o tun0 -p udp --sport 4569 -j MARK --set-mark 5
-A POSTROUTING -o tun0 -p udp --sport 5060 -j MARK --set-mark 5
-A POSTROUTING -o tun0 -p udp --sport 10000:12000 -j MARK --set-mark 5
# RDP-traffic with `mark 6`
-A POSTROUTING -o tun0 -p tcp --sport 3389 -j MARK --set-mark 6
# ICMP-traffic with `mark 6`
-A POSTROUTING -o tun0 -p icmp -j MARK --set-mark 6
# Some third-party applications
-A POSTROUTING -o tun0 -p tcp --dport 2221:2224 -j MARK --set-mark 7
-A POSTROUTING -o tun0 -p udp --dport 2221:2224 -j MARK --set-mark 7
-A POSTROUTING -o tun0 -p tcp --dport 3108:3111 -j MARK --set-mark 7
-A POSTROUTING -o tun0 -p udp --dport 3108:3111 -j MARK --set-mark 7
COMMIT

Взято из конфигурации VPN-сервера центрального филиала, поэтому критериями маркировки, в основном, служат tcp/udp-порты источника данных. В случае использования на клиентском роутере, требовалось бы маркировать пакеты по критерию «адрес/порт назначения».

Описываем очереди для трафика (этот блок можно поместить в /etc/rc.local):

tc qdisc add dev tun0 root handle 1: prio priomap 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 0
tc qdisc add dev tun0 parent 1:1 handle 10: sfq limit 3000
tc qdisc add dev tun0 parent 1:2 handle 20: sfq
tc qdisc add dev tun0 parent 1:3 handle 30: sfq
tc filter add dev tun0 protocol ip parent 1: prio 1 handle 5 fw flowid 1:1
tc filter add dev tun0 protocol ip parent 1: prio 1 handle 6 fw flowid 1:2
tc filter add dev tun0 protocol ip parent 1: prio 1 handle 7 fw flowid 1:2

Пакеты будут иметь приоритет в зависимости от метки (наибольший приоритет у пакетов, попадающих в очередь 1:1, т.е. маркированных меткой «0х05», остальные по нисходящей). Немаркированные пакеты имеют наименьший приоритет и идут очередью 1:3. Дополнительную информацию можно найти на HowtoForge и здесь.

б) Ограничение пропускной способности канала для каждого вида трафика (программа получает гарантированную полосу пропускания):

Конфигурация iptables остается такой же, как и в предыдущем примере; а вот правила шейпинга примут такой вид:

/sbin/tc qdisc add dev tun0 root handle 1: htb default 13
/sbin/tc class add dev tun0 parent 1: classid 1:1 htb rate 920kbit

/sbin/tc class add dev tun0 parent 1:1 classid 1:10 htb rate 128kbit ceil 512kbit prio 0
/sbin/tc class add dev tun0 parent 1:1 classid 1:11 htb rate 128kbit ceil 512kbit prio 1
/sbin/tc class add dev tun0 parent 1:1 classid 1:12 htb rate 128kbit ceil 512kbit prio 2
/sbin/tc class add dev tun0 parent 1:1 classid 1:13 htb rate 128kbit ceil 128kbit prio 3

/sbin/tc filter add dev tun0 parent 1:0 protocol ip prio 1 handle 5 fw classid 1:10
/sbin/tc filter add dev tun0 parent 1:0 protocol ip prio 2 handle 6 fw classid 1:11
/sbin/tc filter add dev tun0 parent 1:0 protocol ip prio 3 handle 7 fw classid 1:12
/sbin/tc filter add dev tun0 parent 1:0 protocol ip prio 4 handle 8 fw classid 1:13

/sbin/tc qdisc add dev tun0 parent 1:10 handle 100: sfq perturb 5
/sbin/tc qdisc add dev tun0 parent 1:11 handle 110: sfq perturb 5
/sbin/tc qdisc add dev tun0 parent 1:12 handle 120: sfq perturb 5
/sbin/tc qdisc add dev tun0 parent 1:13 handle 130: sfq perturb 5

По аналогии с предыдущим примером, здесь мы создаем четыре очереди, но уже классифицированные по HTB. Классы описаны с различными параметрами приоритетов и пропускной способности.

Предполагается, что суммарная пропускная способность всего канала 1Мбит/с (минус 10-15% зарезервировано на организацию QoS – итого классам доступно 920Кбит/с). Очередь первого класса (куда попадают пакеты, маркированные меткой «0х05») имеет наивысший приоритет и гарантированную полосу 128Кбит/с, расширяемую по мере необходимости до 512Кбит/с за счет неиспользованной полосы очередей классов с меньшим приоритетом, если таковые имеются.

Аналогично для второго и третьего класса в наборе – идея состоит в том, чтобы предоставить для данных типов трафика гарантированную пропускную способность, дополнительно задействуя неиспользуемый канал «нижних» очередей, если это возможно.

Очередь четвертого класса, куда попадает весь неклассифицированный и, следовательно, неприоритетный трафик, имеет статичный канал 128Кбит/с и может лишь «давать в долг» пропускную способность очередям «верхних» классов.

Организация VPN-сети (часть восьмая)

linux, vpn, network

Read or add comments to this article