Uso del Mini Smart Router GL-AR300M con Openvpn
Uso del GL-ar200M como puerta de acceso mediante OpenVPN
Se describe cómo configurar el router principalmente para su uso como vía de acceso seguro a dispositivos ubicados en una LAN.
1. Generalidades sobre el router
Está ideado para un uso equivalente al router habitual que en oficinas y casas proporciona acceso a internet, pero con la posibilidad de añadir una conexión VPN, que puede ser configurada para enrutar todo el tráfico externo de la LAN conectada al dispositivo.
La interfaz de configuración y su configuración en general estan pensadas para ello. Pero el sistema operativo es OpenWrt, que proporciona las capacidades de un router en toda su extensión (si bien para ello hay que recurrir a realizar algunos detalles de configuración vía SSH), por lo que puede ser utilizado también para acceder desde fuera a los dispositivos conectados a su LAN, obviamente a traves de la VPN y, por tanto, de forma segura y solo desde orígenes autorizados.
1.1. Conexiones ethernet
Tiene dos puertos ethernet: LAN y WAN. El primero es para sus clientes, el segundo para su acceso a internet. En algunos casos, como en una oficina, ambos irían conectados a la misma red; en otros, como el del cuadro eléctrico de una instalación, el WAN iría conectado a la red de la fábrica y el LAN al switch del cuadro, donde los dispositivos existentes lo usarían para su conexión a internet.
1.2. Botón conmutador.
Por defecto, no tiene asignada ninguna función. Se puede configurar para activar/desactivar la VPN o para conmutar el AP de la Wifi entre modo bridge y modo router. En el primer modo, el AP actúa como repetidor de la Wifi a la que está conectado; en el segundo, habilita su propia subred y servidor DHCP.
2. Configuración general
Por defecto, la IP LAN es 192.168.8.1 y el acceso Wifi está desactivado, así es que para configurarlo hay que conectarse mediante cable a dicho puerto y apuntar a la IP con un navegador. La contraseña por defecto es goodlife.
La interfaz web es confusa, porque la IP del puerto LAN se asigna en el apartado de configuración Wireless. Y también porque la configuración del puerto WAN se hace en el apartado llamado Internet, que no está etiquetado ni como tal ni como WLAN: en la configuración de fábrica solo aparece el icono de globo terráqueo.
Por otro lado, y es IMPORTANTE, intentar modificar las cosas vía Advanced Settings de la ifaz web es, teóricamente, posible, pero resulta una mierda pq deja al router jodido y tienes que restaurar la config de fábrica.
Afortunadamente, tenemos la vía SSH.
2.1. Acceso SSH
Se accede como usuario root, con la misma contraseña utilizada en la interfaz web.
OpenWrt usa UCI para su configuración, ubicando en /etc/config los ficheros de configuración UCI. La doc sobre UCI está en http://wiki.openwrt.org/doc/uci.
2.2. Preservar configuraciones en actualizaciones de firmware
En /etc/sysupgrade.conf se pueden registrar paths a ficheros o directorios que quieren conservarse tras actualizaciones de firmware. Inicialmente nada se mantiene tras actualizaciones de firmware, porque el fichero solo contiene un par de ejemplos comentados. Este es un ejemplo de lo que añadimos:
# Added by rele conf script # /etc/config/firewall /etc/openvpn/ /etc/rc.local /etc/hotplug.d/tty/ttyUSB /root/.profile /root/firewall.include
2.3. Cuidado con /var
lrwxrwxrwx 1 root root 4 Apr 10 06:12 var -> /tmp/
... cada reboot se pierde.
2.4. opkg
Es el sistema de paquetes de OpenWrt. Resumen:
opkg update opkg list | grep <algo> opkg install <paquete>
Es de máxima importancia recordar que la lista de paquetes que se obtiene con opkg update, al menos en este router, va a /var/opkg-lists, con lo que se pierde cada vez que se reinicia, puesto que /var es un symlink de /tmp.
3. DHCP
El router viene configurado como servidor DHCP para su conexión LAN. Cuando no se utiliza este servicio, según la situación puede no importar o puede que sí porque ya exista otro servidor DHCP. Sin embargo, la configuración web no permite deshabilitar el servidor DHCP (ni siquiera vía Advanced Settings): hay que hacerlo a traves de SSH:
Editando /etc/config/dhcp, al bloque config dhcp 'lan' se le añade:
option ignore '1'
y, tras ello, se ejecuta: /etc/init.d/dnsmasq restart.
4. Configuración OpenVPN
Se realiza cargando un fichero de configuración .ovpn y, en su caso, ficheros adicionales. Si los hay, han de ir empaquetados con el de configuración en un .zip o .tar.gz. Se puede configurar para que el tráfico generado dentro de la LAN se canalice completamente a través de la VPN. El procedimiento se describe en la documentación del fabricante
Para lo relativo al fichero de configuración VPN se puede ver la documentación de OpenVPN, y también esta chuleta.
4.1. Acceso a LAN a traves de la VPN
La documentación OpenVPN para la conexión de subredes externas de clientes a través de la VPN se encuentra aquí.
Pero no es suficiente, porque la configuración normal del mini-router prepara un escenario en que los dispositivos conectados a su LAN pueden salir al exterior a traves de la VPN, pero dispositivos en el exterior no pueden acceder a los del interior de la LAN porque las reglas del firewall no lo permiten.
4.1.1. Firewall
Una vez configurada la VPN y realizada la conexión con éxito, un ping desde otro nodo de la VPN a un nodo de la LAN del mini-router devuelve:
From 10.x.x.5 icmp_seq=1 Destination Port Unreachable
Es un mensaje definido en el protocolo ICMP, para uso desde hosts de destino (cuando el puerto de destino no es alcanzable o no hay un proceso escuchando en él), pero no para su uso por routers. Sin embargo, la extensión REJECT de iptables añade ese target con igual resultado que el DROP nativo, pero enviando además un mensaje ICMP con ese error: Destination Port Unreachable.
Tirando de SSH, el análisis de la configuración de iptables (musho mehó con iptables -S que con iptables-save) revela que, tal como queda establecida por la configuración web, el FORWARD viene con target REJECT y no hay ninguna otra regla para zona vpn que autorice el tráfico vpn -> lan. De ahí el mensaje Destination Port Unreachable, procedente de esa regla con target REJECT.
Para resolverlo, no se puede editar /etc/config/firewall y añadir configuración para la zona VPN_client, que es como se harían normalmente los temas de firewall. Sin embargo, al menos en el mini-router de GL.inet ,esto no vale porque cada vez que se arranca la vpn todas las configuraciones relativas a la zona VPN_client se eliminan, incluídas las que se hayan podido introducir manualmente, y se crean de nuevo según establecen los scripts /etc/init.d/startvpn y /usr/bin/setvpnfirewall.
La solución es:
- todas las zonas creadas por fw3 comienzan por una regla que envía los paquetes a una cadena de usuario que se define pero a la que no se añade ninguna regla. Esa cadena se denomina <input|output|forwarding>_<zona>_rule, por lo que la que nos interesa es forwarding_VPN_client_rule. Si añadimos a esta cadena una regla tal que -A forwarding_VPN_client_rule -i tun0 -j ACCEPT , los paquetes pasan a la zona LAN sin problemas.
- Ahora solo es necesario un modo adecuado de añadir las reglas necesarias. Y ese es el mecanismo include de UCI, mediante el que podemos hacer que se ejecute un guión shell cada vez que /etc/init.d/firewall procesa /etc/config/firewall
Es decir, en /etc/config/firewall se añade:
config include
option path '/root/firewall.include'
option type 'script'
... y en /root/firewall.include tenemos:
!/bin/sh # permitir ssh en puerto WAN: esta detras del router ADSL iptables -A input_wan_rule -p tcp --dport 22 -j ACCEPT # aceptar paso de paquetes a lan desde subred especifica de VPN iptables -A forwarding_VPN_client_rule -s 10.202.100.0/24 -d 192.168.10.0/24 -j ACCEPT
4.1.2. Enrutado externo.
Cuando los dispositivos conectados a la LAN del mini-router no utilizan DHCP, sino direccionamiento estático, puede que no tengan establecido el gateway en su configuración IP, dado que a veces la conexión con ellos se hace siempre de forma directa, dentro de la misma subred. En este caso, es imprescindible para el acceso a ellos vía mini-router que éste figure como gateway, para que los paquetes de salida de los dispositivos encuentren el camino a hosts que no estan en la misma subred.
En otras configuraciones, si hay otros routers envueltos en la topología de red, también puede ser necesaria la intervención a nivel de enrutado, estableciendo rutas que aseguren la correcta salida de los paquetes a traves de la VPN, pues el cliente OpenVPN se ocupa de establecer las rutas adecuadas en la máquina conectada a la VPN, pero cómo hacer que los paquetes de otras lleguen a ella es responsabilidad nuestra.
4.1.3. Control de acceso. Aislamiento de subredes
Se puede lograr el encapsulamiento de subredes controlando quién tiene acceso a qué mediante una combinación de configuración OpenVPN y reglas de firewall. La configuración OpenVPN se encarga de asignar IPs fijas para identificar los usuarios mediante la IP asignada (y a grupos de usuarios mediante el rango de la IP), el firewall de cada cliente VPN que actúe como gateway se encarga de restringir el paso de paquetes de manera que usuarios no autorizados a acceder a un recurso no puedan hacerlo.
5. Uso como puente ethernet <-> serial
Un posible uso es la canalización de una conexión serie a través de ethernet. Se enumeran los puntos a resolver.
Importante tener en cuenta que, inicialmente, el mini router no dispone de lista de paquetes opkg y que una vez obtenida no se conserva tras apagado o reiniciado, así es que siempre, antes de trabajar con paquetes, opkg update.
5.1. Instalación de driver para conversor usb<->serie en el mini-router.
Una cantidad de ellos estan disponibles mediante opkg: opkg list | grep ^kmod-usb-serial-. La cuestión es averiguar qué driver es necesario para un dispositivo determinado. A menudo, ni siquiera se encuentra documentación del fabricante: una posibilidad es pinchar el dispositivo en una máquina güin y, a través del administrador de dispositivos, con la información del driver, tratar de identificar su equivalente en el mini-router.
Una vez instalado el driver y el dispositivo conectado, ls /dev/ttyUSB* debe mostrar algúna entrada. Si no lo hace, es posible que el paquete del driver no tenga incluído el identificador del dispositivo como uno de los gestionados por él, lo que se puede remediar:
Necesitamos conocer el identificador usb del dispositivo, compuesto por idVendor + idProduct y que se puede averiguar mediante lsusb, que no está instalado por defecto en el mini router:
opkg install usbutils lsusb # y, con el nº de bus e id observado en la lista: lsusb -v -s <bus>:<id> # muestra toda la información del dispositivo
Con esa info y el nombre del driver, se puede registrar el dispositivo en el driver para que sea reconocido.
Un ejemplo son los productos de Brainboxes. Uno de ellos arroja idVendor 0x05d1 e idProduct 0x1017 y sabemos que utiliza driver ftdi, pero no es reconocido al pincharlo en el mini-router (no aparece con ls /dev/ttyUSB*). Necesitamos ejecutar lo siguiente:
echo 05d1 1017 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id
... y el dispositivo es reconocido y aparece su entrada en /etc/dev (nótese que la numeración se escribe en hexadecimal, pero sin prefijo/sufijo especial). Obviamente, hay que incluir esa instrucción en algún guión shell que se ejecute cada vez que se arranca el mini-router (¿//etc/rc.local/?).
5.2. Uso de socat para enlazar ethernet y serial en el mini-router.
Como socat no está instalado de fábrica, hay que instalar a mano:
opkg update; opkg install socat
Una buena manera de automatizar el enlace es colocar un guión shell en /etc/htoplug.d/tty. Este es uno utilizando socat:
!/bin/sh
# /etc/hotplug.d/tty/ttyUSB
#
# lanza puente de enlace socat eth<->ttyUSBx al conectar conversor
# usb-serial y lo para al desconectar
#
# hay dispositivos, como los modems WAN que tambien instalan devices
# usb-serial: para descartarlos, se utiliza numero de interfaces del
# dispositivo raiz: si es mayor de 1, como suele serlo en dichos modems,
# se descarta y no se lanca el puento socat
PIDFILE=/tmp/pidof-tcpttybridge-$DEVICENAME
TRACEFILE=/tmp/traceof-tcpttybridge-$DEVICENAME
# root device path
ROOTDEVPATH='/sys'${DEVPATH%1-1:*}
if test $SUBSYSTEM == "usb-serial" -a ${DEVICENAME:0:6} == "ttyUSB"; then
echo "$DEVICENAME - $ACTION" > $TRACEFILE
echo $ROOTDEVPATH >> $TRACEFILE
echo Environment: >> $TRACEFILE
env >> $TRACEFILE
# num of interfaces (WAN modems usually have more than one)
ROOTNUMIFACES=cat $ROOTDEVPATH/bNumInterfaces
ROOTNUMIFACES=${ROOTNUMIFACES }
test -n $ROOTNUMIFACES && echo "bNumInterfaces.....: $ROOTNUMIFACES" >> $TRACEFILE
case $ACTION in
"add")
if test $ROOTNUMIFACES -eq 1; then
echo "Single root usb-serial device named $DEVICENAME" >> $TRACEFILE
# Los temas de baudios, paridad, datos y stop habra que configurarlos especificamente
# en cada sitio. Las opciones son:
# - cfmakeraw, imprescindible para que no interprete chars y lo pase to
# - b9600,b19200,b38400,b57200,115200,230400,...
# - parenb=<bool>, habilita paridad
# - parodd=<bool>, 1=odd, 0=even
# o sea, nopar: parenb=0; par: parenb=1,parodd=0; impar: parenb=1,parodd=1
# - cs7,cs8, data bits
# - cstopb=<bool>, stop bits
socat TCP-LISTEN:4321,bind=10.202.100.10,reuseaddr,fork dev$DEVICENAME,cfmakeraw,b19200,parenb=1,parodd=1,cs8,cstopb=1 2>>$TRACEFILE &
echo $! >$PIDFILE
fi
;;
"remove")
if test -e $PIDFILE; then
echo "Killing process for $DEVICENAME" >> $TRACEFLE
kill -SIGQUIT $( cat $PIDFILE )
rm $PIDFILE
fi
;;
esac
fi
5.3. Enlazado serie <-> ethernet en máquina güin de usuario
Hemos realizado pruebas satisfactorias con com0com, que proporciona puertos serie virtuales emparejados y com2tcp (mismo repositorio), que puede conectar uno de ellos a una conexión de red, dejando el otro libre para que lo utilice la aplicación de usuario y constituyendo así un puente serial-ethernet.
CUIDADO: com2tcp parece cerrar conexión con EOF: si es así, habrá que modificarlo: tiene que tragarse cualquier cosa binaria que llegue por el COM, y terminar solo cuando se le mate.