Ты хочешь сказать, что умеешь пльзоваться iptables, чтобы городить NAT там где он не нужен, но вот просто пофильтровать трафик в цепочке forward тебе в голову не приходит?

И как обойтись без ната? Как клиенты из, например, 192.168.0.0 будут отвечать клиенту openvpn?

А если openvpn-клиент изменит адрес виртуального openvpn интерфейса, то теоретически может попасть в сеть 10.12.0.0/24, если подберет себе требуемый ip ?

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

1) Какая у тебя виртуальная сеть openvpn и какая сеть физическая(например является ли твой сервер сервером по умолчанию для хостов из сетей 192.168.0.0/24 и 10.12.0.0/24)?
2) Откуда подключаются клиенты openvpn(из сети 192.168.0.0/24 или там есть еще треттий интерфейс с белым ip4 адресом)?
3) Как писал BOOBLIK, nat здесь не нужен(!!! ПРИ условии что твой сервер является сервером по умолчанию для хостов из сетей 192.168.0.0/24 и 10.12.0.0/24), т.к. клиенты из 192.168.0.0/24 все пакеты в сеть НЕ 192.168.0.0/24 будут слать через маршрут по умолчанию(т.е. через твой сервер, а он уже это направит в openvpn сеть).

Вообще описывай условия однозначно, чтобы не нужно было гадать.

1.192.168.0.0 и 10.12.0.0 - локальные, 10.12.0.2 - интерфейс на котором слушается 1194 (tcp), на пограничном устройстве сделан snat (ну это в терминлогии watchguard)на 10.12.0.2.
2.Клиенты подключаются из внешнего мира через «snat» (с публичного адреса моего пограничного устройства на 10.12.0.2).
3.openvpn сервер и не является шлюзом по умолчанию для клиентов в сетях 10.12.0.0 и 192.168.0.0, именно по этому сделан nat, именно поэтому я задал вопрос:«И как обойтись без ната? Как клиенты из, например, 192.168.0.0 будут отвечать клиенту openvpn?».
4.tun сеть - 10.20.20.0.

Тогда вот что.
На OpenVPN сервере нужно сделать две конфигурации, чтобы создавалось два tun интерфейса, т.е. будет два OpenVPN сервера, каждый со своим сертификатом сервера/корневым сертификатом. Каждый будет слушать на своем tcp-порту. Таким образом будет две группы OpenVPN клиентов и уже в зависимости от OpenVPN-интерфейса ты будешь либо разрешать доступ в 10.12.0.0/24 либо нет. Никакая самостоятельная смена ip адреса своего tun-интерфейса клиентом, не даст ему потенциальной возможности доступа в сеть 10.12.0.0.24

Хм, вы имеете в виду отдельный инстанс openvpn? Если я правильно вас понял, то я что-то подобное делал со сквидом, т.е. линк на существующий демон в /usr/sbin, отдельный pid файл, отдельный init скприт, отдельный конфиг и т.д., верно?

Да верно.
Только init скрипт отдельный не нужен.
У меня в debian 7 при запуске сервиса openvpn запускается по экземпляру /usr/sbin/openvpn на каждый *.conf файл из каталога /etc/openvpn/
Это можно видеть в init-скрипте /etc/init.d/openvpn
В других системах не знаю как устроено.

Я вас понял, спасибо за помощь, буду пробовать.

Опишись, как сделаешь. Самому интересно.

/etc/default/openvpn:

# Start only these VPNs automatically via init script.
# Allowed values are "all", "none" or space separated list of
# names of the VPNs. If empty, "all" is assumed.
# The VPN name refers to the VPN configutation file name.
# i.e. "home" would be /etc/openvpn/home.conf
#
#AUTOSTART="all"
#AUTOSTART="none"
#AUTOSTART="home office"

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

Ну как минимум в топологии net30 (она дефолтная для tun) может хоть об изменяться, в том смысле что менять то он конечно может, только работать ничего не будет :)
Так что ТС вполне хватит iptables.

А если нет, то не хватит. Тем более net30 не рекомендуется.

Тем более net30 не рекомендуется.

