страшное правило для iptables

[AnrDaemon]

-j CONNMARK ставит и fwmark тоже? Из мана это не очевидно.
Хотя... если "MAC source", то СТАВИТЬ fwmark В ЭТОМ СЛУЧАЕ нет смысла.

Код: [Выделить]

*mangle
:PREROUTING ACCEPT [61132114:22745233983]
:INPUT ACCEPT [48014244:14217964417]
:FORWARD ACCEPT [13117637:8527245388]
:OUTPUT ACCEPT [48922131:15746257166]
:POSTROUTING ACCEPT [62187682:24300531725]
-A PREROUTING -m conntrack --ctstate NEW,RELATED -m mac --mac-source MAC:OF:GW:2 -j CONNMARK --set-mark 2А вот дальше что-то у меня затык. Ответ (ACK) на входящий NEW|RELATED как будет классифицироваться? Тоже как NEW (RELATED) ?
Тогда все проверки бессмысленны и просто

Код: [Выделить]

-A PREROUTING -j CONNMARK --restore-mark
COMMITрешит вопрос.

[Lion-Simba]

-j CONNMARK ставит и fwmark тоже? Из мана это не очевидно.

Меток в терминологии iptables две - ctmark (для сессии) и nfmark (для пакета). fwmark - это и есть nfmark. Соответственно, нет - не ставит.

Код: [Выделить]

*mangle
:PREROUTING ACCEPT [61132114:22745233983]
:INPUT ACCEPT [48014244:14217964417]
:FORWARD ACCEPT [13117637:8527245388]
:OUTPUT ACCEPT [48922131:15746257166]
:POSTROUTING ACCEPT [62187682:24300531725]
-A PREROUTING -m conntrack --ctstate NEW,RELATED -m mac --mac-source MAC:OF:GW:2 -j CONNMARK --set-mark 2А вот дальше что-то у меня затык. Ответ (ACK) на входящий NEW|RELATED как будет классифицироваться? Тоже как NEW (RELATED) ?
Тогда все проверки бессмысленны и просто

Код: [Выделить]

-A PREROUTING -j CONNMARK --restore-mark
COMMITрешит вопрос.

А вот тут я уже не уверен. Я думаю, настал момет сесть и поэкспериментировать.

[AnrDaemon]

Чет мои эксперименты пока упёрлись в стену. Сложно экспериментировать, гоняя трафик петлёй в свою собственную сетку через интернет.
Но сделал всё вроде бы верно (таблички маршрутов, деф GW в таблице и маркировка пакетов).
Буду с работы мучить.

[AnrDaemon]

Не работает
Ответы уходят на первый маршрутизатор.
# tcpdump -pi eth0 -s 6553 -e -- host 86.62.108.132 and \(\(tcp port 80\) or \(tcp port 81\)\)

(Нажмите, чтобы показать/скрыть)

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 6553 bytes
15:01:15.836100 00:d0:d0:61:30:2c (oui Unknown) > 00:60:97:93:62:fe (oui Unknown), ethertype IPv4 (0x0800), length 62: h86-62-108-132.ln.rinet.ru.1141 > daemon1.darkdragon.lan.81: S 1557011461:1557011461(0) win 65535 <mss 1460,nop,nop,sackOK>
15:01:15.836294 00:60:97:93:62:fe (oui Unknown) > 00:1b:11:84:e3:90 (oui Unknown), ethertype IPv4 (0x0800), length 62: daemon1.darkdragon.lan.81 > h86-62-108-132.ln.rinet.ru.1141: S 592007803:592007803(0) ack 1557011462 win 5840 <mss 1460,nop,nop,sackOK>
15:01:15.839728 00:1b:11:84:e3:90 (oui Unknown) > 00:60:97:93:62:fe (oui Unknown), ethertype IPv4 (0x0800), length 60: h86-62-108-132.ln.rinet.ru.1141 > daemon1.darkdragon.lan.81: R 1557011462:1557011462(0) win 0
15:01:18.795675 00:d0:d0:61:30:2c (oui Unknown) > 00:60:97:93:62:fe (oui Unknown), ethertype IPv4 (0x0800), length 62: h86-62-108-132.ln.rinet.ru.1141 > daemon1.darkdragon.lan.81: S 1557011461:1557011461(0) win 65535 <mss 1460,nop,nop,sackOK>
15:01:18.795834 00:60:97:93:62:fe (oui Unknown) > 00:1b:11:84:e3:90 (oui Unknown), ethertype IPv4 (0x0800), length 62: daemon1.darkdragon.lan.81 > h86-62-108-132.ln.rinet.ru.1141: S 638250873:638250873(0) ack 1557011462 win 5840 <mss 1460,nop,nop,sackOK>
15:01:18.799341 00:1b:11:84:e3:90 (oui Unknown) > 00:60:97:93:62:fe (oui Unknown), ethertype IPv4 (0x0800), length 60: h86-62-108-132.ln.rinet.ru.1141 > daemon1.darkdragon.lan.81: R 1557011462:1557011462(0) win 0
15:01:24.786658 00:d0:d0:61:30:2c (oui Unknown) > 00:60:97:93:62:fe (oui Unknown), ethertype IPv4 (0x0800), length 62: h86-62-108-132.ln.rinet.ru.1141 > daemon1.darkdragon.lan.81: S 1557011461:1557011461(0) win 65535 <mss 1460,nop,nop,sackOK>
15:01:24.786807 00:60:97:93:62:fe (oui Unknown) > 00:1b:11:84:e3:90 (oui Unknown), ethertype IPv4 (0x0800), length 62: daemon1.darkdragon.lan.81 > h86-62-108-132.ln.rinet.ru.1141: S 731859860:731859860(0) ack 1557011462 win 5840 <mss 1460,nop,nop,sackOK>
15:01:24.790013 00:1b:11:84:e3:90 (oui Unknown) > 00:60:97:93:62:fe (oui Unknown), ethertype IPv4 (0x0800), length 60: h86-62-108-132.ln.rinet.ru.1141 > daemon1.darkdragon.lan.81: R 1557011462:1557011462(0) win 0

