msgbartop
Hail, brothers. Coranon Silaria, Ozoo Mahoke!
msgbarbottom

29 dic 22 Uso de un servidor público y ZeroTier para publicar servicios hacia Internet desde una red con CG-NAT

Desde hace algunos días vengo experimentando problemas con mi conexión doméstica a Internet. Esto es un problema bastante molesto para mí, porque hago uso de una serie de servicios en un servidor casero que publico hacia el exterior. El principal de ellos es este sitio web, pero hay algunos adicionales, como algunos servicios de domótica y una conexión VPN para acceder de manera segura desde el exterior. Hasta ahora, venía publicándolo todo de manera directa, ya que disponía de una IPv4 con mi conexión, pero desde la semana pasada han pasado a darme acceso a Internet detrás de un CG-NAT. Esto implica que ya no dispongo de una IPv4 propia, sino que salgo a través de una NAT del operador, por lo que no es posible acceder de manera remota a dichos servicios.

Mientras me lo solucionan, he optado por poner en pie un mecanismo para poder seguir publicando servicios, basado en el uso de un pequeño servidor público que se encarga de redireccionar los servicios hacia mi sistema detrás del CG-NAT. Y para ello, hago uso de una plataforma que permite establecer redes securizadas mediante una combinación de SG-NAT y VPN, llamada ZeroTier. La gracia de ZeroTier es que el entorno funciona como un concentrador de VPNs, de tal manera que entre los clientes que necesitemos conectar se establece una red privada, con lo que es posible dotar de conectividad entre ellos a los mismos, tan sólo instalando un agente del propio ZeroTier entre ellos, y establecer la visibilidad oportuna entre nodos. Haciendo que el servidor publicado en Internet sea uno de los nodos, puedo proporcionar servicios utilizándolo de pasarela pública.

La segunda pata del asunto es conseguir este servidor frontal público, y hacer que funcione de pasarela. En mi caso, he optado por hacer uso de Oracle Cloud Infrastructure, donde se puede desplegar de manera gratuita un servidor basado en Linux. Y una vez que me he hecho con este servidor, he montado la pasarela con un servidor NGINX, debido a que me permite redireccionar tanto servicios publicados por TCP (mi servidor web y mi servidor MQTT) como UDP (mi servidor VPN), con lo que me ahorro tener que andar instalando y gestionando servicios duplicados en este frontal. Sencillo y eficiente. El diagrama general de cómo ha quedado el entorno es el siguiente:

Configuración de acceso remoto con ZeroTier y Oracle Cloud

Configuración de acceso remoto con ZeroTier y Oracle Cloud

La configuración a nivel interno sí que tiene algunos puntos a tener en cuenta:

  • El primero de ellos es relativo a la instalación de ZeroTier. Ésta es bastante sencilla, se trata de descargar el cliente VPN que proporciona el propio proveedor. A nivel Linux se instala con un simple wget desde la plataforma, y el despliegue se basa en indicarle la red privada que hemos registrado en la misma, y los propios nodos se añaden a ella. El registro en la plataforma es gratuito para redes de hasta 25 nodos, y también permite desplegar sistemas autogestionados para entornos profesionales. Una vez añadidos los nodos, es preciso darles permiso para conectarse a la red privada que hemos creado al registrarnos. Una vez hecho, podrán verse entre ellos. A nivel de sistema operativo, esta conexión aparece como una nueva IP virtual, vinculada a la conexión VPN establecida con ZeroTier. En mi caso, lo he desplegado en dos sitios: el servidor VPS que he creado en Oracle Cloud, y en el servidor que hace de frontal web para las conexiones entrantes a mis sistemas, que actúa de proxy inverso para el resto de servidores.
  • El segundo es el relativo al NGINX en el VPN de Oracle Cloud. Como comentaba, he optado por utilizar NGINX como frontal para publicar servicios. Dado que publico servicios HTTP y HTTPS, no tenía ganas de andar gestionando el tema de un proxy inverso convencional, teniendo que duplicar certificados y gestionar las redirecciones entre ellos. En este caso, he optado por realizar una simple redirección mediante el uso de la directiva stream en nginx.conf, que viene a funcionar como un balanceador de carga, estilo F5 o HAProxy. La idea es que puedes definir un servicio upstream, en el que se indica a qué dirección IP y qué puerto de tu entorno interno quieres proporcionar acceso, y luego se define un server que publica los servicios. En mi caso, en el upstream declaro la IP interna correspondiente a mi servidor doméstico proporcionada por ZeroTier (que, recordemos, es privada y accesible sólo para mi VPS), con lo que me estoy saltando las limitaciones del CG-NAT, y en el server publico los servicios. La gracia del asunto, además, es que vale para conexiones TCP y UDP. Como lo que quiero publicar es un servidor HTTPS, un servidor MQTT y un servidor VPN, todo queda de la siguiente manera:

    stream {
    upstream web_server {
    server IP_PRIVADA_REMOTA_ZEROTIER:443;
    }

    server {
    listen 443;
    ssl_preread on;
    proxy_pass web_server;
    }

    upstream mqtt_server {
    server IP_PRIVADA_REMOTA_ZEROTIER:1883;
    }
    server {
    listen 1883;
    proxy_pass mqtt_server;
    proxy_connect_timeout 1s;
    }

    upstream vpn_server {
    server IP_PRIVADA_REMOTA_ZEROTIER:1194;
    }
    server {
    listen 1194 udp;
    proxy_pass vpn_server;
    }

    }

  • El tercer punto es la redistribución de servicios en el lado del servidor doméstico. Esto es importante para mí, dado que no hago uso de un solo servidor a nivel doméstico, sino de una serie de servidores desplegados en un entorno de virtualización. Mientras que el frontal web (que es un NGINX, a su vez) y mi servidor MQTT residen en el servidor que he conectado a ZeroTier, el servidor WordPress y el servidor de VPN están en sistemas distintos. Esto implica que tengo que encargarme de redirigir las conexiones provenientes del nuevo frontal en Oracle a estos sistemas. La parte de WordPress ya la tenía resuelta, pero quedaba por solucionar la parte del servidor VPN. En este caso, como en el anterior, la idea es utilizar un stream. Siguiendo con la idea anterior:

    stream {

    upstream vpn_server {
    server IP_SERVIDOR_LOCAL_VPN:1194;
    }
    server {
    listen 1194 udp;
    proxy_pass vpn_server;
    }

    }

  • Y por último, he tenido que jugar un poco con mi servidor DNS. He creado un nuevo nombre en mi dominio eniac2000.com para el frontal VPS de Oracle Cloud, y he redireccionado los alias que uso habitualmente (www, bitacora…) hacia este nuevo nombre. Con ello, todo queda configurado de manera transparente.

En realidad, me gusta tanto cómo ha quedado configurado, que es posible que lo deje así incluso cuando se solucione el tema del CG-NAT, ya que añade una capa extra de seguridad y disponibilidad a mis sistemas.

Referencias:
How to bypass CGNAT and expose your server to the internet using ZeroTier, a VPS and NGINX
Bypassing a CGNAT with Wireguard (Especialmente útil para la parte de configuración del entorno en Oracle Cloud)
How to set nginx reverse proxy to an SSL site without certificate?

VN:F [1.9.20_1166]
Rating: 10.0/10 (2 votes cast)

Etiquetas: , , , , , , , ,

31 jul 20 Acceso a través de OpenVPN a equipos de la red local del servidor VPN

La configuración por defecto de OpenVPN permite acceder sólo al equipo servidor de VPN cuando estableces la conexión desde el cliente. Sin embargo, es posible extender el acceso al resto de equipos de la red local de dicho servidor, en caso de necesitar acceso a otras máquinas. La receta es la siguiente:

  • Configurar el servidor para que advierta al cliente de las rutas a las que puede acceder: Para que el cliente sepa que se puede conectar a más redes además de al propio servidor de VPN es preciso advertirle de ello. Se puede hacer fácilmente añadiendo la directiva “push” en el fichero de configuración del servidor. Para permitir acceso a una red de tipo 192.168.0.0/24, bastaría con lo siguiente: push “route 192.168.0.0 255.255.255.0″, y reiniciar el servicio.
  • Permitir que nuestro servidor haga forwarding de paquetes: Se habrá de modificar el fichero /etc/sysctl.conf, y quitar el comentario de la línea # net.ipv4.ip_forward=1. Posteriormente habrá que reiniciar el servicio con sudo sysctl -p.
  • Activar el enmascaramiento de paquetes en nuestro servidor: Este último paso va en función de nuestra arquitectura. Si nuestro servidor de OpenVPN no es la puerta de enlace por defecto de nuestra red, dado que las peticiones de los clientes OpenVPN llegarán al servidor de destino con una IP del tipo 10.8.0.x (o como sea que lo tengamos configurado en nuestro servidor OpenVPN), a la hora de responder a dichas peticiones, enviarán las respuestas a la puerta de enlace por defecto, con lo que se perderán las respuestas, ya que la puerta de enlace por defecto no tendrá constancia de la emisión de las mismas (enrutado asimétrico), y éstas no llegarán al cliente OpenVPN (este problema no se daría con el servidor OpenVPN actuando como puerta de enlace, ya que tendría constancia de los paquetes, y podría enrutarlos adecuadamente). Para evitar el problema, es posible activar el enmascaramiento de paquetes. Bastaría con añadir la siguiente regla a nuestro iptables: iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE… siempre que la interfaz de la red sea la eth0, y que nuestra red de clientes OpenVPN sea la 10.8.0.0/24 (si no, hay que modificar estos valores según correspondan). Para hacer que la configuración sea persistente, recomiendo usar el servicio iptables-persistent, existente en Debian y otras distribuciones.

Referencias:

VN:F [1.9.20_1166]
Rating: 10.0/10 (3 votes cast)

Etiquetas: , , , ,