☰

¿Cómo hacer que el servidor OpenVPN reenvíe paquetes tun0 a la red local?

tag-icon • tag-icon networking vpn openvpn freebsd
¿Cómo hacer que el servidor OpenVPN reenvíe paquetes tun0 a la red local?

Tengo tres máquinas que intento coordinar a través de una conexión TUN.

FREEBSDcuadro que ejecuta el servidor OpenVPN (tun)
10.0.200.21/24 en la subred local
10.0.202.1/24 en VPN

REMOTE
IP pública
10.0.202.6/24 en VPN

WEBSERVER
10.0.200.31/24 en subred local

Puedo acceder REMOTEa VPN FREEBSDa través de OpenVPN y la conexión está bien, pero está configurada incorrectamente. Cuando intento conectarme desde REMOTEa WEBSERVERescribiendo WEBSERVERla dirección IP de en REMOTEel navegador, WEBSERVERno puedo acceder. Es accesible si lo conecto REMOTEdirectamente a la subred local.

Aprendí lo siguiente mientras solucionaba problemas.

  • REMOTEpuede hacer ping FREEBSDe incluso SSH.
  • Una captura de paquetes configurada en FREEBSDel puerto Ethernet de no captura paquetes desde o hacia REMOTEla IP VPN de 10.0.202.6. Entonces los paquetes de REMOTE no llegan a la subred local.
  • Elopenvpn.logarchivo en FREEBSDtiene la siguiente línea:GET INST BY VIRT: 10.0.200.31 [failed]

Entonces, parece que OpenVPN no reenvía los paquetes recibidos en el dispositivo TUN al FREEBSDadaptador Ethernet de ni a la subred local.

Tengo la siguiente línea en mi archivo server.conf.
push "route 10.0.200.0 255.255.255.0"

Intenté agregar esta línea pero no ayudó.
route 10.0.200.0 255.255.255.0


Aquí está la tabla de enrutamiento enFREEBSD

Tablas de enrutamiento

Internet:
Destino Puerta de enlace Banderas Refs Usar Netif Caducar
predeterminado 10.0.200.1 UGS 0 4306 re0
10.0.200.0 enlace#9 U 0 61582 re0
10.0.200.21 enlace#9 UHS 0 41 lo0
10.0.201.0 10.0.200.1 UGS 0 0 re0
10.0.202.0 10.0.202.2 UGS 0 0 tun0
10.0.202.1 enlace#12 UHS 0 0 lo0
10.0.202.2 enlace#12 UH 0 0 tun0
enlace de host local#11 UH 0 193743 lo0


Leí en línea sobre el GET INST BY VIRT: 10.0.200.31 [failed]mensaje y se recomendó que las máquinas Linux ejecutaran el siguiente comando.
echo 1 > /proc/sys/net/ipv4/ip_forward
Tengo miedo de ejecutarlo porque no lo entiendo y no quiero entrar FREEBSDen una configuración extraña. También prefiero una solución que modifique el archivo server.conf para crear automáticamente la configuración necesaria para que se administre y elimine adecuadamente cuando se cierre OpenVPN.

¿Cuál es la solución a este problema?

Respuesta1

Encontré el problema. Resulta que FreeNAS, el software del dispositivo NAS basado en FreeBSD y al que me refiero anteriormente FREEBSD, tiene el net.inet.ip.forwardingvalor 0. Esto se puede ver usando el comando sysctl -a | grep net.inet.ip.forwarding. Para poder reenviar los paquetes, tuve que hacer un archivo sysctl net.inet.ip.forwarding=1.

Este cambio no persiste durante los reinicios. Creo que tendré que usar el archivo /etc/rc.conf y configurarlo gateway_enable="YES", pero hasta ahora he descubierto que esta configuración no se procesa hasta el reinicio y, desafortunadamente, en FreeNAS, rc.conf parece sobrescribirse en cada reinicio. Es posible escribir esta variable en /etc/defaults/rc.conf, que se supone que almacena los valores predeterminados para el sistema y se sobrescribe con configuraciones personalizadas en rc.conf, pero /etc/defaults/rc.conf El archivo tiene una advertencia en la parte superior para no editarlo.

Entonces, este problema no está totalmente resuelto, pero al menos he descubierto cuáles parecen ser los problemas. Ahora que entiendo esto, noto un problema al iniciar sesión en dispositivos de administración web https en la subred local. Ése será otro problema a resolver.

Respuesta2

Bien, entonces su cliente VPN tiene una ruta para llegar a la 10.0.200.0/24red y su servidor VPN tiene una ruta. Pero la pregunta es: ¿su servidor web 10.0.200.31tiene una ruta para llegar a la 10.0.202.0/24red?

Haga un tcpdump en el cuadro freebsd. Sospecho que verá 10.0.202.6que se reenvía el tráfico de su host, pero no verá ningún tráfico de retorno.

información relacionada