И давно так в вашей вселенной? При учете что она дефолтная.
Продолжим, p2p так же не должна работать и по той же причине.
Да и у ТС 146% не subnet. Честно говоря лень голову включать, прокатит ли с subnet смена ip или нет.

https://community.openvpn.net/openvpn/wiki/Topology
Вот прочти, будь добр. А по умолчанию эта опция для обратной совместимости, про это в ссылке есть. Какую топологию ТС использует, лучше у него спросить, а не гадать.

1. А вот ссылка чего-то не рабочая :)
2. «Какую топологию ТС использует, лучше у него спросить, а не гадать.» Гадать не нужно, у него две сети и нат о чем у же написано было выше, так что явно не subnet.
3. Вобщем глупость пишете, и пытаетесь хоть как-то оправдаться.

То, что у него две сети и нат, не определяет того факта, что у него не subnet. Так чтг ты именно гадаешь.
Ссылка и вправду на текущий момент не рабочая. Вот специально завтра проверю еще. Тем не менее на момент написания предыдущего сообщения она была рабочая. Она осталась в открытых страницах у меня, поэтому привожу отрывок. И не для того чтобы перед тобой, как ты выразился оправдаться, а чтобы не вводить в заблуждение ТС и других, кто будет читать тему.

Topology in OpenVPN
Several network topologies exist for servers configured to accept multiple client connections. These are controlled with the --topology option.

Possible topology choices
These are available options as values to the --topology parameter in --dev tun mode. Each topology is described further in its own section below.

subnet
The recommended topology for modern servers. Note that this is not the current default. Addressing is done by IP & netmask.
net30
This is the old topology for support with Windows clients running 2.0.9 or older clients. This is the default as of OpenVPN 2.3, but not recommended for current use. Each client is allocated a virtual /30, taking 4 IPs per client, plus 4 for the server.
p2p
This topology uses Point-to-Point networking. This is not compatible with Windows clients, though use with non-Windows allows use of the entire subnet (no "lost" IPs.)
Topology subnet
Subnet topology is the current recommended topology; it is not the default as of OpenVPN 2.3 for reasons of backwards-compatibility with 2.0.9-era configs. It is safe and recommended to use subnet topology when no old/outdated clients exist that are running OpenVPN 2.0.9 under Windows.

In subnet topology, the tun device is configured with an IP and netmask like a "traditional" broadcast-based network. The traditional network and broadcast IPs should not be used; while tun has no concept of broadcasts, Windows clients will be unable to properly use these addresses. All remaining IPs in the network are available for use.

Since every IP can be used, subnet topology allows the better utilization of IP space and easier to understand network layout.

Topology net30
net30 is effectively "deprecated" but remains the OpenVPN 2.3-series default for fear of breaking backwards-compat configs that rely on this behavior. Each client is allocated a virtual /30 network, and Windows clients must use the 2 IPs in the center, generally allocating the even IP to the client (though this is convention only.)

The only real reason to use the net30 topology is when requiring support for Windows clients before 2.0.9, or when any Windows clients must be supported and non-Windows clients must be supported that cannot set IP+netmask on the tun adapter. These conditions are rare, and the 2.0.9 client is around 7 years out of date as of 2014.

Windows allocates the fake /30 as a local network, while non-Windows will set up a true Point-to-Point config, treating the IP pairing the same as the p2p topology described below.

Routing to/across the VPN range gets harder in net30 since the clients on-link network is just the /30, so an additional "supernet" route must be added to reach the rest of the VPN, including the server at its designated IP. This complicates routing and makes understanding the config harder.

By convention, the server has the first usable IP in the VPN network, and the remaining /30's are available for pool or static assignment.

Topology p2p
This topology is not usable on Windows systems, and is not suitable if the server or any client might be Windows. In this topology, all nodes are configured as true Point-to-Point links. This has the advantage of making every single IP in the subnet usable, including the first/last IPs normally unusable due to Windows considering them network/broadcast addresses. In other words, with a /24 in the p2p topology, all 256 IPs can be used.

By convention, the peering IP of the client should match the assigned IP that the server is using, but thanks to the nature of Point-to-Point networking, the IPs are arbitrary and serve only to mean "this end" or "that end." It is not necessary these IPs be adjacent, and generally won't be for a client.

