Конечно (возможно) - Маршрутизация на основе политик они это называют.

Вы можете использовать маркировку брандмауэра, а затем использовать ip rule.

LARTC это то, что вы хотите прочитать полностью.

У меня была такая же проблема, как и у вас. Вы должны отключить rp_filter и перенаправить весь трафик с целевого порта 80 и 8080 на ваш обычный интерфейс.

Отключить фильтрацию обратного пути

for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do
echo 0 > $i
done

Мы собираемся использовать таблицу 100. Убедитесь, что она больше не используется! Мы собираемся его промыть

ip route flush table 100
ip route del default table 100
ip rule del fwmark 1 table 100
ip route flush cache
iptables -t mangle -F PREROUTING

Создайте таблицу для всех подключений (не VPN-туннель)

ip route show table main | grep -Ev ^default | grep -Ev tun0 \
| while read ROUTE ; do
ip route add table 100 $ROUTE
done
ip route add default table 100 via 192.168.2.254
ip rule add fwmark 1 table 100 
ip route flush cache

Обход порта 80 и 8080

iptables -t mangle -A PREROUTING -i p4p1 -p tcp -m multiport --dports 80,8080 -j MARK --set-mark 1

Вы можете игнорировать или отменять отправку с сервера redirect-gateway вариант. https://community.openvpn.net/openvpn/wiki/IgnoreRedirectGateway

Игнорирование шлюза редиректа

Если вы используете OpenVPN в качестве клиента, а сервер, который вы используете, использует push «шлюз перенаправления», то ваш клиент перенаправляет весь интернет-трафик через VPN. Иногда клиенты этого не хотят, но они не могут изменить конфигурацию сервера. На этой странице объясняется, как переопределить шлюз перенаправления, чтобы клиенту не нужно было перенаправлять Интернет, даже если сервер сообщает об этом. Метод 1: игнорировать

Есть 2 варианта, которые можно использовать для игнорирования маршрутов, отправленных сервером:

--route-noexec Не добавлять или удалять маршруты автоматически. Вместо этого передайте маршруты сценарию --route-up, используя переменные окружения.

--route-nopull При использовании с --client или --pull принимать параметры, передаваемые сервером, ЗА ИСКЛЮЧЕНИЕМ для маршрутов и параметров DHCP, таких как DNS-серверы. При использовании на клиенте этот параметр эффективно запрещает серверу добавлять маршруты в таблицу маршрутизации клиента, однако обратите внимание, что этот параметр по-прежнему позволяет серверу устанавливать свойства TCP / IP интерфейса TUN / TAP клиента.

Метод 2: переопределить

Здесь мы просто добавим маршруты, которые переопределяют --redirect-gateway. Это будет работать так же, как флаг def1 для --redirect-gateway. Это может быть иначе, если сервер использует флаг def1 для параметра --redirect-gateway или нет (проверяя журнал при подключении). Обратите внимание, что net_gateway - это внутренняя переменная openvpn, и ее не нужно ни на что менять. Если вы не знаете, использует ли ваш сервер def1, и не хотите проверять журналы, чтобы понять это, просто предположите, что они ДЕЙСТВИТЕЛЬНО используют def1 и используют 4 маршрута. Это будет работать несмотря ни на что.

def1 - используйте этот флаг, чтобы переопределить шлюз по умолчанию, используя 0.0.0.0/1 и 128.0.0.0/1 вместо 0.0.0.0/0. Это дает преимущество переопределения, но не уничтожения исходного шлюза по умолчанию.

Если сервер НЕ использует def1, добавьте следующие параметры в конфигурацию клиентов:

маршрут 0.0.0.0 128.0.0.0 net_gateway маршрут 128.0.0.0 128.0.0.0 net_gateway

Если сервер ИСПОЛЬЗУЕТ def1 или если вы не знаете, добавьте следующие параметры в конфигурацию клиентов:

route 0.0.0.0 192.0.0.0 net_gateway route 64.0.0.0 192.0.0.0 net_gateway route 128.0.0.0 192.0.0.0 net_gateway route 192.0.0.0 192.0.0.0 net_gateway

Тогда трафик, приходящий извне, будет проходить через обычный шлюз, а трафик из подсети VPN будет идти в VPN. Если за подсетью VPN находятся другие сети, вам придется добавлять маршруты для них вручную.

маршрут 10.0.0.0 255.255.255.0 vpn_gateway

Я верю, что правильным решением будет Раздельное туннелирование, или это то, что я сделаю на клиентской рабочей станции, но у вас ситуация немного другая, потому что есть сервер: можно ли добавить второй сетевой интерфейс?

В этом случае вы можете маршрутизировать весь свой VPN-трафик через первый интерфейс, но при этом позволить вашей службе прослушивать его через второй.