Интерфейс с которого исходит трафик в сеть.

Определеныым образом чтобы нечто происходило дайте мне совет. Нихрена не понял, но нутром чую, что тебе нужен NAT

Нарисуй схему своей «сети» с интерфейсами и дорисуй рядом действующую таблицу маршрутов. Может быть тогда тебя осенит, что же тебе нужно и как это изменить в нужную сторону?

Как я понял, тебе нужно чтобы src-ip пакета уходящего вовне был бы адресом, принадлежащим внутренней сети
Мой ответ - нет

мммм на этом железе установлен отечественный программный продукт, который отслеживает трафик на внешнем интерфейсе, и при соответствии шаблону заворачивает его в туннель. В шаблоне указано, что заворачивать можно трафик только из внутренней сети (например 192.168.111.0.24) до другой внутренней сети (например 192.168.110.0.24). В итоге, если компьютер из сети 111.0/24 направляет через эту железку трафик в сеть 110.0/24 то он завернется в туннель. Но когда трафик отправляется с железки, то в заголовках у него адрес используется внешнего интерфейса, и заворачивающее правило не срабатывает. Роут использовать не могу, так как у туннеля нету устройства, на которое можно было бы завернуть трафик. В итоге нужно сделать так, чтобы с железки трафик инициализируемый в эту сеть, шел с адреса 111.1

Именно, но я не знаю как это реализовать. В рамках работы железки, нат нельзя использовать.

Можно всё это. Пример - eth0 внутренний сеть 192.168.0.0/24, eth1 внешний сеть 10.0.0.0/24:

Базовый конфиг

ifconfig eth0 inet 192.168.0.254 netmask 255.255.255.0
ifconfig eth1 inet 10.0.0.2 netmask 255.255.255.0
route add default gw 10.0.0.1 # ФПСУ, да?

А теперь финт ушами

ifconfig eth1:0 inet 192.168.0.253 netmask 255.255.255.255
route add -net 192.168.10.0/24 dev eth1:0 gw 10.0.0.1

Это должно привести к тому, что трафик на 192.168.10.0/24 будет отправляться со 192.168.0.253, но твой хост будет иметь два IP - 192.168.0.253 и 192.168.0.254.

Но вообще, тебе сказали правильно - используй NAT на дебиане.

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

При установлении соединения приложение может указать с какого ip-адреса оно должно происходить. Например, ping, traceroute, wget, ssh имеют опции командной строки.

Или прописывайте маршрут с указанием ″src″, наподобие:

ip route add 1.2.3.4 via 5.6.7.8 src 192.168.0.254

То что нужно было, благодарствую огромно.

192.168.111.0.24) до другой внутренней сети (например 192.168.110.0.24)

Не точка, / маска обозначается. SNAT и правильный маршрут решит задачу. Сначала ты должен определить маршрут в целевую подсеть, а затем SNAT после принятия решения о маршруте (POSTROUTING) сможет подменить исходный IP на нужный.

iptables -t nat -A POSTROUTING -s 192.168.111.0/24 -d 192.168.110.0/24 -j SNAT --to-source 192.168.111.2 # Тут IP твоего «локального интерфейса».

И соотв. маршрут, типа:

ip route add 192.168.110.0/24 via 10.0.0.1 dev eth1

или же если у тебя во «внешней» сети нет нужного интерфейса, но роутер получаетеля «знает» о твоей сети, можно использовать опцию onlink в маршруте.

Или прописывайте маршрут с указанием ″src″, наподобие:

Это будет работать, если у него на «внешнем» интерфейсе есть этот самый «внутренний» IP. Из его описания это не так, и тогда с таким маршрутом пакеты будут уходить на «внутренний» интерфейс.

тут есть нюанс в работе всей этой железки. Внешние сети не знают о сетях за этими железками. Программный продукт, который организует канал связи, следит за трафиком на внешнем интерфейсе,и если видит исходящий трафик от этой внутренней сети в другую (описывается правилами), то это трафик перехватывается, обрабатывается этим программным продуктам (я так понимаю просто инкапсулируется) и отправляется второй железке. Поэтому трафик со внешнего интерфейса не может попасть в тунель, так как нет такого разрешающего шаблона.

следит за трафиком на внешнем интерфейсе

трафик со внешнего интерфейса не может попасть в тунель

Что-то напутано или недосказано.

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

Проверил ещё раз. Не важно на каком интерфейсе ip-адрес. Пакеты уходят по маршруту, src-ip адрес устанавливается как надо.

да, ваш вариант с ip route мне помог

Хотя да, при отключенном rp_filter будет работать. С вот с ним - нет по идее.

еще один. блин, откуда вы такие беретесь... на трех страницах в Admin уже 5 (пять, блин) тем про одно и тоже с разными вариациями. Кнопка «Поиск» справа вверху. Не, серьезно, давайте прилепим тему как два интерфейса настроить и поставить маршрутизацию, а то уже нифига не смешно.

Напиши статью в лор-вики
Порецензирую после алгебры

лор-вики загнулась, теперь смысла писать на ней нет

ужас, ведь на дворе 21 век, используйте iproute2.

ip route ip rule /etc/iproute2/rt_tabls

забудьте про route ifconfig