LINUX.ORG.RU
ФорумAdmin

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

 ,


0

1

Добрый день, хочу решить задачу настройки роутинга на openvpn сервере через клиента. Дано:

openvpn server tun ip address 10.10.11.0/24
client1 tun0 ip address 10.10.11.10
client2 tun0 ip address 10.10.11.20
мне нужно, весь трафик от client1 заворачивать на client2 Для 2-х клиентов задача решается добавлением в ccd файл client2 такого содержимого:
iroute 1.0.0.0 255.0.0.0
iroute 2.0.0.0 255.0.0.0
iroute 3.0.0.0 255.0.0.0
. . . . . . 

iroute 254.0.0.0 255.0.0.0
iroute 255.0.0.0 255.0.0.0
и добавлением пары правил в таблицу роутинга самого сервера:
ip add default 10.10.11.2 table 120
ip rule add from 10.10.11.10 table 120
Но когда клиентов не 2, а больше и мне нужно трафик клиента 1 заворачивать на клиента 2, а трафик клиента 3 заворачивать на клиента 4 и т.д., то это перестает работать. Вопрос, можно ли как-то задать правила роутинга по входящему адресу в openvpn сервере, чтобы можно было настроить роутинг, так, как мне нужно?

Спасибо

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

anc ★★★★★ ()

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

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

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

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

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

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

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

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

ip add default 10.10.11.19 table 120 # Серверный конец туннеля к client2
вместо
ip add default 10.10.11.2 table 120
но я получаю ошибку RTNETLINK answers: Network is unreachable, которую не знаю, как обойти

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сумбурно написали. Поясню о чем была речь выше.
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 не высок, а точнее тогда он вам и вообще нафиг не нужен. Хотя и в этом случае будут реконекты в цикле.

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

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

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

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

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