Маршрутизация конкретной подсети в VPN-туннель

Моя сеть выглядит так:

Я пытаюсь настроить мой маршрутизатор так, чтобы подсеть (192.168.2.0/24) маршрутизировалась через VPN-туннель (tun0) на шлюзе / маршрутизаторе.

В то же время клиенты в подсети (192.168.1.0/24) маршрутизируются напрямую через ppp0, то есть не через VPN.

Я не хочу запускать программные клиенты VPN, а некоторым клиентам в сети необходим прямой доступ. например, игровой компьютер с Windows, VoIP-телефон и т. д.

Мой маршрутизатор также запускает несвязанный DNS-сервер, который перенаправляет запросы DNS на dnscrypt-proxy.

Сетевые интерфейсы на маршрутизаторе настроены следующим образом:

auto lo
    iface lo inet loopback

auto lo:1
iface lo:1 inet static
    address 127.0.0.2
    netmask 255.0.0.0

auto eth0
iface eth0 inet static
    address 192.168.1.1
    netmask 255.255.255.0

# Virtual interface
auto eth0:2
iface eth0:2 inet static
    address 192.168.2.1
    netmask 255.255.255.0

auto eth1
iface eth1 inet static
    address 192.168.0.2
    netmask 255.255.255.252

auto ppp0
iface ppp0 inet ppp
    pre-up ip link set dev eth1 up
    provider <isp>
    post-down ip link set dev eth1 down

На данный момент я использую виртуальный интерфейс, то есть eth0: 2. Мне также интересно, если это уместно или это должна быть VLAN, то есть eth0.2?

Насколько мне было известно, единственная разница будет в том, что клиентам тогда потребуется интерфейс VLAN, например

/etc/systemd/network/MyEth.network

[Match]
Name=enp10s0

[Network]
DHCP=v4
DNS=192.168.2.1
Address=192.168.2.30/24
Gateway=192.168.2.1
VLAN=vlan2

/etc/systemd/network/MyEth.netdev

[NetDev]
Name=vlan2
Kind=vlan

[VLAN]
Id=2

и не сможет пересечь подсети, например, 192.168.1.10 не сможет общаться с 192.168.2.10

Правила iptables, с которыми я пытался заставить это работать, следующие:

iptables -F
iptables -t nat -F

export WAN=ppp0           # Link to ISP
export INT_IF=eth0        # Interface that serves internal network
export EXT_IF=eth1        # Interface between router and modem
export WAN_TUNNEL=tun0    # VPN tunnel created by OpenVPN
export VPN_VLAN_IF=eth0:2 # Interface internal clients have as their gateway

# Allows internet access on gateway
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

#############
# NAT Rules #
###############################################################################
# VPN
iptables -I FORWARD -i ${VPN_VLAN_IF} -d 192.168.2.0/24 -j DROP
iptables -A FORWARD -i ${VPN_VLAN_IF} -s 192.168.2.0/24 -j ACCEPT
iptables -A FORWARD -i ${WAN_TUNNEL} -d 192.168.2.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o ${WAN_TUNNEL} -j MASQUERADE
###############################################################################

###############################################################################
# NO VPN
iptables -I FORWARD -i ${INT_IF} -d 192.168.1.0/24 -j DROP
iptables -A FORWARD -i ${INT_IF} -s 192.168.1.0/24 -j ACCEPT
iptables -A FORWARD -i ${WAN} -d 192.168.1.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o ${WAN} -j MASQUERADE
###############################################################################

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

echo 1 > /proc/sys/net/ipv4/ip_forward
for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 1 > $f ; done

/etc/init.d/iptables save

Я также ожидаю, что мне потребуется использовать route-nopull в моей конфигурации openvpn, иначе все на шлюзе будет маршрутизироваться через VPN?

По умолчанию при подключении к серверу OpenVPN я вижу:

openvpn[3469]: /sbin/ip route add <ip_of_vpn> dev ppp0
openvpn[3469]: /sbin/ip route add 0.0.0.0/1 via 172.16.32.1
openvpn[3469]: /sbin/ip route add 128.0.0.0/1 via 172.16.32.1

что приводит к маршруту как:

ip route
0.0.0.0/1 via 172.16.32.1 dev tun0 
default dev ppp0  scope link  metric 300 
<ip_of_vpn> dev ppp0  scope link 
128.0.0.0/1 via 172.16.32.1 dev tun0 
172.16.32.0/20 dev tun0  proto kernel  scope link  src 172.16.39.64 
192.168.0.0/30 dev eth1  proto kernel  scope link  src 192.168.0.2 
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.1 
192.168.2.0/24 dev eth0  proto kernel  scope link  src 192.168.2.1 
<ip_from_isp> dev ppp0  proto kernel  scope link  src X.X.X.X

Нужен ли статический маршрут для маршрутизации 192.168.2.0/24 в VPN, т.е. для настройки 0?

Это может быть достигнуто с помощью настраиваемой таблицы маршрутизации и политики (я недавно сделал нечто очень похожее)

1. Сначала создайте собственную таблицу маршрутизации для вашего VPN

   echo "10 vpn" >> /etc/iproute2/rt_tables
   

2. Скажите iproute2 использовать эту таблицу маршрутизации для трафика в и из вашей сети 192.168.2.0

   ip rule add from 192.168.2.0/24 table vpn
   ip rule add to 192.168.2.0/24 table vpn
   

3. Настройте маскарадинг NAT для сети 192.168.2.0

   iptables -A FORWARD -i eth0:2 -s 192.168.2.0/24 -j ACCEPT
   iptables -A FORWARD -i tun0 -d 192.168.2.0/24 -j ACCEPT
   iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o tun0 -j MASQUERADE
   

4. Включить IP-переадресацию, если она не включена (требуется для NAT)

   echo 1 > /proc/sys/net/ipv4/ip_forward
   

5. В вашей конфигурации OpenVPN добавьте следующие строки

   #Prevents default gateway from being set on the default routing table
   route-noexec
   #Allows route-up script to be executed
   script-security 2
   #Calls custom shell script after connection to add necessary routes
   route-up /etc/openvpn/route-up.sh
   

6. Создайте собственный скрипт оболочки в /etc/openvpn/route-up.sh и chmod + x it

   #!/bin/sh
   
   #Clear all routes on vpn routing table (this is to make sure there isn't any crap left over from a previous vpn connection
   /sbin/ip route flush table vpn
   
   #Copy routing table from main routing table into vpn table
   /sbin/ip route show table main | grep -Ev ^default | while read ROUTE ; do ip route add table vpn $ROUTE; done
   
   #Add default gateway to vpn routing table
   /sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table vpn
   

Шаги 2 и 3 не будут сохраняться при перезагрузке, поэтому вам нужно будет добавить эти части в свои сценарии инициализации по мере необходимости.