Сложная маршрутизация на linux роутере. Как правильно готовить policy based routing?

Question

[Godless]

Пипл, нужна помощь с policy based routing или подсказать, что он не нужен.

Ситуация. Роутер Linux Debian 12. несколько сервисов на нем не тяжелых + NAT на другой серв разных служб.
Около 10 локальных подсетей (виланы на 1 проводе, если важно). Фаервол iptables, список правил не маленький...
1 WAN pppoe. пусть ppp0 со статикой, отдельный провод

Все себе жило было прекрасно, пока не появился еще один WAN в виде tun0.
К нему добавилась пара служб, и, что важно, bird с пачкой маршрутов в этот tun0.
В tun0 стала уходить часть исх пакетов. И все вроде гуд, пока я не заметил, что ко мне от одного из почтовиков не приходят письма на мой. А сам ящик завален сначала delayed, потом failed.

Видимо виной всему, то, что входящий пакет на 25й порт в ppp0 натится на другой серв, а потом по возвращению проходит через пачку маршрутов, находит там подсеть и уходит в tun0.

Я вроде понимаю что нужно поглубже в policy based routing, что-то маркернуть в iptables и пульнуть в отдельную таблицу, чтобы оно вернулось через ppp0. Но вообще не понимаю что именно. не весь же трафик... Прочитал статей 10, но там все как-то не то... Почти везде разруливают исходящий трафик.

В общем вопрос, как это правильно делать?
Я намеренно пока не публикую скрипты/конфиги, хочется самому допереть, поэтому если не трудно на примерах или словами. Ежели будет туго, опубликую что сам написал (не сработало, маркирнул в iptables через connmark, output не забыл, и отправил ip rule в таблицу, в которой только default dev ppp0).

Comments

[Valentin Barbolin]

Как связать несколько локальных сетей через WireGuard на ubuntu?

Answer 1

[shurshur]

По поводу этого лучше всего начать с LARTC HOWTO.

Если кратко, маршрутищация в iproute2 устроена так. Есть несколько таблиц маршрутизации, из которых 3 есть всегда (local, main, default), но можно создать ещё. По правилам (команда ip rule) перебираются таблицы, подходящие под условия, в соответствии с приоритетами (preference, первое число в выводе команды). И в каждой таблице есть свои маршруты. Таблицу local изменять нельзя и перед ней ничего маршрутизировать нельзя (это можно обойти через nat в PREROUTING, но это уже другой вопрос).

Самый простой вариант - это source routing. Впервые мне это понадобилось, когда я подключил дома второго провайдера с внешним IP, и мне потребовалось отвечать с обоих внешних адресов со всего интернета. Делается так:

1. В /etc/iproute/rt_tables описываем псевдонимы для новых таблиц (необязательно - можно использовать числовые идентификаторы - но так удобнее). Например, 10 - isp1, 20 - isp2.

2. Задаём правила, которые приведут к выбору таблицы в зависимости от source address:

ip rule add pref 10 from IP1 lookup isp1
ip rule add pref 20 from IP2 lookup isp2

3. В каждую таблицу добавим маршрут default через нужного оператора:

ip route add default via GATEWAY1 table isp1
ip route add default via GATEWAY2 table isp2

4. В таблице main (которая используется по умолчанию, если не указать таблицу в команде явно) описываем маршрут "по умолчанию" - через того оператора, через которого будет идти исходящий трафик (не ответный на входящий), в данном случае пусть будет isp1:

ip route add default via GATEWAY1

Всё это иногда можно в той или иной степени засунуть в конфиги сети (зависит от дистрибутива Linux весьма существенно), а иногда приходится делать скриптами, в том числе, возможно, вызываемыми через hook системы инициализации сети (я, например, обновлял маршрутизацию через postup-хук dhcp-клиента и из скрипта, который поднимал pptp-vpn).

В дальнейшем всё это обросло кучей других особенностей, например, ip rule fwmark по меткам, которые ставилилсиь в iptables по connmark и иногда другим условиям, но это уже следующий уровень сложности и более специфичне задачи. И LARTC HOWTO почитать всё равно рекомендую, ибо там основа основ и все гуру по нему учились.

