Маршрутизация в openVPN

Коллеги, помогите настроить маршрутизацию в сети с openVPN.
Дано:
1. openVPN сервер размещен на шлюзовой машине в Инет. Службы, к которым надо обеспечить ремутный доступ - на третьем компьютере, на котором маршрут по умолчанию - шлюзовая машина. Но о каком VPN этот рабочий сервер не знает. И знать не должен.
2. Имеется два независимых провайдера Интернета, пусть А и Б. Подключение к ним обеспечивает шлюз через физические роутеры. Пусть они имеют адреса для шлюза 192.168.1.1 и 192.168.1.2. А далее - там уже роутеры провайдеров, мне они неинтересны.
3. Дефолтный маршрут на шлюзе смотрит на провайдера А, то есть в 192.168.1.1. В случае проблем с А автоматом переключается на Б.
4. Настраиваю openVPN. Сеть там заложена такая: 192.168.128.0/24. Протокол UDP. Причем, настраиваю таким образом, чтобы VPN-трафик мог приходить от ремутных клиентов как с А, так и с Б. Причем, канал Б даже более (по ряду причин) для VPN предпочтительнее. Это важно.
Проблема в следующем - если я, как клиент, коннекчусь через роутер А (который дефолтный на шлюзе), то всё работает без сучка и задоринки, а вот если пытаюсь законнектится через роутер Б, то ответный трафик шлюз шлет на дефолтный роутер А, ну а дальше клиент, получив такой ответ говорит: "вас тут не стояло".
Вопрос: как направить ответный VPN-трафик в тот мой роутер, откуда приходят запросы. Возможно ли разрулить UDP-ответы или надо в моем случае делать openVPN на протоколе TCP?

Cruiser78 написал:

Коллеги, помогите настроить маршрутизацию в сети с openVPN.
Дано:
1. openVPN сервер размещен на шлюзовой машине в Инет. Службы, к которым надо обеспечить ремутный доступ - на третьем компьютере, на котором маршрут по умолчанию - шлюзовая машина. Но о каком VPN этот рабочий сервер не знает. И знать не должен.
2. Имеется два независимых провайдера Интернета, пусть А и Б. Подключение к ним обеспечивает шлюз через физические роутеры. Пусть они имеют адреса для шлюза 192.168.1.1 и 192.168.1.2. А далее - там уже роутеры провайдеров, мне они неинтересны.
3. Дефолтный маршрут на шлюзе смотрит на провайдера А, то есть в 192.168.1.1. В случае проблем с А автоматом переключается на Б.
4. Настраиваю openVPN. Сеть там заложена такая: 192.168.128.0/24. Протокол UDP. Причем, настраиваю таким образом, чтобы VPN-трафик мог приходить от ремутных клиентов как с А, так и с Б. Причем, канал Б даже более (по ряду причин) для VPN предпочтительнее. Это важно.
Проблема в следующем - если я, как клиент, коннекчусь через роутер А (который дефолтный на шлюзе), то всё работает без сучка и задоринки, а вот если пытаюсь законнектится через роутер Б, то ответный трафик шлюз шлет на дефолтный роутер А, ну а дальше клиент, получив такой ответ говорит: "вас тут не стояло".
Вопрос: как направить ответный VPN-трафик в тот мой роутер, откуда приходят запросы. Возможно ли разрулить UDP-ответы или надо в моем случае делать openVPN на протоколе TCP?

Читать lartc. Там пример есть(глава 4.2), прямо Ваш случай.

CyberDaemon написал:

Читать lartc. Там пример есть(глава 4.2), прямо Ваш случай.

Вы не совсем внимательно прочитали то, что я написал. Я хотел реализовать "разбрасываение" ответного VPN-трафика между двумя провайдерами. При этом (в целях повышения производительности сети) хотел иметь openVPN на UDP-протоколе. То, что описано в главе 4.2 не прямо мой случай. То, что там описано прекрано работает на TCP (и это у меня давно реализовано). А вот с UDP - такая схема не прокатывает, так как как маршрутизатор определит - это исходящий, инициирующий UDP-пакет или он ответный на внешний раздражитель? Вот и кидает все UDP-пакеты на дефолтный маршрут.

Стоило только настроить openVPN-сервер и клиентов на TCP-протокол, как работать начали оба канала безпроблемно. Так как глава 4.2 давно у меня реализована. У меня не было только подобного UDP-трафика с ремутными клиентами.

Типо пришол на B ушёл через А это вроде решается с помощью mark + собственные таблицы маршрутизации.
И TCP тут не выход. В вашем случае обязательно собственные таблицы маршрутизации и ещё советовал бы использовать connmark

Kettler написал:

Типо пришол на B ушёл через А это вроде решается с помощью mark + собственные таблицы маршрутизации.
И TCP тут не выход. В вашем случае обязательно собственные таблицы маршрутизации и ещё советовал бы использовать connmark

Я могу ошибаться, но mark - как будет работать на UDP? Где у него установленное соединение? Упомянутая глава 4.2 прекрасно решает задачу безо всяких mark'ов, но только на TCP-соединениях. Тогда ответные пакеты отправляются обратно по тому пути, по которому запрос пришел. Я это применяю и это прекрасено работает. А вот если обмен построен на UDP, то вот тут и засада. Соединения то нет...

А при чём тут соединения
Например чисто так на бум набросок
PREROUTING -i ppp0 -p udp --dport 9000 -J MARK 80
PREROUTING -i ppp1 -p udp --dport 9000 -J MARK 90


----------внешка1------- ----------внешка2-------
mark 80 mark 90

table 80 table 90

Ответ будет идти по этим же таблицам и соответственно в свой жлюз откуда и пришло.

Kettler написал:

