Как разграничить доступ между VPN пользователями?

Question

[Антон Артёмов]

Здравствуйте. В интернете имеется OpenVPN сервер на CentOS. Режим Tap (ethernet мост). IP адреса для всех клиентов указаны вручную.
Служебным серверам выдаются адреса из подсети 0 (10.30.0.0)
Нашему офису при подключении к серверу выдаются адреса из подсети 1 (10.30.1.0).
Нашим клиентам выдаются адреса подсетей 2,3,4 (10.30.2.0, 10.30.3.0, 10.30.4.0) и т.д.
Маска, которая устанавливается всем - 255.255.0.0.
Устраивает всё, кроме одного момента. Все видят друг друга.
Требование, чтобы наши клиенты не имели доступ друг к другу, но имели доступ к нашим служебным серверам.
Ну а наш офис естественно должен иметь доступ ко всем точкам, как и служебные серверы. Они тоже должны видеть всех.

Первое, что приходит в голову, как то разрулить правилами iptables на сервере OpenVPN, основываясь на подсети.
А может есть какие то решения для этого. В какую сторону хотя бы копать, направьте пожалуйста.

Answer 1

[Дмитрий]

Используйте subnet /30 для туннельной сети клиентов. Доступы к ресурсам разруливайте маршрутизацией и iptables

upd: и да, изменить режим работы на TUN. Так у вас большой растянутый L2 сегмент получается и все видят всех на этом уровне.

Comments

[Антон Артёмов]

Ну TUN я так понимаю для объединения физических сетей? А у многих клиентов сети пересекаются.

[Дмитрий]

Антон Артёмов, TUN - L3, TAP - L2. Если сети за туннелем пересекаются это плохо, но есть выход - netmap

[ky0]

Топологию net30 начиная с версии 2.3 рекомендуют менять на subnet. И директиву client-to-client ещё посмотрите, но она глобальная.

[Антон Артёмов]

а чем плох имеющийся вариант, но если попробовать разрулить подсети правилами iptables? Какие минусы?
Я боюсь, что с TUN мне не справиться.

[Дмитрий]

Антон Артёмов, тем , что клиент может установить любой дополнительный адрес на этот интерфейс и попасть туда, куда ему не следует и вы это не контролируете.

[Антон Артёмов]

Дмитрий, Да... я думал об этом.
Нашел неплохое разъяснение сути
https://arctech.ru/info/sistemnoe_administrirovani...
Наверное действительно придется осваивать TUN, топологии и маршрутизацию. Спасибо.

[Антон Артёмов]

Дмитрий, А вот такой уточняющий момент: а что, если нам не нужно объединять СЕТИ клиентов? У нас их очень много (клиентов). У всех стоят НАШИ сервера доступ к которым мы и хотим получать посредством VPN. Т.е. по сути нам нужны машины в едином пространстве, как это сделано сейчас с удобным разделением по подсетям. Это же меняет дело?

[Дмитрий]

Антон Артёмов, на сервер поставьте vpn клиент и цепляйтесь к своему vpn серверу. Или делайте с клиентом site-to-site vpn

[Антон Артёмов]

Дмитрий, так и есть в принципе. Сеть сейчас работает. Но нужно, чтобы из сервера одного нашего клиента не был доступен сервер другого клиента.
Пытаюсь на VPN сервере делать нечто

-A FORWARD -i tap0 -s 10.86.2.0/24 -d 10.86.3.0/24 -j DROP

чтобы запретить из 2 подсети ходить в 3-ю. Но такое ощущение, что netfilter (iptables) вообще не участвует в трафике между клиентами VPN сети и не может его контролировать.

[Дмитрий]

Антон Артёмов, а до этого нет правила src-nat или маскарадинга трафика для сетей 10.86. ?

[Антон Артёмов]

Дмитрий, нет, есть только для портов порты

# Generated by iptables-save v1.4.21 on ...
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -p tcp -m tcp --dport 23456 -j REDIRECT --to-ports 1199
-A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 1199
-A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 1199
COMMIT
# Completed on Fri Mar  2 11:12:33 2018
# Generated by iptables-save v1.4.21 on ...
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [4926:867742]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m multiport --dports 22,22922,1199,80,443 -m state --state NEW -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -i tap0 -s 10.86.2.0/24 -d 10.86.3.0/24 -j DROP
COMMIT
# Completed on ...

[Дмитрий]

Антон Артёмов, советую посмотреть tcpdump или wireshark что откуда приходит и куда уходит. У меня в похожей конфигурации, но на TUN такого не происходит. И ещй вопрос, как 108.86.2.0/24 знает маршрут до 10.86.3.0/24 ?

[Антон Артёмов]

Дмитрий, Я пробовал tun с subnet. Так же.
"как 10.86.2.0/24 знает маршрут до 10.86.3.0/24" - у всех подключенных маска 255.255.0.0
Буду пробовать tcpdump

[Дмитрий]

Антон Артёмов,

"как 10.86.2.0/24 знает маршрут до 10.86.3.0/24" - у всех подключенных маска 255.255.0.0

это не правильно. если у вас /24 сети, то маска должна быть 255,255,255,0

[Антон Артёмов]

Дмитрий, /24 только в правилах iptables, т.к. применять правила я хочу для 24-х подсетей.
А так у клиентов в подключениях присваивается /16.
На всю ВПН мы взяли 16 подсеть, т.к. очень много клиентов (наших серверов).

[Дмитрий]

Антон Артёмов, мне думается что в этом и проблема. как выглядит настройка интерфейса со сотороны vpn клиента?

[Антон Артёмов]

Дмитрий, Например вот ifconfig одной из подключенных машин

tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/ether 42:65:69:e3:44:d8 brd ff:ff:ff:ff:ff:ff
    inet 10.86.1.1/16 brd 10.86.255.255 scope global tap0

Машина успешно подключается к любым машинам из разных подсетей.

[Дмитрий]

Антон Артёмов, так вот у неё должна быть маска 255.255.255.0 А так машина думает что находится в той же сети и отправляет пакет напрямую, а не на адрес vpn сервера. А так как сеть у нас TAP (Ethernet) то пакет уходит как будто в brigde и не проходит через iptables. Но это только моё предположение.

[Антон Артёмов]

Дмитрий, возможно

[Антон Артёмов]

Дмитрий, tcpdump на ВПН сервере не палит трафик между клиентами. Видимо реально по бриджу проходит незаметно.
tcpdump ловит трафик между клиентом и самим сервером. Т.е. когда я со своего компа шлю пакет ВПН серверу, то он капает ему в tap0 и tcpdump его видит.
Если я шлю пакет другому клиенту, то на tap0 ВПН сервера походу ничего не приходит.
С tun (topology subnet) аналогично.

Answer 2

[Денис]

Маска какая-то совсем не маска. Маршрутиризацией рулить

Comments

[CityCat4]

Видимо с броадкастом попутал :) А маска надо полагать 255.255.0.0

[Антон Артёмов]

CityCat4, да, 255.255.0.0