Como rotear o tráfego da rede privada para a sub-rede openvpn (e vice-versa)

Question

Eu tenho alguns servidores no Linode. Eu estou tentando configurá-los para que eu tenha uma VPN em uma das máquinas e, em seguida, pode acessar todas as outras máquinas usando a rede de linode privada. O acesso público a serviços privados (SSH, etc.) seria restrito apenas àqueles que possuem acesso VPN.

Observação: ainda não tenho firewalls sendo executados nesses servidores.

root@internal:~# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination  

servidor interno (executando o servidor openvpn)

eth0      Link encap:Ethernet  HWaddr f2:3c:91:db:68:b4  
          inet addr:23.239.17.12  Bcast:23.239.17.255  Mask:255.255.255.0
          inet6 addr: 2600:3c02::f03c:91ff:fedb:68b4/64 Scope:Global
          inet6 addr: fe80::f03c:91ff:fedb:68b4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:80780 errors:0 dropped:0 overruns:0 frame:0
          TX packets:102812 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:14317079 (14.3 MB)  TX bytes:17385151 (17.3 MB)

eth0:1    Link encap:Ethernet  HWaddr f2:3c:91:db:68:b4  
          inet addr:192.168.137.64  Bcast:192.168.255.255  Mask:255.255.128.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:172.20.1.1  P-t-P:172.20.1.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:2318 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1484 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:174573 (174.5 KB)  TX bytes:170941 (170.9 KB)

Comentários sobre os itens acima:

• eth0 é a interface pública
• eth0: 1 é a interface para a rede privada
• O túnel VPN funciona corretamente. De um cliente conectado à VPN, posso fazer ping de 172.20.1.1 e 192.168.137.64.
• net.ipv4.ip_forward = 1 está definido neste servidor

servidor de banco de dados (nix03):

root@nix03:~# ifconfig eth0      Link encap:Ethernet  HWaddr f2:3c:91:73:d2:cc  
          inet addr:173.230.140.52  Bcast:173.230.140.255  Mask:255.255.255.0
          inet6 addr: 2600:3c02::f03c:91ff:fe73:d2cc/64 Scope:Global
          inet6 addr: fe80::f03c:91ff:fe73:d2cc/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12348 errors:0 dropped:0 overruns:0 frame:0
          TX packets:44434 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1166666 (1.1 MB)  TX bytes:5339936 (5.3 MB)

eth0:1    Link encap:Ethernet  HWaddr f2:3c:91:73:d2:cc  
          inet addr:192.168.137.63  Bcast:192.168.255.255  Mask:255.255.128.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

Comentários sobre os itens acima:

• eth0 é a interface pública
• eth0: 1 é a interface para a rede privada
• Eu posso pingar o servidor interno na interface privada (192.168.137.64).

Problema atual

Eu quero ser capaz de acertar o servidor de banco de dados através da VPN. Do meu cliente vpn (laptop no meu escritório), eu gostaria de poder fazer o ping 192.168.137.63. No entanto, isso atualmente falha.

Em minhas tentativas de solucionar problemas, decidi abordá-lo pelo lado do servidor db e ver se conseguia fazer ping no túnel VPN no servidor interno (172.20.1.1). Percebi que precisaria configurar uma rota no servidor de banco de dados para dizer para onde enviar os pacotes destinados à rede 172.20.1.0/24, então fiz isso:

root@nix03:~# ip route add 172.20.1.0/24 via 192.168.137.64 root@nix03:~# ip route list default via 173.230.140.1 dev eth0
172.20.1.0/24 via 192.168.137.64 dev eth0
173.230.140.0/24 dev eth0  proto kernel  scope link  src 173.230.140.52
192.168.128.0/17 dev eth0  proto kernel  scope link  src 192.168.137.63 root@nix03:~# ip route get 172.20.1.1
172.20.1.1 via 192.168.137.64 dev eth0  src 192.168.137.63
    cache     

Então, eu acho baseado no acima, quando eu faço ping em 172.20.1.1, meu servidor deve enviar os pacotes para 192.168.137.64 (servidor interno). Esse servidor deve, por causa do encaminhamento de ip, pegar o pacote da eth0: 1 e encaminhá-lo para o tun0 (172.20.1.1).

Mas, como você deve ter adivinhado, o ping 172.20.1.1 do nix03 (db server) não funciona.

Eu fiz alguns pacotes de captura para ver para qual endereço MAC meus pacotes ICMP estavam sendo enviados:

root@nix03:~# tcpdump -i eth0 -e icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 16:41:39.623759 f2:3c:91:73:d2:cc (oui Unknown) > f2:3c:91:db:68:b4 (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.137.63 > 172.20.1.1: ICMP echo request, id 3324, seq 33653, length 64 root@nix03:~# arp Address HWtype HWaddress Flags Mask Iface 192.168.137.64 ether f2:3c:91:db:68:b4 C eth0

E isso me diz que os pacotes devem estar chegando ao servidor interno. Pelo menos, eles estão sendo enviados para o NIC correto. No entanto, quando eu executo o tcpdump em eth0 e eth0: 1 do servidor interno, não vejo nenhum pacote icmp vindo do servidor db.

O que mais eu posso experimentar? Agradecemos antecipadamente.

Atualização # 1

Tabela de roteamento para o servidor "interno":

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gw-li686.linode 0.0.0.0         UG    0      0        0 eth0
23.239.17.0     *               255.255.255.0   U     0      0        0 eth0
172.20.1.0      172.20.1.2      255.255.255.0   UG    0      0        0 tun0
172.20.1.2      *               255.255.255.255 UH    0      0        0 tun0
192.168.128.0   *               255.255.128.0   U     0      0        0 eth0

    

Answer 1

Acabei tendo que adicionar uma regra de NAT ao servidor interno. Não tenho certeza se é necessário, mas é o que funcionou:

*nat
:PREROUTING ACCEPT [21:1248]
:INPUT ACCEPT [21:1248]
:OUTPUT ACCEPT [21:1529]
:POSTROUTING ACCEPT [21:1529]
# enable NAT for VPN clients so they can hit the private network
-A POSTROUTING -s 172.20.1.0/24 -o eth0 -j MASQUERADE
COMMIT

    

Answer 2

Eu encontrei o mesmo problema e cheguei à conclusão de que o Linode não é adequado para esse tipo de configuração VPN.

Primeiro de tudo: o que você tentou fazer (configurar uma rota) de 192.168.137.63 (eth0: 1 no nix03) para 172.20.1.1 (tun0 no interno) está de fato correto e funciona em configurações não-Linode. Eu descrevi a a mesma configuração nos fóruns do Linode e Recebi uma resposta de um ex funcionário da Linode me dizendo que a Linode proíbe esse tipo de configuração .

Além disso, mesmo que o tráfego VPN NAT para a rede interna como você fez seja de fato outra abordagem correta, tenha em mente que a sub-rede 192.168.128.0/24 não é particular para você, mas para todos os clientes Linode com VMs no mesmo datacenter como você. Experimente o nmap para verificar o que estou dizendo:

nmap -sP 192.168.128.0/17

Então, no caso Linode, se você realmente quiser:

Public access to private services (SSH, etc.) would then be restricted to only those who have VPN access.

você precisa configurar cuidadosamente o seu firewall para permitir apenas acessos de endereços IP exatos, já que a sub-rede é privada apenas no significado de palavras do datacenter Linode .