LINUX.ORG.RU
Форум — Admin  

Использование таблицы mangle (MARK, CONNMARK)

 , , ,


0

1

Здравствуйте,

Сейчас пытаюсь немного поиграться с роутером и статическими роутами пакетов. Вот тут тема с проблемой http://www.dd-wrt.com/phpBB2/viewtopic.php?t=310871

Нужно все пакеты с определенного хоста на определенные порты помечать меткой.

Собственно вот такое правило написал 

iptables -A PREROUTING -t mangle -s 192.168.0.113 -p tcp -m multiport --dports 80,443 -j MARK --set-mark 3

В таблице mangle появилось данное правило 

MARK       tcp  --  192.168.0.113        0.0.0.0/0           multiport dports 80,443  MARK set 0x3

Но когда пытаюсь просмотреть активные соединения в ядре, то везде метка 0.

Проверяю с помощью команды 

 cat /proc/net/nf_conntrack

Собственно несколько вопросов.

  • 1. Когда нужно использовать CONNMARK --save-mark ? Насколько я понимаю это используется для того чтобы для всего конекшена (сессии установленной) устанавливать метку такую же как на пакеты ?
  • 2. Нужно ли вместе использовать CONNMARK & MARK ? Пробовал добавить еще правило такое после первого 
    iptables -A PREROUTING -t mangle -s 192.168.0.113 -p tcp -m multiport --dports 80,443 -j CONNMARK --save-mark
    это поменяло ситуацию. Появились вот такие конекшены. 
    ipv4     2 tcp      6 3555 ESTABLISHED src=192.168.0.113 dst=104.27.148.171 sport=57720 dport=80 packets=6 bytes=1536 src=104.27.148.171 dst=193.151.106.238 sport=80 dport=57720 packets=5 bytes=752 [ASSURED] mark=3 use=2
    Поэтому насколько я понимаю мое первое утверждение было верным. Тогда как их правильно использовать и смысл от такого использования какой в отличии от обычного MARK ?
  • 3. Один из главных вопросов с учетом предыдущих. Как дебажить маркирование это ? Пробовал на виртуалке с Centos 7 проверить правила, чтобы исключить ошибку в самих правилах, но там нет замапенного файла из памяти /proc/net/nf_conntrack. Пробовал ss утилиту, но не нашел как там метки отобразить.

Буду благодарен за разъяснение данных вопросов.

Спасибо



Последнее исправление: CROSP (всего исправлений: 3)

1 - ага

2 - Если правила маркировки просты, то можно обойтись без CONNMARK. А вот если нужно пробросить порт с нескольких разных адресов (разных интерфейсов) на 1 адрес во внутренней сети, то без CONNMARK не обойтись

3 - «iptables -j TRACE» для борьбы с особо сложными ситуациями. Использовать очень осторожно! Есть подозрение, что до сих пор не работает в NETNS.

Жаль, что для policy routing нет аналога TRACE.

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

Спасибо большое Вам за ответ.

Получилось реализовать, то что хотел.

Конфигурация следующая.

Есть внутри сети (виртуалка) с запущенным Redsocks, он просто редиректит все запросы поступающее на порты 80,443 на сервер SOCKS5.

Задача была сделать чтобы по определенному критерию, в данном случае просто айпишник машины (клиента) из сети редиректил все запросы сначала на сервак с запущенным Redsocks, а затем уже на прокси сервер само собой

Вот моя конфигурация 

iptables -A PREROUTING -t mangle -s 192.168.0.113 -p tcp -m multiport --dports 80,443 -j MARK --set-mark 3
iptables -A PREROUTING -t mangle -s 192.168.0.113 -p tcp -m multiport --dports 80,443 -j CONNMARK --save-mark

ip rule add fwmark 3 table 13
ip route add default via 192.168.0.145 dev br0 table 13

Все даже взлетело и работает. Но есть одно но. Перестало заходит на внутресетевые ресурсы, которые доступны из вне. Они работают через Reverse Proxy - HAProxy.

То есть грубо говоря есть такой адрес resource.mysite.com. Он резолвится на мой публичный айпишник. Когда приходит на роутер, то все запросы 80 и 443 посылаются на машину с HAProxy, а оттуда уже по виртуалкам разным.

Так вот как раз на такие страницы не заходит, а падает по таймауту.

Попробовал использовать следующее правило 

iptables -A PREROUTING -t mangle -s 192.168.0.113 ! -d 192.168.0.0/24 -p tcp -m multiport --dports 80,443 -j MARK --set-mark 3
iptables -A PREROUTING -t mangle -s 192.168.0.113 ! -d 192.168.0.0/24 -p tcp -m multiport --dports 80,443 -j CONNMARK --save-mark