Comments

[Godless]

Добрый день.
1. Во-первых, спасибо за развернутый ответ.
2. LARTC нагугливал, первичные вещи и вещи связанные с ip rule/route мне понятны.
3. Проблема как раз в сложных вещах с маркировкой пакетов по соединениям. На текущий момент разбираюсь с правильным применением CONNMARK --set-mark на все соединение. Ситуацию осложняет сетевая конфигурация и большой список правил в iptables, но разбираемся...
4. Временно добавил правило решающее проблему: ip rule from local_smtp_ip lookup ...
Пока разбираюсь можно/нужно ли заменить его на маркировку, и как правильно.
smtp должен стучаться только с адресов из DNS, поэтому может и не самое плохое решение для него. Но есть и другие сервисы...

5. Текущие вопросы такие:
Если я правильно понимаю, -j CONNMARK --set-mark ставит маркер на все соединение и заботиться о пакете вернувшемся от SMTP перед SNAT не нужно в части маркировки. так ?
Пока правила такие (их недостаточно).

$ipt -t mangle -A PREROUTING -i $WAN_INT -d $PUBLICIP -m conntrack --ctstate NEW -j CONNMARK --set-xmark $MARK_WAN
 $ipt -t mangle -A PREROUTING -i $WAN_INT -d $PUBLICIP -m connmark ! --mark $MARK_WAN -j CONNMARK --restore-mark

Так же я пока не понимаю нужен ли --save-mark. Он вроде копирует метку из MARK (пакета) в CONNMARK (Соединение), а мы сразу отметили все соединение и нужен ли --restore-mark на обратном пакете. Вроде restore напрашивается в mangle forward/output (до роутинга).

[shurshur]

Godless, есть -j MARK - это метка, которая ставится на пакет, и вот именно её можно использовать в ip rule. Метка -j CONNMARK это метка соединения.

Возможно, будет понятнее из вот такого фрагмента скрипта для моего старого fw:

# Add connmark rules for policy routing
if [ "$CONNMARK" = "1" ]
then
  iptables -t mangle -A PREROUTING -i $IF_V -j MARK --set-mark 6
  iptables -A INPUT -i $IF_Q -j CONNMARK --set-mark 3
  iptables -A INPUT -i $IF_O -j CONNMARK --set-mark 4
  iptables -A INPUT -i $IF_C -j CONNMARK --set-mark 5
  iptables -A INPUT -i $IF_V -j CONNMARK --set-mark 6
  iptables -A INPUT -i $IF_M -j CONNMARK --set-mark 7
  iptables -A INPUT -i $IF_X -j CONNMARK --set-mark 8
  iptables -A INPUT -i $IF_T -j CONNMARK --set-mark 9
  iptables -A INPUT -i $IF_S -j CONNMARK --set-mark 10
  for if in $IF_A $IF_W $IF_S
  do
    iptables -A FWD_ACCEPT -i $IF_Q -o $if -j CONNMARK --set-mark 3
    iptables -A FWD_ACCEPT -i $IF_O -o $if -j CONNMARK --set-mark 4
    iptables -A FWD_ACCEPT -i $IF_C -o $if -j CONNMARK --set-mark 5
    iptables -A FWD_ACCEPT -i $IF_V -o $if -j CONNMARK --set-mark 6
    iptables -A FWD_ACCEPT -i $IF_M -o $if -j CONNMARK --set-mark 7
    iptables -A FWD_ACCEPT -i $IF_X -o $if -j CONNMARK --set-mark 8
    iptables -A FWD_ACCEPT -i $IF_T -o $if -j CONNMARK --set-mark 9
    iptables -A FWD_ACCEPT -i $IF_S -o $if -j CONNMARK --set-mark 10
  done
  for chain in PREROUTING OUTPUT
  do
    iptables -t mangle -A $chain -j CONNMARK --restore-mark
  done
fi

Тут на все входящие и транзитные пакеты ставится CONNMARK, а затем с помощью:

iptables -t mangle -A $chain -j CONNMARK --restore-mark

ставится обычный MARK с таким же значением. Можно было бы делать явный MARK так:

iptables -t mangle -A $chain -m connmark --mark 5 -j MARK --set-mark 5

Но если обе метки имеют одинаковое значение, то --restore-mark часто просто удобнее.

Для работы L2TP было сделано так

for ip in 85.21.0.0/24 78.107.1.0/24
do
  for p in tcp udp
  do
    iptables -t mangle -A OUTPUT -d $ip -p $p --dport 1701 -j MARK --set-mark 5
  done
done

Проблема в том, что L2TP-сервер провайдера на порту 1701 имеет такой же IP, как и внутри туннеля, и с моими наворотами после поднятия VPN трафик до самого VPN начинал роутиться внутрь VPN. Но если явно трафик до сетей, где обитает VPN-сервер, пометить меткой таблицы с роутингом в нужного провайдера мимо VPN, то начинает работать.

В принципе, можно много чего делать. Например, по сигнатурам маркировать трафик при наличии каких-то ключевых комбинаций и маркировать. Или маркировать по --state NEW новые соединения, а дальше уже промаркированными они будут существовать свой жизненный цикл.

Сама маршрутизация таким вот корявеньким но работающим скриптом.

spoiler

#!/bin/sh
#set -v
source /lib/rc/sh/functions.sh
source /etc/firewall/vars

addpr() {
  # if table mark
  if=$1
  table=$2
  mark=$3
  c=$(ip a l dev $if|grep scope\ global|awk '{ print $2 }')
  ip=$(echo $c|cut -d / -f 1)
  mask=$(echo $c|cut -d / -f 2)
  net=$(ip ro l dev $if|grep scope\ link|grep -v metric|awk '{ print $1 }')
  einfo Adding policy routing for $table [$net]
  if [ -z "$net" ]
  then
    ewarn "SKIP $table [net undefined]"
    return
  fi
  #einfo Adding ip=$ip mask=$mask net=$net
  #echo ip route replace $net dev $if src $ip table $table
  ip route replace $net dev $if src $ip table $table
  #echo ip route replace $LAN_A dev $IF_A src $ip table $table
  ip route replace $LAN_A dev $IF_A src $ip table $table
  #echo ip route replace $LAN_W dev $IF_W src $ip table $table
  ip route replace $LAN_W dev $IF_W src $ip table $table
  # fixme: check wheither pointopoint or not, don't compare with ppp0
  if [ "$if" = "ppp0" ]
  then
    ip route replace default dev $if table $table
  else
    gw=$(ip ro l dev $if|grep \ via\ |head -n 1|awk '{ print $3 }')
    if [ -z "$gw" ]
    then
      net1=$(echo $net|cut -d / -f 1)
      # fixme this is buggy
      gw=$(echo $net1|perl -pne 's/\.0$/.1/')
      einfo "BUGGY GW $gw"
    fi
    #echo $table ... gw=$gw
    ip route replace default via $gw table $table
  fi
  ip ru del p 10$mark >& /dev/null
  ip ru add p 10$mark fwmark $mark lookup $table
  ip ru del p 11$mark >& /dev/null
  ip1=$(echo $ip|tr . ' '|awk '{ print $1 "." $2 }')
  if ! [ "$ip1" = "10.254" ]
  then
    ip ru add p 11$mark from $ip lookup $table
  fi
}

eindent
eindent
addpr $IF_Q *** 3
addpr $IF_O *** 4
addpr $IF_C *** 5
addpr $IF_V l2tpvpn 6
addpr $IF_M *** 7
addpr $IF_X *** 8
addpr $IF_T *** 9
addpr $IF_S *** 10
eoutdent

Тут IF_Q, IF_O, IF_C - провайдерские интерфейсы (и локальные сети в них); IF_V - VPN в провайдера IF_C; IF_M, IF_X, IF_T, IF_S - разные VPN; IF_A, IF_W - внутриквартирные сети.

[Godless]

> есть -j MARK - это метка, которая ставится на пакет, и вот именно её можно использовать в ip rule. Метка -j CONNMARK это метка соединения.
в целом в этом и было основное непонимание.
Вчера уже разобрался в теоретических выкладках. Даже в хедеры ядра подглядел.
Спасибо, пока не реализовал, не было времени.