Какой интерфейс нужно использовать для MASQUERADE в iptables при перебросе с одного интерфейса на другой

чтобы клиенты openvpn могли работать с сервисами eth0 через vpn

Для этого совсем не нужен MASQUARADE, нужно просто прописать клиентам маршрут в подсеть висящую на eth0. MASQUARADE был бы нужен, если бы вы хотели пропускать клиентов через eth0 во внешний интернет (в этом случае будет что-то вроде -A POSTROUTING -s vpn_subnet -o eth0 -j MASQUERADE).

Мне нужно перекидывать всё с tun0 на на eth0

Это как-то не так звучит, тем более имеет другое значение, отличное от:

чтобы клиенты openvpn могли работать с сервисами eth0

тем более тут нужно даже немного по другому ставить задачу.

Как-то так:
чтобы клиенты openvpn могли работать с сервисами в локальной сети за шлюзом, например 192.168.10.0\24.

В таком случае можно просто проложить маршрут через IP адрес OpenVPN шлюза до сети 192.168.10.0\24, в конфиг OpenVPN сервера нужно добавить строку прокладки маршрута:

push   "route 192.168.10.0 255.255.255.0"

Но в этом случае на машинах в OpenVPN сети не должно быть пересечения с их локальными сетями. Т.е. если у них их локальная внутренняя сеть будет тоже 192.168.10.0\24, то работать ничего не будет. Но такая сеть маловероятна.

В таком случае клиенты из OpenVPN сети и узлы в локальной сети будут «видеть» себя напрямую.

Если этого не нужно, то опять таки нужно, что бы OpenVPN сервер выдавал клиентам маршрут до локальной сети за шлюзом, но нужно прописать правило NAT (MASQUERADE) для OpenVPN сети.

Т.е., если OpenVPN сеть 192.168.20.0\24, то нужно добавить правило:

-A POSTROUTING -s 192.168.20.0\24 -o eth0 -j MASQUERADE

Но должен быть прописан маршрут на OpenVPN клиентах, как это делается я привёл.

В iptables важна очерёдность правил, если пакет при прохождении таблицы (цепочки) подпадает под какое-либо правило, то он выходит из этой таблицы (цепочки) и другими правилами в таблице уже не обрабатывается.

Нет, я не хочу никаких маршрутов и т.п. Клиент должен только войти в VPN и спокойно работать с сервисами. Клиенты не должны вообще знать про eth0.

Они и не будут о них знать, опция push route задается на сервере. Читайте более детальный пост выше.

Без маршрута на OpenVPN клиенте даже в случае NAT доступ к сети за шлюзом получить не удасться, т.к. у клиента свой шлюз и без маршрута пакеты пойдут через него, а не через VPN сервер.

Маршрут прописывается посредством push, смотри выше.

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

Чтобы было понятнее скажу так. В таких случах, когда eth0 имеет статический IP я решаю эту проблему так:

iptables -t nat -A PREROUTING -p tcp -i tun0 -j DNAT --to-destination x.x.x.x

Где x.x.x.x это IP eth0. Но DNAT нельзя использовать в тех случаях, когда IP динамический. Поэтому я и вынужден использовать MASQUERADE.

Если эти сервисы запущены без привязки к конкретному IP, то они и так должны слушать запросы приходящие на все интерфейсы шлюза на свои порты.

За исключением некоторых сервисов, в которых заместо IP указывается на каком интерфейсе они работают, например DHCP сервер, но это не ваш случай.

Вы имеете в виду, что сервисы слушаются на 0.0.0.0?

Да, если ты ничего не перенастраивал.

Да, сервисы у меня на 0.0.0.0. Но дело в том, что файрвол должен запретить подключаться к сервисам клиентам eth0 и разрешать подключаться к ним клиентами tun0. Вот в этом моя главная задача. Сожалею, если не смог сразу ее точно сформулировать.

Добавь правило, которое запрещает обращение к портам сервисов клиентам с входящим интерфейсом eth0.

Идея хорошая. Проблема в том, что там у меня сервис один есть который открывает порты динамически, а в документациии информации об этих интервалов я так и не нашел. В нете разные данные. Проверить невозможно - так как random. Поэтому я должен разрешить всё клиентам tun0 и запретить всё клиентам eth0 (кроме порта vpn, ssh).

Ну разреши пакеты на порты VPN и SSH клиентам из eth0 (с входящим интерфейсом eth0) или из сети за eth0, можешь ещё ICMP пакеты разрешить, а всё остальное запрети.

В чём проблема?

Да, но если я все запрешаю, то клиенты tun0 также ничего не могут сделать - только что проверил, чтобы убедиться. Или я что-то не понимаю?

Я не знаю какое правило ты ввёл, какие у тебя другие правила в iptables.

Разреши входящие соединения для сети за eth0 на определённые порты, а потом запрети всё для сети за eth0.

Удачи.

Понятно. Обычный бла бла. Сожалею, что сразу не понял.

Что значит обычный «бла бла бла»?

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

iptables-save

Если нет - иди лесом.

Обычный бла бла - когда человек дает какие-то советы, не понимая сути и не нацелен на результат. Кроме того, у меня нет желания говорить с человеком, который говорит - иди лесом.

Я как раз таки нацелен на результат, а советы я говорю не «какие-то», а достаточно конкретные, Если ты не понимаешь что надо ввести в iptables, то должен показать текущее содержимое правил, т.е. вывод iptables-save и привести какие правила ты вводишь в пакетный фильтр.

Если в техническом вопросе ты говоришь, что ты что-то сделал следуя совету, но у тебя не получилось и ты не привёл как минимум команду что вводил, а в данном случае и текущее содержимое правил пакетного фильтра, то что же мне тебе ещё ответить.

В iptables важна очерёдность правил.

Если в начале ты написал что-то вроде:

-A INPUT -i eth0 -s 192.168.10.0\24 -j DROP
-A INPUT -i eth0 -s 192.168.10.0\24 -m tcp --dport 22 -j ACCEPT

-A INPUT -s 192.168.10.0\24 -j DROP
-A INPUT -s 192.168.10.0\24 -m tcp --dport 22 -j ACCEPT

Поэтому если тебе нужна помощь то потрудись привести данные того, что ты вводишь и текущие правила iptables, если ты этого не можешь сделать, видимо просто не знаешь, что делать надо так. А попросту говоришь помогающему тебе человеку, что он несёт «бла бла бла», то мой ответ - иди лесом.

Удачи.

Чувак, он как раз понимает суть, судя по его наводящим вопросам, а вот тебе, похоже, самому до конца не ясно чего ты хочешь.

Где x.x.x.x это IP eth0. Но DNAT нельзя использовать в тех случаях, когда IP динамический. Поэтому я и вынужден использовать MASQUERADE.

Песок плохая замена овсу. Вас ниразу не смущают разные названия цепочек PREROUTING и POSTROUTING.
И далее когда вам хотят помочь с правильными советами еще и на юх посылаете.
Удачи вам, с таким подходом.

нужно просто прописать клиентам маршрут в подсеть висящую на eth0

А ещё на всех устройствах в сети за eth0 надо прописать маршрут в подсеть клиентов. Короче, иногда действительно может быть нужен маскарадинг.

Для того, чтобы человек понял суть (а он ее понял лучше чем ты) нужно в стартовом посте объяснить.

На твой вопрос

Скажите, пожалуйста, какой вариант нужно использовать и почему.

тебе предельно ясно, в первом же ответе сказали

Для этого совсем не нужен MASQUARADE

а дальше как раз и пошли бла-бла-бла без объяснений какие сервисы, на каких портах и т.д. и т.п.