Так, вот что. Ссылка рабочая. Но грузится почему-то очень долго. Проверил только что.
https://community.openvpn.net/openvpn/wiki/Topology

Ой, да этому тексту уже сколько лет. subnet - типа recommended давно, однако... net30 хоть и deprecated но все еще default. Ладно, предлагаю закрыть данный вопрос, т.к. что там у ТС мы все равно не знаем.

Ты извини, если чем обидел. Но ты первый написал, что я пишу глупость, хотя это не так. В том тексте по ссылке написано, что по дефолту эта опция для того, чтобы конфиги, написанные для старых версий OpenVPN(в которых еще не было subnet топологии и соответственно net30 было по умолчанию и поэтому не указывалось явно) работали.

PS И btw все-таки согласитесь что с p2p вариантами гораздо удобнее реализовать задачу ТС :)

А если windows клиенты?

Просто поясню почему мой вывод скорее ближе к действительности. Если задают вопрос про ovpn с subnet, то это осознанное действие и его обычно указывают отдельно в теме. Так же редко кто ставит subnet для маршрутиризируемых сетей (то что у тс нат роли не играет).
ЗЫ И опять таки читайте мой первый пост, я не уверен что и с subnet смена ip прокатит.

А если windows клиенты?

А что с ними не так? Просто работают так же как и мак ос и смарты.

1) Сейчас поздно. Но вот проверю завтра смену ip.
2) По приведенной мной ссылке написано, что топология p2p не совместима с windows клиентами.

2) По приведенной мной ссылке написано, что топология p2p не совместима с windows клиентами.

Ясно, возникло недопонимание. Я написал «p2p вариантами» вариантами - т.е. во множественном числе, под p2p я подразумевал все point-to-point. Надо было через запятую написать net30,p2p. Простите.

1) Сейчас поздно. Но вот проверю завтра смену ip.

Отпишите потом. А то сегодня мне лениво тестить :)
Нет реально интересно, вроде где-то был с subnet сервак, но его еще искать нужно...

Задержался я. Проверил, при смене ip-адреса tun интерфейса клиентом, OpenVPN сервер отбрасывает все пакеты от данного клиента, т.к. в его(OpenVPN) внутренней таблице маршрутизации с данным клиентом ассоциирован другой ip адрес его tun интерфейса. Возможно получится данный фокус, если используется tap интерфейс, но нужно проверять.

Спасибо напомнили. Сам проверил, с бриджем на tap можно менять ip. Подведя итог: Если не пользовать такой вариант (а он по большому счету не очень и нужен) то iptables вполне хватает.

Вариант с разделением клиентов по разным экземплярам openvpn все таки нужен. Объясню почему. Во первых в будущих реализациях openvpn, могут изменить описанное поведение(когда сервер openvpn отбрасывает пакеты с измененным адресом источника), ну это причина конечно потенциальная и пока не актуальная. Вторая причина в том, что клиентам таким образом удобнее выставлять разрешения или запреты. Т.е. закинул привелигированных клиентов к одному openvpn экземпляру(соответственно пакеты от данных клиентов будут приходить на tun0 интерфейс сервера) и выставил разрешения в iptables одной командой на все, что приходит с tun0. Затем всех клиентов с ограниченным доступом подключил к второму экземпляру openvpn сервера(т.е. от них все будет приходить на интерфейс tun1) и организуй запреты или разрешения в iptables относительно tun1. А если всех клиентов гнать на один сервер, то придется работать с отдельными ip адресами. Группами управлять удобнее.

Насчет групп вы конечно правы. Но вот например у меня нужно рулить отдельными пользователями, не вопрос конечно запускать по отдельному экземпляру openvpn, но лично мне удобнее это все в заскриптованном варианте. Роутинг до хостов прописан в ccd и из него же я беру данные для генерации правил iptables.

Во первых в будущих реализациях openvpn, могут изменить описанное поведение(когда сервер openvpn отбрасывает пакеты с измененным адресом источника)

Это врядли технология p2p потомучто :)

Если к клиентам нужен индивидуальный подход то конечно да. Тут преимущество будет при массовости.