LINUX.ORG.RU
ФорумAdmin

Openvpn: прокидывание клиентов в изолированные ланы


0

1

Столкнулся тут с необходимостью организовать VPN доступ из дома для сотрудников. В первую очередь взгляд упал на openvpn. Однако есть проблема: необходимо, в зависимости от имени засовывать пользователя в определенную сеть, например 10.0.x.0/24.

Собственно гарантирует ли openvpn изоляцию пользователя или ему достаточно сменить свой ip, чтобы оказаться в дамках? Легкий гуглинг показал, что нужно подымать несколько серверов, но с большим количеством подсетей это глупо. Можно еще делать бридж в реальную сеть, но можно ли это делать для групп клиентов не ясно.

★★★★

Ответ на: комментарий от kombrig

Это не отменяет вопроса может ли пользователь сменив ip выпрыгнуть за пределы своего лана.

zloelamo ★★★★
() автор топика
Ответ на: комментарий от kombrig

А если оно уже поднято. Я так понимаю, что после устаноки соединения openvpn не контролирует тоннель, т.к. в противном случае оно должно анализировать весь трафик в развернутом виде, сверяя сессионную информацию с выданным ip. И если этого контроля нет, то ничего не мешае клиенту выбрать любой адрес, который ему придёт в голову, после установки соединения.

zloelamo ★★★★
() автор топика
Ответ на: комментарий от zloelamo

Сейчас специально попробовал при тунельном соединении отключить на виндовом компе получение автоматически и задал адрес вручную при поднятом соединении. Получил ошибку

WARNING: You have selected '--ip-win32 dynamic', which will not work unless the TAP-Win32 TCP/IP properties are set to 'Obtain an IP address automatically'

kombrig ★★★
()
Ответ на: комментарий от kombrig

Это ты получил на клиенте. Замечательно. А если будет не нативный клиент? А если вообще не клиент в традиционном понимании, а скрипт, пытающийся проломить это дело. Меня интересует не сторона клиента - я не могу её контролировать, а сторона сервера. А с этой стороны я вижу удручающую картину: один сервер - один tun/tap интерфейс и с виду никакого контроля, как это в ipsec например сделано.

zloelamo ★★★★
() автор топика

Может быть, вот это?

--client-to-client
Because the OpenVPN server mode handles multiple clients through a single tun or tap interface, it is effectively a router. The --client-to-client flag tells OpenVPN to internally route client-to-client traffic rather than pushing all client-originating traffic to the TUN/TAP interface.

When this option is used, each client will «see» the other clients which are currently connected. Otherwise, each client will only see the server. Don't use this option if you want to firewall tunnel traffic using custom, per-client rule

anonymous
()
Ответ на: комментарий от zloelamo

Так вроде и нужно, чтобы не видели :) Если же вы хотите «море секьюрики», то с помощью iptables фильтруем по связке «mac виртуальной сетевухи +ip». Хотя это конечно тоже не вариант - юзер может узнать связку mac+ip для другого юзера и т.п.

anonymous
()
Ответ на: комментарий от anonymous

Мне нужно чтобы они не только не видели друг друга, но и не могли увидеть чужие ресурсы находящиеся в сети к которой они коннектятся.

Т.е. более доступно: пользователь Вася должен обладать доступом к базам данных ибо он dba, а пользователь Петя, только ко внутренним корпоративным порталам, ибо он секретарша. Пока оба индивида в офисе это решается vlan'ами. Т.е. с конкретного физического порта низя попасть в базу ибо рожей не вышел, сколько ip не меняй. А вот когда они коннектятся снаружи я не могу прикинуть как мне их гарантировано разделить с помощью openvpn.

zloelamo ★★★★
() автор топика
Ответ на: комментарий от zloelamo

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

zloelamo ★★★★
() автор топика
Ответ на: комментарий от zloelamo

OpenVPN идентифицирует пользователя по имени сертификата. А дальше сервер раздает IP-адреса для клиентских tun-интерфейсов, именно с него и будет клиент стучаться на сервер. Соединение точка-точка, не думаю что клиент может как-то поменять адрес.

Если настроить ipp.txt (ifconfig-pool-persist ipp.txt), уже Вася не получит Петин адрес. Другое дело если Петя одновременно поднимет еще одно соединение, то получит еще один свободный адрес, но никак не Васин. Может можно запретить здесь одному клиенту дважды регистрироваться, не задавался такой целью, не знаю.

Можешь прописать IP клиенту через ccd, тогда гарантированно он его получит, и врядли сможет одновременно поднять 2 соединения.

lvi ★★★★
()
Ответ на: комментарий от zloelamo

Я что-то не понимаю...

У вас тоннель есть... ip - to - ip... Соответственно, openvpn выдал ip указанный в правилах. И посылает пакеты на него... Клиент поменял ip, openvpn продолжает посылать пакеты на старый адрес -> связь порвалась. Клиент сделал алиас - > openvpn ничего не знает об алиасе -> маршрутизировать его не будет.

Разве не так?

