Почему не работает правило ip rule add fwmark?

Question

[netc1983]

Настраиваю несколько uplink'ов на шлюзе.

На шлюзе также работает openvpn внутри lxc контейнера (сеть организована через bridge интерфейс, в который входят сетевые интерфейсы lxc и физический eth0 смотрящий в LAN)

root@gate:/etc/init.d# brctl show
bridge name	bridge id		STP enabled	interfaces
br-eth0		8000.002191ef8b35	no		eth0
							vethGPYWS8
							vethXGQ5EQ
lxcbr0		8000.000000000000	no

Связь по протоколам udp/tcp с службами работающими на шлюзе прекрасно работает для клиентов из Интернет.

Не получается настроить проброс OPENVPN сервера, работающего по udp.

Суть в том, что как только я добавляю правило

ip rule add from 192.168.128.13 lookup isc-ml

Где 192.168.128.13 - ip контейнера openvpn, работающего на шлюзе

То клиент нормально устанавливает соединение с сервером.

А нужно чтобы работало правило:

ip rule add from all fwmark 0x2 lookup isc-ml prio 1000

Дополнительная информация:

root@gate:/home/sysadmin# ip rule list
0:	from all lookup local 
1000:	from all fwmark 0x2 lookup isc-ml 
32759:	from all to 95.X.X.0/24 lookup isc-ml 
32760:	from 95.X.X.40 lookup isc-ml 
32762:	from all to 83.Y.Y.194 lookup isc-rt 
32763:	from 93.Y.Y.67 lookup isc-rt 
32766:	from all lookup main 
32767:	from all lookup default

Трассировка iptables
Где - 93.Z.Z.117 - ip openvpn клиента

Aug 14 13:01:30 gate kernel: [934528.016392] TRACE: mangle:PREROUTING:rule:2 IN=ethmiddle OUT= MAC=90:94:e4:82:0e:00:68:05:ca:0f:20:aa:08:00 SRC=93.Z.Z.117 DST=95.X.X.40 LEN=42 TOS=0x00 PREC=0x00 TTL=53 ID=8720 DF PROTO=UDP SPT=44619 DPT=1194 LEN=22 MARK=0x2 
Aug 14 13:01:30 gate kernel: [934528.016425] TRACE: mangle:PREROUTING:rule:4 IN=ethmiddle OUT= MAC=90:94:e4:82:0e:00:68:05:ca:0f:20:aa:08:00 SRC=93.Z.Z.117 DST=95.X.X.40 LEN=42 TOS=0x00 PREC=0x00 TTL=53 ID=8720 DF PROTO=UDP SPT=44619 DPT=1194 LEN=22 
Aug 14 13:01:30 gate kernel: [934528.016498] TRACE: nat:PREROUTING:rule:6 IN=ethmiddle OUT= MAC=90:94:e4:82:0e:00:68:05:ca:0f:20:aa:08:00 SRC=93.Z.Z.117 DST=95.X.X.40 LEN=42 TOS=0x00 PREC=0x00 TTL=53 ID=8720 DF PROTO=UDP SPT=44619 DPT=1194 LEN=22 MARK=0x2 
Aug 14 13:01:30 gate kernel: [934528.016557] TRACE: mangle:FORWARD:policy:1 IN=ethmiddle OUT=ethmiddle MAC=90:94:e4:82:0e:00:68:05:ca:0f:20:aa:08:00 SRC=93.Z.Z.117 DST=192.168.128.13 LEN=42 TOS=0x00 PREC=0x00 TTL=52 ID=8720 DF PROTO=UDP SPT=44619 DPT=1194 LEN=22 MARK=0x2 
Aug 14 13:01:30 gate kernel: [934528.016600] TRACE: filter:FORWARD:policy:12 IN=ethmiddle OUT=ethmiddle MAC=90:94:e4:82:0e:00:68:05:ca:0f:20:aa:08:00 SRC=93.Z.Z.117 DST=192.168.128.13 LEN=42 TOS=0x00 PREC=0x00 TTL=52 ID=8720 DF PROTO=UDP SPT=44619 DPT=1194 LEN=22 MARK=0x2 
Aug 14 13:01:30 gate kernel: [934528.016633] TRACE: mangle:POSTROUTING:rule:1 IN= OUT=ethmiddle SRC=93.Z.Z.117 DST=192.168.128.13 LEN=42 TOS=0x00 PREC=0x00 TTL=52 ID=8720 DF PROTO=UDP SPT=44619 DPT=1194 LEN=22 MARK=0x2

iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j RETURN # if already set, we're done
iptables -t mangle -A PREROUTING -i ethmiddle      -j MARK --set-mark 0x2
iptables -t mangle -A POSTROUTING -o ethmiddle     -j MARK --set-mark 0x2
iptables -t mangle -A POSTROUTING -j CONNMARK --save-mark

Проброс

iptables -t nat -A PREROUTING -d $XINETIP -p UDP --dport 1194 -j DNAT --to-destination $VPNSERVER:1194

Почему не работает ip rule fwmark, а ip rule add from vpnserver - работает?

UPDATE 1:

Tcpdump на шлюзе.

при не работающем fwmark-ке:

00:00:07.106369 IP (tos 0x0, ttl 53, id 16663, offset 0, flags [DF], proto UDP (17), length 42)
    93.Z.Z.117.43148 > 95.X.X.40.openvpn: [udp sum ok] UDP, length 14
00:00:00.000056 IP (tos 0x0, ttl 52, id 16663, offset 0, flags [DF], proto UDP (17), length 42)
    95.X.X.40.43148 > openvpn.cvision.lab.openvpn: [udp sum ok] UDP, length 14

при добавленном правиле ip rule add from 192.168.128.13 lookup isc-ml - проброс работает и соединение устанавливается:

00:00:00.000000 IP (tos 0x0, ttl 53, id 41756, offset 0, flags [DF], proto UDP (17), length 42)
    93.Z.Z.117.57380 > 95.X.X.40.openvpn: [udp sum ok] UDP, length 14
00:00:00.000832 IP (tos 0x0, ttl 63, id 43790, offset 0, flags [DF], proto UDP (17), length 54)
    95.X.X.40.openvpn > 93.Z.Z.117.57380: [udp sum ok] UDP, length 26
00:00:00.044444 IP (tos 0x0, ttl 54, id 41767, offset 0, flags [DF], proto UDP (17), length 50)
    93.Z.Z.117.57380 > 95.X.X.40.openvpn: [udp sum ok] UDP, length 22
00:00:00.000089 IP (tos 0x0, ttl 54, id 41768, offset 0, flags [DF], proto UDP (17), length 142)
    93.Z.Z.117.57380 > 95.X.X.40.openvpn: [udp sum ok] UDP, length 114
...

Кстати не могу понять почему я вижу это

95.X.X.40.43148 > openvpn.cvision.lab.openvpn: [udp sum ok] UDP, length 14

Получается, что каким то странным образом на внутренний сервер сам шлюз со своего внешнего интерфейса инициирует соединение ?

Возможно это было из-за SNAT без источника. Сейчас я добавил в правило SNAT ЛВС, и поидее такого уже не будет. Но эти дампы видимо делались ранее, когда еще SNAT был не таким точным. Ранее с одним провайдером он работал нормально. Случайно обнаружил в примерах у народа -s $LANNETIP

Answer 1

[netc1983]

РЕШЕНИЕ СМ. НИЖЕ. Спасибо всем кто пытался разобраться.

Есть

root@gate:/etc/init.d# ip ro sh ta isc-ml
default via 95.X.X.1 dev ethmiddle

Дело в том, что именно через fwmark не работает.

Еще меня смущают логи про martians packages:

