CONNMARK + TC

>Как connmark дружит с tc?

Никак. Они друг друга игнорируют.

Если я мечу пакет через connmark, то метится все соединение, т.е. и те пакеты, которые придут ко мне назад..

Точно так.

У меня ассиметричный канал (точнее их 3) - каким образом мне правильно поделить как входящий, так и исходящий трафик?

См. статью про iptables в википедии, в частности, начиная со слов «Примечание: следующий пример планируется к переносу в еще не написанный раздел статьи (Прочие критерии → statistic)»

И еще. Я так понимаю - метки CONNMARK и MARK различные. А они могут одновременно существовать?

Да, конечно. Они абсолютно независимы и никак не мешают друг другу. Но по традиции принято, чтобы одни и те же значения по смыслу обозначали одно и то же.

Причем обычно используется следующая схема: соединение распознается через критерии iptables и маркируется CONNMARK'ом. Затем ко всем пакетам применяется операция «CONNMARK --restore-mark», обеспечивающая копирование маркировки соединения в маркировку пакетов. После чего шейпер и маршрутизация спокойно работают на основании маркировки пакетов.

Большое спасибо за внятные разъяснения.
Все это дело до меня довольно туговато доходит, посему еще прошу помощи.
На роутере 2 карты eth0(локалка) и eth1(интернет). Если я через connmark помечу пакеты, затем в построутинге делаю --restore-mark, и завожу 2 дисциплины htb на 1 и на 2 интерейсе и фильтры на fwmark в tc, то я полагаю, оно неправильно будет считаться - ибо в каждом классе будут пакеты как исходящие, так и входящие. Правильно я мыслю? Если да, то как надо разрулить такую ситуацию, подскажите плз

А вот в tc я, к сожалению, нифига не понимаю.

такие правила:
$IPT -A PREROUTING -t mangle -s 192.168.5.50 -j CONNMARK --restore-mark
$IPT -A PREROUTING -t mangle -s 192.168.5.50 -j MARK --set-mark $serg
$IPT -A PREROUTING -t mangle -m mark --mark $serg -j CONNMARK --save-mark
$IPT -A PREROUTING -t mangle -m connmark --mark $serg -j ACCEPT
$IPT -A FORWARD -m connmark --mark $serg -j ACCEPT
$IPT -A POSTROUTING -t nat -m connmark --mark $serg -j SNAT --to-source $RUNNET_IP

$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -t mangle -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A FORWARD -t mangle -m state --state ESTABLISHED,RELATED -j ACCEPT

Передрал с http://www.linux.org.ru/jump-message.jsp?msgid=2216568&cid=2220361
такие вот правила. Пинг проходит, но tcp не работает - telnet ya.ru 80 не пускает. Из за чего может быть? а последние четыре правила - нужны ли они, если я соединение маркирую?
И мне не совсем понятно, для чего первое правило должно быть --restore-mark?
Разъясните, плз.

И мне не совсем понятно, для чего первое правило должно быть --restore-mark?

Мне тоже не понятно зачем добавлять правило, которое никому не нужно.
Первое правило можно смело удалять.
Да и вообще «качество» правил оставляет желать лучшего.
Посоветовал бы никогда не передирать готовые правила, не понимая их сути.
А с mark и connmark думаю проще работать на уровне:
маркируем (-j MARK) и проверяем маркировки (-m mark) через mark, connmark же используем только на уровне save/restore.
... -j CONNMARK --restore-mark # connmark -> mark
... -m mark ! --mark 0 -j RETURN # восстановилось что-то ? да - выходим, нет - маркируем
... серия правил с -j MARK --set-mark N
... -j CONNMARK --save-mark # mark -> connmark

Полагаю, проще вообще работать только в два захода:
1. Маркируем все соединение через CONNMARK --set-mark
2. Копируем маркировку соединения на пакеты CONNMARK --restore-mark

>такие вот правила. Пинг проходит, но tcp не работает - telnet ya.ru 80 не пускает. Из за чего может быть? а последние четыре правила - нужны ли они, если я соединение маркирую?

Вообще не понимаю в данному случае, зачем увязывать вместе маркировку и фильтрацию? Фильтрация по меткам обычно применяется только в довольно сложных случаях.

А для обычной фильтрации достаточно
iptables -I INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F OUTPUT
После этого исходящие соединения должны работать без проблем.