Все равно падает по таймауту.

Подскажите в чем может быть проблема и вообще по правилам все ли верно задал.

Спасибо

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

Перестало заходит на внутресетевые ресурсы, которые доступны из вне.

Либо их дропает rp_filter, либо в таблице 13 нет локальных маршрутов.

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

У PR есть только дебаг в виде «ip ru» и «ip ro get».

ip ro get 8.8.8.8 from 192.168.0.113 iif br0 mark 3 - покажет куда будет послан пакет 192.168.0.113->8.8.8.8 пришедший на интерфейс br0 с маркой 3

а для rp_filter есть счетчик «netstat -s counter| grep IPReversePathFilter»

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

Спасибо за ответ.

Тут такое чувство что половина аргументов не воспринимается или урезанные сильно тулзы установлены на DD-WRT. Отрабатывает без ошибок 

ip ro get 8.8.8.8 from 192.168.0.113 iif br0 mark 3
Но в ответ пустота, точнее вообще ничего

Хоть что-то чтобы писало вот так только проходит 

ip route get 8.8.8.8
// Output
8.8.8.8 via 172.20.1.254 dev ppp0  src 193.151.106.238 
    cache

Остальное просто молчит

Версия ядра 

root@CROSP Router:~# uname -ra
Linux CROSP Router 3.18.1 #256 Mon Dec 22 04:38:27 CET 2014 mips GNU/Linux

На счет rp_filter, насколько я понимаю он не используется на роутере 

root@CROSP Router:~# cat /proc/sys/net/ipv4/conf/default/rp_filter
0

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

Спасибо

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

Попробовал следующий вараинт 

iptables -A PREROUTING -t mangle -s 192.168.0.113 ! -d `nvram get lan_ipaddr`/`nvram get lan_netmask` -p tcp -m multiport --dports 80,443 -j MARK --set-mark 3
iptables -A PREROUTING -t mangle -s 192.168.0.113 ! -d `nvram get wan_ipaddr` -p tcp -m multiport --dports 80,443 -j MARK --set-mark 3
iptables -A PREROUTING -t mangle -s 192.168.0.113 ! -d `nvram get lan_ipaddr`/`nvram get lan_netmask` -p tcp -m multiport --dports 80,443 -j CONNMARK --save-mark
iptables -A PREROUTING -t mangle -s 192.168.0.113 ! -d `nvram get wan_ipaddr` -p tcp -m multiport --dports 80,443 -j CONNMARK --save-mark

Все равно та же проблема. Начал дебажить непосредственно сами пакеты с помощью

tail -f /proc/net/ip_conntrack | grep "dport=80"

Получил интересную картину

tcp      6 47 SYN_SENT src=192.168.0.113 dst=23.37.43.27 sport=64777 dport=80 packets=1 bytes=64 [UNREPLIED] src=23.37.43.27 dst=192.168.0.113 sport=80 dport=64777 packets=0 bytes=0 mark=3 use=2
tcp      6 93 TIME_WAIT src=192.168.0.123 dst=134.213.81.97 sport=46632 dport=80 packets=6 bytes=514 src=134.213.81.97 dst=193.151.106.238 sport=80 dport=46632 packets=5 bytes=670 [ASSURED] mark=0 use=2
tcp      6 73 SYN_SENT src=192.168.0.113 dst=178.255.83.1 sport=64816 dport=80 packets=1 bytes=64 [UNREPLIED] src=178.255.83.1 dst=192.168.0.113 sport=80 dport=64816 packets=0 bytes=0 mark=3 use=2
tcp      6 3 SYN_SENT src=192.168.0.113 dst=23.37.43.27 sport=64737 dport=80 packets=1 bytes=64 [UNREPLIED] src=23.37.43.27 dst=192.168.0.113 sport=80 dport=64737 packets=0 bytes=0 mark=3 use=2

Тут вообще нет моего внешнего айпишника. dst=23.37.43.27 вот подобные адреса мне вообще не известны.

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

Все домены на которые не могу зайти внутри сети, резолвятся правильно.

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

ip ro get 8.8.8.8 from 192.168.0.113 iif br0 mark 3

Но в ответ пустота, точнее вообще ничего

Там наверно урезанный iproute2 из busybox. Нужен нормальный iproute2 (для openwrt он есть).

Про прямые маршруты (без iproute2 не обойтись imho)

то, что выдает ip ro ls proto kernel должно быть в таблице 13

Наличие ppp-интерфейсов усложнят задачу, т.к. после подъема такого интерфейса нужно продублировать маршрут в таб.13

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

Наличие ppp-интерфейсов усложнят задачу, т.к. после подъема такого интерфейса нужно продублировать маршрут в таб.13

Но у ТСа же бридж...

