LINUX.ORG.RU
ФорумAdmin

SNAT по определенному порту для локальных приложений


0

1

всем добрый день! есть одна сетевая карточка - на которую приходит как тегированый трафик так и не тегированый.

eth0 сюда идет не тегированый трафик из сети А шлюз а.а.а.а

eth0.10 сюда идет тегированный трафик из сети В

eth0.20 ........ сеть Д и т.д.

есть программа, которая ломится с моей машины на компьютеры пользователей по порту 3333, но на компах юзеров из сетей В и Д стоит айпифильтр и соединение возможно только если находишься в сети А ...

так вот как сделать так чтобы бы трафик уходящий на порт юзеров из любых подсетей 3333 шел только через eth0, a не через eth0.10 eth0.20 ?

то что можно расширить список сетей в айпифильтре это понятно, но вот как решить такую проблему через iptables?

Долгие мучения привели к следующей конструкции

echo 201 program.test >> /etc/iproute2/rt_tables

iptables -t mangle -A OUTPUT -p tcp --dport 3333 -j MARK --set-mark 255

iptables -t nat -A POSTROUTING -m mark --mark 255 -j SNAT --to-source a.a.a.a (шлюз для eth0)

ip rule add fwmark 255 table program.test

ip ro add default via a.a.a.a dev eth0.10 table program.test

но вот на добавлении роута он мне говорит RTNETLINK answers: No such process

как быть?

Ответ на: комментарий от genyabms

Если a.a.a.a это шлюз, то есть ip-адрес другой машины в сети eth0, то почему SNAT на этот адрес, а не на адрес, присовенный eth0. И почему пытаетесь прописать маршрут для устройства eth0.10, а не для устройства eth0 ?

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

с Snat на интерфейс eth0 - это я проспал ... просто я понимаю так , когда мне надо подключиться к программе , которая стоит у юзера из другой подсети, то происходит принятие решение о маршрутизации на моей машине и пакеты отправляются по кратчайшему пути, т.е. через интерфейсы eth0.10 и т.д. которые смотрят в эту подсеть ... но мне так не подходит, с учетом того что что в программе стоит айпифильтр и пакеты приходящие с соурсадресом eth0.10 отбрасываются ... все что мне надо, так это чтобы трафик , который идет c моей машины на дестонейшен порт 3333 уходил с соурс адресом eth0 ... для этого я так понимаю надо сделать

iptables -t mangle -A OUTPUT -p tcp --dport 3333 -j MARK --set-mark 255 маркировка трафика на дестанейшен порт 3333

iptables -t nat -A POSTROUTING -m mark --mark 255 -j SNAT --to-source eth0 весь маркированный трафик отправлять с айпи адресом интерфейса eth0 в заголовке пакета

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

но блин не работает ...

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

В принципе, SNAT правила должно хватать, если только нет лишних правил. Раз не работает, то смотрите пакеты tcpdump'ом, там видно, куда и с какими ip-адресами уходят пакеты. Заодно можно попробовать дампить пакеты на каком-нибудь компе пользователя, тогда, может, будет виднее.

А вобще, протокол то позволяет делать SNAT? Внутри протокола случаем не передаётся ip-адрес?

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

просмотрел трафик tcpdumpom ... Snat отрабатывает, айпиадре соурса заменяется на тот который мне надо , но вот есть момент который мне не понятен ... когда идет замена адреса то он я так понимаю в пакет добавляет еще тег влана

vlan 10, p 0, IP 192.168.1.18.53475 > 10.1.10.99.3333: Flags [.], ack 1, win 46, options [nop,nop,TS val 1387583 ecr 930467], length 0

и соединение после нескольких попыток разрывается ....

если же у клиента пойти и снять айпифильтр и попробовать соединение заново но уже без snat а напрямую с интерфейса eth0.10, то тег влана не подставляется и соединение проходит

IP 10.1.10.18.35582 > 10.1.10.99.3333: Flags [.], ack 1, win 46, options [nop,nop,TS val 1399537 ecr 0], length 0

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

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

iptables не занимается маршрутизацией, SNAT только меняет адрес. У вас маршут к 10.1.10.99 идёт через eth0.10, поэтому через этот интерфейс идёт пакет, то есть добавляется тег vlan'а. tcpdump видит все пакеты на физическом интерфейсе, то есть и eth0 и eth0.10 и eth0.20 видны, если дампить пакеты на eth0.

