Preciso configurar uma rota da nossa rede local para a nossa VPN. Ou seja, qualquer pessoa de dentro da LAN deve poder se comunicar com máquinas na VPN, sem ser um cliente VPN em si . O problema é que eu sou meio bobo quando se trata de redes...
A rede local tem um alcance de 8 bits, 192.168.2.X O próprio servidor VPN está em outra rede, em 192.168.3.20 (8 bits) A rede VPN tem um alcance de 16 bits, 10.8.XX
A interface eth0 da máquina que executa o servidor openvpn possui um IP estático em 192.168.3.20. A interface tun0 do próprio servidor vpn escuta 10.8.0.1
O que já estamos trabalhando é que os pacotes para 10.8.xx na rede local sejam redirecionados para o servidor:
traceroute to 10.8.0.1 (10.8.0.1), 30 hops max, 60 byte packets
1 gateway (192.168.2.1) 2.508 ms 2.364 ms 2.325 ms
2 10.8.0.1 (10.8.0.1) 1.898 ms 1.895 ms 1.911 ms
Então eu já posso ssh nele em 10.8.0.1, tudo bem.
No entanto, quando tento acessar um cliente na VPN, o resultado é um pouco diferente:
traceroute to 10.8.0.178 (10.8.0.178), 30 hops max, 60 byte packets
1 gateway (192.168.2.1) 2.315 ms 2.152 ms 2.036 ms
2 192.168.3.20 (192.168.3.20) 1.764 ms 1.760 ms 1.776 ms
3 * * *
etc...
O que me incomoda um pouco sobre isso é que uma solicitação direta ao servidor termina em 10.8.0.1, enquanto eu esperava que não funcionasse ou terminasse em 192.168.3.20. Então, obviamente, eu não entendo muito do que está acontecendo aqui...
A partir daí, pensei que poderia resolver o problema encaminhando o tráfego que chega em eth0 para tun0:
sudo iptables -A FORWARD -i eth0 -o tun0 -d 10.8.0.0/16 -j ACCEPT
Mas isso não surtiu efeito. E é praticamente onde estou preso. Eu tentei algumas variações do acima e brinquei com a rota na configuração do OpenVPN, tudo sem nenhuma alteração visível.
O que é interessante, porém, é que a atividade de rastreamento realmente aparece no
*VPN log, but I don't understand much of what's going on here either:
Fri Oct 19 11:57:53 2018 us=219532 GET INST BY VIRT: 10.8.0.158 -> y18022c/185.184.117.20:1194 via 10.8.0.158
Fri Oct 19 11:57:53 2018 us=219539 y18022c/185.184.117.20:1194 TUN READ [60]
Fri Oct 19 11:57:53 2018 us=219544 y18022c/185.184.117.20:1194 TLS: tls_pre_encrypt: key_id=0
Fri Oct 19 11:57:53 2018 us=219555 y18022c/185.184.117.20:1194 ENCRYPT IV: 14c0471a 9fe7860f
Fri Oct 19 11:57:53 2018 us=219580 y18022c/185.184.117.20:1194 ENCRYPT FROM: 000000ae fa450000 3cac0400 000b1135 5ec0a803 010a0800 9e98b682 bf00282[more...]
Fri Oct 19 11:57:53 2018 us=219612 y18022c/185.184.117.20:1194 ENCRYPT TO: 14c0471a 9fe7860f 00bbfc72 b50c8915 8390d362 82f0a84c c22803b1 2a7ceca[more...]
Fri Oct 19 11:57:53 2018 us=219622 PO_CTL rwflags=0x0002 ev=4 arg=0x5654a4302150
Fri Oct 19 11:57:53 2018 us=219629 PO_CTL rwflags=0x0000 ev=5 arg=0x5654a4302068
Fri Oct 19 11:57:53 2018 us=219637 I/O WAIT Tr|Tw|Sr|SW [0/63574]
Fri Oct 19 11:57:53 2018 us=219646 PO_WAIT[0,0] fd=4 rev=0x00000004 rwflags=0x0002 arg=0x5654a4302150
Fri Oct 19 11:57:53 2018 us=219652 event_wait returned 1
Fri Oct 19 11:57:53 2018 us=219658 I/O WAIT status=0x0002
Fri Oct 19 11:57:53 2018 us=219696 y18022c/185.184.117.20:1194 UDPv4 WRITE [101] to [AF_INET]185.184.117.20:1194: P_DATA_V1 kid=0 DATA c15dc78e ddd12705 8c3a860c 9cd9fe1e da29c4b2 14c0471a 9fe7860f 00bbfc7[more...]
Fri Oct 19 11:57:53 2018 us=219707 y18022c/185.184.117.20:1194 UDPv4 write returned 101
Fri Oct 19 11:57:53 2018 us=219715 PO_CTL rwflags=0x0001 ev=4 arg=0x5654a4302150
Fri Oct 19 11:57:53 2018 us=219722 PO_CTL rwflags=0x0001 ev=5 arg=0x5654a4302068
Fri Oct 19 11:57:53 2018 us=219730 I/O WAIT TR|Tw|SR|Sw [0/63574]
Fri Oct 19 11:57:53 2018 us=231770 PO_WAIT[0,0] fd=4 rev=0x00000001 rwflags=0x0001 arg=0x5654a4302150
Fri Oct 19 11:57:53 2018 us=231782 event_wait returned 1
Fri Oct 19 11:57:53 2018 us=231789 I/O WAIT status=0x0001
Fri Oct 19 11:57:53 2018 us=231799 UDPv4 read returned 53
Fri Oct 19 11:57:53 2018 us=231809 GET INST BY REAL: 185.184.117.20:1194 [succeeded]
Fri Oct 19 11:57:53 2018 us=231837 y18022c/185.184.117.20:1194 UDPv4 READ [53] from [AF_INET]185.184.117.20:1194: P_DATA_V1 kid=0 DATA 1196c495 845bb7fd e61cc8d8 ed4d427a b901d6c8 e81fe5a9 3ab1acce b5687f0[more...]
Fri Oct 19 11:57:53 2018 us=231846 y18022c/185.184.117.20:1194 TLS: tls_pre_decrypt, key_id=0, IP=[AF_INET]185.184.117.20:1194
Fri Oct 19 11:57:53 2018 us=231859 y18022c/185.184.117.20:1194 DECRYPT IV: e81fe5a9 3ab1acce
Fri Oct 19 11:57:53 2018 us=231876 y18022c/185.184.117.20:1194 DECRYPT TO: 00000036 fa2a187b f3641eb4 cb07ed2d 0a981fc7 48
Fri Oct 19 11:57:53 2018 us=231897 y18022c/185.184.117.20:1194 PID_TEST [0] [SSL-0] [>EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE] 0:53 0:54 t=1539943073[0] r=[0,64,15,0,1] sl=[11,53,64,528]
Fri Oct 19 11:57:53 2018 us=231905 y18022c/185.184.117.20:1194 RECEIVED PING PACKET*
Meu maior problema é realmente que eu não tenho idéia do que exatamente está acontecendo aqui... Por que uma solicitação para 10.8.0.1 não é roteada através de 192.168.3.20? Quero dizer, seria lógico que ele tivesse que passar pelo servidor real antes de terminar na VPN...? E quando os pedidos estão chegando em eth0 (como é evidente por 192.168.3.20 aparecendo no rastreamento), por que eles não são encaminhados para tun0? O próprio openVPN está bloqueando algo aqui?
Não tenho pontos suficientes para comentar, mas gostaria de saber como você tem 192.168.2.X e 192.168.3.X conectados? Em um palpite, o que você precisa é empurrar as rotas para 192.168.3.X de volta para a outra extremidade da VPN. No /etc/openvpn/server.conf adicione a rota para 192.168.2.X: (Você provavelmente já tem a rede 192.168.3.X lá)
Agora, desde que o servidor VPN local seja o gateway padrão para a LAN, cada lado deve ser capaz de rotear para o outro.
É isto que você quer dizer?