vodz ★★★★★
()
Ответ на: комментарий от ne-vlezay

Спасибо всем за ответы.

Вот тут немного продебажил

Вот как выглядят пакеты с хоста, который не идет через прокси. 

root@CROSP Router:~# cat /proc/net/ip_conntrack | grep "port=80"
tcp      6 3598 ESTABLISHED src=192.168.0.103 dst=my.public.ip sport=62936 dport=80 packets=2 bytes=92 src=192.168.0.124 dst=192.168.0.1 sport=80 dport=62936 packets=1 bytes=52 [ASSURED] mark=2147483648 use=2
tcp      6 3598 ESTABLISHED src=192.168.0.103 dst=my.public.ip sport=62937 dport=80 packets=2 bytes=92 src=192.168.0.124 dst=192.168.0.1 sport=80 dport=62937 packets=1 bytes=52 [ASSURED] mark=2147483648 use=2
tcp      6 101 TIME_WAIT src=192.168.0.123 dst=134.213.81.97 sport=47036 dport=80 packets=6 bytes=514 src=134.213.81.97 dst=193.151.106.238 sport=80 dport=47036 packets=5 bytes=671 [ASSURED] mark=0 use=2
tcp      6 3598 ESTABLISHED src=192.168.0.103 dst=my.public.ip sport=62938 dport=80 packets=2 bytes=92 src=192.168.0.124 dst=192.168.0.1 sport=80 dport=62938 packets=1 bytes=52 [ASSURED] mark=2147483648 use=2
tcp      6 3598 ESTABLISHED src=192.168.0.103 dst=my.public.ip sport=62935 dport=80 packets=5 bytes=512 src=192.168.0.124 dst=192.168.0.1 sport=80 dport=62935 packets=3 bytes=2825 [ASSURED] mark=2147483648 use=2
tcp      6 41 TIME_WAIT src=192.168.0.123 dst=134.213.81.97 sport=46652 dport=80 packets=6 bytes=514 src=134.213.81.97 dst=193.151.106.238 sport=80 dport=46652 packets=5 bytes=670 [ASSURED] mark=0 use=2

Самое интересное что отличает такие пакеты этот какой-то здоровый маркер mark=2147483648 откуда он берется, видно из таблицы mangle. MARK 0  — 0.0.0.0/0 my.public.ip MARK or 0x80000000

Вот как выглядит output команды 

ip route show table all

default via 192.168.0.145 dev br0  table 13 
default via 172.20.1.254 dev ppp0 
127.0.0.0/8 dev lo  scope link 
169.254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1 
172.20.1.254 dev ppp0  proto kernel  scope link  src my.public.ip 
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1 
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
broadcast 169.254.0.0 dev br0  table local  proto kernel  scope link  src 169.254.255.1 
local 169.254.255.1 dev br0  table local  proto kernel  scope host  src 169.254.255.1 
broadcast 169.254.255.255 dev br0  table local  proto kernel  scope link  src 169.254.255.1 
broadcast 192.168.0.0 dev br0  table local  proto kernel  scope link  src 192.168.0.1 
local 192.168.0.1 dev br0  table local  proto kernel  scope host  src 192.168.0.1 
broadcast 192.168.0.255 dev br0  table local  proto kernel  scope link  src 192.168.0.1 
local my.public.ip dev ppp0  table local  proto kernel  scope host  src my.public.ip
broadcast my.public.ip dev ppp0  table local  proto kernel  scope link  src my.public.ip

И таблица mangle 

root@CROSP Router:~# iptables -L -n -t mangle
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
MARK       0    --  0.0.0.0/0            my.public.ip      MARK or 0x80000000
CONNMARK   0    --  0.0.0.0/0            0.0.0.0/0           CONNMARK save  
ACCEPT     tcp  --  192.168.0.145        0.0.0.0/0           multiport dports 80,443 
ACCEPT     tcp  --  192.168.0.124        0.0.0.0/0           multiport dports 80,443 
MARK       tcp  --  192.168.0.113       !192.168.0.0/24      multiport dports 80,443  MARK set 0x3
MARK       tcp  --  192.168.0.113       !my.public.ip  multiport dports 80,443  MARK set 0x3
CONNMARK   tcp  --  192.168.0.113       !192.168.0.0/24      multiport dports 80,443 CONNMARK save  
CONNMARK   tcp  --  192.168.0.113       !my.public.ip   multiport dports 80,443 CONNMARK save  

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
TCPMSS     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x02 TCPMSS clamp to PMTU 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

А если слать запрос из машина которая под прокси в данном случае 192.168.0.113

То вот такое получаем 

