Маршрутизация... опять

Да. И почему у меня при приходе пакета на какой-либо из интерфейсов должны срабатывать правила:

32748:  from PROV2_GW lookup PROV2 
32749:  from 10.0.0.1 lookup PROV1 

SRC IP же будет другим не провайдеровским.

Как я уже неоднократно говорил, правильно настроенные роуты и рулезы сами по себе могут корректно обрабатывать только исходящие соединения. Для обработки входящих нужен iptables -j CONNMARK.

>роуты и рулезы сами по себе могут корректно обрабатывать только исходящие соединения
Нда. Я вот тоже начал уже сам до этого доходить. Спасибо за адрес.

Я тогда не понимаю, для чего дан этот пример? Кому нужно общаться непосредственно с гейтами свого прова? Он годится только для конкретных конечных внешних адресов.

>Я тогда не понимаю, для чего дан этот пример?

Полагаю, для фаерволов, работающих только на выход.

А фразу

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

можно объяснить неточностью перевода.

Может у меня этот пример отображается неправильно, но там

ip rule add from $IP1 table T1
ip rule add from $IP2 table T2 

где «$IP1 будет IP адресом $IF1», то есть 10.0.0.3 в вашем случае.

Это нормально работает, понятно, что с интерфейса PROV1 должны приходить пакеты только для 10.0.0.3, а с интерфейса PROV2 только пакеты для 1.2.3.4. А вот если у вас каким то образом с интерфеса PROV1 могут придти пакеты для 1.2.3.4, то тогда надо CONNMARK.

Откуда берутся правила, приведёные в вашем превом посту я не знаю. Зачем они нужны я тоже не знаю, ну, допустим для корректной работы программ настройки динамической маршрутизации.

P.S. Не знаю как сейчас, но раньше после добавления «ip rule» надо бы было делать «ip route flush cache».

>с интерфейса PROV1 должны приходить пакеты только для 10.0.0.3
Что вы имеете в виду под PROV1? eth0 (в моём случае)?

В общем, ситуация, как мне кажется, стала немного запутанной (для меня).
Обрисую в общем:
У пограничного роутера есть 2 внешних интерфейса. Допустим, оба этих интерфейса имеют реальные IP:
eth0: 1.2.3.4
eth1: 5.6.7.8
default via 1.2.3.254 dev eth0

На всех интерфейсах sshd слушает tcp/22.
На eth1 с dst IP 5.6.7.8 & dst tcp port 22 приходит SYN.
Мне нужно, чтобы SYN/ACK ушёл с этого же, eth1, интерфейса.
Какие бы я роуты-рулезы не писал, он всё= пойдёт via eth0.
Правильно ли я понимаю, что мне нужно сделать следующее:

iptables -t mangle -N PROV2_SSH_IN
iptables -t mangle -A PROV2_SSH_IN -j CONNMARK --set-mark $SOMEMARK
iptables -t mangle -A PROV2_SSH_IN -j CONNMARK --save-mark

iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -i eth1 -d 5.6.7.8 -p tcp --dport 22 -j PROV2_SSH_IN

======
ip rule fwmark $SOMEMARK table prov2 (в prov2 лежит default via 5.6.7.254)

>Что вы имеете в виду под PROV1? eth0 (в моём случае)?

Вторая строчка первого поста. eth0.

На eth1 с dst IP 5.6.7.8 & dst tcp port 22 приходит SYN.

[code] ip rule add from 1.2.3.4 table 4 ip rule add from 5.6.7.8 table 8 ip route add default via 1.2.3.254 dev eth0 table 4 ip route add 192.168.0.0/24 dev eth2 table 4 ip route add default via 5.6.7.254 dev eth1 table 8 ip route add 192.168.0.0/24 dev eth2 table 8 ip route flush cache [/code]

При этом в выводе команды «ip rule show» правила относительно table 4 и 8 должны быть перед «from all lookup main».

Номера таблиц 4 и 8 взяты для примера, можете определить им имена и обращаться к таблицам маршрутизации по именам.

>ip rule add from 1.2.3.4 table 4

ip rule add from 5.6.7.8 table 8

ip route add 192.168.0.0/24 dev eth2 table 4

ip route add default via 1.2.3.254 dev eth0 table 4

ip route add 192.168.0.0/24 dev eth2 table 8

ip route add default via 5.6.7.254 dev eth1 table 8

Не сработает такой вариант для приведённой мной схемы: исходящему пакету до лампочки этот (from 5.6.7.8) рулез. На момент посыла SYN/ACK роутер уже «забыл», что SYN пришёл на eth1. А для самого SYN-пакета (первого в сессии) запись default via 5.6.7.254 бесполезна, ибо он адресован локальному приложению и никуда дальше роутиться не будет.

И описание внутренней сети можно сделать в main. Соединениям извне не нужно знать про локалку. Это не маршрутизатор между локальными сетями.

Сорри. Был неправ =)