Что делает connection mark?

Зачем в пакет ? В conntrack - таблице метится соединение

гейт и сервер - это два разных компьютера. Для того, чтобы сервер смог решить, на какой из двух гейтов отсылать ответный пакет он должен как-то различать пакеты с разных гейтов.

Пусть на гейте что-то там будет в какой-то таблице - это никак серверу в принятии решения куда роутить не поможет.

Пусть на гейте что-то там будет в какой-то таблице - это никак серверу в принятии решения куда роутить не поможет.

Совершенно верно.

Поэтому,

Можно ли сказать, что connection mark прямо в пакет дописывает, через какой гейт этот пакет пришел?

Нет, нельзя.

Как мне сделать, чтобы программа отвечала на пакеты с каждого гейта именно на тот гейт, а не на default gateway всегда?

https://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.html#A...

Если сервер различает в какую таблицу отправлять на основании исходящего IP-адреса, то зачем вообще нужны эти две разные таблицы?
Почему на основании исходящего адреса нельзя просто отправлять на разные гейты? Ведь раутинг в каждую из двух локальных сетей и так добавляет две записи в таблицу раутинга.

т.е. примерно так:
ip route add $P1_NET dev $IF1 src $IP1 via $P1
ip route add $P2_NET dev $IF2 src $IP2 via $P2

Если сервер различает в какую таблицу отправлять на основании исходящего IP-адреса, то зачем вообще нужны эти две разные таблицы?
Почему на основании исходящего адреса нельзя просто отправлять на разные гейты?

Потому что так придумано.

все можно. комбинация из policy based routing и функционала ipset тебе нужна.

Нарисуйте схемку.
Как понял я приблизительно

gw1 localip 192.168.0.1 - +
                          - server 192.168.0.3
gw2 localip 192.168.0.2 - + 

Проще всего использовать source-based routing.

Пусть есть интерфейс $IF1 с адресом $IP1 и шлюзом $GW1. И VPN с интерфейсом $IF2 с адресом $IP2 и шлюзом $GW2.

# Добавим VPN как маршрут по-умолчанию в таблицу main:
ip route add default dev $IF2 via $GW2 src $IP2

# Трафик без VPN завернём в отдельную таблицу
ip rule add from $IP1 table 123

# Все direct-connected (и другие ранее созданные) маршруты без VPN скопируем в эту таблицу
ip route show dev $IF1 | xargs -i ip route add {} dev $IF1 table 123

# И добавим ещё в ту же талбицу маршрут по-умолчанию
ip route add default dev $IF1 via $GW1 src $IP1 table 123

echo «1 wireguard» >>/etc/iproute2/rt_tables

ip route add 10.0.0.0/8 dev wg0 src 10.0.0.2 table wireguard
ip route add default via 10.0.0.1 table wireguard
ip route add 192.168.0.0/24 dev eth0 src 192.168.0.2 table main
ip route add default via 192.168.0.1 table main

route add -host 195.82.146.214 gw 10.0.0.1 dev wg0
# nslookup 195.82.146.214
214.146.82.195.in-addr.arpa name = rutracker.org.

Такой подход не будет работать, если rutracker.org окажется инициатором трафика, и пойдёт на eth0, а не на wg0.

Если такой случай не интересен, то можно вообще забить на множественные таблицы и выкинуть три первые строки.

Если интересен, то надо добавить ещё и ip rule, либо через покраску трафика (connmark, fwmark), либо (что проще) через source-based routing (ip rule add from $IP table wireguard), где $IP - адрес на интерфейсе wg0.

Я считал, что первое и третье правила как раз описывают source-based routing (у них есть слово src перед адресом на интерфейсе сервера).

либо через покраску трафика (connmark, fwmark)

Вот, а это никто не хочет рассказать. Потому что вроде как покраска в сами пакеты не добавляется.

и ещё мне непонятно, как все эти команды засунуть в конфиги systemd

потому что после перезагрузки всё отваливается

Вот, а это никто не хочет рассказать. Потому что вроде как покраска в сами пакеты не добавляется.

1. Вы зачем плодите темы об одном и том же ?
2. Вам вроде уже объяснили. connmark - будет в conntrack, но не более того. mark - в пакете который проходит через ведро, но так же не более того. Итого, и первое и второе не выходит за рамки вашей машинки. Первое маркирует соединение, второе пакеты. Ну почитайте хоть немного теории в конце концов, вам уже советовали.

Я считал, что первое и третье правила как раз описывают source-based routing

Нет, src XX это указание системе предпочитать использование адреса XX в качаестве source IP.

source-based routing это когда маршрут выбирается по srcip; в противовес умолчальному алгоритму выбора маршрута из таблицы маршрутизации (обычно main) по наиболее специфичному (по числу единиц в route.mask) совпадению packet.dstip & route.mask с route.dstip.

Вот, а это никто не хочет рассказать.

Маршрутизация, 2 прова. (комментарий)

Информация о покраске обычно никак не выходит за пределы хоста. В необычных случаях можно использовать поле ToS в IPv4 (когда покраска используется для раскидывания трафика на тяжёлый в дешёвый high-bandwidth канал, интерактивный в дорогой low-latency канал) или поля Traffic class и Flow label в IPv6.

При прохождении пакетов через stateful firewall, заполняется таблица connection tracking. Connection mark это поле (число) в каждой строке этой таблицы. Policy routing не умеет смотреть на это поле, так как маршрутизация работает не с соединениями, а с пакетами, но у пакетов тоже есть своя метка. Метки пакетов и соединений можно синхронизировать с помощью --save-mark (из пакета в соединение) и --restore-mark (в обратную сторону).

ip rule add from aaaa:bbbb::/48 table 100 превращается в

[RoutingPolicyRule]
From=aaaa:bbbb::/48
Table=100

ip route add cccc:dddd::/48 via eeee:ffff::1 table 100 в

[Route]
Table=100
Destination=cccc:dddd::/48
Gateway=eeee:ffff::1

в /etc/systemd/network/$IFACE.network

Если нужен iptables, то есть netfilter-persistent; или же можно написать oneshot service с iptables-restore.