tcp      6 118 SYN_SENT src=192.168.0.113 dst=my.public.ip sport=55304 dport=80 packets=2 bytes=128 [UNREPLIED] src=192.168.0.124 dst=192.168.0.113 sport=80 dport=55304 packets=0 bytes=0 mark=3 use=2
tcp      6 118 SYN_SENT src=192.168.0.113 dst=104.27.149.171 sport=55300 dport=80 packets=1 bytes=64 [UNREPLIED] src=104.27.149.171 dst=192.168.0.113 sport=80 dport=55300 packets=0 bytes=0 mark=3 use=2
tcp      6 118 SYN_SENT src=192.168.0.113 dst=my.public.ip  sport=55297 dport=80 packets=2 bytes=128 [UNREPLIED] src=192.168.0.124 dst=192.168.0.113 sport=80 dport=55297 packets=0 bytes=0 mark=3 use=2
tcp      6 118 SYN_SENT src=192.168.0.113 dst=my.public.ip  sport=55303 dport=80 packets=2 bytes=128 [UNREPLIED] src=192.168.0.124 dst=192.168.0.113 sport=80 dport=55303 packets=0 bytes=0 mark=3 use=2

Как видно из вышеприведенного аутпута. Не смотря на правила заданные в таблице mangle метка устанавливается в значение 3.

Правило

MARK 0  — 0.0.0.0/0 my.public.ip MARK or 0x80000000

Было добавлено роутером автоматически, вручную ничего не добавлял.

Скажите пожалуйста почему получаю такой результат и правила которые задал, чтобы не устанавливали метку не работают ?

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

Ошибся, ребутнул роутер

Вот такие правила по умолчанию 

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
MARK       0    --  0.0.0.0/0           my.public.ip      MARK or 0x80000000
CONNMARK   0    --  0.0.0.0/0            0.0.0.0/0           CONNMARK save
CROSP
() автор топика
Ответ на: комментарий от CROSP

Походу решил проблему. Про приоритет правил совсем забыл.

iptables -I PREROUTING 1 -t mangle -s 192.168.0.113 ! -d `nvram get lan_ipaddr`/`nvram get lan_netmask` -p tcp -m multiport --dports 80,443 -j MARK --set-mark 3
iptables -I PREROUTING 2 -t mangle -s 192.168.0.113 ! -d `nvram get wan_ipaddr` -p tcp -m multiport --dports 80,443 -j MARK --set-mark 3
iptables -I PREROUTING 3 -t mangle -s 192.168.0.113 ! -d `nvram get lan_ipaddr`/`nvram get lan_netmask` -p tcp -m multiport --dports 80,443 -j CONNMARK --save-mark
iptables -I PREROUTING 4 -t mangle -s 192.168.0.113 ! -d `nvram get wan_ipaddr` -p tcp -m multiport --dports 80,443 -j CONNMARK --save-mark

Честно говоря немного не понимаю вот это логики с меткой, зачем роутеру нужно это правило

Вот так сейчас выглядит таблица mangle 

root@CROSP Router:~# iptables -vL -t mangle
Chain PREROUTING (policy ACCEPT 153K packets, 117M bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1514  225K MARK       tcp  --  any    any     192.168.0.113        !192.168.0.0/24      multiport dports www,https  MARK set 0x3
 1434  212K MARK       tcp  --  any    any    192.168.0.113        !my.public.ip multiport dports www,https  MARK set 0x3
 1502  224K CONNMARK   tcp  --  any    any     192.168.0.113        !192.168.0.0/24      multiport dports www,https CONNMARK save  
 1425  211K CONNMARK   tcp  --  any    any     192.168.0.113        !my.public.ip multiport dports www,https CONNMARK save  
 1569  724K MARK       0    --  !ppp0  any     anywhere             my.public.ip  MARK or 0x80000000
 153K  117M CONNMARK   0    --  any    any     anywhere             anywhere            CONNMARK save

Вроде заходит сейчас нормально.

Кто может, объясните пожалуйста логику этих всех меток, зачем роутер устанавливает на все соединения где адрес назначения мой публичный айпишник метку 0x80000000

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

Кроме бриджа к него еще есть интерфейсы

ip route get 8.8.8.8

// Output

8.8.8.8 via 172.20.1.254 dev ppp0 src 193.151.106.238 cache

Собственно вопрос пока такой - является ли отсутствие прямых маршрутов в таблице 13 причиной недоступности локальных адресов ?

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

Насколько я понял, тут немного по-другому. Выше я написал что сделал чтобы заработало.

Из-за порядка правил, метка сохранялась и не ставилось это магическое значение MARK or 0x80000000, все такие пакеты висели и падали по таймауту.

Когда исправил все заработало, только понимания о происходящем не добавило.

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

Кроме бриджа к него еще есть интерфейсы

У него ppp0 - default, а не 13.

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