Aug 14 11:56:30 gate kernel: [930628.627386] IPv4: martian source 192.168.128.13 from 93.Z.Z.117, on dev ethmiddle
Aug 14 11:56:39 gate kernel: [930636.846542] IPv4: martian source 192.168.128.13 from 93.Z.Z.117, on dev ethmiddle
Aug 14 11:56:54 gate kernel: [930652.586677] IPv4: martian source 192.168.128.13 from 93.Z.Z.117, on dev ethmiddle
Aug 14 11:57:08 gate kernel: [930665.944650] ll header: 00000000: ff ff ff ff ff ff 4c b1 6c 42 d1 7c 08 06        ......L.lB.|..
Aug 14 11:57:22 gate kernel: [930680.503274] ll header: 00000000: ff ff ff ff ff ff 4c b1 6c 42 d1 7c 08 06        ......L.lB.|..
Aug 14 11:57:26 gate kernel: [930684.060642] IPv4: martian source 192.168.128.13 from 93.Z.Z.117, on dev ethmiddle
Aug 14 11:57:32 gate kernel: [930690.082268] ll header: 00000000: ff ff ff ff ff ff 4c b1 6c 42 d1 7c 08 06        ......L.lB.|..
Aug 14 11:57:32 gate kernel: [930690.813437] IPv4: martian source 192.168.128.13 from 93.Z.Z.117, on dev ethmiddle
Aug 14 11:58:04 gate kernel: [930721.847001] ll header: 00000000: ff ff ff ff ff ff 00 25 22 89 80 df 08 00        .......%".....

Когда нет правила ip rule add from 192.168.128.13 lookup isc-ml

Я отключал rp_filter но это не дало результата. Если кто-то подскажет почему в моей ситуации возникают такие оказии - буду благодарен.

-----

РЕШЕНИЕ:

OPENVPN работать не будет, точнее CONNMARK не подходит т.к. UDP протокол не использует соединения. Но об этом я и так знал. Просто тупил.

Разобрался с работой CONNMARK для TCP протокола (на примере FTP). Дело было в порядке следования по правилам маршрутизации. По умолчанию на linux в таблицу main помещается маршрут по умолчанию (у нас это делает демон для pppoe от rt). Добавленное в начало цепочки правил правило маршрутизации в зависимости от mark срабатывало только для входящих пакетов, которые отправлялись сразу же назад.

Как то так:

Aug 27 16:25:38 gate kernel: [2069757.534619] mylog: IN=ethmiddle OUT=ethmiddle MAC=90:94:e4:82:0e:00:68:05:ca:0f:20:aa:08:00 SRC=95.X.X.50 DST=192.168.128.2 LEN=48 TOS=0x00 PREC=0x00 TTL=125 ID=29782 DF PROTO=TCP SPT=53224 DPT=2121 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0x2

Странно не правда ли ?

А в main таблице маршрут по умолчанию отправлял все пакеты от сервера FTP через основного провайдера.

Aug 27 16:51:29 gate kernel: [2071308.015057] mylog: IN=br-eth0 OUT=ppp60 PHYSIN=eth0 MAC=00:21:91:ef:8b:35:50:46:5d:59:6c:c6:08:00 SRC=192.168.128.2 DST=95.X.X.50 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=2121 DPT=53846 WINDOW=29200 RES=0x00 ACK SYN URGP=0 MARK=0x2

Вывод простой используйте iptables log, так

iptables -t filter -I FORWARD -d 95.X.X.50 -p tcp -m tcp ! --dport 1194 -j LOG --log-prefix "mylog: "

-I - добавляет в начало цепочки правило - это важно, иначе если ACCEPT или DROP сработают то к LOG правилу пакет уже не дойдет и вы ни чего не увидите в syslog.

По сути нужно было смотреть в таблицы маршрутизации и проверять каждое правило на то, может ли оно отправлять через провайдера rt. Оказалось может. Теперь надеюсь прикрутить это все как полагается в Debian-based системе и очень постараюсь написать еще одну статью )

Comments

[EvilMan]

Покажите, пожалуйста, iptables-save -c (полный дамп правил вместе со счётчиками), а так же покажите вывод команд ip route get mark и ip route get from iif - они покажут, какие маршруты будут выбираться для пакетов с заданной меткой и для пакетов, пришедших на определённый интерфейс с определённого айпи-адреса. Возможно, где-то что-то не отрабатывает должным образом. Не забывайте сбрасывать роут-кэш и таблицы коннтрака после изменения правил маршрутизации. Удобно, так же, для траблшутинга использовать nflog + tcpdump/wireshark.

[EvilMan]

Кстати, CONNMARK прекрасно работает с UDP и любым другим протоколом, который поддерживается трассировщиком соединений.

Answer 2

[Владимир]

похоже у вас нет нужных роутов в таблице isc-ml
ip ro sh ta isc-ml

Comments

[Владимир]

может быть ещё не хватает исходящего NAT или он завязан на другие метки