Типичный usecase (случай из жизни). Особо трудолюбивый пользователь хочет работать из сортира дома, из кафе, из отпуска и так далее. Нужно обеспечить ему доступ к локальной сети, документам, принтерам и всё такое. Что делают одмины? Правильно, настраивают ему OpenVPN. Почему именно его? Тут всё просто.
Во-первых, OpenSource, халява, ревизируемый код, множество различных криптоалгоритмов на выбор. Во-вторых, есть режимы работы поверх UDP и TCP. Последнее особенно важно в случае подключения через каких-нибудь нетрадиционно мыслящих провайдеров или кривые роутеры. В-третьих, в отличие от остальных решений на базе SSL и/или PPP, он умеет принимать на клиентское устройство набор статических маршрутов и пропускать через себя только определённый, а не весь подряд трафик. В-четвёртых, в отличие от IPSec не требует ковыряния глубоко в системных кишках. В-пятых, есть возможность подцеплять токены посредством PKCS#11.
Но есть и ряд засад. В частности, прописывание тех самых статических маршрутов требует повышения привилегий процесса. Которого сложно добиться, если пользователь изначально работает с сильно ограниченными правами. Можно запустить OpenVPN как службу из-под системной учётки. Но тогда теряется интерактивность (а как пользователю прикажете его запускать-тормозить?) и становится невозможной работа с токенами. И так далее. Как обходил всё это я.
Если пользователь работает с правами локального админа, имеет внутри черепной коробки мозг и умеет с ним обращаться, то я отдаю ему конфиг в виде файла, а закрытый ключ пишу на eToken. Последнее нужно для уверенности, что пресловутый закрытый ключ не будет скопирован или скомпрометирован каким-нибудь зловредом или мальчиком из службы "скорой компьютерной помощи".
Но есть и другая категория пользователей. Которым нельзя давать права локального админа, иначе 100% своего рабочего времени придётся только и заниматься тем, что вычищать от вирусов и восстанавливать работоспособность их терминала. В таком случае фирма покупает им за конторский счёт отдельный ноутбук, который мы настраиваем "в режиме киоска". То есть юзверю доступен только рабочий стол, RDP-клиент, и всё. С разными вариациями под запросы конкретных клиентов, разумеется.
Вот с такой категорией иметь дело тяжелее всего. Раньше я выдавал им всем токены и запихивал рабочую учётку в Network Operators ("Операторы настройки сети"), но довольно быстро понял, что аз есьм геморрой. Тогда стал поступать проще. При помощи заклинания "subinacl /SERVICE "OpenVPNService" /GRANT=Пользователи=TO" я разрешаю всем подряд запускать и останавливать службу OpenVPN без повышения и без необходимости в каких-либо системных привилегиях. Сама служба работает из-под системной учётки, у неё прав на всё хватает. А файл конфига встроенными средствами самой винды я делал читаемым только для системы и администраторов. Такой подход показал себя оправданным и успешно эксплуатировался довольно длительное время.
Но потом, уже не помню с какой версии OpenVPN (кажется, 2.2.x), разработчики в OpenVPN GUI встроили обязательное требование повышения привилегий через UAC. Халява кончилась. Но я не отчаивался. Я ставил свежую версию OpenVPN "как обычно", а где-нибудь рядом складывал старый GUI, в котором требования повышения ещё не было вкомпилировано. Счастье продлилось ещё на какое-то время.
Но в релизе 2.4.0, который выпустили в самом конце 2016-го года, они переделали вообще всю архитектуру и идеологию виндового клиента, а также полностью переписали GUI. Теперь при инсталляции прописываются сразу три службы: собственно сам демон, интерфейс управления этим демоном и legacy-служба для обратной совместимости с чем-то там. Гую тоже досталось: раньше он хранил свои настройки в HKLM\Software, теперь в HKCU. Кроме того, он ищет конфиги и складывает логи по умолчанию в профиле пользователя, а не в "Program Files".
С одной стороны, это конечно хорошо и приятно. Полный рефакторинг, сделали всё вроде как по уму и ваапще. С другой стороны, отныне этот долбаный GUI обязательно хочет прочитать конфиг, вот вынь да положь. И если не может его найти, говорит "ну не шмагла я". После чего наотрез отказывается запускаться. А если я не хочу показывать пользователю конфиг? Если у меня там внутри закрытые ключи лежат? А вот нииволнует.
Попробовал по-старинке взять старый GUI. Тоже облом-с. Не работает он с новым форматом службы. Точнее, работает, но криво. При первом запуске говорит, что якобы не может запустить службу, хотя на самом деле всё прекрасно стартует. Но в production такое отдавать не будешь.
Выход нашёлся вот какой. Секретный ключ кладём в отдельный файл, закрываем к нему доступ всем кроме системы и группы админов. Сам конфиг оставляем world-readable. Дальше лезем в HKCU целевого пользователя, находим там ветку "Software\OpenVPN-GUI", сами создаем ключ типа "REG_DWORD" с именем "service_only" и значением "1". Также (и там же) ему необходимо указать правильную папку, где искать логи (ключ "log_dir" типа "REG_SZ"). После этого всё снова начинает работать, как и в старые добрые времена. Но с некоторыми неудобствами.
Поскольку настройки хранятся в HKCU, теперь приходится явно задавать их для каждого пользователя. Для этого нужно либо заранее знать сколько и какие именно личности будут заседать за данным устройством. Либо быть суровым виндовым админом и уметь делать это скриптами при первом логоне. Конечно, и то, и другое решаемо. Но раньше было и солнце ярче, и трава зеленее как-то проще.
Ну и в принципе GUI в 2.4 оброс странными неприятными глюками. Где-то настройки не сохраняются, где-то ещё что-то. Всё норовит в автозапуск себя запихнуть по поводу и без. Опять-же, эта ситуация с обязательным чтением конфига видится мне крайне нелогичной. Всё хочу написать им на community-форуме, да как-то вечно руки не доходят. И это я еще не тестировал работу новой версии с токенами.
Если кто-то помимо меня "гоняет" OpenVPN под виндой, милости прошу в комменты. Делитесь пожалуйста вашими впечатлениями от версии 2.4.0. Обсудим.