Часто задаваемые вопросы:
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Кбит/с и может лишь «давать в долг» пропускную способность очередям «верхних» классов.