Ну и запретить одному клиенту два коннекта это также можно, у меня так сделано.

DALDON ★★★★★
()

При работе в режиме клиент-сервер OpenVPN проводит фильтрацию пакетов, приходящих от клиента. Если со стороны клиента идут пакеты с IP-адресом, отличным от ожидаемого (ожидаемый - это тот, который выдал сам сервер), то такие пакеты будут отброшены с выдачей соответствующего сообщения в журнале. См. http://www.openvpn.net/index.php/open-source/faq/79-client/317-qmulti-bad-sou...

VitalkaDrug ★★
()
Ответ на: комментарий от VitalkaDrug

>При работе в режиме клиент-сервер OpenVPN проводит фильтрацию пакетов, приходящих от клиента.

Вот именно это я и хочу нарыть. Правда ли сервер это делает.

См. http://www.openvpn.net/index.php/open-source/faq/79-client/317-qmulti-bad-sou...

Это не совсем корректно. В описании говорится, что openvpn не нашел соответствующего роута для этого ip. А если найдёт? Т.е. если злоумышленник угадает более привелегерованный ip? Более того там ещё одна странная фраза: «Use client-config-dir and create a ccd file for your client containing the iroute option to tell OpenVPN that the 192.168.100.0/24 network is available behind this client.» Т.е. серверу пливать на самом деле, что ip сменился, главная проблема это отсутствие роутов.

zloelamo ★★★★
() автор топика
Ответ на: комментарий от anton_jugatsu

Чего отфильтровать то? Если у меня все ip верные, только одни более привелегированные чем другие? Как мне гарантировать, что нет подмены ip, без запуска нескольких серверов.

Я чего так взъелся то. Насколько я помню в vpn у офтопика ровно таже проблема: ip клиент может подменить на ура.

У cisco vpn этой траблы нет, но покупать ещё одну циску ради плевой задачи не хочется, а те что есть не потянут vpn.

zloelamo ★★★★
() автор топика
Ответ на: комментарий от zloelamo

Что значит подменить? Подменить сертификаты? Клиент получает ip-адрес в соответствии с ipp.txt. Доступ к отдельным хостам фильтруется так:

iptables -A FORWARD -p tcp --dport 3389 -i tun0 -s 10.10.10.10 -j ACCEPT
anton_jugatsu ★★★★
()
Ответ на: комментарий от zloelamo

> В описании говорится, что openvpn не нашел соответствующего роута для этого ip.

А если найдёт? Т.е. если злоумышленник угадает более привелегерованный ip?


Если OpenVPN нашел роут на такой IP - значит у него на связи есть добропорядочный клиент с таким IP, который ему выдан именно сервером. И даже если от злоумышленника будет получен пакет с измененным IP-адресом отправителя, ответный сервер пошлет вовсе не злоумышленнику, а добропорядочному клиенту с этим IP. Так что ваш злоумышленник не сможет не то что-бы установить какое-то соединение, а даже ни одного пакета не получит от кого бы то ни было, адресованных выставленному им IP-адресу.

Более того там ещё одна странная фраза: «Use client-config-dir and

create a ccd file for your client containing the iroute option to


tell OpenVPN that the 192.168.100.0/24 network is available behind


this client.» Т.е. серверу пливать на самом деле, что ip сменился,


главная проблема это отсутствие роутов.



Если нет роутов - пакет тем более никуда отправляться не будет. В данном случае OpenVPN никакую магию с пакетами не творит - все работает в соответствии с маршрутизацией. Нет маршрутов - некуда посылать - никто ответов не получит - никакой связи у злоумышленника не будет :) А ваша цитата - это настройка сервера на работу с клиентом как маршрутизатором за существующую за клиентом сеть. Выполняется на стороне сервера, следовательно - полностью контролируется именно сервером.

Вобщем, не парьтесь - смена клиентом IP-адреса на туннеле позволит ему лишиться возможности какого-либо обмена через туннель, не меньше и не больше...

VitalkaDrug ★★
()
Ответ на: комментарий от zloelamo

Не выйдет ничего. Тут и понимать особо нечего.

Если во время нашего телефонного разговора вы смените свой номер и не скажете об этом мне, как думаете, мы сможем продолжать разговор?

DALDON ★★★★★
()
Ответ на: комментарий от DALDON

>Если во время нашего телефонного разговора вы смените свой номер и не скажете об этом мне, как думаете, мы сможем продолжать разговор?

Шикарный пример! Вот в том то и дело что сможем, так как номер используется только для коммутации, а разговор либо завязан на идентификаторы телефона в случае сотового, либо на физику в случае обычного телефона.

Ладно я понял, буду эксперементировать. Спасибо.

zloelamo ★★★★
() автор топика
Ответ на: комментарий от zloelamo

Ну я уже отписал, и в общем то понял, что может не совсем удачный пример. Но суть ясна: скажем при активной закачке по ftp если вы смените у себя ip адрес, то вестимо соединение у вас пропадёт, тут я думаю аналогично.

DALDON ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.