Как запретить изменение настроек клиентам OpenVPN?

Question

[Смотритель]

Приветствую профи. Нужна помощь по OpenVPN.
Суть:
- каждый юзер подключается к серверу OpenVPN с использованием своего сертификата (сертификаты генерятся с паролем)
- в настройках сервера каждому юзеру выделяется свой IP-адрес
- в настройках сервисов подсети, куда попадают клиенты у каждого сервиса есть пул IP-адресов, которым можно использовать этот сервис

Нужно каким-то образом исключить возможность клиентам подменять свой IP-адрес, который ему выставляется сервером (либо выкидывать/не пускать в подсеть в принципе). Потенциально такая вероятность существует, т.к. юзерам дается файл настроек подключения, в который они теоретически могут добавить свои директивы, в том числе задать свой IP-адрес (который может быть выделен для другого юзера) и получить доступ к неположенным сервисам.

Помогите, плз, решить проблему.

Answer 1

[Cr3w]

Чисто в теории через iptables можно попробовать разрулить.
Написать скрипт, который при подключении/отключении клиента (параметры client-connect и client-disconnect) будет добавлять метку к пакетам с этого ip (iptables -t mangle -A INPUT -s ${IP} -j MARK --set-mark 0x???). Метка в зависимости от $common_name. Соответственно iptables изначально настроить авторизацию доступа до ресурсов через метки (iptables -t filter -A FORWARD -i tun0 -m mark --mark 0x??? -d ip_ресурса -j ACCEPT) и в принципе можно убирать статическую привязку клиентов по ip. При дисконнекте удалять правила.

Comments

[Смотритель]

Хммм... как-то заморочно получается, но с другой стороны, можно будет убрать на самих сервисах все фильтры, и делать их только на уровне iptables аля "ты туда ходи, а туда не ходи"

[Cr3w]

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

[Смотритель]

Cr3w, это не играет роли на самом деле, сервисы в большей степени - это набор из примерно 4 node-приложений, каждый экземпляр которых просто запускается на своем файле настроек... и в этих настройках указывается помимо параметров работы экземпляра (базы, условия, в общем много чего) и массив IP-шников, с которых можно подключаться к управлению этим процессом...

Можно, конечно, лезть в код, добавлять туда авторизацию, но тогда придется дорабатывать и сервисы, которые с этими службами работают в автоматизированном режиме (собирают и обрабатывают отчеты, архивация и т.д.)...

Answer 2

[ky0]

А зачем вы выдаёте клиентам сетевые конфиги, если можно пушить их с сервера с помощью ccd? Если клиент поменяет IP-адрес на интерфейсе, у него просто пакеты ходить не будут.

Comments

[mureevms]

Вы ошибаетесь. Если клиент руками сменит IP адрес, то будет с него иметь соответствующий доступ
> А зачем вы выдаёте клиентам сетевые конфиги
Ни кто и не дает, посмотреть IP, маску и шлюз при уже подключенном впн большого ума не надо.

[ky0]

mureevms, так произойдёт, если на сервере топология типа subnet. В таком случае да, придётся как-то по другому это разруливать.

[mureevms]

ky0, так произойдет в 99% случаев, поскольку по дефолту используется именно эта топология. Если другая, то об этом уведомляют при вопросе

[Смотритель]

А зачем вы выдаёте клиентам сетевые конфиги, если можно пушить их с сервера

Никакие сетевые настройки в конфигах и не присутсвуют, они пушатся с сервера, но это ведь не исключает возможности добавить самостоятельно в свой конфиг своих директив.
А узнать базовые значения, как выше написали, не сложно банальным ipconfig /all после подключения с исходным конфигом...

Вот я юзеру 1 назначил на сервере адрес 10.0.0.1 и у него свои доступы по сервисам, а у другого 10.0.0.2 и у него другие доступы... Вот юзер 1 возьмет в своем конфиге вставит директивы для назначения адреса 10.0.0.2 и вот как бы это пресечь...

[АртемЪ]

Вот я юзеру 1 назначил на сервере адрес 10.0.0.1 и у него свои доступы по сервисам, а у другого 10.0.0.2

А в чем проблема, то?
У юзера 1 свои доступы по сервисам у другого юзера, другие, какая вам разница у кого какой IP адрес?

[Смотритель]

АртемЪ, если юзер 1 не подменит свой адрес, проблем никаких нет... а если подменит, то сможет получить доступы к сервисам юзера 2...
к сожалению сами сервисы такие, что могут делать ограничения только на базе IP-шников подключаемых юзеров

[mureevms]

АртемЪ, очевидно, что доступ разграничивается по IP адресу.

Answer 3

[mureevms]

Интересный вопрос. Мне кажется, что в данной формулировке никак.
Я бы решил задачу добавлением второго (третьего...n) инстанса OpenVPN с аналогичными настройками и отличием только в подсети. Ну и порт тоже придется изменить у каждого последующего инстанса. Клиентам раздавать\ограничивать доступ до сервисов из нужных подсетей, а не IP адресов, как это сделано в текущий момент. Т.е. при смене адреса клиентом он будет ограничен правилами подсети и смена адреса потеряет смысл.

Answer 4

[Армянское Радио]

Ваша задача не имеет решения - всегда найдется хитрый юзер с патченным клиентом, который плевать хотел на ваши запреты.
Разграничение доступа по адресам смысла не имеет - для этого есть другие средства, TLS, вот это вот все.