Политика маршрутизации для сервера и клиента OpenVPN на одном маршрутизаторе?

ПРОБЛЕМА

Экземпляр сервера OpenVPN ( tun, udpпорт 1194) настроен на Linux на основе маршрутизатора в котором также используется клиентское экземпляр OpenVPN ( tun, udp, порт 1197), подключив его к провайдеру VPN. И клиент, и экземпляр сервера работают нормально по отдельности . Однако клиенты не могут подключиться к VPN-серверу, когда включен экземпляр VPN-клиента.

Я уверен, что это происходит потому, что экземпляр клиента VPN изменяет mainтаблицу маршрутизации так, чтобы весь трафик от ( OUTPUT) и через ( FORWARD) маршрутизатора направлялся к провайдеру VPN. Это желаемое поведение по умолчанию, но не для подключений, которые инициируются из Интернета.

Используя iptablesи / или ipкак настроить политику маршрутизации, чтобы все (или, по крайней мере, VPN) соединения, инициированные из Интернета, маршрутизировались через стандартный шлюз по умолчанию ( 192.168.1.1)?

НАСТРОИТЬ

LINUX ROUTER ----------------------------------------- | LAN if: br-lan, 192.168.2.1/24 | | VPN client if: tun0, 10.63.10.6/32 | | VPN server if: tun1, 10.255.0.1/24 | | DMZ if: eth0, 192.168.1.2/24 | ----------------------------------------- | GATEWAY ROUTER | -------------------------- | DMZ if: 192.168.1.1/24 | | WAN if: x.x.x.x/x | -------------------------- | INTERNET | VPN CLIENT OF LINUX ROUTER (public IP: y.y.y.y/y) ----------------- -------------------------------------- | |----| VPN client if: tun1, 10.255.0.6/24 | ----------------- -------------------------------------- | | VPN PROVIDER OF LINUX ROUTER --------------------------------  | VPN server if: 10.63.10.1/32 | -------------------------------- 

Как вы заметите, мы находимся в ситуации двойного NAT. Как бы неудобно это ни было, проблема не в этом, поскольку клиенты могут подключаться, когда экземпляр VPN-клиента отключен.

С включенными экземплярами VPN-клиента и сервера это mainтаблица маршрутизации, представленная ip route list table main:

0.0.0.0/1 via 10.63.10.5 dev tun0 #added by VPN client instance default via 192.168.1.1 dev eth0 proto static  10.63.10.1 via 10.63.10.5 dev tun0 #added by VPN client instance 10.63.10.5 dev tun0 proto kernel scope link src 10.63.10.6 #added by VPN client instance 10.255.0.0/24 via 10.255.0.2 dev tun1  10.255.0.2 dev tun1 proto kernel scope link src 10.255.0.1  128.0.0.0/1 via 10.63.10.5 dev tun0 #added by VPN client instance 178.162.199.211 via 192.168.1.1 dev eth0 #added by VPN client instance 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2  192.168.2.0/24 dev br-lan proto kernel scope link src 192.168.2.1  

и это правила ip, как указано ip rule list:

0: from all lookup 128 #a non-existent table 1: from all lookup local  32766: from all lookup main  32767: from all lookup default #empty table 

ПОПЫТКИ

Прежде всего, я создал no_vpn_providerтаблицу маршрутизации ( echo "2 no_vpn_provider" >> /etc/iproute2/rt_tables), точную копию mainтаблицы без изменений экземпляра VPN-клиента. ip route list table no_vpn_providerшоу

default via 192.168.1.1 dev eth0 proto static  10.255.0.0/24 via 10.255.0.2 dev tun1  10.255.0.2 dev tun1 proto kernel scope link src 10.255.0.1  192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2  192.168.2.0/24 dev br-lan proto kernel scope link src 192.168.2.1 

1) Я попробовал эти простые ipправила

ip rule add from 192.168.1.2 table no_vpn_provider priority 2 ip rule add from 10.255.0.1 table no_vpn_provider priority 3 

где 192.168.1.2и 10.255.0.1IP-адреса внешнего интерфейса eth0и интерфейса VPN-сервера tun1соответственно.

Я тоже пробовал from all iif eth0и from all iif tun1вместо from 192.168.1.2а from 10.255.0.1.

2) Я попытался пометить 0x1новые подключения ( conntrackмодуль установлен) к интерфейсам eth0иtun1

iptables -t mangle -A PREROUTING -m conntrack --ctstate NEW -i eth0 -j CONNMARK --set-mark 0x1 iptables -t mangle -A PREROUTING -m conntrack --ctstate NEW -i tun1 -j CONNMARK --set-mark 0x1 

и добавление этого правила, чтобы помеченные соединения использовали новую таблицу маршрутизации

ip rule add fwmark 0x1 table no_vpn_provider priority 2 

3) Я попытался пометить исходящие пакеты с порта VPN-сервера.1194

iptables -t mangle -A OUTPUT -p udp --sport 1194 -j MARK --set-mark 0x1 iptables -t mangle -A OUTPUT -p tcp --sport 1194 -j MARK --set-mark 0x1 # just in case 

и используя то же правило

ip rule add fwmark 0x1 table no_vpn_provider priority 2 

Я также пробовал 2) и 3) с разными отметками и с добавлением ( -I) вместо добавления ( -A). Подозреваю, что мой брандмауэр вообще не помечен

iptables -t mangle -A FORWARD -s 192.168.2.0/24 -j MARK --set-mark 0x1 ip rule add fwmark 0x1 table no_vpn_provider priority 2 

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

4) Единственное, что работает до сих пор, это уродливое правило

ip rule add from all to y.y.y.y/y table no_vpn_provider priority 2 

где yyyy / y - публичный IP-адрес клиента, пытающегося подключиться: это, конечно, ужасное решение, потому что клиенты не собираются подключаться всегда из одной и той же сети.