9 packets captured
9 packets received by filter
0 packets dropped by kernel

# ip rule list
0:      from all lookup local
32765:  from all fwmark 0x2 lookup adsl.mtu
32766:  from all lookup main
32767:  from all lookup default

# ip route list table adsl.mtu
default via 192.168.1.2 dev eth0

# iptables-save -t mangle

(Нажмите, чтобы показать/скрыть)

*mangle
:PREROUTING ACCEPT [2387:338395]
:INPUT ACCEPT [2046:209696]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2042:939437]
:POSTROUTING ACCEPT [2048:940922]
-A PREROUTING -m conntrack --ctstate NEW,RELATED -m mac --mac-source 00:D0:D0:61:30:2C -j CONNMARK --set-mark 0x2
-A PREROUTING -j CONNMARK --restore-mark
COMMIT

[xeon_greg]

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

[AnrDaemon]

Я не ищу марок в дампе. Я привёл его в подтверждение своих слов.
arp забыл...

# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.1              ether   00:1B:11:84:E3:90   C                     eth0
192.168.1.2              ether   00:D0:D0:61:30:2C   C                     eth0

Всё, что приходит с 192.168.1.2, должно уходить на него же. Такова идея, по крайней мере.

[xeon_greg]

ну наверное стоит добавить правила в таблицу маршрутизауии adsl.mtu для
локального интерфейса и для самой сети 192.168.1.0

[AnrDaemon]

Так есть.
# ip route list table adsl.mtu
default via 192.168.1.2 dev eth0

Или чего не хватает?

[xeon_greg]

нет помимо дефолтного роута,

Код: [Выделить]

sudo route add 192.168.1.0/24 dev eth0  src 192.168.1.2  table adsl.mtu
sudo route add 127.0.0.0/8 dev lo table adsl.mtu

[AnrDaemon]

Добавил, ничего не поменялось (да и не могло поменяться, это правило только на пакеты внутри сети действует)

(Нажмите, чтобы показать/скрыть)

# /etc/network/if-up.d/iproute2
# ip route list table adsl.mtu
192.168.1.0/28 dev eth0  scope link  src 192.168.1.12
default via 192.168.1.2 dev eth0
root@daemon1:~
# tcpdump -epi eth0 -s 6553 -- host 86.62.108.132 and \(\(tcp port 80\) or \(tcp port 81\)\)
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 6553 bytes
18:41:38.312979 00:d0:d0:61:30:2c (oui Unknown) > 00:60:97:93:62:fe (oui Unknown), ethertype IPv4 (0x0800), length 74: h86-62-108-132.ln.rinet.ru.43972 > daemon1.darkdragon.lan.81: S 981776797:981776797(0) win 5840 <mss 1460,sackOK,timestamp 183043126 0,nop,wscale 6>
18:41:38.320353 00:60:97:93:62:fe (oui Unknown) > 00:1b:11:84:e3:90 (oui Unknown), ethertype IPv4 (0x0800), length 74: daemon1.darkdragon.lan.81 > h86-62-108-132.ln.rinet.ru.43972: S 1772760888:1772760888(0) ack 981776798 win 5792 <mss 1460,sackOK,timestamp 38542421 183043126,nop,wscale 5>
18:41:38.323688 00:1b:11:84:e3:90 (oui Unknown) > 00:60:97:93:62:fe (oui Unknown), ethertype IPv4 (0x0800), length 60: h86-62-108-132.ln.rinet.ru.43972 > daemon1.darkdragon.lan.81: R 981776798:981776798(0) win 0

3 packets captured
3 packets received by filter
0 packets dropped by kernel

Даже логгинг прикрутил. Коннмарки ставятся. Сейчас FWMARK проверю. Проверил - ставится...

(Нажмите, чтобы показать/скрыть)

-A PREROUTING -m mark --mark 2 -j LOG --log-prefix "IPT_FWMARK2 "