но уже без snat а напрямую с интерфейса eth0.10, то тег влана не подставляется

Мне не понятно, почему тег vlan не подставляется в этом случае. Это если дампить пакеты на сервере?

Тег убирать нельзя, можно только пустить пакеты через eth0, с помощью «ip rule».

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

>>Тег убирать нельзя, можно только пустить пакеты через eth0, с помощью «ip rule».

подскажите как это правильно сделать ...

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

В первом посту всё было правильно, разве что «ip route ... dev eth0», и, возможно, не нужно использовать точку в имени таблицы. Я вобще не даю таблицам имена, а везде указываю число.

И, прописывая default маршрут в таблицу «program.test», нужно было, либо сначала добавить в неё маршрут на сеть A

«ip route add a.a.a.a/24 dev eth0 table program.test»,

либо использовать магическое слово «onlink»

«ip route add default via a.a.a.a dev eth0.10 table program.test onlink» .

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

iptables -t mangle -A OUTPUT -p tcp --dport 3333 -j MARK --set-mark 255

iptables -t nat -A POSTROUTING -m mark --mark 255 -j SNAT --to-source 192.168.1.18 (ip_eth0)

echo 201 3333 >> /etc/iproute2/rt_tables

ip rule add fwmark 255 table 3333

ip ro add 192.168.1.0/24 dev eth0 table 3333

ip route add default via ip_шлюза_eth0 dev eth0 table 3333

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

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

>мой комп запрашивает соединение ему отвечают

Значит, ответные пакеты не доходят до вашего приложения. Возможно сбрасываются в iptables, возможно rp_filter включён на это интерфейс.

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

попробовал отключать rp_filter как на этот интерфейс так и для всех ... результата увы не дало ... вот что мне пишет tcpdump

13:04:10.010128 IP (tos 0x0, ttl 64, id 45621, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.18.36052 > 10.1.10.99.3333: Flags , cksum 0x3acf (correct), seq 1195529919, win 5840, options [mss 1460,sackOK,TS val 1369226 ecr 0,nop,wscale 7], length 0

13:04:10.010596 IP (tos 0x0, ttl 127, id 19367, offset 0, flags [DF], proto TCP (6), length 60) 10.1.10.99.3333 > 192.168.1.18.36052: Flags [S.], cksum 0x4931 (correct), seq 2575447489, ack 1195529920, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS val 1448194 ecr 1369226], length 0

13:04:13.002919 IP (tos 0x0, ttl 64, id 45622, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.18.36052 > 10.1.10.99.3333: Flags , cksum 0x39a3 (correct), seq 1195529919, win 5840, options [mss 1460,sackOK,TS val 1369526 ecr 0,nop,wscale 7], length 0

13:04:13.008886 IP (tos 0x0, ttl 127, id 19395, offset 0, flags [DF], proto TCP (6), length 60) 10.1.10.99.3333 > 192.168.1.18.36052: Flags [S.], cksum 0x4805 (correct), seq 2575447489, ack 1195529920, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS val 1448494 ecr 1369226], length 0

13:04:19.000416 IP (tos 0x0, ttl 64, id 45623, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.18.36052 > 10.1.10.99.3333: Flags , cksum 0x374b (correct), seq 1195529919, win 5840, options [mss 1460,sackOK,TS val 1370126 ecr 0,nop,wscale 7], length 0

13:04:19.009171 IP (tos 0x0, ttl 127, id 19408, offset 0, flags [DF], proto TCP (6), length 56) 10.1.10.99.3333 > 192.168.1.18.36052: Flags [S.], cksum 0x59bc (correct), seq 2575447489, ack 1195529920, win 8192, options [mss 1460,sackOK,TS val 1449094 ecr 1369226], length 0

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

Попробуйте добавить во все цепочки iptables, через которые должен пройти ответный пакет правило-счётчик типа:

iptables -t mangle -I PREROUTING -s 10.1.10.99 -p tcp --sport 3333

и посмотреть счётчики (iptables -L -n -v -x, и так для всех таблиц) до и после попытки установления соединения. Может будет понятнее, где теряется пакет.

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