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

    @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 системе и очень постараюсь написать еще одну статью )
    Ответ написан