NAT para vários servidores com iptables sobre o OpenVPN

2

Eu criei com sucesso uma rede OpenVPN (servidor hospedado em um VPS ) 10.8.0.0/255.255.0.0 para minhas necessidades, e clientes que suportam clientes OpenVPN podem se conectar através do servidor e se conectar entre eles com sucesso.

Existem também algumas máquinas (como NAS) que não suportam o OpenVPN, mas eu quero me conectar a elas através da rede VPN. Minha solução foi ter uma máquina pequena (como um Raspberry Pi [<> endereço IP: 192.168.1.109 ]) sendo um cliente OpenVPN e encaminhando corretamente os pacotes para as máquinas de destino, mas eu não gosto do solução proposta aqui porque:

  1. Eu não quero ter conflitos de sub-rede entre diferentes redes locais (e minha casa);
  2. Existem algumas máquinas em minha casa que não querem ser acessadas pela VPN.

Por isso, criei um certificado de cliente por máquina para estar conectado à VPN (2 no meu caso) e experimente iptables para fazer um NAT para acessar essas máquinas usando o endereço IP da VPN. Eu consegui me conectar com sucesso à VPN. Aqui está a saída de ifconfig do Raspberry Pi:

eth0      Link encap:Ethernet  HWaddr b8:27:eb:40:44:76
          inet addr:192.168.1.109  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::ed10:b13d:8e57:7a64/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:208623 errors:0 dropped:10506 overruns:0 frame:0
          TX packets:183838 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:181180734 (172.7 MiB)  TX bytes:35462529 (33.8 MiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1175 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1175 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:69061 (67.4 KiB)  TX bytes:69061 (67.4 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.8.0.26  P-t-P:10.8.0.25  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:83 errors:0 dropped:0 overruns:0 frame:0
          TX packets:82 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:8940 (8.7 KiB)  TX bytes:9786 (9.5 KiB)

tun1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.8.0.34  P-t-P:10.8.0.33  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:18 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:912 (912.0 B)  TX bytes:0 (0.0 B)

Com a ajuda de iptables , desejo mapear os IPs 10.8.0.26 a 192.168.1.201 e 10.8.0.34 a 192.168.1.202 . Depois de muitas tentativas, consegui criar as regras descritas abaixo (usando o comando iptables -t nat --list ):

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       all  --  anywhere             10.8.0.26            to:192.168.1.201
DNAT       all  --  anywhere             10.8.0.34            to:192.168.1.202

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
SNAT       all  --  10.8.0.0/16          192.168.1.0/24       to:192.168.1.109

Se eu colocar as regras para uma das máquinas, elas funcionam corretamente. Quando eu coloco os dois (como dito acima) o segundo NAT não funciona (neste caso o 10.8.0.34 a 192.168.1.202)!

Qual você acha que é o possível problema? Meu melhor palpite é que, no segundo caso, enquanto a resposta deve retornar a partir de 10.8.0.34, ela provavelmente a envia pela interface errada (tun0). O comando ip route retorna isso:

0.0.0.0/2 via 192.168.1.1 dev eth0
0.0.0.0/1 via 10.8.0.25 dev tun0
default via 192.168.1.1 dev eth0  metric 202
10.8.0.0/24 via 10.8.0.25 dev tun0
10.8.0.25 dev tun0  proto kernel  scope link  src 10.8.0.26
10.8.0.33 dev tun1  proto kernel  scope link  src 10.8.0.34
64.0.0.0/2 via 192.168.1.1 dev eth0
81.XXX.YYY.ZZZ via 192.168.1.1 dev eth0
128.0.0.0/2 via 192.168.1.1 dev eth0
128.0.0.0/1 via 10.8.0.25 dev tun0
192.0.0.0/2 via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.109  metric 202

O que você acha que é uma solução possível?

Editar 1:

Apresento aqui um pequeno diagrama da Rede, a fim de esclarecer melhor a topologia.

/---------------------------\
| OpenVPN Server            |                  /-----------------------------------\
| Public IP: 81.XXX.YYY.ZZZ |  ----- ... ----- | Home Router Local Ip: 192.168.1.1 | 
| VPN IP: 10.8.0.1          |                  \-----------------------------------/
\---------------------------/                      |   |   |   |   |   |   |   |  
                                                   |   |   |   |   |   |   |   |
                                                  /--\/--\/--\/--\/--\/--\/--\/--\
                                                  |S1||S2||S3||S4||S5||S6||S7||S8|
                                                  \--/\--/\--/\--/\--/\--/\--/\--/

S[*]: All machine have local ip in 192.168.1.0/255.255.255.0
S1: Server that has capabilities to run OpenVPN client (for example 10.8.0.12)
S2: The Raspberry PI that runs the 2 instances of OpenVPN Client (10.8.0.26, 10.8.0.34)
S3-4: The local servers where the are not capable for running the OpenVPN client (192.168.1.201, 192.168.1.202)
S5-8: Local server that I don't want to be availiable in the OpenVPN network. 

Editar 2: fiz a pergunta superusuário , o que é mais apropriado.

    
por hargikas 29.08.2016 / 08:45

0 respostas