А при чём тут соединения
Например чисто так на бум набросок
...
Ответ будет идти по этим же таблицам и соответственно в свой жлюз откуда и пришло.

Спорить не буду. Но у меня выход в инет построен достаточно тривиально, но чуток не так - шлюз имеет не 3 интерфейса (как на картинках), а только два, один обслуживает LAN, а другой - весь WAN. На втором интерфейсе висит небольшая сеточка в которой живут два роутера. И вот как отмаркировать потоки, приходящие с двух этих роутеров на один интерфейс шлюза со всего инету - не знаю. Поставить дополнительную сетевую карту в сервер - нереально.

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

По идее можно по маку

/sbin/iptables -A PREROUTING -t mangle -m mac --mac-source 00:0F:EA:91:04:08 -j MARK --set-mark 0x0ff

Macumazan написал:

По идее можно по маку

А ведь действительно... Совсем про это забыл. Про интерфейс и адреса источника в iptables помню, а вот про маки....
Вечерком протестируем...
----------------
и всё равно - не понимаю я, как это будет работать на "проходном" шлюзе, когда идет обмен с внешним миром (инициатор - клиент во внешнем мире) по протоколу UDP. Ну отмаркируем мы входящий UPD-пакет с запросом. Пробросим его на наш внутренний сервер. Тот поразмыслит и кинет ответный UDP-пакет. Ответный пакет то будет немаркированным??? Или, все таки, маркер на UDP-ответах сохраняется?.. Каким образом?

По идее не маркируются. Надо смотреть tcpdump`ом для верности.

Хм.. Если есть 2 независимых провайдера и нет своей AS, то значит есть 2 внешних ip на . То тогда как решается вопрос регулирования того, с А или Б должны приходить клиентские запросы? Это важно, так как витают мысли, но пока не хватает каких-то деталей.

Вообще, про connmark тут правильно подметили. Состояния new, established, related для UDP имеет место быть.
http://hexbot.blogspot.com/2009/03/2-connmark.html - вот примерно похожий случай. Идеи можно взять оттуда.

Macumazan написал:

По идее не маркируются. Надо смотреть tcpdump`ом для верности.

Хм.. Если есть 2 независимых провайдера и нет своей AS, то значит есть 2 внешних ip на . То тогда как решается вопрос регулирования того, с А или Б должны приходить клиентские запросы? Это важно, так как витают мысли, но пока не хватает каких-то деталей.

Итак, основанные на моей дырявой памяти сомнения меня не обманули. А именно:
общие данные - сделана маркировка на шлюзе по mac-адресу роутера как здесь было указано выше и потом добавлены нужные таблицы маршрутизации через ip... Ну, всё по учебнику.
Конфигурация 1: openVPN построен на протоколе TCP. Пакет от клиента приходит на роутер Б, далее - через маркирующий шлюз на openVPN-сервер. Ответ идет от openVPN-сервера через шлюз и далее тот направляет его на правильный роутер Б. При этом - дефолтный роутер - А. Ниже - информативная часть лога на клиенте:

Конфигурация 2: openVPN построен на протоколе UDP. Собственно - ожидаемый обломайтис. ответные пакеты со шлюза идут не в роутер Б, а в дефольный роутер А. Что очень хорошо видно из прилагаемого лога:

А видно, что UDP-"соединение" через выбранный клиентом роутер не идет, ответы сервера направляются шлюзом в дефолтный роутер А, и клиентом отвергаются. Но, как только клиент коннектится через роутер А - здесь маршрут совпадает с дефолтным и "соединение" устанавливается.

Ну и ответ на поставленный запрос - клиентские запросы могут приходить через любой из двух роутеров. Это дело клиента выбрать по каким-то критериям желаемый роутер. Хоть рандомно выбирай. Считаем, что это непредсказуемо. Хотя критерии там простые - у меня два типа подключения к Инету, первый - ADSL с медленным исходящим каналом и быстрым входящим. Поставлен на шлюзе по дефолту для обеспечения работы юзеров фирмы в инете. Второй - кабельный, с достаточно быстрым исходящим каналом, но не шустрым каналом входящим. Через этот канал ходьба на отдельные сайты, требующие эффективной отдачи нашего трафика, плюс разные служебные трафики. В принципе несложно сделать маршрутизацию по источнику в этот кабельный канал. Но как тогда система будет переключаться на иной, когда провайдер его выключит (а такое случается)? Вот и рисую openVPN с двумя удаленными хостами. Пусть он сам разбирается какой маршрут более живой.

Macumazan написал:

Вообще, про connmark тут правильно подметили. Состояния new, established, related для UDP имеет место быть.
http://hexbot.blogspot.com/2009/03/2-connmark.html - вот примерно похожий случай. Идеи можно взять оттуда.

Это читал. Всё, что там написано - слишком "сложно". У меня конфигурация схожая, но я обошелся базовыми возможностями только ip2. А именно, провайдерские сети (в которых сидят роутеры) различны (сидят на интерфейсе, имеющем 2 IP-адреса). Пусть опять, А.0/24 и Б.0/24. При этом роутеры к провайдерам имеют традиционные адреса А.1 и Б.1, а интерфейсы шлюза А.2 и Б.2. Тогда, чтобы раскидать трафик на эти роутеры, применяю команды:

ip rule add from А.2 table 101
ip rule add from Б.2 table 102
ip route add А.0/24 dev eth1  proto kernel  scope link  src А.2  metric 1 table 101
ip route add default via А.1 table 101
ip route add Б.0/24 dev eth1:1  proto kernel  scope link  src Б.2 table 102
ip route add default via Б.1 table 102
ip route flush cache

С TCP эта конструкция работает эффективно. А вот с UDP... Увы-с...