Как маркировать пакеты?

Проблемы у fr или у l2tp0? И что у них прописано DNS-ом, а то не понятно, есть ли у вас CONNMARK в OUTPUT.

А в целом, не уверен в нормально работоспособности этой схемы. Если у вас на адрес 1.1.1.2 порт 53 придут два пакета с одинаковыми src-ip адресами и src-портами, как conntrack будет различать к какому соединению относится ответный пакет?

Может быть нужно маркировать не только соединения, но и пакеты, приходящие с fr, чтобы при SNAT'е они различались...

Проблемы у fr. l2tp0 Работает хорошо DNS там никакие не прописаны. Днсы выдаются в локалке через dhcp... там отдельный кеширующий днс в локалке который роутится напрямую без всяких туннелей.

А как это работает в обычном случае? Я правильно понимаю что fwmark ищет метку пакета? а -j CONNMARK --restore-mark маркирует все пакеты в соединений ? в чем тогда разница с -j MARK с критерием -m connmark ?

Там DNAT то как бы нет. Все входящие без маркировки будут роутится в main таблице. Если понадобится dnat то да нужно будет отмаркировать чтобы в fr уходило, без маркировки, вот как сейчас, оно будет уходить в l2tp0. Наверно можно добавить restore-mark в output mangle по критерию connmark 10 чтобы fr input был доступен для подсетей.

А как это работает в обычном случае?

Как-то работает, обычно удовлетворительно. Может я и не прав, но обычно смотрится ситуация, типа такой, что далёкий хост 1.2.3.4 может подключится со своего порта 1234 на наш порт 25 через интерфейс eth0 или eth1, и все пакеты от него и будут приходит через один и тот же интерфейс и мы должны туда отвечать. А если он попытается установить с нами два соединения с полностью одинаковыми «реквизитами» (адресами), одно через eth0, другое через eth1, то не сработает.

Я правильно понимаю что fwmark ищет метку пакета?

Да, только не ищет, а смотрит. Метка (MARK) это дополнительное поле пакета, которое появляется как пакет пришёл с интерфейса и убирается, когда он уходит в сеть. И метка (поле) доступно всем подсистемам, обрабатывающим пакет. Метка соединения (CONNMARK) это поле в таблице отслеживания соединений (conntrack). Пока пакет не отнесён к какому-либо соединению, у него его нет.

а -j CONNMARK --restore-mark маркирует все пакеты в соединений ?

Маркирует те пакеты соединения, для которых срабатывает условие (match) правила.

в чем тогда разница с -j MARK с критерием -m connmark ?

В чём разница цели правила и критерия (условия) правила?

Там DNAT то как бы нет

Я вобще про SNAT. Они что, после маршрутизации, выходят через eth0 без SNAT?

Можно сделать вот так

iptables -t mangle -A PREROUTING -m connmark --mark 10 -j CONNMARK --restore-mark

iptables -t mangle -A PREROUTING -m connmark --mark 10 -j MARK --set-mark 10

Я чуточку ближе подобрался к решению проблемы. Заметил на гипере на котором виртуалка которая gre peer, вот такую штуку conntrack: generic helper won't handle protocol 47. Please consider loading the specific helper module. Я ниочень понял что оно хочет, но решил поменять gre на ipip. И о чудо аплоад по iperf вырос с 240кб\с до 40мб\с а даунлоад до 60мб\с. Это явно прогресс. Но тем не менее сайты все равно открываются очень долго. через l2tp0 который по тестам всего 10мб\с открывается намного быстрее.

Конкретно в случае этих правил разницы нет, просто restore-mark позволяет уменьшить число правил при развесистой маркировки с кучей разных макеров и масок.

conntrack: generic helper won't handle protocol 47.

Патч из разряда «когда коту делать нечего...» На скорость прохождения пакетов влиять не должно. Далеко не всегда требуется conntrack для GRE тунелей, особенно, если они без PPTP.

Быстрота открытия сайта — делайте дамп всего трафика компа при открытии одной страницы, чтобы было видно, сколько идёт DNS запрос, а сколько загрузка страницы.

Сделал. Днс запроса нет вообще. закеширован. а get / на 11кбайт длится 2.5с.