PROBLEMA
Uma instância do servidor OpenVPN ( tun , udp , porta 1194 ) é configurada em um roteador baseado em Linux que também executa uma instância do cliente OpenVPN ( tun , udp , port 1197 ) conectando-o a um provedor de VPN. Tanto o cliente quanto a instância do servidor funcionam bem individualmente . No entanto, os clientes não podem se conectar ao servidor VPN quando a instância do cliente VPN está ativada.
Tenho certeza de que isso acontece porque a instância do cliente VPN modifica a tabela de roteamento main para que todo o tráfego de ( OUTPUT ) e ( FORWARD ) o roteador seja roteado para o provedor de VPN. Esse é o comportamento padrão desejado, mas não para conexões que estão sendo iniciadas na Internet.
Usando iptables e / ou ip , como uma política de roteamento pode ser configurada para que todas as conexões (ou pelo menos VPN) iniciadas na Internet sejam roteadas pelo gateway padrão ( 192.168.1.1 )?
CONFIGURAÇÃO
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 |
--------------------------------
Como você notará, estamos em uma situação dupla de NAT aqui. Por mais desconfortável que possa ser este não é o problema , já que os clientes podem se conectar quando a instância do cliente VPN é desativada.
Com o cliente VPN e as instâncias do servidor ativadas, esta é a tabela de roteamento main , conforme fornecido por 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
e estas são as regras de ip, como dadas por 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
TENTAÇÕES
Primeiro, criei uma tabela de roteamento no_vpn_provider ( echo "2 no_vpn_provider" >> /etc/iproute2/rt_tables ), uma cópia exata da tabela main sem as modificações da instância do cliente VPN. ip route list table no_vpn_provider mostra
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) Eu tentei estas regras simples de 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
em que 192.168.1.2 e 10.255.0.1 são os endereços IP da interface externa eth0 e da interface do servidor VPN tun1 , respectivamente.
Eu também tentei from all iif eth0 e from all iif tun1 em vez de from 192.168.1.2 e from 10.255.0.1 .
2) Eu tentei marcar com 0x1 new conexões (o módulo conntrack está instalado) para as interfaces eth0 e 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
e adicionando esta regra para fazer conexões marcadas, use a nova tabela de roteamento
ip rule add fwmark 0x1 table no_vpn_provider priority 2
3) Eu tentei marcar pacotes de saída da porta do servidor 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
e usando a mesma regra
ip rule add fwmark 0x1 table no_vpn_provider priority 2
Eu também tentei 2) e 3) com marcas diferentes e com inserção ( -I ) em vez de acrescentar ( -A ). Suspeitando que meu firewall não estava marcando nada eu testei
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
mas, como esperado, os pacotes da minha LAN não foram encaminhados para o provedor de VPN.
4) A única coisa que funciona até agora é essa regra feia
ip rule add from all to y.y.y.y/y table no_vpn_provider priority 2
onde y.y.y.y / y é o endereço IP público do cliente que está tentando se conectar: esta é obviamente uma solução terrível, porque os clientes não irão se conectar sempre da mesma rede.