Изпечатай

[romeo_ninov]

Здравейте, имам следния проблем. Машина с няколко интерфайса. Но DNS заявките трябва да излизат през eth0 а default route е през eth2 172.20.2.11. Опитах това:

Примерен код

cat /etc/iproute2/rt_tables 1 DNS

Примерен код

iptables -A PREROUTING -t mangle -p tcp --dport 53 -j MARK --set-mark 1 iptables -A PREROUTING -t mangle -p udp --dport 53 -j MARK --set-mark 1 ip route add default via 172.20.11.1 dev eth0 table DNS ip rule add from all fwmark 1 table DNS

както пише тук: http://www.linuxhorizon.ro/iproute2.html
но последната команда ми връща грешка:

Цитат

RTNETLINK answers: Numerical result out of range

[gat3way]

Това не е мрежов проблем, а проблем с разминаване между kernel API-то и юзърспейските програми (iproute2) според мен.

Тъй като надали ти се сменя ядрото, виж дали няма да се оправи след ъпдейт на iproute пакета.

[mortimor]

Здравей,
защо не направиш route за IP-тo/тата na DNS сървар-а/ите?
смисъл не знам дали съм схванал идеята но по-специфичният път винаги е по предпочитан. Друг е въпроса ако на тези DNS имаш и други services....

поздрави.
Y.Boikov
:wq

[romeo_ninov]

Цитат (gat3way @ Април 25 2008,18:14)

Това не е мрежов проблем, а проблем с разминаване между kernel API-то и юзърспейските програми (iproute2) според мен. Тъй като надали ти се сменя ядрото, виж дали няма да се оправи след ъпдейт на iproute пакета.

Ъпдейтнато до последните с официалните пакети на CentOS. А и проблема го решихме в мрежовите устройства, така че остава спортната страст :-)
П.П. понеже тази машина е все още в процес на настрйка не би има проблем за смяна на ядрото

Цитат (mortimor @ Април 25 2008,18:38)

Здравей, защо не направиш route за IP-тo/тата na DNS сървар-а/ите? смисъл не знам дали съм схванал идеята но по-специфичният път винаги е по предпочитан. Друг е въпроса ако на тези DNS имаш и други services.... поздрави. Y.Boikov :wq

Проблема е че има и пощенски услуги :-( иначе колега предложи точно тази идея и тя работи прекрасно със статичен route :-)

[gat3way]

Рових се в гугъл по въпроса, изглежда наистина се чупи малко протокола, по който си комуникират iproute и kernel-а по netlink сокет-а, поне така твърдят големите глави. Според тях това е станало някъде между 2.6.19 и 2.6.21.

Така че ако от спортна злоба решиш да сменяш ядра, пробвай с по-старо '>

[teleport]

Примерен код

# ip rule help Usage: ip rule [ list | add | del | flush ] SELECTOR ACTION SELECTOR := [ from PREFIX ] [ to PREFIX ] [ tos TOS ] [ fwmark FWMARK ]             [ dev STRING ] [ pref NUMBER ] ACTION := [ table TABLE_ID ]           [ prohibit | reject | unreachable ]           [ realms [SRCREALM/]DSTREALM ] TABLE_ID := [ local | main | default | NUMBER ]

Забележи синтаксиса: "ip rule [ list | add | del | flush ] SELECTOR ACTION"!

"from all" и "fwmark" са "SELECTOR", и не може да ги комбинираш в един ред.

"ip rule add fwmark 1 table DNS" работи и ще прати всички маркирани с fwmark 1 пакети в таблицата DNS. Това ли се иска?

[gat3way]

Мне, синтактично е вярно.

[teleport]

"ip rule add from all fwmark 1 table xxx" не работи и при мене, а кернела и iptables на Centos 5 със сигурност нямат несъвместимости. Отделно от това: защо трябва да казваш "from|to" към "fwmark" при положение че марките се слагат в iptables, където пакетите вече са минали филтър? Ако искаш различен рутинг за "from xxx" и "from yyy" просто ги маркираш в iptables с различна fwmark.

[gat3way]

router:/storage/files/gat3way/tst# ip route add default via 172.20.11.1 dev eth0 table 1
router:/storage/files/gat3way/tst# ip rule add from all fwmark 1 table 1
router:/storage/files/gat3way/tst#

Нямам проблеми, ядрото е 2.6.17-2

[teleport]

При мене:

# ip rule add from all fwmark 1 table btc
RTNETLINK answers: Numerical result out of range
# ip rule add fwmark 1 table btc
# ip rule add from 1.2.3.4/32 fwmark 15 table btc

Резултата в кернела:

# ip rule ls
0:      from all lookup 255
32764:  from 1.2.3.4 fwmark 0xf lookup btc
32765:  from all fwmark 0x1 lookup btc
32766:  from all lookup main
32767:  from all lookup default


И все мисля че повторно филтриране при вече сетната fwmark е излишно.

PS:
# uname -r
2.6.18-53.1.4.el5PAE

Току що го проверих и на друга машина: Centos 5 с кернел от fedora 9, оригиналния iproute:

# uname -r
2.6.23.1-42

# ip rule add from all fwmark 1 table 1
# ip rule add fwmark 2 table 2

Причината явно е в модула в ядрото. Но така или иначе "from all fwmark 1" е еквивалентно на само "fwmark 1". Иначе и проблемия кернел 2.6.18 приема и работи коректно ако "from" не е "all" а е ip/mask.

[romeo_ninov]

Цитат (teleport @ Април 25 2008,23:17)

# ip rule add from all fwmark 1 table 1 # ip rule add fwmark 2 table 2 Причината явно е в модула в ядрото. Но така или иначе "from all fwmark 1" е еквивалентно на само "fwmark 1". Иначе и проблемия кернел 2.6.18 приема и работи коректно ако "from" не е "all" а е ip/mask.

При мен и с двата синтаксиса има проблем. Но както писах проблема се реши от мрежовия специалист и машината се приближата до production и за съжаление нямам време за промени
П.П. Между другото синтаксиса ip rule add from all fwmark 1 table 1 е описан в официалното ръководство :-)

[teleport]

Съгласен. Между другото един бърз strace показва интересни неща.

"ip rule add fwmark 1 table 1" подава към кернела 36 байта.
"ip rule add from 1.2.3.4/32 fwmark 1 table 1" подава към кернела 40 байта.
"ip rule add from all fwmark 1 table 1" също подава 40 байта. ( ip транслира all|any|default като 0/0 ).

По тази логика първото правило ще match-ва само fwmark. Второто и третото обаче винаги ще match ip AND fwmark. В случая на "from all" това е една проверка в повече ( винаги true ) + един AND ( fwmark ) повече за всеки пакет. И 4 байта повече памет в кернела за всяко правило. Това в случай че модула в ядрото не прави допълнителна оптимизация на подаваното от ip което е малко вероятно.

[romeo_ninov]

В този контекст съм съгласен. Честно казано не мога да се нарека експерт по мрежи и линукс ядро, но наистина първото изглежда по-пестящо цикли. Макар че при моя случай не се очакваше особен трафик по двата протокола не е лошо такива детайли да се имат предвид :-) Благодаря