Como posso acessar uma única máquina local através do OpenVPN?

Como posso acessar uma única máquina local através do OpenVPN?

Parece uma pergunta trivial, mas ainda não consegui encontrar a resposta.

Na minha LAN (azul na foto) tenho um NAS e um Raspberry Pi, entre outras máquinas. Instalei um servidor OpenVPN no Raspberry Pi. Quero que o cliente OpenVPN consiga acessar o NAS, ou seja, FTP, HTTP, etc. O cliente não deve conseguir acessar nenhuma máquina que não seja o Raspberry e o próprio NAS.

Nesta foto você tem minha topologia de redes:

redes_topologia

Posso conectar o cliente OpenVPN ao seu servidor. Sei que tenho um conflito de sub-redes, mas não consigo alterar as sub-redes.

Configuração do meu servidor:

port 1194
proto udp
dev tun

ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/myserver.crt
key /etc/openvpn/easy-rsa/keys/myserver.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem

server 10.8.0.0 255.255.255.0
#push "route 192.168.1.0 255.255.255.0"

ifconfig-pool-persist /etc/openvpn/easy-rsa/ipp.txt

keepalive 10 120
cipher AES-128-CBC
persist-key
persist-tun

status /var/log/openvpn-status.log
#log         /var/log/openvpn.log
log-append  /var/log/openvpn.log
verb 3

Meu arquivo de configuração do cliente:

client

remote x.y.z.t 1194
proto udp
dev tun

ca /etc/openvpnclient/ca.crt
cert /etc/openvpnclient/client.crt
key /etc/openvpnclient/client.key

cipher AES-128-CBC

#route-method exe
#route-delay 3
#route 10.8.0.0 255.255.255.0
###route-nopull
route 192.168.1.20 255.255.255.255

resolv-retry infinite
nobind
persist-key
persist-tun

mute 20
verb 3

Posso me conectar usando o cliente Windows, mas não consigo executar ping ou acessar o NAS de qualquer maneira. Tenho certeza de que ainda estou faltando alguma coisa, mas não consegui descobrir como posso direcionar o tráfego. Li muitos tópicos sobre o assunto, mas ainda não tive sorte.

Devo poder adicionar uma regra de roteamento no roteador que está na rede do servidor OpenVPN, se necessário.


Atualização 18/11/2019 às 17h31 CET

Tenho dois requisitos principais:

  1. Preciso que o cliente chegue ao NAS, mas não às outras máquinas da LAN;
  2. Preciso que o cliente consiga se conectar mesmo quando sua sub-rede entrar em conflito com a sub-rede NAS (ou seja, 192.168.1.0/24).

Tom Yan eEste artigome ajudou a encontrar uma solução para o primeiro problema. Acredito que o segundo problema ainda esteja descoberto.

Solução para o problema nº 1:

Na configuração do servidor precisei adicionar (descomentar) esta linha, para garantir o roteamento das solicitações do cliente OpenVPN para o NAS:

push "route 192.168.1.0 255.255.255.0"

Para ativar o roteamento do NAS de volta ao cliente OpenVPN, adicionei esta regra de roteamentono NAS:

vi /etc/sysconfig/network-scripts/route-eth0

adicionando esta linha naquele arquivo de configuração (vazio)

10.8.0.0/24 via 192.168.1.88

E service network restartgarantiu a rota estática a ser aplicada.

Depois disso, restringi o tráfegono Raspberry Piatravés do iptables. Na verdade, tornei-o permanente instalando iptables-persistente seguindoeste guia.

iptables -A FORWARD -i tun0 -s 10.8.0.0/24 -d 192.168.1.20 -j ACCEPT


Atualização nº 2

Sim, preciso de muitos clientes para poder me conectar e acho que devo evitar NAT e mascaramento por esse motivo.

Responder1

Você precisa adicionar uma rota para 10.8.0.0/24(onde estaria o gateway 192.168.1.88, ou seja, Rasp.Pio servidor OVPN) para NASou ROUTER(assumindo ROUTERque seja o gateway padrão NASnesse caso, é claro), para que NAS/ ROUTERsaiba para onde direcionar o tráfego de resposta.

Se não puder, você precisará fazer SNAT/ MASQUERADEwith iptables(ou nftables, é claro) on Rasp.Pipara que todos os tráfegos dos clientes VPN pareçam ser originados do servidor.

O cliente não deve conseguir acessar nenhuma máquina além do Raspberry e do próprio NAS.

Certifique-se de limitar o tráfego de encaminhamento com iptables. Depois de ativar o encaminhamento de IP Rasp.Pi(é necessário, caso contrário os clientes VPN não conseguirão acessar sua LAN), um cliente pode adicionar qualquer rota necessária para alcançar um determinado host na LAN do servidor, portanto, não empurrar determinado caminho não vai ajudá-lo a conseguir isso.

Atualizar:

Para ativar o encaminhamento de IP (e tornar a configuração persistente durante as inicializações):

sysctl -w net.ipv4.ip_forward=1
echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.conf

Para permitir apenas o encaminhamento necessário neste caso ( eth0e tun0são assumidos):

iptables -F FORWARD
iptables -P FORWARD DROP
iptables -A FORWARD -m conntrack --ctstate NEW -i tun0 -s 10.8.0.0/24 -o eth0 -d 192.168.1.20 -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Para fazer o NAT de origem para encaminhar tráfegos (para que você não precise configurar a rota de retorno em NAS/ ROUTER) que sai via eth0:

iptables -t nat -F POSTROUTING

(pule o acima se você tiver outras regras na cadeia que também precisa)

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

ou, se o IP eth0for persistente ao longo do tempo/inicializações:

iptables -t nat -A POSTROUTING -o eth0 -j SNAT 192.168.1.88

PS Se quiser dar flush nas mesas em que tocou, você pode fazer:

for i in $(cat /proc/net/ip_tables_names); do iptables-restore /usr/share/iptables/empty-"$i".rules; done

Observe também que iptablesos comandos não são persistentes durante a inicialização, então você desejará salvar as regras em um arquivo iptables-save(e configurar seu sistema para restaurá-las na inicialização de alguma forma).

Atualização 2:

Você realmente deveria verificar acima como configurar corretamente a FORWARDcadeia (na filtertabela). Sem a DROPpolítica (ou uma DROPregra “padrão” no final), qualquer ACCEPTregra seria inútil. (E sua regra não seria suficiente depois de consertar a DROPpeça)

Para evitar conflito de sub-rede (mais precisamente, rota), é melhor enviar uma rota de host (é o que você precisa de qualquer maneira) em vez de uma rota de sub-rede, então você deve push "route 192.168.1.20 255.255.255.255"(a máscara de sub-rede pode realmente ser omitida), pois a chance de que um host do cliente teria uma rota de host para um host LAN (diferente do gateway padrão) é muito menor (uma rota de sub-rede é sempre adicionada no Linux quando um não- /32endereço é atribuído a uma interface).

Você também pode, por exemplo, ativar push "route 10.8.1.1"o DNATdestino para o caso em que uma rota já existe em um cliente (você ainda deve poder acessar com ):192.168.1.20Rasp.Pi192.168.1.20NAS10.8.1.1

iptables -t nat -A PREROUTING -d 10.8.1.1 -j DNAT --to-destination 192.168.1.20

informação relacionada