[Из песочницы] OpenVPN c расширенной аутентификацией и авторизацией – Компьюлента Orion – Hi-Tech новости со всего света

Linux

В openvpn есть баг, который не дает пользователю ввести PIN-код от токена, если пакет собран с поддержкой systemd. Поскольку в последнее время systemd есть везде, все пакеты, которые уже доступны в репозиториях собраны с его поддержкой. Клиентам на линуксе нужно собирать пакет самостоятельно. Вот пример конфигурации, которая заработала у меня на Arch Linux:

Mas os

Под Mac OS есть только один бесплатный клиент —

Windows

Под windows все вроде работает. Официальный клиент не умеет вводить pin-код от токена, обходится через запуск openvpn руками из консоли.

Запускать от администратора установщие клиента. Самое главное — все делать из под администратора. Запускать терминал в котором стартуется openvpn тоже с правими админа, иначе он не сможет управлять сетевым интерфейсом.

Это касается как ovpn-конфига так и опции –show-pkcs11-ids в командной строке. Под виндой путь до библиотеки для работы с токенами должен записываться через двойные слеши.

pkcs11-providers “c://Windows//System32//rtPKCS11ECP.dll”pkcs11-id ‘Aktivx20Cox2E/Rutokenx20ECP/342b871d/Rutoken/01’

Библиотека pkcs#11

Для работы с токенами нужна специальная библиотека. Библиотека нужна как для создания ключевых пар, так и для собственно подключения.

Использование токена для аутентификации

Найти id сертификата, который нужно предъявить серверу:

Пример полного конфига сервера

example-server.conf

Скорость

Наибольший прирост скорости дает включение udp режима. Это советуют во всех мануалах. Смысл в том, что нет смысла запускать клиентское tcp-подключение в tcp канале. Одного tcp у клиента достаточно, чтобы производить корректную доставку пакетов. Если в udp-канале будут пропадать пакеты, то корректировку доставки будет контролировать клиентское tcp-соединение.

Скорость возрастет как минимум потому что не надо ждать подтверждения доставки каждого пакета в канале. С tcp есть вторая проблема — один клиентский tcp пакет скорее всего не влезает в один пакет vpn-канала. MTU совпадает, но к клиентскому пакету нужно еще добавлять заголовки. В результате на один пользовательский пакет приходится отсылать два пакета внутри vpn-канала.

TCP имеет смысл использовать когда по-другому нельзя. Например, когда vpn работает через ssh канал.

Создание сертификата на токене

Сгенерировать на токене ключевую пару. Параметр id здесь — это порядковый номер слота на токене, куда укладываются ключевая пара.

pkcs11-tool --module /usr/lib64/librtpkcs11ecp.so --keypairgen --key-type rsa:2048 -l --id 01 

Управление пользователями

Добавление

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

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

Удаление

Удаление пользователей производится через тот же скрипт установки. Сертификат добавляется в CRL, новый CRL подпихивается vpn-серверу. Все сертификаты, которые есть в CRL сервер считает недействительными и принимать отказывается.

Как отозвать сертификат вручную:

cd /etc/openvpn/easyrsa # отозвать сертификат ./easyrsa revoke $CLIENT # сгенерировть новый crl ./easyrsa gen-crl # удалить старый crl rm -rf /etc/openvpn/crl.pem # подменить его новым cp /etc/openvpn/easy-rsa/pki/crl.pem /etc/openvpn/crl.pem # openvpn должен уметь читать crl, когда он уже дропнул привелегии до nobody chown nobody:nobody /etc/openvpn/crl.pem 

Установка openvnp

Взять скрипт

, запустить от root.

Фильтрация доступных хостов для клиентов

Клиентов необходимо ограничивать по тем хостам на которые им можно ходить внутри сети, когда они подключаются к openvpn.

Вручную

После NAT фильтровать их будет уже не почему — у них у всех будет ip-адрес openvpn сервера во внутренней сети. Идея в том, чтобы ловить пакеты еще на интерфейсе tun0, в который они приходят от клиентов и фильтровать их до того как они попадают в NAT.

по сути роутятся системой) обрабатываются таблицей FORWARD. Пакеты, которые проходят сквозь систему (не исходят непосредственно из нее и не являются входящими, т.е. Таблицы в iptables обрабатываются сверху вниз, если ни одно из правил в таблице не привело к решению судьбы пакета, тогда срабатывает дефолтное правило.

Подготовка таблицы FORWARD:

# сбросить всеiptables -F FORWARD# дефолтное правило для таблицы FORWARD – не пропускать ничегоiptables -P FORWARD DROP# пропускать уже установленные соединенияiptables -I FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

Пример правил для конкретного клиента. Поскольку дефолтное правило для таблицы — DROP, осталось только разрешить те пары хост порт, куда можно. Разрешить доступ к порту на хосте пинговать сам хост: