Início / server / Perguntas / 1161502
Accepted
Ricky883249
Asked: 2024-06-25 18:24:35 +0800 CST

O roteamento de 2 conexões OpenVPN para a porta encaminhada só funciona quando 1 conexão está inoperante

  • 772

Eu tenho uma rede doméstica com um roteador DSL. Uma máquina na rede abre uma conexão openvpn com um provedor VPN de terceiros. Esta máquina atua como um roteador para todas as máquinas da minha rede que têm seu gateway configurado para esta máquina, fornecendo-lhes acesso à Internet pela VPN. Algumas máquinas precisam configurar um roteador DSL como gateway e acessar a internet sem VPN.

Gostaria de usar o roteador DSL para acessar minha rede doméstica quando estiver ausente. Para isso, criei uma segunda conexão openvpn na máquina que fornece o vpn que escuta na porta 1194 e encaminhei essa porta no meu roteador DSL. No entanto, só consigo acessar a porta quando a primeira VPN está inativa.

Suspeito que haja algum erro simples de roteamento que não entendo.

Algumas informações básicas:

# 192.168.178.1 is my DSL router.
# 192.168.178.8 is the machine that opens the tun0 vpn connection and routes all traffic through tun0.
# xx.xxx.xxx.xxx is the ip of my third party vpn provider.
# (not relevant but shows up below) Port 33075 is open from the vpn side and is forwarded to a specific machine on the network.
# tun1 was created on 192.168.178.8 with port 1194 for access from outside.
# Port 1194 is opened on the DSL router (192.168.178.1) and forwarded to 192.168.178.8

Com tun0 e tun1 desativados:

% route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 eno1
192.168.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eno1

% ip route
default via 192.168.178.1 dev eno1 proto static
192.168.0.0/16 dev eno1 proto kernel scope link src 192.168.178.8

% sudo iptables-save
(empty output)

Com apenas tun1 ativado: a porta encaminhada 1194 do exterior não VPN mostra aberta

% route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 eno1
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun1
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun1
192.168.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eno1

% ip route
default via 192.168.178.1 dev eno1 proto static
10.8.0.0/24 via 10.8.0.2 dev tun1
10.8.0.2 dev tun1 proto kernel scope link src 10.8.0.1
192.168.0.0/16 dev eno1 proto kernel scope link src 192.168.178.8

% sudo iptables-save
(empty output)

Com tun0 e tun1 ativados: a porta encaminhada 1194 do exterior não VPN mostra fechada

% route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.28.78.1      128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 eno1
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun1
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun1
10.28.78.0      0.0.0.0         255.255.255.0   U     0      0        0 tun0
xx.xxx.xxx.xxx  192.168.178.1   255.255.255.255 UGH   0      0        0 eno1
128.0.0.0       10.28.78.1      128.0.0.0       UG    0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eno1

% 0.0.0.0/1 via 10.28.78.1 dev tun0
default via 192.168.178.1 dev eno1 proto static
10.8.0.0/24 via 10.8.0.2 dev tun1
10.8.0.2 dev tun1 proto kernel scope link src 10.8.0.1
10.28.78.0/24 dev tun0 proto kernel scope link src 10.28.78.159
xx.xxx.xxx.xxx via 192.168.178.1 dev eno1
128.0.0.0/1 via 10.28.78.1 dev tun0
192.168.0.0/16 dev eno1 proto kernel scope link src 192.168.178.8

%  sudo iptables-save
# Generated by iptables-save v1.8.10 (nf_tables) on 
*filter
:INPUT ACCEPT [44:5124]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i eno1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j ACCEPT
-A FORWARD -d 192.168.178.138/32 -p tcp -m tcp --dport 33075 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -d 192.168.178.138/32 -p udp -m udp --dport 33075 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on 
# Generated by iptables-save v1.8.10 (nf_tables) on 
*nat
:PREROUTING ACCEPT [76:7067]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -i tun0 -p tcp -m tcp --dport 33075 -j DNAT --to-destination 192.168.178.138:33075
-A PREROUTING -i tun0 -p udp -m udp --dport 33075 -j DNAT --to-destination 192.168.178.138:33075
-A POSTROUTING -o eno1 -j MASQUERADE
-A POSTROUTING -o tun0 -j MASQUERADE
COMMIT
# Completed on
iptables

1 respostas

  1. Best Answer

    Como sua tun0VPN adiciona "substituições" de rota padrão (ou seja, as /1rotas, que aparentemente SÃO o que você deseja), os tráfegos (encapsulados) enviados pelo tun1servidor VPN (para clientes em uma "rede remota") serão roteados para o tun0túnel (em vez disso do seu roteador) e, portanto, seria NAT com um IP público diferente daquele que o cliente usou para se conectar ao servidor, que o cliente não reconheceria.

    Você precisaria de roteamento de política para isso:

    ip route add default via 192.168.178.1 dev eno1 onlink table 123
ip rule add iif lo sport 1194 lookup 123

    (Você pode adicionar ipproto udpou ipproto tcpà regra dependendo do protocolo usado pela tun1VPN.)

    Certifique-se também de que o rp_filtersysctl de eno1não seja 1(mas 0ou 2).

    • 0

relate perguntas