LINUX.ORG.RU
ФорумAdmin

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

 , ,


0

1

Доброго времени суток, уважаемые форумчане. У меня следующая ситуация. Есть два интерфейса tun0(openvpn) и eth0. Мне нужно перекидывать всё с tun0 на на eth0 чтобы клиенты openvpn могли работать с сервисами eth0 через vpn (зная только IP интерфейса tun0). В силу того, что используется динамичческий IP я использую MASQUERADE вместо DNAT. После чтения всей доступной информации до сих пор не понятно, какой вариант использовать:

Вариант 1:

iptables -A FORWARD --in-interface eth0 -j ACCEPT
iptables --table nat -A POSTROUTING --out-interface tun0 -j MASQUERADE

Вариант 2:

iptables -A FORWARD --in-interface tun0 -j ACCEPT
iptables --table nat -A POSTROUTING --out-interface eth0 -j MASQUERADE 

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

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

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

Deleted ()

Мне нужно перекидывать всё с 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"
и на шлюзе разрешить просто продвижение пакетов (ip_forward) и forwarding до OpenVPN сети с выходным интерфейсом tun0 и до сети 192.168.10.0\24 с входным интерфейсом tun0.

Но в этом случае на машинах в 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 клиенты смогут подключиться к узлам в локальной сети за шлюзом, но узлы в локальной сети не будут «видеть» узлы в OpenVPN сети.

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы было понятнее скажу так. В таких случах, когда 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи.

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

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

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

iptables-save
указывай какие порты должны быть доступны из eth0 и показывай что и куда ты вводишь.

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

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

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

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

Я как раз таки нацелен на результат, а советы я говорю не «какие-то», а достаточно конкретные, Если ты не понимаешь что надо ввести в 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, если ты этого не можешь сделать, видимо просто не знаешь, что делать надо так. А попросту говоришь помогающему тебе человеку, что он несёт «бла бла бла», то мой ответ - иди лесом.

Удачи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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