CONNMARK/MARK

Ведь отличие CONNMARK от простого MARK только в том, что первый маркирует соединения, а второй - пакеты.

В этом и отличие. По простому, через ip rule у вас пролетает именно пакет. MARK - маркирует пакет, но не соединение. CONNMARK - соединение но не пакет.

В простом случае как у вас MARK отработает как надо, т.е. каждый пакет с исходящим адресом перечисленном в --src-range получит однозначно метку на основании которой позже будет оправлен в соответствующую таблицу.

Теперь предположим другой простой случай. У вас два интерфейса назовем их по аналогии с вашими таблицами raw_link и vpn_link оба смотрят наружу. Необходимо сделать dnat для входящих на любой из этих интерфейсов на адрес 172.16.0.3. Если входящее соединение прилетит на raw_link то и исходящее уйдет с него же в соответствии с вашими правилами. Но вот если прилетит на vpn_link уйдет все равно с raw_link что уже скорее всего будет не правильно. Обычным mark тут не решить, т.к. на уровне пакета исходящего с 172.16.0.3 вы не знаете по какому маршруту его отправить. Вот в данном случае поможет connmark, маркируем вводящее соединение в зависимости от того на какой интерфейс прилетело, а потом --restore-mark который скопирует метку соединения connmark в метку пакета mark.

И первый рекомендуют как дефолт.

Никогда такого не слышал.

Но почему в моём случае CONNMARK не работал, а MARK работает?

restore-mark забыли?

Спасибо! Разъяснили всё доходчиво.

Никогда такого не слышал.

На Stackoverflow можно встретить подобное.

restore-mark забыли?

Его в какую цепочку? POST или PRE routing?

Его в какую цепочку? POST или PRE routing?

PRE. она так и называется prerouting. В post уже «не интересно» :)