¿Cómo puedo llegar a una única máquina local a través de OpenVPN?

Question

Parece una pregunta trivial, pero todavía no pude encontrar la respuesta.

En mi LAN (azul en la imagen) tengo un NAS y una Raspberry Pi, entre otras máquinas. Instalé un servidor OpenVPN en Raspberry Pi. Quiero que el cliente OpenVPN pueda acceder al NAS, es decir, FTP, HTTP, etc. El cliente no debe poder acceder a ninguna máquina que no sea Raspberry y el propio NAS.

En esta imagen tenéis la topología de mis redes:

Puedo conectar el cliente OpenVPN a su servidor. Sé que tengo un conflicto de subred pero no puedo cambiar las subredes.

Configuración de mi 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

Mi archivo de configuración de 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

Puedo conectarme usando el cliente de Windows, pero no puedo hacer ping ni acceder de todos modos al NAS. Estoy seguro de que todavía me falta algo, pero no puedo encontrar la manera de dirigir el tráfico. He leído muchos temas sobre el tema, pero aún no he tenido suerte.

Debería poder agregar una regla de enrutamiento en el enrutador que se encuentra en la red del servidor OpenVPN, si es necesario.

Actualización 18/11/2019 a las 17:31 CET

Tengo dos requisitos principales:

1. Necesito que el cliente llegue al NAS, pero no a las otras máquinas de la LAN;
2. Necesito que el cliente pueda conectarse incluso cuando su subred entre en conflicto con la subred del NAS (es decir, 192.168.1.0/24).

Tom Yan yEste artículoMe ayudó a encontrar una solución al primer problema. Creo que la segunda cuestión aún está descubierta.

Solución al problema n.° 1:

En la configuración del servidor, necesitaba agregar (descomentar) esta línea para garantizar el enrutamiento de las solicitudes desde el cliente OpenVPN al NAS:

push "route 192.168.1.0 255.255.255.0"

Para habilitar el enrutamiento desde el NAS al cliente OpenVPN, agregué esta regla de enrutamientoen la NAS:

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

agregando esta línea en ese archivo de configuración (vacío)

10.8.0.0/24 via 192.168.1.88

Y service network restartaseguró la ruta estática a aplicar.

Después de eso, restringí el tráfico.en la frambuesa pia través de iptables. De hecho, lo hice permanente instalando iptables-persistenty siguiendoesta guía.

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

Actualización #2

Sí, necesito muchos clientes para poder conectarme y supongo que debería evitar NAT y el enmascaramiento por este motivo.

Answer 1

Debe agregar una ruta para 10.8.0.0/24(donde estaría la puerta de enlace 192.168.1.88, es decir, Rasp.Piel servidor OVPN) a NASo ROUTER(asumiendo que ROUTERes la puerta de enlace predeterminada NASen ese caso, por supuesto), para que NAS/ ROUTERsepa hacia dónde dirigir los tráficos de respuesta.

Si no puede, deberá hacer SNAT/ MASQUERADEwith iptables(o nftables, por supuesto) on Rasp.Pipara que todo el tráfico de los clientes VPN parezca originarse en el servidor.

El cliente no debe poder acceder a ninguna máquina que no sea la Raspberry y el propio NAS.

Asegúrese de limitar el tráfico de reenvío con iptables. Una vez que haya habilitado el reenvío de IP Rasp.Pi(debe hacerlo; de lo contrario, los clientes VPN no podrán llegar a su LAN), un cliente puede agregar cualquier ruta que necesite para llegar a un determinado host en la LAN del servidor, así que simplemente no Impulsar cierta ruta no te ayudará a lograrlo.

Actualizar:

Para habilitar el reenvío de IP (y hacer que la configuración sea persistente durante el arranque):

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

Para permitir solo el reenvío que necesita en este caso ( eth0y tun0se supone):

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 hacer NAT de origen para reenviar tráficos (para que no tenga que configurar la ruta de retorno en NAS/ ROUTER) que sale a través de eth0:

iptables -t nat -F POSTROUTING

(omita lo anterior si tiene otras reglas en la cadena que también necesita)

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

o, si la IP de eth0es persistente en el tiempo/arrancas:

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

PD: Si quieres limpiar las mesas que tocaste, puedes hacer:

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

También tenga en cuenta que iptableslos comandos no son persistentes durante el arranque, por lo que querrá guardar las reglas en un archivo iptables-save(y configurar su sistema para restaurarlas al arrancar de alguna manera).

Actualización 2:

Realmente deberías consultar lo anterior para saber cómo configurar correctamente la FORWARDcadena (en la filtertabla). Sin la DROPpolítica (o una regla "predeterminada" DROPal final), cualquier ACCEPTregla sería inútil. (Y tu regla no sería suficiente una vez que arregles la DROPpieza)

Para evitar conflictos de subred (más precisamente, ruta), es mejor impulsar una ruta de host (es lo que necesita de todos modos) en lugar de una ruta de subred, por lo que debería hacerlo push "route 192.168.1.20 255.255.255.255"(la máscara de subred en realidad se puede omitir), ya que la posibilidad de que un El host del cliente tendría una ruta de host a un host de LAN (que no sea la puerta de enlace predeterminada) es mucho más baja (siempre se agrega una ruta de subred en Linux cuando /32se asigna una dirección sin dirección a una interfaz).

También puede, por ejemplo, activar push "route 10.8.1.1"el DNATdestino en el caso de esquina donde ya existe una ruta en un cliente (entonces aún debería poder acceder con ):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