Буду излагать сюда свои мысли, авось дойдёт до меня, где что не так. А может кто подскажет быстрее.
Дано: два интерфейса с белыми айпи, условно скажем <ip1> и <ip2>, на интерфейсах условно скажем eth0 и eth1.
Маршрутизация расписана таблицами, скажем, <table1> и <table2>, таким образом:
ip route add default via <gate1> table <table1>
ip route add default via <gate1> table <table2>
ip rule add from <ip1> table <table1>
ip rule add from <ip2> table <table2>
где <gate1> и <gate2> соответственно шлюзы первого и второго провайдера.
Зачем. спрашивается, таблицы? Ну, всякими там "ip route add ..." рисуются статичные маршруты на провайдерские подсети. Они тут не рассматриваются, поскольку вопрос стоит с интернетовскими адресами, не относящимися ни к одному из провайдеров.
Теперь сама проблема, наконец. Пингуем одного из провайдеров - скажем, первого. Всё в порядке. Пингуем второго - непорядок, затык. Берём в руки tcpdump и видим такую картину:
{удалённій хост с айпи <ip3>}
Обмен пакетами с <ip2> по 32 байт:
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
{сервер, смотрим со стороны eth0}
11:54:35.255015 IP <ip2> > <ip3>: ICMP echo reply, id 256, seq 56320, length 40
11:54:40.753809 IP <ip2> > <ip3>: ICMP echo reply, id 256, seq 56576, length 40
{сервер, смотрим со стороны eth1}
11:57:14.759467 IP <ip3> > <ip2>: ICMP echo request, id 256, seq 513, length 40
11:57:20.262087 IP <ip3> > <ip2>: ICMP echo request, id 256, seq 769, length 40
Видали такой финт? По айпишкам вроде бы всё правильно - на <ip2> пришёл запрос, и от <ip2> даётся ответ... вот только он даётся на интерфейсе eth0, у которого <ip1>! Такие пакеты конечно же отвергаются...
# ip route show
<gate1> dev eth0 proto kernel scope link src <ip1>
<gate2> dev eth1 proto kernel scope link src <ip2>
default dev eth0 scope link
Ну вроде всё правильно же...
Где же косяк зарыт, который скурить надо?..
Примечание:
Извиняюсь, опечатался. Правильно, разумеется,
ip route add default via <gate1> table <table1>
ip route add default via <gate2> table <table2>
Собственно это видно по выхлопу ip route show.
Примечание:
> действительно актуально указывать оба шлюза как default?
Так требует синтаксис. Нельзя же маршрут вникуда прокладывать. default это фактически синоним для 0.0.0.0, т.е. любой адресат.
> может одно направление ограничить конкретными маршрутами?
Требуется, чтобы любой из айпишек сервера отвечал на входящие запросы. Если кого-то чем-то ограничивать, то он не будет доступен с произвольного внешнего айпи.
Примечание:
> пакеты ушли в прошлое?
Да нет, на время не стОит обращать внимание - ответы от других запросов. Я же снимал дамп не одновременно, а последовательно.
> Нужно правило, заставляющее отправлять ответ через тот-же шлюз, с которого пришел запрос
Я о таком правиле не слышал... Не особо представляю как это сделать.
> и а таблицы для нас остаются загадками
Да они не интересны - работают только в пределах провайдерских подсетей.
Примечание:
Как-то раз после очередной перезагрузки всё само вренулось в норму... По крайней мере я так и не понял что было не так :) Закрываю тему.