Ваша идея неосуществима по нескольким причинам:
1)
Насколько я помню, в самой OpenVPN нет функции для передачи данных из VPN-подключения в пользовательский процесс перед пересылкой.
Для справки: проверьте, где TCP/IP используется в стеке OSI.
OpenVPN находится на уровне 3 стека OSI (сетевой уровень), а пакеты TCP принадлежат уровню 4 (транспортный уровень).
Только по этой причине ваш вопрос выходит за рамки того, чего хочет достичь OpenVPN.
Единственное, чем вы можете манипулировать, это то, что происходит, когда клиент подключается к серверу или отключается.
Эти ситуации можно определить в файле конфигурации вашего сервера с помощью следующих настроек:
# клиент подключен к VPN-серверу
клиент-подключение "/script/client_connect.sh"
# клиент отключен от VPN-сервера
клиент-отключение "/script/client_disconnect.sh"
Все переменные среды, доступные для вашего пользовательского скрипта, доступны здесь:
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/#scripting-and-environmental-variables
Но, по сути, единственная информация, которую вы можете отслеживать, — это то, какой сертификат клиента использовался для подключения к серверу и какой IP-адрес был назначен клиенту, а затем выполнять некоторую пользовательскую логику на сервере в зависимости от того, кто подключается и что делать, когда они снова отключаются.
Одной из типичных настроек может быть реализация динамической стороны DNS-сервера или выполнение какой-либо пользовательской маршрутизации, например маршрутизация при отказе, в зависимости от того, какое VPN-подключение установлено.
2)
Ссылаясь на эту диаграмму пакета IPv4 от Википедия:
По сути, вы хотите манипулировать полем данных в зависимости от исходного или конечного адреса.
Это также известно как атака «человек посередине».
Как вы уже поняли, это сложно сделать, прослушивая интерфейс OpenVPN, так как весь контент зашифрован. Что происходит, так это то, что пакет IPv4, предназначенный для Интернета, инкапсулируется в другой пакет IPv4, предназначенный для сервера OpenVPN.
Инкапсулированный пакет IPv4 хранится в поле данных на приведенной выше диаграмме.
Это декапсулированный пакет, который пересылается в Интернет с VPN-сервера.
Однако есть оговорка:
Я предполагаю, что VPN-клиент делает нет иметь публичный IP-адрес. Это означает, что задействуется преобразование NAT, а исходный адрес перезаписывается так, чтобы он был адресом VPN-сервера, прежде чем свяжется какой-либо хост в Интернете.
Точно так же, когда хост отвечает ответом, у нас есть IPv4-адрес назначения, такой же, как у VPN-сервера.
Это означает, что для манипулирования полем данных нам нужно отслеживать, какие порты используются в таблица трансляции сетевых адресов (он же НАТ).
Используемые порты обычно являются динамическими по своей природе, поскольку более одного клиента VPN могут подключаться к Интернету через VPN и NAT, и каждый сеанс TCP (почта, Интернет, ssh и т. д.) использует другой порт.
Итак, если вы хотите манипулировать расшифрованный TCP-пакет это должно произойти после расшифровки, но до трансляции в NAT.
Теоретически вы можете перехватить пакет, используя iptables, но это нетривиально, когда VPN и NAT находятся на одной машине.
Другой подход заключается в прямой атаке зашифрованного трафика OpenVPN, поскольку вы контролируете сервер OpenVPN, а значит, вы также контролируете, какие сертификаты и закрытые ключи используются как на сервере, так и на клиенте.
Это выполнимо как классическая атака «человек посередине». Хотя я не знаю, как это делается. :-)
... но это приводит меня к моему последнему аргументу:
3)
Большая часть трафика в Интернете шифруется по протоколу TLS.
Таким образом, даже после того, как вы расшифровали трафик OpenVPN, вам придется преодолеть еще один уровень шифрования, чтобы манипулировать содержимым поля данных.
Эту часть еще сложнее атаковать, чем просто атаковать зашифрованный трафик OpenVPN, поскольку вы не контролируете ключи шифрования, используемые для сеанса.
Даже если вы попытаетесь расшифровать трафик TLS и повторно зашифровать контент, чтобы конечный пользователь выглядел так, будто зашифрованный трафик действительно исходит от YouTube или чего-то еще, тогда это все равно будет бесполезно, поскольку сертификат, который вы используете для шифрования трафика https, не доверял браузерами на компьютерах конечных пользователей.
Уже одно это делает вашу атаку «человек посередине» бесполезной.
Вот это максимально близко к полному ответу на ваш вопрос.
Есть и другие способы атаки на TCP-сессию, но сейчас мы переходим к расширенной области, которая принадлежит форуму, полному экспертов по безопасности.
Эта часть НАМНОГО выше моей квалификации. :-)
