Se requiere una solución temporal para OpenVPN: solo puede conectarse a una única IP en una red remota


0

Lo intenté esta solución pero no funcionó. Básicamente, puedo conectarme a mi red remota a través de OpenVPN, pero solo a una IP en la red. Para las conexiones basadas en servidor, empleé el reenvío de puertos a través de ssh. Esto funcionó y obtuve acceso a algunos recursos, pero aún no puedo conectarme a algunos recursos compartidos de red a los que necesito acceder.

¿Alguna idea / consejos / soluciones?

EDITAR - Aquí están las configuraciones:

cliente

dev tun
proto udp
remote remote.mydomain.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert cert.crt
key key.key
comp-lzo
verb 3

servidor

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 10.8.0.0. 255.255.255.0
ifconfig-pool-persist
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-kiey
persist-tun
status openvpn-status.log
verb 3

Debo tener en cuenta que esta configuración ha funcionado durante muchos meses. Todavía funciona (más o menos) porque puedo acceder a través del túnel VPN al servidor donde se ejecuta la VPN. Simplemente no puedo acceder a las otras IP en la red sin soluciones alternativas (este es el nuevo comportamiento).

Lo único que se me ocurre que ha cambiado es que reconfiguré un Drobo en la misma red con samba.

EDIT 2 - Aquí hay más información sobre la configuración de la red para esta situación:

Donde me siento es una red local: 192.168.5.0/24

Donde trabajo es otra red local: 192.168.1.0/24

Red VPN: 10.8.0.0/24

En la red 192.168.1.0, hay un par de servidores (uno de los cuales es el servidor OpenVPN) y un par de redes compartidas a las que necesito acceso. Mediante el reenvío de puerto ssh puedo conectarme al enrutador WRT (192.168.1.1, que tiene un puerto hacia adelante para la VPN, a través del puerto 1194) y otro servidor CRM que necesito: 192.168.1.20. La máquina que ejecuta VPN (192.168.1.10) es la única IP accesible cuando uso mi configuración VPN existente (ver arriba) que, anteriormente, funcionó bien (esto significa que tuve acceso a todas las redes compartidas, a todos los servidores, a todas las máquinas locales compartidas en la red 192.168.1.0).

Uno de los recursos compartidos de red se encuentra en 192.168.1.15. El Drobo que mencioné anteriormente se encuentra en el servidor de CRM (192.168.1.20). El Drobo solía ser un DroboShare, con su propia IP (192.168.1.16). Esto fue cambiado recientemente. Puedo montar los recursos compartidos de red que se analizan aquí en 192.168.1.10 (ya que puedo acceder a esta máquina vis ssh), así que técnicamente tengo acceso a todo lo que necesito. El problema es que es incómodo hacerlo de esta manera, especialmente porque estaba acostumbrado a una VPN que funciona como debería.

Esperemos que esta edición aclare las cosas.


¿Administras la VPN? Necesitaremos más detalles de configuración para resolver esto. Es decir, ¿se trata de una VPN enrutada, qué rutas se insertan, y se incluye la directiva de cliente a cliente? Como mínimo, se requieren estos para poder hablar entre clientes VPN.
imoatama

Sí. Config a seguir ...
nicorellius

¿Las máquinas a las que intenta acceder en la subred VPN 10.8.0.0? Si es así deberás incluir el client-to-client directiva del servidor. Si no están en la subred de VPN, están conectados al servidor a través de una LAN física con, por ejemplo, la subred 192.168.10.0, deberá agregar una push "route 192.168.10.0" Directiva a la configuración del servidor.
imoatama

Cuando dice que la configuración funcionó durante varios meses, ¿fue eso con o sin tunelización a través del servidor? Parece implicar que ni siquiera el tunelizado funciona para usted ahora para algunos servicios.
imoatama

El EDIT 2 anterior debe borrar la configuración de la (s) red (es). @ imoatama: no creo que necesite una directiva de cliente a cliente. Pero tal vez un push "route".
nicorellius

Respuestas:


1

Supongo que las otras máquinas en su red no saben cómo enrutar al rango de IP que los clientes de OpenVPN están usando (en su caso, 10.8.0.0/24). Si la casilla que ejecuta el servidor OpenVPN no es también el enrutador predeterminado, es probable que los hosts de la red envíen sus paquetes a 10.8.0.x al enrutador en lugar del servidor OpenVPN.

La solución más sencilla es agregar una ruta estática en su enrutador para 10.8.0.0/255.255.255.0 donde la puerta de enlace es la dirección IP de LAN de su servidor OpenVPN. Si eso no es posible, también puede agregar la misma ruta estática a cada servidor o host con el que los clientes necesitan hablar.

También es posible configurar OpenVPN para que funcione en modo puenteado, de modo que los clientes parezcan estar en la misma subred LAN que el servidor OpenVPN. Esto es más difícil de configurar; en Linux, necesita crear una interfaz táctil y unirla a una interfaz Ethernet.


Tus sugerencias son muy buenas. He usado el modo de puente antes. Tengo una configuración de firewall pfSense en mi red local (192.168.5.0). Terminé no usando este modo en última instancia, pero veo cómo puede funcionar esto. Mi principal problema es por qué diablos estaba funcionando y luego no, solo porque agregué un recurso compartido de red a una configuración de samba?
nicorellius

1

Dependiendo del diseño de VPN, probablemente deba incluir las siguientes directivas de configuración del servidor:

  • server
  • dev tun
  • push route <network>
  • client-to-client (Esto dependerá de la arquitectura; es necesario si todos se conectan al servidor a través de la VPN, en lugar de que el servidor esté en la misma red que algunas máquinas y otras obtienen acceso a ellas a través de la VPN)

Hay muchos lugares en los que esto podría ir mal. p.ej

  • Ninguna ruta se está empujando para las direcciones de los servidores
  • Los servidores solo están conectados a un servidor VPN a través de VPN en lugar de a una LAN física, y client-to-client no está encendido
  • Errores ocultos en OpenVPN ( ¡Ojalá no este! )

¿Puede publicar (redactado) copias de sus archivos de configuración de servidor y cliente? De lo contrario, ¿puede darnos una idea básica de la arquitectura de red?

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.