Mar 24 18:48:24 daemon1 kernel: [385965.588516] IPT_FWMARK2 IN=eth0 OUT= MAC=00:60:97:93:62:fe:00:d0:d0:61:30:2c:08:00 SRC=86.62.108.132 DST=192.168.1.12 LEN=60 TOS=0x00 PREC=0x20 TTL=55 ID=18438 DF PROTO=TCP SPT=51218 DPT=81 WINDOW=5840 RES=0x00 SYN URGP=0
Mar 24 18:48:24 daemon1 kernel: [385965.591934] IPT_FWMARK2 IN=eth0 OUT= MAC=00:60:97:93:62:fe:00:1b:11:84:e3:90:08:00 SRC=86.62.108.132 DST=192.168.1.12 LEN=40 TOS=0x00 PREC=0x00 TTL=57 ID=0 DF PROTO=TCP SPT=51218 DPT=81 WINDOW=0 RES=0x00 RST URGP=0
Mar 24 18:48:25 daemon1 kernel: [385966.143137] IPT_FWMARK2 IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:d0:d0:61:30:2c:08:00 SRC=192.168.1.2 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2
Mar 24 18:48:27 daemon1 kernel: [385968.577779] IPT_FWMARK2 IN=eth0 OUT= MAC=00:60:97:93:62:fe:00:d0:d0:61:30:2c:08:00 SRC=86.62.108.132 DST=192.168.1.12 LEN=60 TOS=0x00 PREC=0x20 TTL=55 ID=18439 DF PROTO=TCP SPT=51218 DPT=81 WINDOW=5840 RES=0x00 SYN URGP=0
Mar 24 18:48:27 daemon1 kernel: [385968.581041] IPT_FWMARK2 IN=eth0 OUT= MAC=00:60:97:93:62:fe:00:1b:11:84:e3:90:08:00 SRC=86.62.108.132 DST=192.168.1.12 LEN=40 TOS=0x00 PREC=0x00 TTL=57 ID=0 DF PROTO=TCP SPT=51218 DPT=81 WINDOW=0 RES=0x00 RST URGP=0

ЧЯДНТ?
Может стандартный дефолт GW убить? Как тогда остальной трафик роутить? (Входящий с первого я, положим, замаркирую, а исходящий и форварды - тоже маркировать? >.< )

[xeon_greg]

да тоже заинтересовал этот момент при указании в ip rule не маркой, все нормально ходит и приходит через тот шлюз что нужно, а вот при установке марки судя по iptraf  то уходит и приходит через то что нужно, но в консоли результатов не вижу  (тренируюсь на пингах)

[AnrDaemon]

Я уже голову сломал. И доломал сервер до того, что он не отвечает вообще.
Благо сервер под столом
Люююдии... научите, а?

[xeon_greg]

как будт-то все пришедшее убивается в ядре не дойдя до приложения

[AnrDaemon]

Второй раунд (попытка маркировать всё вообще) окончился провалом ввиду невозможности проверить коннект на отсутствие марки (я так понимаю).
Третий раунд - экстенсивный лог всегоподряд... Начали!
Пользователь решил продолжить мысль 24 Марта 2011, 20:04:07:ip route delete default
ip route add default via 192.168.1.1 dev eth0 src 192.168.1.12 table default

FFFFFFFFFFFFFFFFFFFFFFFFFUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU!!!!!!!!!!!!!!!!!!!!!!!!!!!!

(Первому, кто догадается, что я сделал - моральное удовлетворение)

http://anr-daemon.livejournal.com/1655.html

[xeon_greg]

Второй раунд (попытка маркировать всё вообще) окончился провалом ввиду невозможности проверить коннект на отсутствие марки (я так понимаю).
Третий раунд - экстенсивный лог всегоподряд... Начали!
Пользователь решил продолжить мысль 24 Марта 2011, 20:04:07:ip route delete default
ip route add default via 192.168.1.1 dev eth0 src 192.168.1.12 table default

FFFFFFFFFFFFFFFFFFFFFFFFFUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU!!!!!!!!!!!!!!!!!!!!!!!!!!!!

(Первому, кто догадается, что я сделал - моральное удовлетворение)

http://anr-daemon.livejournal.com/1655.html

покопавшись чуток в
этом всем,чуть добавлю свои наблюдения, да работает хорошо. а вот если смоделировать ситуацию, на этом примере

http://anr-daemon.livejournal.com/1655.html

,но если использовать шлюз по умолчанию отличный от тех двух, скажем совсем с другого интерфейса, то все престает работать. восстановить работу получается  если отключить rp_filter на all и на интерфейсе через который необходимо отдать трафик в нужные роутеры. с rp_filter аналогичная ситуация если необходимо скажем , имеея несколько шлюзов на разных интерфейсах  и имея дефолт роут через 1 из них, менять маршрутизацию на  по каким-либо критериям с помошью меток в iptables но не трогая дефолт роут в таблице main