Обычная маршрутизация отвечает на вопрос: куда отправить пакет по адресу назначения? Но иногда этого мало. Например, на linux-сервере есть два провайдера, два интерфейса или несколько VPN. И нужно, чтобы часть трафика шла через один шлюз, а часть — через другой.
Вот здесь появляется Policy Based Routing. PBR позволяет маршрутизировать трафик не только по destination IP, но и по дополнительным условиям:
• source IP
• интерфейс
• fwmark
• отдельная таблица маршрутизации
• правила из ip rule
▪️ Классический пример:
eth0 -> 192.168.1.10/24 -> gateway 192.168.1.1 eth1 -> 10.10.10.10/24 -> gateway 10.10.10.1
Обычный default route может быть только один основной. А нам нужно, чтобы ответы с адреса 10.10.10.10 уходили обратно через 10.10.10.1, а не через первый шлюз.
Создаем отдельную таблицу маршрутизации:
echo "100 isp2" >> /etc/iproute2/rt_tables
Добавляем маршрут в эту таблицу:
ip route add 10.10.10.0/24 dev eth1 src 10.10.10.10 table isp2 ip route add default via 10.10.10.1 dev eth1 table isp2
Теперь добавляем правило:
ip rule add from 10.10.10.10/32 table isp2
Смысл такой: если пакет идет от source IP 10.10.10.10, использовать таблицу isp2.
Проверить правила:
ip rule show
Проверить маршруты в таблице:
ip route show table isp2
Проверить, как ядро выберет маршрут:
ip route get 8.8.8.8 from 10.10.10.10
Это одна из самых полезных команд при отладке PBR.
▪️ Где Policy Based Routing реально нужен:
• сервер с несколькими провайдерами
• отдельный выход в интернет для VPN-клиентов
• маршрутизация по source IP
• разделение служебного и пользовательского трафика
• multi-WAN
• асимметричные схемы
• маршрутизация через разные туннели
Можно использовать и fwmark, если нужно направлять трафик по меткам firewall. Например, пометить пакеты через iptables:
iptables -t mangle -A OUTPUT -p tcp --dport 443 -j MARK --set-mark 10
И отправить такие пакеты в отдельную таблицу:
ip rule add fwmark 10 table isp2
Так можно строить более гибкую логику: не только от какого IP, но и какой именно трафик.
❗️ При PBR особенно важно проверять не только маршруты, но и правила:
ip route # маршруты ip rule # правила
Потому что решение принимает не одна таблица маршрутизации, а связка: rule -> table -> route