Push route что это
Главное меню
Последние статьи
Счетчики
Связываем локальные сети при помощи OpenVPN
Имеем центральный офис и три филиала. Все используют разных интернет-провайдеров, и разные технологии.
Центральный офис: 10.10.10.0 255.255.255.0
Филиал под условным названием npn: 192.168.0.0 255.255.255.0
Филиал под условным названием mg: 192.168.10.0 255.255.255.0
Филиал под условным названием westfood: 192.168.2.0 255.255.255.0
Ставим (и на сервере и на клиентах):
sudo su
apt-get install openvpn
Создание ключей (производится только на сервере. затем необходимые ключи копируются с сервера на клиенты).
Переходим в каталог со скриптами создания ключей шифрования:
cd /usr/share/doc/openvpn/examples/easy-rsa/2.0
Открываем файл, содержащий переменные для скриптов:
nano vars
изменяем следующие параметры под свою организацию:
export KEY_COUNTRY=»RU»
export KEY_PROVINCE=»PS»
export KEY_CITY=»Pskov»
export KEY_ORG=»MegaHolod»
export KEY_EMAIL=» Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript «
export KEY_DIR=»/etc/openvpn/keys»
Заносим переменные из только что отредактированного файла в память
Перед созданием ключей запускаем скрипт:
./clean-all
Далее переходим непосредственно к генерированию ключей путем запуска соответствующих скриптов. Так как в файл с переменными мы уже занесли нужные значения, жмем просто Enter в ответ на вопросы скриптов, за исключением:
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Итак создаем CA ключ:
./build-ca
Создаем DH ключ (нужен только серверу):
./build-dh
./build-key-server gate
Создаем ключи в PKCS #12 формате для машин-клиентов;
./build-key-pkcs12 mg
./build-key-pkcs12 npn
./build-key-pkcs12 westfood
Создаем TLS-ключ (Общий для сервера и клиента):
Из папки «/etc/openvpn/keys» нужно скопировать ta.key и *.p12 соответствующий клиенту на машины-клиенты.
Настраиваем сервер (создаем файл-конфиг и заполняем его):
touch /etc/openvpn/server.conf
nano /etc/openvpn/server.conf
port 17993 # порт, на котором будет слушать сервер
proto tcp # протокол (по умолчанию udp)
dev tun # тип устройства (tun или tap)
tls-server # явно указывает, что данный хост является tls-server
ca /etc/openvpn/keys/ca.crt # файл сертификата для CA
cert /etc/openvpn/keys/gate.crt # сертификат сервера
key /etc/openvpn/keys/gate.key # ключ сервера
dh /etc/openvpn/keys/dh1024.pem # файл с ключем Диффи-Хелмана
# автоматически присваивает адреса всем клиентам (DHCP) в указанном
# диапазоне с маской сети. Данная опция заменяет ifconfig и может
# работаеть только с TLS-клиентами в режиме TUN, соответственно
# использование сертификатов обязательно.
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt # Тут будут храниться ip адреса клиентов
push «route 10.10.10.0 255.255.255.0» # передача клиенту маршрута к сетке,
# в которой сервер.
# каждые 10 секунд посылать ping на удаленный хост, и, если за 60 секунд
keepalive 10 60
# параметр сжатия трафика, идущего через виртуальный туннель.
# Может принимать значения yes, no, adaptive.
# Последнее используется по умолчанию.
comp-lzo
# Для улучшения безопасности рекомендовано запускать
# все сервисы с минимальными правами. Openvpn будет работать от имени nobody.
user nobody
group nogroup
persist-key # указывает не перечитавать файлы ключей при перезапуске туннеля
persist-tun # данная опция оставляет без изменения устройства tun/tap
#при перезапуске OpenVPN.
# сервер работает в режиме демона
daemon
status openvpn-status.log # указывает путь к статус-файлу,
# в котором содержится информация о текущих соединениях и
# информация о интерфейсах TUN/TAP
log-append openvpn.log # дописывать сообщения в лог-файл, а не перезаписывать.
verb 4 # уровень логирования
mute 20 # в лог будет записываться только по 20 сообщений из одной категории
client-to-client # позволяет клиентам видеть друг друга (сети)
client-config-dir /etc/openvpn/ccd # папка содержащая маршруты к сетям
# клиентов и посылаемые клиентам ip адреса клиента и сервера
ccd-exclusive # каждому клиенту свои настройки
management localhost 7505
tun-mtu 1500 # устанавливает максимальный размер MTU
tun-mtu-extra 32
mssfix 1450
# маршруты к сетям клиентов
route 192.168.10.0 255.255.255.0 10.8.0.2
route 192.168.0.0 255.255.255.0 10.8.0.2
route 192.168.2.0 255.255.255.0 10.8.0.2
Настройки маршрутизации к клиентским сетям и выдача им ip.
Выбранные пары IP-адресов, во-первых, должны быть уникальными, во-вторых, должны входить в состав последовательных подсетей, ограниченных маской /30 (255.255.255.252), и, в-третьих, должны находиться в пределах пула IP-адресов, выделенного для виртуальной частной сети (определяется параметром server файла конфигурации сервера OpenVPN). С учетом перечисленных условий для клиентов и сервера подойдут пары IP-адресов со следующими парами последних октетов:
[ 1, 2] [ 5, 6] [ 9, 10] [ 13, 14] [ 17, 18] [ 21, 22] [ 25, 26] [ 29, 30] [ 33, 34] [ 37, 38]
[ 41, 42] [ 45, 46] [ 49, 50] [ 53, 54] [ 57, 58] [ 61, 62] [ 65, 66] [ 69, 70] [ 73, 74] [ 77, 78]
[ 81, 82] [ 85, 86] [ 89, 90] [ 93, 94] [ 97, 98] [101,102] [105,106] [109,110] [113,114] [117,118]
[121,122] [125,126] [129,130] [133,134] [137,138] [141,142] [145,146] [149,150] [153,154] [157,158]
[161,162] [165,166] [169,170] [173,174] [177,178] [181,182] [185,186] [189,190] [193,194] [197,198]
[201,202] [205,206] [209,210] [213,214] [217,218] [221,222] [225,226] [229,230] [233,234] [237,238]
[241,242] [245,246] [249,250] [253,254]
Создаем на сервере файлы для каждого клиента:
touch /etc/openvpn/ccd/npn
nano /etc/openvpn/ccd/npn
iroute 192.168.0.0 255.255.255.0
ifconfig-push 10.8.0.5 10.8.0.6 255.255.255.252
# посылает клиенту ай-пи адрес клиента и сервера
для других сетей аналогично:
touch /etc/openvpn/ccd/mg
nano /etc/openvpn/ccd/mg
iroute 192.168.10.0 255.255.255.0
ifconfig-push 10.8.0.9 10.8.0.10 255.255.255.252
touch /etc/openvpn/ccd/westfood
nano /etc/openvpn/ccd/westfood
iroute 192.168.2.0 255.255.255.0
ifconfig-push 10.8.0.13 10.8.0.14 255.255.255.252
Правила для IPTABLES.
Для того что-бы это все работало, в фаерволе (iptables), если он используется, нужно разрешить трафик. Пример куска моего скрипта настройки, касающегося openvpn:
#!/bin/bash
# Переменные
#указываем внешний ip сервера и внешн. сетевой интерфейс
INET_IP1=195.239.136.ххх
INET_IFACE1=eth2
# указываем внутренний ip сервера и внутр. сетевой интерфейс
LAN_IP=10.10.10.4
LAN_IFACE=eth0
# указываем сетевой интерфейс VPN, и сеть, ему принадлежащую
VPN_IFACE=tun0
VPN_RANGE=10.8.0.0/24
# внутренняя сеть
LAN_RANGE=10.10.10.0/24
# сетевой интерфейс петли и ip
LO_IFACE=lo
LO_IP=127.0.0.1
#OpenVPN
# разрешаем трафик между локальной сетью и VPN
# (необходимо для возможности доступа к серверу по внутреннему ip. c клиента)
# разрешаем входящий и исходящий трафик для vpn-интерфейса
# (необходимо для возможности установки vpn соединения)
# разрешаем icmp пакеты через vpn
# (необходимо для пинга)
Теперь на машинах-клиентах создаем конфиг:
touch /etc/openvpn/client.conf
nano /etc/openvpn/client.conf
client
dev tun # тип устройства tun или tap
#dev-node OpenVPN # раскоментировать если клиент под виндовс
# для виндовс нужно указать название
# создаваемого сетевого адаптера
proto tcp # протокол. по умолчанию udp
remote 195.239.136.ххх 17993 # ip и порт сервера
remote 93.153.252.ххх 17993
resolv-retry infinite # для dyndns
persist-key # указывает не перечитавать файлы ключей при перезапуске туннеля
persist-tun # данная опция оставляет без изменения устройства tun/tap
tls-client
# пути к файлам ключей, которые мы скопировали с сервера
pkcs12 /etc/openvpn/keys/westfood.p12
tls-auth /etc/openvpn/keys/ta.key 1
# параметр сжатия трафика, идущего через виртуальный туннель.
# Может принимать значения yes, no, adaptive.
# Последнее используется по умолчанию.
comp-lzo
verb 4 # уровень логирования
tun-mtu 1500 # устанавливает максимальный размер MTU
tun-mtu-extra 32
mssfix 1450
route-delay 5 # посылать маршруты через 5 сек. после установки vpn-канала
management localhost 7505
# show-net-up # раскоментировать, если клиент под виндовс
# если в конфиг OpenVPN вставить show-net-up, то OpenVPN запросит
# windows через API всю таблицу маршрутизации и выведет её в лог
#ip-win32 manual # раскоментировать, если клиент под виндовс
Запускаем на сервере, а затем и на клиентах демон openvpn:
Команды OpenVPN
Опции в режиме сервера
Аналогично с помощью push клиенту могут передаваться следующие параметры:
route
route-gateway
route-delay
redirect-gateway
inactive
ping, ping-exit, ping-restart
persist-key, persist-tun
comp-lzo
dhcp-option
ip-win32
Последние две опции применимы только для Window-клиентов. Например передадим Windows-клиенту адрес DNS-сервера 11.11.11.11:
push «dhcp-option DNS 11.11.11.11»
Команды и параметры при работе с сертификатами x509 и параметрами шифрования
Последние две опции очень сильно снижают безопасность OpenVPN, крайне не рекомендуется их использование.
Для улучшения безопасности рекомендовано запускать все сервисы с минимальными правами. Следующими двумя командами мы укажем с правами какого пользователя и группы будет работать openvpn:
user nobody
group nogroup
Где, соответственно, nobody и nogroup имена пользователя и группы.
Команды для управления маршрутизацией
Команды для управления туннелем
Методы аутентификации
Работа с прокси
OpenVPN без проблем может работать через http и socks прокси.
Если требуется авторизация на прокси-сервере:
Так же после authfile требуется указать метод авторизации. Можно оставить auto для автоматического выбора метода авторизации или указать явно через auth-method.
auth-method может быть трех видов «none», «basic» или «ntlm».
Используется в OpenVPN начиная с версии 2.1.
Скриптинг
Команды отладки и поиска неисправностей
Логирование
Разные вопросы
В. Для чего нужны файлы serial и index.txt при генерации ключей с easy-rsa?
О. Эти два файла используются в качестве временной базы данных, используемой при генерации ключей. Должны находиться в том каталоге, где и ключи.
Если клиент получил ошибку AUTH_FAILED
то он перестает переподключение и тупо гасит демона/сервис, помогает только перезапуск ОС или ручной запуск клиента
OpenVPN, о котором вы так мало знали
OpenVPN, как много в этом слове. Мультиплатформенный, гибко настраиваемый, бесплатный VPN сервер с открытым исходным кодом, являющийся фактически стандартом «defacto» для организации доступа к внутренним корпоративным сетям. Большинство администраторов используют его с настройками по умолчанию или с типовыми конфигурациями широко описанными в разных HOW-TO. Но так ли прост OpenVPN, как он кажется на первый взгляд? В данной статье мы рассмотрим скрытые от глаз внутренние механизмы OpenVPN, которые кардинально меняют представление о его возможностях.
OpenVPN сервер распространяется в виде исходного кода или готовых к установке скомпилированных пакетов для различных операционных систем. В качестве библиотеки обеспечивающей шифрование используется OpenSSL.
Большинство конфигураций для связи клиентов с сервером, а также между серверами, предполагает использование связки приватных или приватно/публичных ключей для обеспечения безопасности внутреннего трафика. Для корпоративных сетей в режиме MultiPoint-To-SinglePoint обычно используется свой центр сертификации PKI, который легко строится либо при помощи easy-rsa, либо на основе XCA. Для межсервенной коммуникации типа Point-to-point, в основном используется конфигурация с общим ключом. Вспомним основные, всем известные механизмы и возможности.
Основные механизмы и возможности
Сертификатная аутентификация
Про неё написано огромное количество документации. Суть проста. Создаётся свой центр сертификации, который выпускает пользовательские сертификаты. С помощью центра сертификации обеспечивается контроль за подключением пользователей к OpenVPN серверу. При окончании времени действия сертификата или его отзыве, доступ пользователя блокируется. Приватные ключи с установленым на них паролем, выпускаемые совместно с сертификатом обеспечивают безопасность от несанкционированного подключения к внутренним ресурсам.
Приватные point-to-point ключи
С точки зрения подключения к ресурсам компании только одного пользователя/сервера, используется схема с приватными ключами. На одном из хостов генерируется ключ, который является общим для сервера и клиента.
Во всех случаях подключения для безопасности «рукопожатия» handshake между клиентом и сервером используется протокол Diffie-Hellmann.
Внешняя аутентификация пользователей
Для упрощения контроля за подключением пользователей, вместо схемы со своим PKI, можно использовать схему с внешней аутентификацией пользователей по логину/паролю. Данная схема удобна для аутентификации пользователей скажем по доменному логину/паролю. Для подключения к серверу в конфигурационный файл клиента добавляется сертификат сервера и ключ подписи передаваемых пакетов HARDENING OPENVPN SECURITY.
пример клиентского конфига
Часть серверного конфига для аутентификации клиентов через файл
Using alternative authentication methods
Данная схема удобна, но очень небезопасна.
Для повышения безопасности можно использовать подключаемые модули обеспечивающие проверку логина/пароля во внешних системах. Самым распространённым методом является системный PAM(Pluggable Authentication Modules).
В конфигурационный файл OpenVPN необходимо добавить строку
Маршрутизация
Т.к. основной задачей сервера является обеспечение доступа удалённых пользователей/серверов к внутренним ресурсам, сервер позволяет определять статическую маршрутизацию от клиентов к серверу и от сервера к клиентам. С точки зрения доступа клиентов к внутренним ресурсам, сервер при помощи протокола DHCP и директив «route» или «push route» позволяет передать клиенту маршруты внутренних сетей. Для оповещения самого сервера об удалённых сетях на стороне клиента используется «client config dir» (ccd), механизм позволяющий описать при помощи директивы «iroute» список внутренних сетей клиента, которые должны попасть в таблицу маршрутизации сервера для транзита в них трафика.
На этом «штатные» широкоиспользуемые возможности заканчиваются и начинается локальная кастомизация для каждого конкретного случая.
Дополнительные возможности OpenVPN
Рассмотрим дополнительные возможности OpenVPN, о которых может кто-то и слышал, но в реальности не видел или не использовал.
Безопасность сетей/Packet Filtering
Директивы блока (ACCEPT/DENY) задают действие по умолчанию для всех клиентов не указанных внутри блока.
Например файл для клиента user2
заблокирует трафик ко всем пользователям и сетям, но разрешит трафик в сторону клиента user1. Если у user1 не будет явным образом описано разрешение передачи трафика в сторону user2, то трафик будет ходить только в одну сторону user2->user1.
Или другой пример.
Отключить всё кроме доступа между пользователями и DNS сервером находящимся в локальной сети и тестовым контуром в сети 192.168.0.0/24
Механизм фильтрации активируется через конфигурационный файл, либо при подключении плагина «выставившего» флаг «OPENVPN_PLUGIN_ENABLE_PF».
Данную возможность мы обсудим позже.
Вторым режимом фильтрации трафика является встроенный в систему пакетный фильтр. Для его активации в конфиге не должно быть директивы «client-to-client». С точки зрения автоматизации включения/выключения необходимых правил при подключении/отключении клиентов удобнее всего использовать отдельные вставки в список правил, реализуемые либо через CHAINS в Iptables(Linux), либо в Anchors в PF(FreeBSD). Активация/деактивация правил обычно осуществляется через директивы client-connect/client-disconnect в конфигурационном файле сервера, вызывающие соответствующие скрипты при подключении/отключении пользователя.
Расширенная PAM аутентификация
Под расширенной PAM аутентификацией подразумевается изменение логики работы проверки логина и пароля пользователя. Достигается это либо установкой соответствующих плагинов для OpenVPN, обеспечивающих чтение и проверку данных во внешних источниках, либо подключением в систему библиотек позволяющих скриптовать любую логику. Одной из такой библиотек является pam_python, которая помогает скриптовать любую логику проверки логина/пароля через Python скрипты.
В случае её использования строка проверки пользователя меняется следующим образом.
Так как «под капотом» PAM находятся алгоритмы диалогов системы с пользователем или внешними библиотеками, то этими диалогами можно управлять. Например подключить OTP токены в систему. Библиотека LinOTP взята просто для примера, т.к. свою самописную библиотеку написанную во время тестирования я где-то потерял ¯\(ツ)/¯
Также примеры легко гуглятся по слову «pam_python».
Основной проблемой при работе с внешними PAM модулями является невозможность получить сессионное окружение OpenVPN внутри вызываемого Python или любого другого скрипта, вызываемого через системный pam. Т.е. скрипт обеспечивает только те функции по проверке логина/пароля, которые на него возложены.
«Отложенная» аутентификация
Сервер OpenVPN поддерживает так называемую «отложенную» аутентификацию. «Отложенная» аутентификация используется в случаях, когда сервис аутентификации не может обслужить запрос проверки логина/пароля в реальном режиме времени.
Плагины OpenVPN
Это отдельная параллельная вселенная, про которую может быть и знают, но из-за некоторой запутанности не умеют или боятся использовать. Да действительно, написание функционального плагина для OpenVPN требует программирования на C со всеми вытекающими. Примеры простых плагинов включены в исходное дерево OpenVPN или например есть плагин для демонстрации вызова методов из OpenVPN.
Попробуем разобраться как плагины работают со стороны OpenVPN.
Функции и параметры используемые для работы с плагинами описаны в отдельном файле
Основная задача плагина, при инициализации его сервером OpenVPN, передать список поддерживаемых плагином функций и при вызове любой из функций вернуть правильный код ответа, который будет понятен серверу.
Остановимся поподробнее на каждой группе. Логику работы мы будем рассматривать на основе парольной аутентификации пользователя.
При старте сервера, после чтения конфигурационного файла, сервер вызывает функции OPENVPN_PLUGIN_UP и OPENVPN_PLUGIN_ROUTE_UP. В переменном окружении вызываемых функций передаются основные параметры запущенного сервера.
Данные функции можно использовать для оповещений при старте сервера либо смене конфигурации.
При подключении клиента, OpenVPN запрашивает возможность активации внутреннего пакетного фильтра.
Как видно из дампа, появилась переменная pf_file. В данном файле должны находиться правила внутреннего пакетного фильтра для текущей обрабатываемой сессии.
Далее проверяется логин и пароль пользователя в функции OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY
Это единственное место где пароль в переменном окружении присутствует в открытом виде.
Результатом работы данной функции должны быть три варианта ответа.
Если сервер получает ответ OPENVPN_PLUGIN_FUNC_DEFERRED, то в работу вступает механизм «отложенной» аутентификации. Как мы видим, в переменном окружении появилась переменная «auth_control_file», содержимое данной переменной содержит имя файла, в котором будет ожидаться ответ от системы аутентификации. Ответом является помещённый в указанный файл символ 0(для разрешения доступа), 1(для запрета доступа). Параметр сервера «hand-window» определяет таймаут в секундах, в течении которого сервер будет ожидать ответ. Во время ожидания трафик от других клиентов не прерывается.
Так как мы работаем с парольной аутентификацией, то функции проверки сертификатов OPENVPN_PLUGIN_TLS_VERIFY не вызывается. Вместо этого сразу вызывается OPENVPN_PLUGIN_TLS_FINAL, подтверждающий установление сессии.
Далее срабатывает вызов OPENVPN_PLUGIN_IPCHANGE, вызываемый перед сменой ip адреса клиента.
Функция OPENVPN_PLUGIN_CLIENT_CONNECT_V2, вызывается при установке IP адреса внутренним DHCP сервером.
В переменном окружении появляются переменные содержащие параметры туннеля «ifconfig_pool_local_ip» и «ifconfig_pool_remote_ip».
Функция OPENVPN_PLUGIN_LEARN_ADDRESS вызывается при обучении OpenVPN сервером, связки IP адресов и маршрутов к ним. После выхода из этой функции активируется процедура применения настроек пакетного фильтра из файла. Переменное окружение OPENVPN_PLUGIN_LEARN_ADDRESS при этом соответствует фазе OPENVPN_PLUGIN_CLIENT_CONNECT_V2.
При отключении клиента вызывается функция OPENVPN_PLUGIN_CLIENT_DISCONNECT.
В переменном окружении добавляются длительность соединения и трафик пользователя.
Как вы успели заметить, в связи с обилием данных в разных вызовах, написание и отладка плагина на языке программирования C(C++) будет довольно трудоёмкой задачей.
Для расширения функционала было решено сделать «чудо» сначала для внутреннего проекта, а потом выложить его в свободный доступ 🙂
После долгого чтения исходных кодов OpenVPN и различных примеров узкоспециализированных плагинов, был написан проект, который в качестве языка программирования логики обработки сессии использует Python. Код представляет собой подключаемый к OpenVPN плагин на языке C, который все запросы поступающие в плагин, отправляет в Python модуль через c-api reference.
Python c-api reference работая с python файлами напрямую, некорректно работает с загрузкой python библиотек.
При инициализации плагина в OpenVPN, плагин возвращает масочный список всех функций, которые может обслужить. При наступлении очередной фазы подключения или внутреннего события, OpenVPN вызывает соответствующие функции из плагина. Плагин преобразует переменное окружение и параметры переданные функции в структуру, инициализирует python и передаёт структуру в соответствующую процедуру python модуля. Процедура возвращает плагину один из трёх ответов (0 — Success, 1 — Error, 2 — Deferred). Ответ транформируется и возвращается OpenVPN.
Обратите внимание, что все вызовы модуля являются «stateless», это означает, что процедуры не помнят и не знают, что происходило ранее в других вызовах. Ориентироваться можно только на переменное окружение передаваемое плагину из OpenVPN.
Внутри python модуля вы можете реализовать любую логику, подключая нужные библиотеки и ресурсы. Если вы не уверены в скорости выполнения проверок, то используйте «отложенные» подтверждения.
Используя группировку пользователей подключаемых к сервису, через pf_file можно довольно тонко настроить сетевое взаимодействие между пользователями и другими ресурсами. В свою очередь подключив плагин на мониторинг, всегда можно будет через management интерфейс OpenVPN управлять сессиями клиентов.
Во время тестирования проекта был разработан механизм генерации паролей, аналогичный jwt токенам, но имеющим меньший размер.
Суть проста. Токен содержит в себе идентификатор клиента и срок окончания доступа. Для подписи токена используется HMAC_SHA1 с закрытым ключом. После подписи токена, текстовое содержимое ксорится подписью и конвертится в base64. Таким образом получается «запечатывание» токена. «Запечатанный» токен используется в качестве пароля пользователя. При несанкционированном изменении блока с данными, поломается xor, если поломается xor, значит поломается проверка подписи. Без закрытого ключа подпись изменить не получится.
Если вы не хотите руками контролировать время действия пароля, то генерируете такой токен, и проверяете его на валидность внутри плагина, не вызывая внешние сервисы. Данная схема очень удобна для сессионной генерации паролей на определенное время. При этом вы можете во внешнюю систему управления передать содержимое токена и она сама настроится на отключение пользователя по окончании действия токена.
Надеюсь информация в данной статье была вам полезна.
Спасибо за потраченное на её прочтение время.
Если есть вопросы, попробую ответить на что смогу.
© Aborche 2019 