Как настроить роутинг в openvpn через клиента

Наискосок. Использовать маркировку MARK в iptables и по ней отправлять пакеты в iproute2

Нет, только вешать отдельные openvpn сервера на разные порты (или править исходники openvpn).

Наискосок. Использовать маркировку MARK в iptables и по ней отправлять пакеты в iproute2

Не совсем понял, можно на примере? Как должна выглядеть эта схема?

А вы задачу полее опишите. Мы не знаем что у вас на самом клиенте происходит, маскарад? Что-то еще?

Да все просто. На всех клиентах выход в инет через nat. На каждом поднят туннель до сервера. Друг друга клиенты видят. Способ, что я описал в первом посте работает, я с одного клиента хожу в интернет через другого. Все решилось бы просто, если бы я мог в своем примере указать

ip add default 10.10.11.19 table 120 # Серверный конец туннеля к client2

ip add default 10.10.11.2 table 120

Протупил, думая о чуть другой своей реальной схеме. Простите :( чсх изначально начал отвечать так же как и mky Как настроить роутинг в openvpn через клиента (комментарий)
Попробую повторить, если у вас парная схема клиент1 - клиент2, клиент3 - клиент4 и т.д. то совет mky очень верный, использовать несколько ovpn серверов самое то.

Да, я понимаю, спасибо. Но этот способ ужасно неудобен, поскольку требует каждый раз перенастройки клиентов. Фактически под каждого клиента, способного выпустить через себя наружу, требуется отдельный сервер (читай настройка и администрирование) Неужели нельзя как-нибудь обойтись одним?

Честно говоря не вижу проблемы, скопировать настройки существующего сервера и поменять порт. Работы на 10 минут с перекуром.

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

Можно разбить конфиг файл на два и одинаковые параметры разных серверов инклудить.

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

Неужели нельзя как-нибудь обойтись одним?

Нельзя без правки исходников. Ещё нельзя на ходу изменять iroute...

Можно разбить конфиг файл на два и одинаковые параметры разных серверов инклудить.

А так можно было? :)

Не знаю, насколько это применимо в вашем случае, но ведь openvpn можно DNAT'ить на сервере. Не меняя настроек на стророне клиента его можно будет направлять на разные openvpn-сервера.

Вроде по задаче ТС да.

Понятно, что если у клиентов динамические ip-адреса, то это не интерестно.

Кстати это тоже можно заскриптовать. Пусть и костыльно. Делаем дэфолтный порт с дэфолтным сервером при соединении в скрипте на основании common_name и получив trusted_ip вносим изменения в nat и exit 1, клиент пересоединится уже на правильный сервак.

А можно идею чуть подробнее. Все клиенты выходят в инет через провайдера и сидят за натом. Как их DNATить? Или какой скрипт будет их обрабатывать? Собственно, задача - минимальными усилиями отправить трафик к.л. клиента в интернет через к.л. другого клиента. При этом может быть так, что несколько клиентов ходят в инет через одного, а другие несколько через другого.

Сумбурно написали. Поясню о чем была речь выше.
1. DNAT на сервере в iptables прописываем что-то типа -t nat -A PREROUTING -p udp -s IP-клиента --dport порт-поумолчанию-который-придумали-и-раздали-всем-клиентам-в-конфиге -j DNAT --to-destination ip-сервера:порт-нужного-сервера-на-который-отправляем-по-ip-этого-клиента
Это про вариант если у клиента статика.
2. Теперь про вариант костылей. Хотя я бы такого не делал, просто если очень надо, то возможно, но за кач-во не ручаемся.
В конфиг сервера прописываем скрипт в параметре client-connect в котором на основании переменной common_name (имя клиента) смотрим на переменную trusted_ip (реальный ip клиента).
Если у нас в iptables уже прописан именно этот ip для dnat то ничего не делаем.
Если нет то удаляем старое и добавляем на его место новое (простой вариант использовать отдельные цепочки iptables для этого) и exit 1, клиент пересоединится, итого всего одно пересоединение. Вероятность что за это время у клиента который вам нужен как defroute измениться ip не высок, а точнее тогда он вам и вообще нафиг не нужен. Хотя и в этом случае будут реконекты в цикле.

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

Спасибо. Теперь все понятно. К сожалению, все клиенты сидят не на статике и таки придется пробовать костыльный вариант. Кстати, не совсем понимаю в чем его костыльность. В этом варианте при смене ip у клиента будет наблюдаться задержка в трафике на него на время переконнекта и все. Или я не прав?

Правы.