OpenVPN | Como fazer o servidor se comunicar com outro servidor na LAN via gateway OpenVPN?

Question

Estou tentando que minha instância do EC2 (OMD) se comunique com meu servidor de rede local (Raspberry Pi) por meio de outra instância do EC2 (OpenVPN), mas não consigo fazer isso funcionar.

O servidor do OMD pode executar ping no RPi, mas não pode se conectar a ele via SSH, embora as configurações do SSH sejam padrão e não haja firewall. Port 6556 está acessível embora.

Verificação de portas do servidor do OMD

[root@omd ~]# nc -zvv 192.168.16.150 6556
Connection to 192.168.16.150 6556 port [tcp/*] succeeded!
[root@omd ~]# nc -zvv 192.168.16.150 22
nc: connect to 192.168.16.150 port 22 (tcp) failed: Connection timed out
[root@omd ~]#

O RPi's 22 e 6556 estão abertos a todos, mas por que o OMD não consegue SSH?

root@rpi:~# netstat -tunlp | egrep "6556|22"
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      535/sshd
tcp        0      0 0.0.0.0:6556            0.0.0.0:*               LISTEN      743/xinetd
tcp6       0      0 :::22                   :::*                    LISTEN      535/sshd
root@rpi:~#

Veja o que eu tenho tentado alcançar. Por favor, veja este link .

1. O OpenVPN e o RPi estão conectados uns com os outros por meio de conexão VPN
2. O OMD não se conectará à VPN, apenas usará o servidor OpenVPN como um gateway
3. O OMD se comunicará com o RPi por meio do servidor OpenVPN e vice-versa

Você poderia me ajudar com isso?

Por favor, deixe-me saber se você precisar de mais informações.

Obrigado antecipadamente, pessoal!

AWS - OMD Review eth0: 10.0.0.4

=======================
PING
=======================
[root@omd ~]# ping -c 3 192.168.16.150
PING 192.168.16.150 (192.168.16.150) 56(84) bytes of data.
64 bytes from 192.168.16.150: icmp_seq=1 ttl=63 time=100 ms
64 bytes from 192.168.16.150: icmp_seq=2 ttl=63 time=100 ms
64 bytes from 192.168.16.150: icmp_seq=3 ttl=63 time=159 ms    

--- 192.168.16.150 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2159ms
rtt min/avg/max/mdev = 100.072/119.877/159.357/27.917 ms
[root@omd ~]#    
=======================
TRACEROUTE
=======================
[root@omd ~]# traceroute 192.168.16.150
traceroute to 192.168.16.150 (192.168.16.150), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
[root@omd ~]#    
=======================
ROUTE TABLE
=======================
[root@omd ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.16.0    10.0.0.5        255.255.255.0   UG    0      0        0 eth0
172.17.0.0      10.0.0.5        255.255.255.0   UG    0      0        0 eth0
0.0.0.0         10.0.0.1        0.0.0.0         UG    0      0        0 eth0
[root@omd ~]#

AWS - OpenVPN
eth0: 10.0.0.5
tun0: 172.17.0.1

=======================
PING
=======================
[root@openpvn ~]# ping -c 3 10.0.0.4
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
64 bytes from 10.0.0.4: icmp_seq=1 ttl=64 time=0.502 ms
64 bytes from 10.0.0.4: icmp_seq=2 ttl=64 time=0.639 ms
64 bytes from 10.0.0.4: icmp_seq=3 ttl=64 time=0.570 ms

--- 10.0.0.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.502/0.570/0.639/0.059 ms
[root@openpvn ccd]# ping -c 3 192.168.16.150
PING 192.168.16.150 (192.168.16.150) 56(84) bytes of data.
64 bytes from 192.168.16.150: icmp_seq=1 ttl=64 time=173 ms
64 bytes from 192.168.16.150: icmp_seq=2 ttl=64 time=142 ms
64 bytes from 192.168.16.150: icmp_seq=3 ttl=64 time=120 ms

--- 192.168.16.150 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 120.684/145.486/173.209/21.546 ms
[root@openpvn ~]#
=======================
ROUTE
=======================
[root@openvpn ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.0.1        0.0.0.0         UG    0      0        0 eth0
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.169.254 0.0.0.0         255.255.255.255 UH    0      0        0 eth0
172.17.0.0      0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.16.0    172.17.0.2      255.255.255.0   UG    0      0        0 tun0
[root@openvpn ~]#
=======================
IPTABLES
=======================
[root@openvpn ~]# cat /etc/sysconfig/iptables
*nat
:POSTROUTING ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -s 172.17.0.0/24 -d 0.0.0.0/0 -o eth0 -j MASQUERADE
COMMIT
[root@openvpn ~]#
=======================
SYSCTL
=======================
[root@openvpn ~]# grep forward /etc/sysctl.conf
# Controls IP packet forwarding
net.ipv4.ip_forward = 1
[root@openvpn ~]#

LAN - Raspberry Pi
eth0: 192.168.16.150
tun0: 172.17.0.253

=======================
PING
=======================
root@rpi:~# ping -c 3 10.0.0.4
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
64 bytes from 10.0.0.4: icmp_seq=1 ttl=63 time=128 ms
64 bytes from 10.0.0.4: icmp_seq=2 ttl=63 time=106 ms
64 bytes from 10.0.0.4: icmp_seq=3 ttl=63 time=126 ms   

--- 10.0.0.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 106.837/120.409/128.312/9.644 ms
root@rpi:~# 
=======================
TRACEROUTE
=======================
root@rpi:~# traceroute 10.0.0.4
traceroute to 10.0.0.4 (10.0.0.4), 30 hops max, 60 byte packets
 1  172.17.0.1 (172.17.0.1)  177.150 ms  200.416 ms  199.949 ms
 2  10.0.0.4 (10.0.0.4)  205.052 ms  216.804 ms  223.456 ms
root@rpi:~# 
=======================
ROUTE TABLE
=======================
root@rpi:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.17.0.1      128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.8.1     0.0.0.0         UG    0      0        0 eth1
0.0.0.0         192.168.16.254  0.0.0.0         UG    202    0        0 eth0
0.0.0.0         192.168.8.1     0.0.0.0         UG    203    0        0 eth1
5X.XX.XX.XXX    192.168.8.1     255.255.255.255 UGH   0      0        0 eth1
128.0.0.0       172.17.0.1      128.0.0.0       UG    0      0        0 tun0
172.17.0.0      0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.8.0     0.0.0.0         255.255.255.0   U     203    0        0 eth1
192.168.16.0    0.0.0.0         255.255.255.0   U     202    0        0 eth0
root@rpi:~#

    

Answer 1

Dado o diagrama que vejo é especificado que você está usando um adaptador tun, significando uma rede roteada, e não uma rede vpn da camada 2. Você precisa ter o encaminhamento de IP funcionando corretamente. Além disso, para a sua situação, você também precisará fazer algum NAT no servidor VPN, devido à segurança envolvida no protocolo ssh, para garantir que o tráfego vá e volte pelo mesmo servidor.

Existem algumas peças para que isso funcione. Todos os itens abaixo são para um sistema CentOS um pouco antigo.

Configure o encaminhamento de IP em qualquer máquina OpenVPN (cliente ou servidor) que tenha uma LAN conectada.

• vi / etc / sysconfig / network e inclua a linha FORWARD_IPV4 = true
• vi /etc/sysctl.conf e altere net.ipv4.ip_forward = 1

Para configurar o NAT necessário, se você estiver usando iptables para o seu firewall, estes comandos são necessários em qualquer máquina OpenVPN (cliente ou servidor) que tenha uma LAN conectada.

• iptables --table nat --appendar POSTROUTING --out interface eth0 -j MASQUERADE
• iptables --table nat --appenda POSTROUTING --out interface tun0 -j MASQUERADE

Desativar o firewall irá quebrá-lo. Você provavelmente também pode usar o firewalld, mas eu não tenho os comandos necessários para isso. Também, uma vez satisfeito com as regras do iptables, lembre-se de salvá-las, assim elas persistirão durante a reinicialização.

Além disso, para cada extremidade da VPN saber encaminhar tráfego para a LAN na outra extremidade da VPN para passar pelo túnel que o servidor precisa

• as linhas de configuração roteiam a sub-rede remote_network para cada um dos sites remotos com uma LAN conectada, para que o servidor local saiba rotear o tráfego destinado a essas sub-redes naquele túnel.
• as linhas de configuração empurram "sub-rede da rede de rotas" para que cada um dos clientes conectados saiba encaminhar o tráfego através do túnel para essas sub-redes. Isso incluirá a LAN do servidor e todas as LANs do cliente.
• a linha de configuração client-config-dir ccd para que o servidor saiba para verificar a pasta / etc / openvpn / ccd para arquivos com nomes de clientes com LANs nela
• o arquivo ccd / client-name com o conteúdo irrompe a sub-rede para que o software VPN saiba que, quando esse cliente se conectar, o tráfego dessa sub-rede será enviado para esse cliente.

Ter todas essas linhas é necessário ou, pelo menos, particularmente útil quando você tem mais de uma conexão LAN cliente. Quando há apenas um único cliente conectando-se a um único servidor, é muito mais simples. Uma única LAN para LAN não é muito mais que isso.