OpenVPN e encaminhamento de porta

Question

Eu tenho um problema com meu servidor baseado em Linux em relação a VPN e encaminhamento de porta. Eu também sou um iniciante nessa área, então me perdoe por qualquer erro.

Primeiro, deixe-me descrever a infraestrutura. Eu tenho um servidor Linux VPS ( S1 ) com o openvpn configurado corretamente, e uma máquina com Linux ( C1 ) também com o openvpn configurado corretamente. Eles estão conectados usando o número de porta 1194 . Este é basicamente o esquema:

    S1
    [ip: X.X.X.221]
    [tun0 ip: 10.8.0.1]

    C1
    [ip: Y.Y.Y.19]
    [tun0 ip: 10.8.0.6]

Quando eu digo que tudo está configurado corretamente é porque eu posso fazer ping com êxito 10.8.0.1 de C1 .

Agora, vem o problema ... Eu tenho um serviço P1 em execução na porta 1800 em S1 e um cliente para esse serviço em C1 . Eu posso dar o endereço IP X.X.X.221: 1800 com sucesso ao cliente em C1 , mas quero que o cliente acesse P1 via conexão VPN. Isso é uma maneira de fazer isso?

No começo eu achava que isso era simplesmente um problema de redirecionamento de portas, e tudo que eu precisava fazer era encaminhar todas as requisições da porta 1194 para a porta 1800 , e encontrei este comando para fazer isso (btw, venet0 é minha interface):

    iptables -t nat -A PREROUTING -i venet0 -p udp --dport 1194 -j REDIRECT --to-port 1800

Mas isso não vai funcionar.

Qualquer ajuda? Obrigado :)

EDIT1:

Resultado da emissão de netstat -rn e 10.8.0.6 em S1 :

    Kernel IP routing table
    Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
    10.8.0.2        0.0.0.0         255.255.255.255 UH        0 0          0 tun0
    10.8.0.0        10.8.0.2        255.255.255.0   UG        0 0          0 tun0
    0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 venet0

    traceroute to 10.8.0.6 (10.8.0.6), 30 hops max, 60 byte packets
     1  10.8.0.6 (10.8.0.6)  116.769 ms  119.000 ms  120.618 ms

Resultado da emissão de netstat -rn e traceroute 10.8.0.1 em C1 :

    Kernel IP routing table
    Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
    0.0.0.0         192.168.1.254   0.0.0.0         UG        0 0          0 eth0
    10.8.0.1        10.8.0.5        255.255.255.255 UGH       0 0          0 tun0
    10.8.0.5        0.0.0.0         255.255.255.255 UH        0 0          0 tun0
    192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

    traceroute to 10.8.0.1 (10.8.0.1), 30 hops max, 38 byte packets
     1  10.8.0.1 (10.8.0.1)  83.825 ms  83.639 ms  86.877 ms

EDIT 2:

Arquivo de configuração para S1 (acredito que o que começa com ; não é considerado):

    ;local a.b.c.d
    port 1194
    proto udp
    dev tun
    ;dev-node MyTap
    ca ca.crt
    cert server.crt
    key server.key  # This file should be kept secret
    dh dh2048.pem
    server 10.8.0.0 255.255.255.0
    ifconfig-pool-persist ipp.txt
    ;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100
    ;push "route 192.168.10.0 255.255.255.0"
    ;push "route 192.168.20.0 255.255.255.0"
    ;client-config-dir ccd
    ;route 192.168.40.128 255.255.255.248
    ;client-config-dir ccd
    ;route 10.9.0.0 255.255.255.252
    ;learn-address ./script
    push "dhcp-option DNS 8.8.8.8"
    push "dhcp-option WINS 8.8.4.4"
    ;client-to-client
    ;duplicate-cn
    keepalive 10 120
    ;tls-auth ta.key 0 # This file is secret
    ;cipher BF-CBC        # Blowfish (default)
    ;cipher AES-128-CBC   # AES
    ;cipher DES-EDE3-CBC  # Triple-DES
    comp-lzo
    ;max-clients 300
    user root
    group root
    persist-key
    persist-tun
    status openvpn-status.log
    ;log         openvpn.log
    ;log-append  openvpn.log
    verb 3
    ;mute 20

Arquivo de configuração para C1

    client
    remote 176.9.192.221 1194
    ca ca.crt
    cert client.crt
    key client.key
    cipher BF-CBC
    comp-lzo
    dev tun
    proto udp
    nobind
    persist-key
    persist-tun
    user root
    group root

    

Answer 1

Você pode remover manualmente as rotas estáticas existentes em C1 para 10.8.0.1 e 10.8.0.5 ; exemplo:

route del -net 10.8.0.1 gw 10.8.0.5 netmask 255.255.255.255 dev tun0

Em seguida, adicione uma nova rota no C1 usando:

route add -net 10.8.0.1 gw 10.8.0.6 netmask 255.255.255.255 dev tun0

Veja se isso funciona. Lembre-se de acompanhar suas rotas antigas, caso precise adicioná-las novamente. Isso deve corrigir o problema de roteamento da sua VPN.

Seu outro problema é que sua rede VPN não pode falar com a rede na qual a NIC do servidor da OpenVPN está. Você pode corrigir isso adicionando uma nova rota estática em cada lado para essas redes.

Em C1:

route add -net X.X.X.221 gw 10.8.0.6 netmask 255.255.255.255 dev tun0

Em S1:

route add -net Y.Y.Y.19 gw 10.8.0.6 netmask 255.255.255.255 dev tun0

Observação: eu não recomendaria isso, a menos que você possa reverter suas alterações. caso isso não funcione.

Você também pode tentar usar a opção push route na sua configuração do OpenVPN. Por exemplo:

push "route  X.X.X.221 255.255.255.0"

Finalmente, se nada disso funcionar, você pode tentar adicionar algo no seu IPTABLES para encaminhar o tráfego da sua rede VPN (NAT) para a sua rede local no S1. Algo como:

iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -t nat -A PREROUTING -s 10.8.0.6 -p tcp --dport 1800 -j DNAT --to-destination X.X.X.221:1800

    

Answer 2

Assim, o seu serviço S1 deve estar escutando no IP da VPN, 10.8.0.1, e o seu cliente C1 precisa se conectar a 10.8.0.1:1800 ... enquanto sua VPN estiver funcionando totalmente.

    

Answer 3

Parece que sua configuração do serviço S1 não está ouvindo a interface tun. Não há problema com o roteamento. Qual é o seu serviço? Você pode mostrar a configuração dele? Enfim - tente telnet 10.8.0.1 1800 no S1 telnet X.x.x.221 1800 no S1. Se você receberá uma resposta em um dos casos - problema de pesquisa no arquivo de configuração do serviço.