Вам вверху дали првильную ссылку, но, имхо, там несколько запутанно. Можно обойтись более простыми мерами.> Пытаюсь из-вне пропинговать адреса интерфесов сервера.
> ping 10.1.1.110 - отправлено 5 пакетов / получено 5 пакетов
> ping 10.2.2.220 - отправлено 5 пакетов / получено 0 пакетов
> ping 10.3.3.30 - отправлено 5 пакетов / получено 0 пакетов
> Сканер запущенный на сервере показал, что пинги на сервер прилетают, но ответы
> отправляются через enp1 (Default Gateway) с выставленным Source IP 10.1.1.110.
> Боюсь, что с OpenVPN может возникнуть такая же ситуация.
Да. Именно так оно и происходит по дефолту.
Дело в том, что:
- Интерфейс для исходящих пакетов зависит от выбранного маршрута, а именно gateway.
- Маршрут зависит от адреса получателя, мы его не контролируем совсем.
- Получатель, когда подключался к нам, сам выбрал по какому (нашему) адресу это делать, и этот адрес может не совпадать с интерфейсом на котором находится gateway который выбиаем мы на основе таблицы маршрутизации.
Важно не путать "исходящий пакет" с "исходящим соединением". Независимо от того, клиент мы (подключаемся к кому-то) или сервер (принимаем подключение), пакеты будут ходить в обе стороны. В даном случае, мы сервер, но фиксить надо поведение исходяих пакетов.
> Подскажите, пожалуйста, как сделать так, чтобы ответы на пинги (и сессии OpenVPN),
> отправлялись с того же интерфейса (и с того же IP), на
> который пришел запрос?
Если коротко, то надо как-то заставить вашу систему выбирать маршрут не только на основе адреса получателя, но и на основе адреса отправителя. Адрес отправителя, очень кстати, будет соответствовать интерфейсу на котором мы приняли подключение с самого начала.
> Поможет ли тут Source routing от iproute2?
Да, именно iproute2. Я знаком с этой технологией под именем Policy Based Routing. Source routing первый раз слышу, но, возможно, исключительно от недостатка эрудиции.
Читайте https://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.mult...
Для каждого из ваших enp1-3:
- Создайте новую _дополнительную_ таблицу маршрутизации, со своим default gateway и маршрутом к локалной сети (2 маршрута).
- Создайте правило policy, что к пакетам с конкретнум адресом отправителя надо применять конкретную таблицу.
Вы привели замечательный пример разнообразия интернетов. Смотрите:
> enp1: Provider 1. IPAddress: 10.1.1.110/30 Default Gateway: 10.1.1.109
ip route add 10.1.1.108/30 dev enp1 src 10.1.1.110 table 1011
ip route add default via 10.1.1.109 table 1011
ip rule add from 10.1.1.110 table 1011
> enp2: Provider 2. IPAddress: 10.2.2.220/28 Gateway: 10.2.2.209
ip route add 10.2.2.208/28 dev enp1 src 10.2.2.220 table 1022
ip route add default via 10.2.2.209 table 1022
ip rule add from 10.2.2.220 table 1022
> enp3: Provider 3. IPAddress: 10.3.3.30/29 Gateway: 10.3.3.25
ip route add 10.3.3.24/29 dev enp1 src 10.3.3.30 table 1033
ip route add default vi 10.3.3.25 table 1033
ip rule add from 10.3.3.30 table 1033
(я нигде в масках не ошибся?)
Этого достаточно для того, чтобы отвечать на том-же интерфейсе на который подключился клиент.
Это базовая конфигурация multihomed. На её основе можно достраивать разнообразные усложнения, типа резервирования каналов, балансировку и т.д.
Это proof of concept, оно будет работать, но для продакшена стоит его причесать. Дать осмысленные имена таблицам, автоматизировать добавление правил при включении интерфейса, и убирании их-же при выключении, и т.д.
Вариант для распечатки
(ok), 19-Мрт-20, 17:59 
