DEV Community: Federico Jensen

Comprendiendo cómo funciona OpenVPN y configurar un Split Tunnel basado en usuarios (NixOS)

Federico Jensen — Sun, 06 Jul 2025 21:14:30 +0000

Ninguna IA ha estado involucrada en la creación de este artículo.

Introducción

En este artículo veremos, detalladamente, como OpenVPN manipula el networking de nuestro Linux para lograr la "magia" que conocemos como Full Tunnel (conexión VPN típica). Luego hablaremos sobre los peligros del DNS Leak y como solucionarlo. Finalmente revisaremos como podemos usar iproute2 para lograr tener un Split Tunnel basado en una división de trafico dado el usuario (UID) que genere el trafico.

Este artículo es extenso y detallado, no asume grandes conocimientos previos; y esta redactado en una forma secuencial, aclaratoria y reflexiva. O sea, si estas con prisa, aquí no encontraras un código para "copiar y pegar"; esto mas bien es una exploración profunda del funcionamiento de redes, Linux y los VPNs.

A considerar, en este artículo:

No se asumen conocimientos avanzados de redes, por tanto, pasamos bastante tiempo explicando de manera sencilla y prolongada determinados términos que ya podrías conocer perfectamente.
Uso la distribución de Linux conocida como NixOS. Si usan otra distribución este artículo puede ser igualmente útil, pero seguramente deberán adaptar los ejemplos.
No se usa el firewall (iptables/nftables) para lograr el Split Tunnel, solo iproute2.
Usare como proveedor de VPN (servidor), los servicios de pago de AirVPN (no he recibido compensación económica de ellos para este post). Es muy poco probable, pero si usan otro servidor VPN, podrían tener que adaptar algunos de mis ejemplos a su situación particular.

Vamos a ello!

Contexto

Generalmente al usar OpenVPN, como cliente de VPN, nuestra red se configurara de forma automática para que todo el trafico sea cifrado y enviado por un "túnel". Este túnel es un concepto abstracto y que, aunque es una buena analogía, entender realmente cómo funciona puede ser mas complejo.

La "entrada al túnel" sera nuestro computador y la "salida del túnel" algún lugar perteneciente al servidor VPN donde nos estemos conectado. Realmente la "entrada al túnel" es mas que una interfaz de red virtual configurada con una serie de reglas de ruteo, que canalizan la gran mayoría de nuestras conexiones salientes para que sean cifradas hasta una locación remota. Esa locación remota, "la salida del túnel", es un servidor VPN que toma dichos conexiones salientes y las direcciona a internet. Luego las respuestas de internet retornan al servidor VPN y este realiza el proceso inverso hasta nuestro equipo.

De esta manera, "ante el mundo", nosotros estamos donde esta el servidor VPN y no en en nuestra locación real. Adicionalmente, a ojos del ISP (empresa que nos provee de internet) el trafico esta totalmente ofuscado, siendo imposible que puedan rastrear realmente el contenido de los datos transferidos, como tampoco su destino (ojo, esto solo si tenemos todo bien configurado... vamos a ver algo que se llama DNS Leak, que puede "romper" parte del anonimato).

Este caso que he expuesto es el mas común, desear que todo el trafico del equipo use el túnel; esto se denomina Full Tunnel. Esta configuración es la que generalmente se aplica de forma automática por OpenVPN u cualquier otro cliente de VPN. Pero existe otro tipo de implementación un cliente de VPN, la de Split Tunnel.

En Split Tunnel dividimos el trafico siguiendo una o varias reglas. Si la regla se cumple, el trafico usará el túnel; y en caso que no, el trafico saldrá de alguna otra forma a internet. Esta "otra forma" puede ser directamente a internet (como normalmente), o también, podría ser algun otro túnel paralelo administrado por otro cliente de VPN.

Las "reglas" que definen como dividimos el trafico pueden ser variadas. En este artículo nos centraremos específicamente en una división basada en UID (IDs de usuarios de Linux). O sea, que solo el trafico generado por un usuario especifico sea enrutado por el túnel, el resto que salga a internet de forma directa.

Dependiendo de la complejidad de las "reglas", la forma de implementarlas puede recurrir pequeñas o grandes manipulaciones de nuestro networking. En esta guiá veremos que solo usando las tablas de ruteo y sus regla se puede lograr el Split Tunnel. No usaremos módulos de firewall como iptables o nftables; algo que podría ser necesario si las reglas que deseamos aplicar para la división de trafico fueran mas complejas que solo UIDs.

Durante las ultimas semanas he estado implementado una configuración de Split Tunnel para lograr tener funcionando, en paralelo, OpenVPN y Tailscale. En este proceso he aprendido bastante sobre que sucede en nuestro sistema, a nivel de redes, cuando estos clientes se auto-configuran. En este artículo espero aclarar dudas de lo que realmente sucede en nuestro networking.

En el próximo artículo podrán encontrar las siguientes secciones:

Examinación profunda de como OpenVPN configura de forma automática nuestro networking para darnos un Full Tunnel.
Sobre DNS, OpenVPN, el peligro del DNS Leak y como arreglarlo.
Proceso para desactivar las configuraciones automáticas de OpenVPN, dándonos la oportunidad de manualmente definir el networking del túnel.
Paso a paso de los comandos necesarias para lograr tener un Split Tunnel con OpenVPN basado en UID. Con una explicación clara de las configuraciones de networking creadas y de los métodos para probar su correcto funcionamiento.
Uso de un Script para automatizar los procesos de generar un Split Tunnel en nuestro NixOS.

Si ustedes quieren ir directamente al tema del Split Tunnel, pueden ignorar la parte 1 y 2 del artículo.

Por ultimo recordar que estaré usando NixOS, mi distribución de Linux favorita para Home Servers. Pero en general, todo la información presentada en este artículo debería ser fácilmente "traducible" a otras distribuciones siempre que estas usen iproute2 para la gestión del networking y systemd para la gestión de servicios.

Explorando la configuración por defecto de OpenVPN y el Full Tunnel

El cliente de OpenVPN es bastante flexible en su funcionamiento. Esto quiere decir que realmente la manera en la cual establece su conexión con el servidor VPN y la forma el la cual manipule nuestro networking para crear el túnel es variada. Esta se ajustara a: 1) lo especificado en el .ovpn (archivo de configuración de la conexión OpenVPN) y 2) las configuraciones remotas que el servidor VPN "inyecte" en nuestro equipo (ya veremos mas de esto...).

Nosotros nos pondremos en una situación "convencional", donde el servidor VPN al cual nos estamos conectados pertenece a un proveedor de pago. En mi caso siempre he usado AirVPN, así que este artículo basará sus puntos en el uso de este servicio. De todos modos, independiente de lo anterior, en general no deberían encontrar gran diferencia si usan otro proveedor... siempre y cuando permita el uso del cliente OpenVPN, claro.

Instalando y configurando OpenVPN

OpenVPN solo necesita del archivo .ovpn para funcionar. Este archivo contiene toda la información de lo que debe hacer OpenVPN para: conectarse, autentificarse y establecer el túnel con el servidor VPN. En mi caso ya he generado el archivo .ovpn desde la interfaz web de AirVPN. Y lo he guardado en /etc/nixos/airvpn.ovpn. Su contenido se ve así:


client
dev tun
remote america3.vpn.airdns.org 443
resolv-retry infinite
nobind
persist-key
persist-tun
auth-nocache
verb 3
explicit-exit-notify 5
push-peer-info
setenv UV_IPV6 yes
remote-cert-tls server
comp-lzo no
data-ciphers AES-256-GCM:AES-256-CBC:AES-192-GCM:AES-192-CBC:AES-128-GCM:AES-128-CBC
data-ciphers-fallback AES-256-CBC
proto udp
auth SHA512
...
<...certificados...>
...

Nota 1: He omitido mostrar los certificados contenidos en mi .ovpn... claramente.

Nota 2: Puede ser buena idea comparar su .ovpn con el mio. Si ven que su cliente OpenVPN no se comporta como yo explico a continuación, seguramente son diferencias en lo declarado en este archivo de configuración.

Por otro lado, he instalado OpenVPN en mi NixOS modificando el configuration.nix y he usado el nombre airVPN como nombre de la instancia de OpenVPN.

...
services.openvpn = {
  servers = {
    airVPN = {
      config = "config /etc/nixos/airvpn.ovpn"; 
    };
  };
};
...

Pueden ver que simplemente estoy pasando la ruta del .ovpn al parámetro config. NixOS se encargará, automáticamente, de crear un servicio (administrado por systemd) para iniciar y conectar OpenVPN al servidor VPN indicado en el .ovpn durante el inicio del sistema. El servicio llevará por nombre uno asignado por NixOS; en mi caso el servicio ha quedado con el nombre: openvpn-airVPN.service.

Con todo eso listo, se puede usar el comando sudo nixos-rebuild switch para crear una nueva generación de NixOS. Posterior a un reinicio del sistema, al usar systemctl status openvpn-airVPN.service vamos a poder confirmar que OpenVPN esta andando correctamente.

Si entramos a una web para ver nuestra IP, verán que, a los ojos del mundo, estamos en una locación remota y adicionalmente no existirá datos de nuestra ISP:

Por ultimo, podemos hacer una prueba desde la terminal y deberían ver un resultado muy similar:

curl https://ipv4.ipleak.net/json/

OpenVPN esta funcionando perfectamente en modo Full Tunnel :)

Analizando lo que ha manipulado OpenVPN durante su inicio en un escenario de funcionamiento "normal"

¿Que ha "tocado" OpenVPN para darnos acceso a internet "mágicamente" al otro lado del mundo?. Una forma fácil de investigar esto es usar el comando journalctl -b | grep 'openvpn'. Con este vamos a ver los logs de OpenVPN emitidos desde el ultimo inicio del sistema.

Estos logs muestran cosas... muchas cosas... pero para entenderlo solo nos enfocaremos en lo principal. De manera secuencial iremos revisando los logs y haciendo coherencia de que esta pasando en nuestro equipo. Vamos a ello.

Nota: Solo muestro los segmentos de logs mas relevantes para nuestro análisis.

1) Inicia nuestro OpenVPN en la versión 2.6.14 usando OpenSSL 3.4.1.

openvpn[945]: OpenVPN 2.6.14...
openvpn[945]: library versions: OpenSSL 3.4.1...

2) Primero OpenVPN debe establecer comunicación con el servidor VPN. Para eso usa la información indicada en la directriz remote del .ovpn. Generalmente aquí esta la IP del servidor VPN, en mi caso es un hostname (otra opción valida). Así que primero OpenVPN usará la red normal (y el DNS que tengamos configurado en nuestro equipo) para resolver el dominio. Luego de un par de intentos, mi OpenVPN logra resolver el hostname en la IP 184.75.223.237:443. Esta es la ip:port donde AirVPN me esta "ofreciendo" un servidor VPN y es el lugar con el cual el cliente OpenVPN va a intentar establecer comunicación.

openvpn[945]: RESOLVE: Cannot resolve host address: america3.vpn.airdns.org:443...
openvpn[945]: Restart pause, 1 second(s)
...
openvpn[945]: UDPv4 link remote: [AF_INET]184.75.223.237:443

Nosotros denominaremos a 184.75.223.237:443 como: la dirección pública del peer/servidor VPN remoto.

3) OpenVPN realiza una prueba de nuestras interfaces de red y busca "como" salir a internet. Si notamos la linea net_route_v4_best_gw veremos que OpenVPN ha decidido usar mi interfaz enp0s3, con la gateway asociada 192.168.1.1, para alcanzar internet. Luego de esto, OpenVPN procede a autentificarse con el peer remoto usando los certificados encontrados en el .ovpn. Finalmente OpenVPN se ha conectado de forma exitosa y segura con el servidor VPN de AirVPN.

Importante de identificar en este segmento: mi interfaz ethernet, con la cual tengo internet en mi servidor, tiene por nombre enp0s3. Y esta pertenece, como es de esperar, a una red local privada (mi hogar); donde la gateway (router) tiene la IP de 192.168.1.1. Si los paquetes son enrutados a esta IP, mediante enp0s3, salen a internet.

openvpn[945]: TLS: Initial packet from [AF_INET]184.75.223.237:443...
openvpn[945]: net_route_v4_best_gw result: via 192.168.1.1 dev enp0s3
openvpn[945]: Validating certificate extended key usage
openvpn[945]: Peer Connection Initiated with [AF_INET]184.75.223.237:443
openvpn[945]: TLS: tls_multi_process: initial untrusted session promoted to trusted

4) Es importante aclara, a pesar del punto 3), que OpenVPN aun no tiene un túnel creado. Solo se ha autentificado con el servidor VPN de AirVPN y tiene la capacidad e intercambiar información para proseguir el proceso de configuración.

Ahora viene lo interesante: El servidor VPN enviá, de forma remota, hacia nosotros una serie de configuraciones. Esto se denomina PUSH. Dicho de otra manera, el servidor remoto nos dará una serie de instrucciones de "como proceder" con la configuración local de nuestro equipo para habilitar un túnel que nos permita salir a internet a través del servidor remoto.

openvpn[945]: PUSH: Received control message:...
openvpn[945]: OPTIONS IMPORT...
openvpn[945]: OPTIONS IMPORT...
...

Si analizamos el contenido del PUSH encontraremos la información clave. Aquí he destacado los tres parámetros mas importantes:

-ifconfig 10.10.238.249 255.255.255.0: Es la IP y mascara que serán asignadas a la interfaz virtual que será creada en nuestro equipo (entrada al túnel). Si usamos ambos valores IP y mascara podemos calcular la red que conforma el túnel: 10.10.238.0/24.
-route-gateway 10.10.238.1: Es la IP de la gateway donde la interfaz virtual debe enviar sus conexiones para salir a internet (salida del túnel). Como de es de esperar de una gateway, este es la primera IP del rango 10.10.238.0/24.

dhcp-option DNS 10.6.214.1: Es la IP(v4) del servidor DNS que nuestro proveedor de VPN ofrece. Veremos este tema, con mas detall, en un capitulo posterior. Generalmente tiene el mismo valor que la IP de la gateway.

Estos valores serán usados para manipular el networking de nuestro equipo y es importante no olvidarlos.

5) Ahora OpenVPN implementará las configuraciones que han llegado por el PUSH para setear nuestra red. En primer lugar volverá a confirmar la interfaz física por donde puede salir a internet. Como vimos antes, en la punto 2), en mi caso es la interfaz ethernet enp0s3, con gateway 192.168.1.1. En esta comprobación también veremos la mascara que usa dicha IP, en mi caso 255.255.255.0, por lo cual podemos calcular la red local: 192.168.1.0/24 (la típica de toda la vida).

Posteriormente OpenVPN creará una interfaz de red virtual. Esta, por defecto, lleva el nombre de tun0. Seguidamente le fijará a tun0 la IP indicada por las instrucciones PUSH (ifconfig): 10.10.238.249/24. Y finalmente la pasará a estado "up" (encenderá la interfaz).

openvpn[945]: ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=enp0s3...
openvpn[945]: TUN/TAP device tun0 opened
openvpn[945]: net_addr_v4_add: 10.10.238.249/24 dev tun0
openvpn[945]: net_iface_up: set tun0 up

Es importante destacar que en este ultimo paso de encender la interfaz tun0 (paso a "up"), el Kernel de Linux automáticamente añadirá, a las tablas de ruteo del sistema, la información para que dicha interfaz quede asociada a la red correcta. Esta configuración (entre otra) la podemos ver usando ip route, y se ve así:

10.10.238.0/24 dev tun0 proto kernel scope link src 10.10.238.249

Esto se lee como: "cualquier conexión que vaya a alguna dirección del rango 10.10.238.0/24, enviala por la interfaz tun0 y usa la IP de origen (src) 10.10.238.249". Con esto básicamente podemos hablar con cualquier dispositivo de la red 10.10.238.0/24 mediante tun0, incluyendo la gateway, que justamente esta en 10.10.238.1.

Nota: También se añade otro ruteo, un poco mas oculto de detectar: local 10.10.238.249 dev tun0 proto kernel scope host src 10.10.238.249. Este se puede observar en la tabla de rutas "local": ip route show table local. En esta tabla de rutas están centralizados los ruteos relacionados a paquetes localhost y bradcast. Esta regla se lee como: "cualquier trafico local dirigido a 10.10.238.249 envialo a tun0 con IP de origen 10.10.238.249". Simplemente permite que nos podemos auto-enviar trafico a notros mismos por tun0 si usamos nuestra propia IP.

6) Posteriormente a encender tun0 y tenerla conectada a la red 10.10.238.0/24, OpenVPN utilizará otras instrucción, indicadas en el PUSH, para configurar nuestras rutas. Estas configuraciones permitirán "focalizar" (casi*) todas las conexiones de nuestro equipo a tun0en vez de enp0s3 (la interfaz normal). En el proceso, se indicara específicamente la gateway e interfaz a usar. Por ultimo, también se añadirá una regla para que el propio túnel funcione correctamente.

openvpn[945]: net_route_v4_add: 184.75.223.237/32 via 192.168.1.1 dev [NULL] table 0 metric -1
openvpn[945]: net_route_v4_add: 0.0.0.0/1 via 10.10.238.1 dev [NULL] table 0 metric -1
openvpn[945]: net_route_v4_add: 128.0.0.0/1 via 10.10.238.1 dev [NULL] table 0 metric -1

Si usamos ip route veremos estas reglas ya implementadas en nuestras tablas de ruteo (ignoremos otros ruteos que puedan aparecer en la tabla por el momento).

0.0.0.0/1 via 10.10.238.1 dev tun0 y 128.0.0.0/1 via 10.10.238.1 dev tun0: Estas dos se usan en combinación y forman parte de un "truco" que usan muchos clientes de VPN.

Explico el "truco": Nosotros queremos enviar TODO el trafico generado por el sistema mediante tun0 a la gateway correspondiente, y normalmente para decir "todas las IPs" usaríamos un ruteo como 0.0.0.0/0 via 10.10.238.1 dev tun0. 0.0.0.0/0 es literalmente TODO absoluto. El ruteo se leería como: "enviá el todo absoluto a la gateway 10.10.238.1 mediante la interfaz tun0". Pero resulta que ese ruteo es "tan poderosa" que no puede convivir con otros ruteos mas granulares que podríamos (y necesitamos) ocupar. La solución es dividir el "ruteo absoluto" en dos. Usando de forma combinada el rango 0.0.0.0/1 y 128.0.0.0/1 virtualmente estamos cubriendo, a igual que con 0.0.0.0/0, todas las conexiones salientes. Pero ahora el sistema si analizará posibles otros ruteos (configurados en la misma tabla) que podrían definir el uso de rutas alternativas. Nuevamente, es solo un truco, porque si usamos 0.0.0.0/0 el sistema simplemente descartá cualquier otro ruteo definido en la misma tabla.

O sea, podemos leer estas declaraciones de ruteo como: "Todo trafico que salga dirigido a una IP perteneciente al rango 0.0.0.0/1 o 128.0.0.0/1 (todas las IPs existentes), envialo a la gateway 10.10.238.1 mediante la interfaz tun0 al menos que otro ruteo (en la misma tabla) diga lo contrario".

184.75.223.237 via 192.168.1.1 dev enp0s3: Esta regla se lee como: "Si hay paquetes que se dirigen a 184.75.223.237, usa la gateway 192.168.1.1 mediante la interfaz enp0s3". Si recordamos 184.75.223.237 es la IP publica del servidor VPN remoto. Con esto logramos evitar que el trafico al servidor VPN sea canalizado por dentro del propio túnel (lo cual generaría un problema recursivo). Visto de otra manera: "Que todo trafico use tun0 para ir a internet, pero usa enp0s3 para mantener la conexión del túnel al servidor VPN".

7) Con las configuraciones listas, el sistema termina de activar el canal de datos y finalmente setea un timer para verificar constantemente que el túnel esta activo y funcionando.

openvpn[945]: Initialization Sequence Completed
openvpn[945]: Data Channel: cipher 'AES-256-GCM', peer-id: 2, compression: 'stub'
openvpn[945]: Timers: ping 10, ping-restart 60
openvpn[945]: Protocol options: explicit-exit-notify 5

Revisando las tablas de ruteo

Veamos el panorama completo. Ahora que OpenVPN ya ha iniciado, revisemos la totalidad de nuestras reglas y tablas de ruteo.

Si hacemos ip rule para ver las reglas:

0:  from all lookup local
32766:  from all lookup main
32767:  from all lookup default

Esta son las reglas que el sistema operativo revisa para determinar que tabla de ruteo usar. Cada paquete que el equipo debe enrutar es leído (sus propiedades) y se busca un match usando las tablas listadas. Se revisan en orden de prioridad, de menor a mayor número. La tabla local (que siempre es la primera con valor 0) tiene en su interior los ruteos de paquetes localhost y brodcast. La podemos ignorar, y aunque tiene una gran importancia en el funcionamiento de red, no viene a tema por ahora. La segunda tabla, main, es la tabla principal y, por defecto, es la que contiene los ruteos de todas las conexiones salientes del equipo. La ultima tabla, default, cumple la función de dar termino y bloquear cualquier paquete que no sea coherente con las reglas especificadas hasta el momento, por eso siempre lleva el numero mas grande (32767).

Ahora veremos el contenido de la tabla de ruteo main usando ip route (por defecto al usar ip route vemos la tabla main):

0.0.0.0/1 via 10.10.238.1 dev tun0 
default via 192.168.1.1 dev enp0s3 proto dhcp src 192.168.1.13 metric 100 
10.10.238.0/24 dev tun0 proto kernel scope link src 10.10.238.249 
128.0.0.0/1 via 10.10.238.1 dev tun0 
184.75.223.237 via 192.168.1.1 dev enp0s3 
192.168.1.0/24 dev enp0s3 proto kernel scope link src 192.168.1.13 metric 100

Dentro de una tabla de ruteo se busca una coincidencia entre las rutas listadas y las propiedades del paquete de datos que sale a la red. Si hace match, se usa dicha ruta para el paquete. Las decisiones se toman de menor nivel de granularidad de IP a mayor. O sea, un ruteo que especifique por donde enviar trafico de UNA sola IP (Ej: 184.75.223.237) tiene mas poder de prioridad que un ruteo que engloba un rango de IPs (Ej: 10.10.238.0/24). Y una mascara pequeña (Ej: 128.0.0.0/1) tiene menos prioridad que una mascara grande (Ej: 192.168.1.0/24). Existen 2 excepciones. El uso de 0.0.0.0/0 domina a cualquier otro ruteo y es absoluto. Y la palabra especial default se interpreta como: "si ninguna otra ruta de esta tabla hace match con el paquete, usa esta ruta". Por ultimo, si una tabla de ruteo no tiene default y un paquete no encuentra una ruta a usar porque no existe match, el paquete "sale" de dicha tabla de ruteo y pasa a usar la siguiente listada en las reglas (ip rule).

Analicemos los ruteos. Existen dos rutas que ya estaban en la tabla main, incluso antes que OpenVPN iniciara, y que quiero mencionar:

default via 192.168.1.1 dev enp0s3 proto dhcp src 192.168.1.13 metric 100: Este ruteo es, por defecto, el que ha sido agregado mediante DHCP para que nuestra interfaz ethernet enp0s3 tenga acceso a internet. Se puede leer como: "Por defecto, si no hay otro match en esta tabla, enviá todo el paquete a la gateway 192.168.1.1 mediante la interfaz enp0s3 con una IP de origen de 192.168.1.13 (la IP local de nuestro equipo)". Sin este ruteo, nuestra interfaz física simplemente no funciona, no tendríamos internet y OpenVPN ni siquiera podría entablar la comunicación inicial con el servidor.
192.168.1.0/24 dev enp0s3 proto kernel scope link src 192.168.1.13 metric 100: Este segundo ruteo es añadido automáticamente, por el Kernel, cuando la interfaz enp0s3 pasa a estado "up" (durante el inicio del equipo). Y sirve para poder comunicarnos con los otros dispositivos de la red local, incluyendo la gateway correspondiente. Se puede leer como: "Todo trafico saliente dirigido a una de las IPs del rango 192.168.1.0/24 envialo por la interfaz enp0s3 usando la IP de origen 192.168.1.13 (la IP local de nuestro equipo)". Es importante notar que este ruteo es el que permite usar dispositivos en nuestra red local como impresoras, a pesar de estar conectados a la VPN. Ojo: esto es lo que provoca que el trafico local no sea considerado por los ruteos 0.0.0.0/1 y 128.0.0.0/1 del VPN, sino que se mantenga por fuera del túnel. Recordemos el orden de prioridad: /1 menos prioridad que /24. Nota: este ruteo, aunque es generado por el Kernel, es parte configurado gracias a DHCP.

¿Que es es DHCP?. En resumen es el método que usa nuestro equipo, cuando se inicia, para coordinar con nuestro router como integrarse a la red local y acceder a internet. Mas específicamente el protocolo DHCP ayuda a coordinar: la red local, su gateway y la IP que deberá tener cada dispositivo dentro de dicha red. Y, dependiendo de la configuración, también configura el servidor DNS que nuestro equipo usara para resolver hostnames (luego hablaremos mas de esto y como se relaciona a DNS Leak).

Los demás ruteos ya los mencionamos en su momento, pero ahora cobran mas sentido sabiendo las reglas de prioridad de la tabla y como funcionan:

184.75.223.237 via 192.168.1.1 dev enp0s3: Un ruteo de alta prioridad porque especifica una sola IP (184.75.223.23), en este caso la del servidor VPN. Este trafico debe ser enviado por enp0s3 para evitar problemas de recursividad.
10.10.238.0/24 dev tun0 proto kernel scope link src 10.10.238.249: Ruteo que explica que cualquier trafico a 10.10.238.0/24 (red del túnel), debe usar la interfaz tun0 con la IP origen 10.10.238.249.
0.0.0.0/1 via 10.10.238.1 dev tun0 y 128.0.0.0/1 via 10.10.238.1 dev tun0: Dos reglas de ruteo, que en combinación, ayudan a hacer match con todos los paquetes (a excepción que otro ruteo de la misma tabla tenga match) para que sea enviado por tun0.

Antes de finalizar esta sección, quiero que reflexionemos en algo. Aunque esta modalidad de VPN se denomina "Full Tunnel", o sea, todo el trafico se va por la VPN... la verdad es que no y lo podemos ver. Si el trafico va a la red local (192.168.1.0/24), no sale por tun0. Si el trafico va específicamente a 184.75.223.237 (servidor VPN), tampoco usa tun0. Y, aunque no lo vimos en detalle, también están varias reglas de localhost y multicast que queda fuera del túnel (tabla local). Por tanto, realmente no existe nada como un "Full Tunnel", de alguna manera, siempre ha sido un "Split Tunnel" con reglas de división basadas en IPs.

Nosotros ahora, simplemente, tomaremos el control del networking y configuraremos un "Split Tunnel" para dividir el trafico dada nuestras necesidades.

Sobre el DNS y DNS Leak con OpenVPN

Ahora nos iremos por una tangente, nada que ver con el Split Tunnel, pero extremadamente importante si deseas que OpenVPN realice su trabajo correctamente.

Hablemos de DNS, Linux, OpenVPN y DNS Leak

¿Que es el DNS y su gran dilema en Linux?

Este tema es como un iceberg. Ni siquiera se como abordar la explicación... partamos desde lo básico. Nuestro sistema operativo cada vez que debe usar una dirección web, ejemplo: google.com, debe "resolver" dicho domino (o hostname) a una (o varias) IPs. Para lograr esto, el sistema operativo se comunica con un servidor de resolución de DNS. Existen miles en el mundo (y su propia estructura y funcionamiento es bien interesante, pero fuera del alcance de este artículo). Estos servidores DNS tienen tablas enormes donde están todos los dominios y su/s IPs correspondientes.

¿Pero cual servidor usa nuestro sistema operativo cuando debe resolver un hostname?... bueno... el servidor DNS esta en internet... por tanto también tiene una IP, así que nuestro sistema operativo debe saber esa IP y tenerla guardada en algún lugar... ¿no?

Nota: claramente el servidor DNS no puede tener un dominio, ejemplo "super-server-dns.org"; porque ese dominio debería también resolverse de alguna manera. Así que los servidores DNS solo se identifican con IP, no con hostname.

La cosa es que a través de los años de evolución de: Linux, su Kernel y las diversas distribuciones; se ha generado una confusión HORRIBLE!. Hoy en día es sumamente confuso saber donde esta configurado el DNS en Linux y que mecanismos se usan para definir y leer ese valor. Si no me creen, miren este maravilloso post de Tailscale donde un pobre hombre ha tratado de explicarlo. No pretendo darle sentido.

En resumen, existen muchas piezas en el sistema que se mueven y coordinan para configurar el DNS. Y también, luego, para rescatar dicha configuración cada vez que se necesite resolver un hostname. Esas piezas y mecanismos dependerán de su distribución de Linux, versión y paquetes instalados.

En NixOS, por defecto, el principal lugar donde debemos observar para saber a que servidor DNS estamos apuntando es: /etc/resolv.conf. Si hacemos cat /etc/resolv.conf veremos la IP del servidor DNS que nuestro sistema va a usar cada vez que trate de resolver un hostname. Existen 2 servicios que tienen un control sobre este archivo: networkmanager y resolvconf. Si desean editar y controlar su DNS, se deben usar directamente estos servicios para editar las configuraciones o recurrir a programa que se integre con esta arquitectura (como es el caso de OpenVPN que veremos a continuación).

DNS y OpenVPN

Nosotros esperaríamos que al usar un Full Tunnel nuestras actividades quedaran ocultadas ante ojos del ISP (proveedor de internet) ¿no?. Pues, podemos tener un túnel perfectamente funcionando con OpenVPN y aun así, el ISP ver perfectamente a donde nos estamos conectando. ¿Como? Sucede cuando el DNS de nuestro sistema operativo esta configurado para usar un servidor DNS que se encuentra fuera del dominio de conexiones que OpenVPN esta canalizando por el túnel. Esto se denomina DNS Leak y es mas común de lo que piensas.

Realicemos algunas pruebas.

Con su OpenVPN encendido (con configuraciones automáticas para lograr un Full Tunnel) podemos entrar a la web ipleak.net. Podrán ver que su IP publica corresponde al servidor remoto VPN donde estemos conectado. Pero un poco mas abajo, en "DNS Addresses", claramente información relacionada a ustedes. Este es un indicador que su sistema esta consultado la resolución de hostnames a la infraestructura de su ISP. DNS Leak detectado.

Si revisan que IP de servidor DNS esta usando su sistema con: cat /etc/resolv.conf seguramente verán la IP de su gateway de la red local. O sea, su router. Esto quiere decir que su equipo, cada vez que resuelve un dominio, consulta a su router por la IP de la pagina web. Luego, el router, consulta siguiendo una serie de procesos a diversos servidores del ISP.

La IP encontrada en /etc/resolv.conf es configurada automáticamente por su NetworkManager cuando el sistema de DHCP asigna la IP local a su interfaz física.

Nosotros NO queremos bajo ninguna motivo usar un DNS que pertenezca a la ISP. ¿que soluciones tenemos? Existen 2 alternativas relativamente simple de aplicar:

Configurar, mediante su NetworkManager, un DNS publico con buena reputación como: 1.1.1.1, 8.8.8.8 o 9.9.9.9. Luego de hacer esto las resoluciones de hostname pasaran, por el interior del túnel, hasta dichos servidores DNS. El ISP ya no tendrá la posibilidad de ver a donde están accediendo. En NixOS es posible ajustar estos DNS mediante el configuration.nix.
Configurar OpenVPN para que setee, en nuestro sistema, el servidor DNS que nuestro propio proveedor de VPN tiene. En mi caso, AirVPN ofrece a todos sus usuarios un servidor DNS interno mantenido por ellos.

Nosotros usaremos la opción 2, el DNS del proveedor VPN.

Activarlo es muy sencillo en NixOS, solo debemos añadir updateResolvConf = true a la configuración de OpenVPN en configuration.nix:

...
services.openvpn = {
  servers = {
    airVPN = {
      ...
      updateResolvConf = true;
      ...
    };
  };
};
...

Nota: Al activar updateResolvConf, que por defecto esta desactivada, NixOS usara la técnica de update-resolv-conf para automáticamente ajustar el valor de /etc/resolv.conf al DNS indicado en las instrucciones PUSH que OpenVPN ha recibido desde el servidor VPN.

Ahora creamos una nueva generación de NixOS y reiniciamos el sistema.

Si volvemos a acceder a ipleak.net veremos que no solo nuestra IP publica corresponde a la del servidor VPN, sino que también el servidor DNS. De esta manera hemos logrado evitar el DNS Leak.

También podemos verificar usando cat /etc/resolv.conf que ahora esta la IP correspondiente a la gateway de tun0. Generalmente es la IP de la gateway del túnel donde reside el servidor DNS (Ojo, puede que en otros proveedores de VPN sea distinto)

Si tienen dudas de cual es la IP del servidor DNS que su proveedor VPN tiene, la forma mas segura de averiguarlo es entrar log de OpenVPN (journalctl -b | grep "openvpn") y buscar las instrucciones PUSH. Generalmente la IP del servidor VPN esta en un argumento llamado dhcp-option.

Nota: Quiero mencionar que, por defecto, todas las consultas DNS no están cifradas. Si las consultas no usan un túnel, el contenido puede ser fácilmente analizado por el ISP para saber a que dominios se están conectado. Esto incluso si usan 1.1.1.1 o 8.8.8.8. Existen tecnologías para evitar esto como DoT, DoH y DNSCrypt. Por tanto siempre es prioritario asegurar que todas sus resoluciones DNS usen el túnel, de esta manera estarán cifradas y serán ilegibles por el ISP.

Si no usas NixOS

Si no usan NixOS, puede que en su sistema se encuentren con el DNS correctamente configurado desde un principio. En caso contrario, dependerá de su distribución la forma de solucionar el DNS Leak. La mejor manera de afrontarlo es asegurar que OpenVPN este usando la implementación update-resolv-conf o update-systemd-resolved. Puede leer mas del tema aquí.

Configurando nuestro Split Tunnel

"Split Tunnel" es la capacidad de enviar trafico por dentro o fuera del túnel de VPN usando una serie de reglas/ruteos que lo dividan. Esto se puede lograr de diversas maneras. Entre ellas podemos encontrar dos métodos que no requieren el uso de paquetes adicionales a los ya incluidos en la mayoría de las distribuciones de Linux. El primero, y mas sencillo, es usando exclusivamente iproute2, el paquete de herramientas predeterminado para la gestión de redes. Y el segundo método es usando una combinación de iptables/nftables (el firewall) y iproute2. Aquí dejo una comparación de los dos métodos:

iproute2: Es comparativamente fácil de implementar. Solo nos permite usar reglas básicas para dividir el trafico, tales como reglas basadas en: IP de destino/origen, protocolo, puerto y usuario dueño del proceso que genera el trafico.
iptables/nftables + iproute2: Es mas complejo de configurar, ya que debemos coordinar las reglas y tablas de ruteo mas las reglas del propio firewall. Permite una división mucho mas exacta, basada no solo en lo anteriormente mencionado, sino también en: MACs, grupos de usuario, marcas de paquetes, procesos, tamaño de paquete, enrutamiento de forwarding...y otras cosas mas.

Nosotros nos enfocaremos solo en el método de iproute2, ya que sin dominar esto, es peligroso pensar en también querer usar iptables/nftables. De esta manera, nosotros editaremos nuestras tablas de enrutamiento y las reglas que las dominan y no tocaremos nada relacionado al firewall.

Nuestro objetivo sera dividir el trafico basado en usuarios. Si el trafico es generado por el usuario root o nixos (mi usuario normal), se enviara por fuera del túnel. Si el trafico es generado por el usuario vpn_user, se enviara por dentro del túnel.

Antes de comenzar dos puntos muy importantes:

1) Recordar que en todo este artículo estoy omitiendo el uso de IPv6 porque, sinceramente, aun no lo domino completamente. Así que las próximas configuraciones solo permitirán el uso del Split Tunnel con IPv4.

2) Ya que no tocaremos el firewall, vamos a asumir que las reglas actuales de su iptables/nftables permiten todo el trafico de salida (y respuestas a dicho trafico) sin restricciones de de interfaz, protocolos o IPs de origen/destino. Esto es importante ya que puede que ustedes digan: "no me funciona nada de lo que dice este artículo" y resulta que todo el tiempo ha sido su firewall ejecutando bloqueos. ¿Como saber si mi firewall afectará el Split Tunnel? Bueno, si puedes usar OpenVPN en modo "normal", o sea, con la configuración automática que revisamos el capitulo anterior; quiere decir que todo esta bien y no deberían tener problema tampoco al configurar el Split Tunnel.

Desactivando las manipulaciones automatices de OpenVPN

El primer paso sera cambiar la configuración de OpenVPN para que durante su proceso de inicio no manipule nuestras tablas/reglas de ruteo. Ni que tampoco encienda la interfaz virtual tun0. Ojo, que la cree, pero que no la configure ni encienda.

Para lograr esto debemos añadir 2 instrucciones a nuestro .ovpn:
-ifconfig-noexec: Provocará que el sistema no asigne IP ni encienda la interfaz virtual tun0. Solo la va a crear y la dejara apagada.
-route-noexec: Con esto evitaremos que OpenVPN manipule las tablas de ruteo y las reglas asociadas.

Normalmente deberíamos añadir estas dos instrucciones al .ovpn, pero en NixOS podemos añadirlas directamente en configuration.nix:

...
services.openvpn = {
  servers = {
    airVPN = {
      config = "config /etc/nixos/airvpn.ovpn \n ifconfig-noexec \n route-noexec";
      updateResolvConf = true;
    };
  };
};
...

Luego de: guardar las configuraciones, crear una nueva generación de NixOS y reiniciar el OS; veremos que efectivamente OpenVPN inicia, pero sin activar tun0 y tampoco modificando nuestros ruteos. Podemos comprobarlo usando: ip addr, ip rule y ip route. De hecho, en la tabla de ruteo main, solo veremos los 2 ruteos por defecto que enp0s3 necesita para funcionar.

Lo otro que necesitaremos es crear el usuario: "vpn_user". Todo el trafico generado por este usuario usara el túnel de OpenVPN. Trafico generado por otros usuarios, como root o nixos no usaran el túnel. Yo he creado este usuario al "modo" NixOS, pero ustedes pueden hacerlo como corresponda en su distribución. Lo importante es tener claro el UID que tendrá este usuario. En mi caso usare el UID 1100. Así ha quedado mi configuration.nix:

...
users.users = {
  nixos = {
    isNormalUser = true;
    description = "nixos";
    extraGroups = [ "networkmanager" "wheel" ];
  };
  vpn_user = {
    isSystemUser = true;
    group = "vpn_user_g";
    uid = 1100;
  };
};
users.groups.vpn_user_g = {};
...

Nota 1: En mi caso he creado a vpn_user como un usuario de sistema, aunque esto no es obligatorio (no tendrá shell ni carpeta personal). Por requisito de NixOS también he tenido que crear un grupo de usuario asociado a vpn_user, este grupo lo he llamado vpn_user_g.

Nota 2: También pueden ver en esta configuración la existencia del usuario nixos, el cual es el usuario normal. Ojo, el usuario root también existe, aunque no esta presente en ninguna parte del configuration.nix.

Para ver todos los usuarios y su correspondiente UID podemos usar: awk -F: '{ print $1, $3 }' /etc/passwd. Seguramente verán bastante mas usuarios de los esperados... la mayoría son del sistema de Linux y los diversos servicios que estén presente en el sistema. Los importantes a identificar en el listado son: el usuario normal que estén usando, en mi caso nixos con UID 1000, el usuario vpn_user, que acabamos de crear, con UID 1100 y el usuario root con UID 0.

Con esto listo podemos ponernos a configurar manualmente el networking.

Comandos de configuración

Es MUY importante destacar que el orden de uso de los comandos influye. Esto se debe a que ciertas cosas no puedan ser ejecutadas antes que otras. Y por otro lado, las reglas de ruteo tienen prioridades y ordenes de ejecución. Así que mucho cuidado con el orden.

Antes de empezar con los comandos necesitamos tener claro lo siguientes valores:

uid_range El rango de UID de usuarios que su trafico sera enviado por la VPN. En mi caso es "1100-1100" (si, es obligatorio que sea un rango; en caso de ser solo un usuario pueden iniciar y terminar el rango con el mismo UID).
openvpn_peer_ip La IP publica de servidor remoto de VPN. En mi caso es: 184.75.223.237.
tun0_host La IP que el servidor VPN a asignado a nuestra interfaz tun0. En mi caso es: 10.10.238.249.
tun0_gateway La IP de la gateway de la red del túnel. En mi caso: 10.10.238.1.
tun0_dns La IP del DNS del servidor VPN. Generalmente tiene exactamente el mismo valor que tun0_gateway. En mi caso: 10.10.238.1.
tun0_network El rango de la red que usa tun0 con la mascara incorporada en formato CIDR. En mi caso: 10.10.238.0/24.
enp0s3_network El rango de la red local que usa enp0s3 con la mascara incorporada en formato CIDR. En mi caso: 192.168.1.0/24.

Cada vez que OpenVPN inicia, estos valores podrían cambiar. ¿Como los obtengo?. Lo mas fácil es usar: journalctl -b | grep 'openvpn' y leer los logs en búsqueda de cada valor. El mejor lugar para buscar es la sección PUSH.

En caso del valor de enp0s3_network, una forma fácil de obtenerlo es con ip addr show enp0s3, luego tomar el valor inet (IP host del nuestro equipo) y cambiar el ultimo octeto por un .0. Ej: 192.168.1.13/24 -> 192.168.1.0/24. Nota: si su interfaz física no se llama enp0s3, recuerden cambiar al nombre correspondiente.

Claramente realizar los pasos anteriores de manera manual es lento y complicado. Luego de esta explicación del paso a paso, lo automatizaremos todo en un script.

Bien, con estas variables definidas ejecutaremos un total de 9 comandos de iproute2:

1) ip addr add <tun0_host> dev tun0: Le asignamos a la interfaz tun0 la IP host indicada por el PUSH de OpenVPN.

2) ip link set tun0 up: Pasamos la interfaz tun0 a estado "activa".

3) ip route add <tun0_network> dev tun0 scope link src <tun0_host> table 200: Esto enviara por la interfaz tun0, con IP de origen 10.10.238.249, todo trafico dirigido a 10.10.238.0/24. Pero OJO, esta regla no la estamos añadiendo a la tabla main (tabla de ruteo por defecto), sino a la tabla "200" (este numero lo he seleccionado de manera aleatoria y sirve como identificado, pueden usar otro si desean).

4) ip route add default via <tun0_gateway> dev tun0 src <tun0_host> table 200: Enviamos todo el trafico, si no hay otro ruteo en la misma tabla que realice match, a la la gateway 10.10.238.1 mediante la interfaz tun0 usando como IP de origen 10.10.238.249. Y OJO, nuevamente, esto también lo hemos añadido a la tabla "200".

5) ip rule add from all uidrange <uid_range> lookup 200: Creamos nuestra primera regla. Donde todo el trafico generado por el rango de usuarios 1100-1100 deberá dirigirse a ver la tabla de ruteo "200".

Ahora tomaremos una pausa de usar comandos y examinaremos como están nuestras tablas de ruteo y reglas. Usemos ip rule, ip route show table 200 y ip route. Veamos como va nuestro networking:

ip rule

0:  from all lookup local
32765:  from all uidrange 1100-1100 lookup 200
32766:  from all lookup main
32767:  from all lookup default

Cuando el sistema necesite enviar un paquete por red lo primero que revisara son las reglas. Como pueden ver ahora (a diferencia de cuando OpenVPN se auto-configura como Full Tunnel) es que existe una nueva regla. Y esta posicionada antes de main. Cualquier paquete emitido por el rango de usuarios 1100-1100 deberá a ir a ver la tabla de ruteo "200".

ip route

default via 192.168.1.1 dev enp0s3 proto dhcp src 192.168.1.13 metric 100 
192.168.1.0/24 dev enp0s3 proto kernel scope link src 192.168.1.13 metric 100

La tabla main no ha sufrido ningún cambio. Todo lo que llegue a esta tabla usara la interfaz enp0s3 ya sea para salir a internet por la gateway 192.168.1.1 o para ir a algún otro destino en la red local 192.168.1.0/24. Siempre usando como IP de origen 192.168.1.13.

ip route show table 200

default via 10.10.238.1 dev tun0 src 10.10.238.249 
10.10.238.0/24 dev tun0 scope link src 10.10.238.249

Finalmente nuestra nueva tabla de ruteo "200", creada durante el comando 3 y 4. Como pueden ver es muy similar a la tabla main. Cualquier paquete que llegue a esta tabla usara la interfaz tun0, ya sea para salir a internet por la gateway 10.10.238.1 o para ir a algún otro destino de la red 10.10.238.0/24. Siempre usando como IP de origen 10.10.238.249.

Si ahora reflexionamos sobre estas reglas y tablas de ruteo podemos tratar de inferir que pasará con los paquetes de datos en diversas condiciones:

-¿Si un paquete va a localhost o broadcast? -> Se usa la tabla de ruteo "local".
-¿Si un paquete fue generado por UID 1100? -> La segunda regla hace match y se aplicar la tabla de ruteo "200", donde se especifica el uso de la interfaz tun0.
-¿Si un paquete no coincide con la primera y segunda regla? -> Se usa la tabla de ruteo main, y por ende, la interfaz enp0s3.

Genial!

Pero lamentablemente no hemos terminado. Dada la configuración anterior, existen 4 escenarios donde nuestro networking va a fallar. Veamos cada uno de estos casos "especiales" y como abordarlos:

6) ip rule add from <tun0_network> lookup 200: En Linux existe algo llamado rpfilter. Este es un mecanismo que se asegura que no recibamos ataques de sniffing.

Este tipo de ataques se basa alterar los paquetes entrantes al equipo para acceder a zonas de la red que no deberían y "mapear" posibles puntos de ataque. Con rpfilter el sistema se asegura que todas las respuestas a paquetes que entren por una interfaz X, usen la misma interfaz X para salir. De esta manera, al menos que una configuración de networking diga lo contrario, se mantienen aisladas las redes a las cuales esta conectado nuestro sistema (evitando el sniffing). El rpfilter esta implementado a nivel Kernel generalmente. En caso de NixOS el rpfilter esta presente como reglas del firewall iptables (específicamente en la tabla mangle chain nixos-fw-rpfilter).

Resulta que el rpfilter bloqueara los paquetes que entren a tun0, ya que al verificar la interfaz de salida (respuesta) encontrara a enp0s3. Esto provoca que rpfilter piense que se tratan paquetes que están tratando de hacer sniffing. ¿Pero porque sucede esto? Porque solo el usuario 1100 tiene las reglas para usar tun0 y el rpfilter es administrado por root (UID 0). Por tanto, es imposible que el rpfilter realice correctamente su trabajo... no puede ni acceder a tun0 para ver si los paquetes entrantes también salen por ahí.

Con esta regla que hemos añadido estamos ayudando rpfilter. Básicamente se lee como: "si algo entra por 10.10.238.0/24, usa la tabla de ruteo 200 para ver como responder", o sea, "si entra por tun0, sale por tun0, independiente del usuario que este manipulando el paquete de datos".

7) ip rule add to <openvpn_peer_ip> lookup main: ¿Que pasa si el usuario 1100 intenta comunicarse con la IP publica del servidor VPN?. Pues como la regla uidrange 1100-1100 lookup 200 esta antes que lookup main, el sistema va a insistir que el usuario 1100 use la tabla "200". Y esto no tiene sentido... porque no podemos alcanzar la IP publica del servidor VPN (184.75.223.237) desde el interior de túnel. Entonces, esta regla la anteponemos a uidrange 1100-1100 lookup 200 para asegurarnos que, independiente del usuario, todo paquete dirigido a la IP publica del servidor VPN (184.75.223.237) debe usar la tabla main, o sea, interfaz enp0s3. Comprendo que esta regla puede ser algo extraña, pero recuerden: desde el interior del túnel, por recursividad, no se puede llegar a la IP publica del servidor VPN.

8) ip rule add to <enp0s3_network> lookup main: Esta regla tiene un fin parecido a la anterior. ¿Que pasa si el usuario 1100 quiere comunicarse con un dispositivo de la red local... por ejemplo una impresora?... pues la regla uidrange 1100-1100 lookup 200 lo va a obligar a usar la interfaz tun0. Pero claramente desde el túnel es imposible llegar a nuestra impresora. Esta regla la anteponemos a uidrange 1100-1100 lookup 200, para obligar que cualquier trafico, independiente del usuario, que se apunte a algún dispositivo de la red 192.168.1.0/24, use la tabla main y por ende la interfaz enp0s3.

9) ip rule add to <tun0_dns> lookup 200: Esta ultima regla es para que el DNS funcione correctamente en modo Split Tunnel. Resulta que el sistema operativo no tiene una funcionalidad por defecto de tener algo como "Split DNS" (para eso debemos usar otras herramientas como Unbound). Por tanto, tenemos que definir un solo DNS para todo el sistema, independiente del usuario que este requiriendo resolver un hostname. Si no añadimos esta regla, solo el usuario vpn_user podrá acceder a usar el DNS que se ha definido en /etc/resolv.conf (automáticamente durante el inicio de de OpenVPN). Si otro usuario, como root o nixos intentan resolver un hostname, trataran de usar 10.10.238.1 pero, dadas las reglas, van a ser dirigidos a la tabla main; lugar por el cual es imposible llegar a 10.10.238.1 de tun0. Con esta novena regla nos aseguramos que, independiente del usuario, cualquier parte del sistema que requiera resolver un hostname, pueda usar la tabla "200" para llegar al servidor DNS que ofrece el proveedor VPN.

Nota: En caso que usen un DNS como 1.1.1.1 o 8.8.8.8 deberán configurar esta regla con dicho valor para hacer las consultas a esos servidores DNS usando el túnel. En caso contrario las resoluciones ocuparan la interfaz enp0s3 y el ISP podrá detectar a que dominós se esta conectado (para evitar esto ultimo pueden investigar sobre el uso de DoT o DoH aqui).

Si volvemos a usar ip rule, ip route y ip route show table 200 deberíamos ver:

ip rule

0:  from all lookup local
32761:  from all to 192.168.1.0/24 lookup main
32762:  from all to 184.75.223.237 lookup main
32763:  from 10.10.238.0/24 lookup 200
32764:  from all to 10.10.238.1 lookup 200
32765:  from all uidrange 1100-1100 lookup 200
32766:  from all lookup main
32767:  from all lookup default

Ojo, miren la importancia del orden de cada regla

ip route

default via 192.168.1.1 dev enp0s3 proto dhcp src 192.168.1.13 metric 100 
192.168.1.0/24 dev enp0s3 proto kernel scope link src 192.168.1.13 metric 100

ip route show table 200

default via 10.10.238.1 dev tun0 src 10.10.238.249 
10.10.238.0/24 dev tun0 scope link src 10.10.238.249

Realizando pruebas

Una vez usemos las 9 instrucciones deberíamos tener nuestro Split Tunnel funcionando. Vamos a realizar algunas pruebas:

Si hacemos con nuestro usuario nixos (normal):

curl https://ipv4.ipleak.net/json/

Deberíamos ver como respuesta nuestra IP publica, muestra nuestro IPS y el país donde residimos... o sea, no esta usando la VPN.

Y lo mismo para el usuario root:

sudo curl https://ipv4.ipleak.net/json/

Deberíamos ver que el túnel no se usa.

PERO si usamos nuestro usuario vpn_user, con UID 1100:

sudo -u vpn_user curl https://ipv4.ipleak.net/json/

Magia! Dicha solicitud web esta saliendo por el túnel. Deberíamos ver una IP que no se puede asociar a nosotros a igual que una IPS y país distinto.

Pruebas de DNS

También podemos realizar pruebas para asegurar que no tenemos DNS Leak. Existe un método usando la terminal y pueden encontrar los detalles aqui. Lo primero que deberán hacer es generar una cadena de 40 caracteres aleatorios, esta sera la "session". Luego deberán hacer un curl a la siguiente URL usando dicha "session". Deben hacer varios curl consecutivos usando la misma "session", pero en cada una de ellas cambiar el valor de "random".

curl https://[session]-[random].ipleak.net/dnsdetection/

Las respuestas que acumulen de cada curl empezarán a formar un "mapeo" de los servidores DNS que se están usando. Luego tiene que tomar dichas IPs de respuesta e investigar mediante reverse IP lookup (link1, link2, link3) a que servidores corresponden.

Si su DNS esta correcto deberían ver que el servidor DNS usado no puede ser asociado a ustedes geográficamente.

Luego, generando una nueva "session", repitan el proceso para los otros usuarios: sudo curl..., sudo -u vpn_user curl...; el resultado debería ser siempre el mismo.

Si el DNS que detectan es geograficamente cercano a ustedes, algo no esta funcionando bien y tienen DNS Leak.

Split Tunnel basado en usuarios y sin DNS Leak funcionando :)

Automatizando el proceso

Claramente ejecutar 9 comandos y ademas tener que leer los logs de OpenVPN para configurar el Split Tunnel es... lento, fácil de cometer errores... no gracias. Bueno, podemos automatizar esto.

Aquí pueden encontrar un script que automatiza el proceso. Yo lo he guardado en /etc/nixos/vpn_custom_script.sh. Y debe ser integrado haciendo estos cambios en su configuration.nix:

...
services.openvpn = {
  servers = {
    airVPN = {
      config = "config /etc/nixos/airvpn.ovpn \n route-noexec \n ifconfig-noexec";
      updateResolvConf = true;
      up = ''
        UID_RANGE="1100-1100"
        CUSTOM_SCRIPT_MODE="up"
        ${builtins.readFile /etc/nixos/vpn_custom_script.sh}
      '';
      down = ''
        UID_RANGE="1100-1100"
        CUSTOM_SCRIPT_MODE="down"
        ${builtins.readFile /etc/nixos/vpn_custom_script.sh}
      '';
    };
  };
};
systemd.services.openvpn-airVPN.path = [ pkgs.gawk pkgs.ipcalc ];
...

La integración de OpenVPN en NixOS nos da el parámetro declarativo up y down. La cadena de texto pasada a estos parámetros será "incrustada" en los scripts del ciclo de vida del servicio de OpenVPN. Lo indicado en up se ejecutará luego que OpenVPN termine de iniciar. Lo indicado en down luego que el servicio se detenga. Estos son lugares perfectos para añadir funcionalidades que estén relacionadas en manipular la red.

Nuestro vpn_custom_script.sh, dependiendo del valor CUSTOM_SCRIPT_MODE, aplica o revierte las manipulaciones de red. El único valor que tenemos que definir manualmente es el rango de UID de usuarios en UID_RANGE. Estos son los usuarios cuyo trafico sera dirigido por dentro del túnel.

Nota 1: Usamos builtins.readFile para leer el contenido del .sh y pasarlo como cadena de caracteres a up y down. Esto ya que dichos parámetros no esperan un path a un script, sino, literalmente una cadena de texto que sera incrustada a los .sh de OpenVPN. Pueden ver aquí para mas información.

Nota 2: En systemd.services.openvpn-airVPN.path hemos añadido, al estilo NixOS, los paquetes que son usados al interior de vpn_custom_script.sh: gawk y ipcalc. Sin esta referencia, NixOS no podrá encontrar los path a los binarios necesarios.

Nota 3: Puede que te extrañe, que al interior de vpn_custom_script.sh, existen algunas variables como $ifconfig_netmask que parecieran ser usadas "de la nada" sin ser nunca declaradas. Realmente el valor de estas variables corresponde a variables de entorno que OpenVPN usa en su proceso. Por tanto, como el contenido de vpn_custom_script.sh esta siendo "incrustado" a los .sh propios de OpenVPN, podemos aprovechar de acceder a sus variables de entorno. Lugar donde, por fortuna, están los principales parámetros de red de la VPN. Puedes ver mas aquí.

Si no tienes NixOS

Como he dicho al inicio, este artículo esta pensado en NixOS. Así que si usas otra distribución de Linux te tocará idear como automatizar el proceso para tu ambiente. Espero que el script te pueda servir de inspiración para encontrar la mejor solución a tu caso.

El mayor desafió es encontrar el valor de las IPs y redes involucradas en la VPN. Para eso tienes 2 opciones. 1) De alguna manera acceder a las variables de entorno que maneja de OpenVPN (como lo hace mi script) o 2) usar journalctl -b | grep 'openvpn' para obtener y procesar el texto de los logs de OpenVPN. Generalmente OpenVPN permite añadir al .ovpn paths a scripts que deben ser ejecutados durante su proceso de inicio (up) y cierre (down). Es aquí el mejor lugar para que ustedes realicen la referencia a los scripts que vayan a usar en su proceso de automatización. Relacionado a esto, les recomiendo leer sobre script-security de OpenVPN. También, como ultimo consejo, no olviden tener, al igual que un script de seteo, un script para revertir todas las reglas y ruteos cuando OpenVPN se apaga o reinicia. Si no hacen esto, podrían llegar a corromper su networking.

Bonus: la regla inversa, que todos los usuarios, menos uno, usen el túnel

He decidido añadir este bonus donde explico, rápidamente, como lograr la "negación" de nuestro Split Tunnel. Que todos los usuarios, menos uno, usen OpenVPN.

Para esto deben reemplazar las reglas de ruteo para usar los rangos de esta manera. Supongamos que queremos mantener el trafico del usuario UID 1100 fuera del túnel.

ip rule add from all uidrange 0-1099 lookup 200
ip rule add from all uidrange 1101-65535 lookup 200

Nota: Verifiquen en su distribución cual es el máximo valor UID que puede existir. En NixOS es 65535.

Luego deberán hacer solo un cambio mas. Tiene que ver con el rpfilter. Debemos tener una regla que asegure que todo el trafico que llega por enp0s3 salga por enp0s3.

ip rule add from 192.168.1.0/24 lookup main

Esto se necesita ya que ahora root (usuario dueño de rpfilter) siempre estará usando el tun0 y provocará que cuando se encuentre con trafico del usuario 1100, y lo analice para ver si hay sniffing, no pueda usar la interfaz enp0s3 para ver la salida del mismo. Con esta regla lo solucionamos.

Conclusión

Espero que este artículo los ayudará a comprender mejor cómo funciona el networking que gestiona OpenVPN y como lograr tener un Split Tunnel. Los invito a leer más de mis artículos, donde hablo generalmente en profundidad de seguridad, NixOS y Home Servers.

Sin nada más que añadir, que tengan un lindo día experimentando :)

Desbloqueo remoto LUKS, una solución innovadora - NixOS

Federico Jensen — Thu, 22 May 2025 02:27:48 +0000

Ninguna IA ha estado involucrada en la creación de este articulo.

En este articulo veremos:

Como lograr desbloquear remotamente nuestro NixOS que use LUKS como medida de cifrado completo. Esto será posible ya que, durante el Boot, nuestro OS solicitará a un "dispositivo remoto autorizado", por ejemplo nuestro celular, la clave LUKS. Como intermediario de comunicación usaremos Ntfy y todo el intercambio de información estará cifrado con múltiples capas de seguridad. Finalmente, y como algo opcional, abordaremos la integración de AirVPN (OpenVPN) como una VPN que se usara durante el Boot para asegurar la comunicación. También abordaremos detalles respecto a posibles DNS leak del proceso.

Esta solución nace desde la imposibilidad, en circunstancias normales, de desbloquear un servidor NixOS que tenga LUKS de alguna forma que no requiera la presencia física de un humano con dicha maquina. En mi caso tengo un HomeLab que, físicamente, se encuentra en un lugar remoto y donde no tengo acceso habitual. Luego de cortes energéticos o reinicios de emergencia, era para mi un fastidio tener que ir físicamente a introducir la clave LUKS para que mi servidor iniciara nuevamente a su funcionamiento habitual. Buscando soluciones a esto, solo encontré el proyecto Clevis-Tang, un servidor de autentificación LUKS, que podría ayudar con mi problema. Pero sus características técnicas no se adecuaron a mis necesidades; requiriendo modificaciones profundas del proyecto para poder adaptarlo a mis circunstancias. Tales como: una funcionalidad asíncrona del sistema, la capacidad manual de introducir la clave LUKS, la autorización por parte de dispositivos específicos y la funcionalidad de usar un celular como "terminal remoto". Con ello, nace esta idea.

La propuesta que presento es estable y puede ser implementada con confianza. La lógica de seguridad que usaremos es resiliente a diversos vectores de ataque, tales como: Men-in-the-middle, fuerza bruta, intervención/secuestro/inyección de paquetes de datos y suplantación de identidad. A pesar de esto, es aun una obra en progreso y muchas mejoras pueden ser realizadas.

Este articulo también es una invitación a, exactamente, mejorar esta propuesta y añadir nuevas funcionalidades.

A continuación podrán encontrar dos videos tutoriales relacionados a este articulo. El primero es una introducción y el segundo toda la guiá de implementación. Los códigos que usamos (aunque son pocos) los pueden encontrar aquí: -GitHub-.

Video Introducción:

Desbloqueo remoto LUKS - NixOS - Introducción

Video introductorio sobre una implementación para desbloquear, de manera remota, un NixOS protegido mediante LUKS.

odysee.com

Video Implementación:

Desbloqueo remoto LUKS - NixOS - Implementación

Video donde vemos, en profundidad, la implementación de un sistema para desbloquear remotamente un NixOS con LUKS.

odysee.com

Requisitos

1- El requisito mas importante es que nuestro NixOS tenga conectividad a internet durante Stage1 del proceso de Boot. Claramente, si nuestro sistema no tiene red, sera imposible realizar un proceso de descifrado remoto. En este articulo pueden encontrar una guiá completa de como lograr esto.

1.1- Opcionalmente: tener habilitado en la Stage1, del proceso de Boot, un servidor SSH. Lo anterior, para facilitar el debugeo ante posibles errores en el proceso de implementación. En el articulo donde explico como tener internet en Stage1, también explico como habilitar un servidor SSH para estos propósitos. Nuevamente, esto es solo opcional y algo útil de tener habilitado en caso de encontrarnos con errores inesperados durante el Boot.

Federico Jensen

Apr 4 '25

Red y SSH en Stage1 (boot - initrd) de NixOS - Parte 1

#spanish #nixos #linux

Comments

13 min read

2- Estar dispuestos en usar Ntfy como nuestro "intermediario" para enviar y recibir mensajes entre el NixOS y el "dispositivo remoto" desde donde desbloquearemos la unidad LUKS. Ntfy ofrece canales de comunicación con funcionalidades pub/sub gratuitos y de alta disponibilidad. El gran "pero" es que los canales son públicos. A pesar de ello, el sistema propuesto usa diferentes métodos criptográficos donde esto no afecta la seguridad de la solución. Esta guiá usa exclusivamente Ntfy, aunque los invito a tomar la iniciativa y hacer implementación para otros intermediarios de comunicación como: Plugins para Discord, sistemas basados en Email, conexiones directas/privadas entre NixOS y otro servidor... la imaginación es el limite.

3- En caso de seguir la parte final de este articulo: "Implementación de una VPN para el proceso de desbloqueo remoto (opcional)", estar dispuestos a pagar por los servicios de AirVPN como proveedor de VPN. Como alternativa, también pueden usar cualquier servidor/proveedor de VPN que sea compatible con el cliente de OpenVPN. Vuelvo a repetir, esto es opcional... yo uso AirVPN en este articulo porque consdiero que es el mejor servicio de VPN actualmente.

Por ultimo, hacer un recordatorio que lo expuesto en este articulo es focalizado en NixOS. Aunque no me cabe duda que puede servir de inspiración para realizar una implementación similar en otras distribuciones de Linux.

Certificados CA TLS

Como parte del proceso para habilitar una forma de desbloqueo remoto de LUKS, nuestro NixOS deberá comunicase con los servidores de Ntfy mediante HTTPS. Lamentablemente durante el Boot del sistema operativo, por defecto, no se encuentran disponibles los Certificados CA TLS para resolver el protocolo HTTPS. Nuestra primera configuración sera añadir estos certificados al proceso de Boot.

Para esto, en nuestro archivo de configuración /etc/nixos/hardware-configuration.nix añadiremos unas declaraciones. Específicamente en la sección boot.initrd.systemd.contents. Esta delcaracion nos permite listar ficheros que deben ser considerados para ser "montados" en el Ram-Disk/initrd (sistema de archivos temporal, montado en RAM, usado durante el proceso de Boot de Linux).

boot = {
  ...
  initrd = {
    ...
    systemd = {
      ...
      contents = {      
        "/etc/ssl/certs/ca-certificates.crt".source = builtins.toFile "ca-certificates.crt" (builtins.readFile "/etc/ssl/certs/ca-certificates.crt");
        "/etc/ssl/certs/ca-bundle.crt".source = builtins.toFile "ca-bundle.crt" (builtins.readFile "/etc/ssl/certs/ca-bundle.crt");
      };
    };
  };
};

Nota 1: Es buen momento para verificar que boot.initrd.systemd.enable tenga un valor de true. O sea, que estemos usando SystemD para administrar los servicios del proceso de Boot. De todos modos, esto ya deberia estar activado si cumpimos con el requisito de tener internet durante Stage1, ya que es necesario para configurar las interfaces de red correctamente.

Nota 2: La sintaxis que usamos dentro de contents para "copiar" los ficheros .crt al listado de los que deben estar presentes en el proceso de Boot puede parecer algo confuso. El uso de builtins.toFile y builtins.readFile como métodos auxiliares (parte del lenguaje de Nix se debe a que los .crt realmente son symlinks. Para que contents pueda copiar el contenido de los .crt correctamente debemos usar estos métodos auxiliares para leer el contenido, traspasarlos a un archivo temporal y luego copiar el contenido de dicho archivo a los que deberán estar disponibles durante el Boot.

Clave criptográfica RSA

Ahora debemos generar un par de claves publico-privada RSA. Estas servirán para que solo un "dispositivo remoto" autorizado pueda "darle sentido" a los mensajes que están involucrados en descifrar la unidad LUKS de NixOS y que transitaran por Ntfy. La parte privada, de la clave, quedará en el dispositivo remoto y la parte publica la dejaremos en nuestro NixOS.

Para generar las claves podemos usar OpenSSL. Es MUY importante que la calve RSA generada tenga una longitud de 4096bits. Para generar la clave privada podemos usar el comando:

openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:4096

Luego, para generar la parte publica, de dicha clave privada, podemos usar el comando:

openssl rsa -in private_key.pem -pubout -out public_key.pem

En caso de usar Windows, deberán instalar primero OpenSSL. La forma mas fácil es ejecutando un Power Shell en modo administrador y luego usando el comando choco install openssl. Luego de reiniciar la terminal, ya podrán usar los comandos anteriores en Windows para generar la clave.

La clave privada la dejaremos en el equipo remoto... mas delante la utilizaremos. Ahora nos debemos enfocar en la clave publica. Esta la deberemos dejar en /etc/nixos/ de nuestro NixOS. En mi caso he llamado al archivo que contiene la clave publica public_key.pem.

Nota 1: La implementación que propongo en este articulo esta preparada para admitir solo un par de claves. Por tanto, si deseamos tener múltiples dispositivos, cada uno con claves distintas (lo recomendado), deberemos entra a programa dicha funcionalidad.

Nota 2: La necesidad de tener que usar una clave de 4096bits se debe a que, internamente, la implementación que configuremos usara otras claves criptográficas en "modo onion" (capas). Y por longitud de mensajes, debemos hacer que estas sean de 4096bits, en caso contrario las otras "capas" del cifrado superaran el "espacio" permitido.

Con nuestra clave publica ya en /etc/nixos/public_key.pem, ahora deberemos disponibilizar ese .pem en el proceso de Boot (similar a como disponibilizamos los .crt anteriormente).

Para esto en nuestro hardware-configuration.nix usaremos la declaración boot.initrd.secrets de esta manera:

boot = {
  ...
  initrd = {
    ...
    secrets = {
      ...
      "/etc/nixos/public_key.pem" = "/etc/nixos/public_key.pem";
    };
  };
};

Nota: La razón de usar boot.initrd.secrets para esto y no boot.initrd.systemd.contents se debe a que, dada las buenas practicas de NixOS, se recomienda el uso de secrets para... eso... claves; y contents para ficheros de otra índole.

Creando nuestro canal en Ntfy

Crear un canal de Ntfy es extremadamente sencillo. Simplemente debemos ir a la pagina web de Ntfy (https://ntfy.sh) y luego añadir en la URL un "/" continuado de una cadena alfanumérica de caracteres ("-" y "_" tambien estan permitidos). Esta "cadena" sera la ID del canal. La idea es que esta "cadena" sea algo aleatorio. Por ejemplo: "UGaCGId_S4w-7rYxtg". Ahora cualquiera que acceda a https://ntfy.sh/UGaCGId_S4w-7rYxtg podrá usar dicho canal para enviar o recibir notificaciones (sistema pub/sub).

Lo ideal es usar un genrador aleatorio para crear la ID que usaremos para el canal. La longitud máxima de caracteres para la ID es de 64... así que recomiendo usar dicha cantidad. Recordemos guardar la ID que usaremos, ya que la vamos a necesitar en futuras configuraciones.

Quiero aprovechar nuevamente de recordar, que aunque el canal de Ntfy es publico, o sea, cualquiera que tenga la ID puede escribir y leer mensajes en dicho canal; nuestra implementación es segura. Esto ya que los mensajes que intercambiaremos entre NixOS y el "dispositivo remoto" estarán cifrados con múltiples capas de seguridad. Estos resguardos nos protegen diversos ataques como: intercepción de paquetes, reutilización de paquetes, análisis de patrones, fuerza bruta, man-in-the-middle y/o suplantación de identidad entre otros posibles vectores. En el Anexo de este articulo pueden leer un poco mas sobre estas medidas de seguridad.

Donde sucede la magia: CustomDecrypt.sh

El Script CustomDecrypt.sh es el cual realiza toda la "magia". Este Script se iniciara durante Stage1 del proceso de Boot y sera el encargado de todo el proceso de comunicación con Ntfy y posterior desbloqueo de la unidad LUKS. Este Script en su interior realiza varias otras funciones, como:

Comprobar el estado de las unidades de almacenamiento y la precedencia de particiones aseguradas con LUKS.
Usar la clave publica (correspondiente a la clave privada del "dispositivo remoto") para asegurar los mensajes.
La generación de claves RSA efímeras axilares para lograr una comunicación de con cifrado de múltiples capas.
Enviar la solicitud de la clave LUKS a Ntfy (para que el "dispositivo remoto" reciba una notificación de la necesidad de digitar la clave LUKS).
Gestionar la "escucha" de respuestas desde Ntfy de mensajes.
Considerar varios aspectos de integridad y seguridad del proceso de comunicación.
Desbloquear las unidades LUKS una vez se tenga una clave valida.
Soportar algunos procesos extra que deben ser considerados en caso de estar usando OpenVPN.
Considerar algunos escenarios limites en el cual se puede encontrar el proceso de Boot y/o el Script que podrían generar problemas en la secuencia de inicio y/o seguridad.

Como pueden ver... son bastantes cosas...

Como sea, el contenido de CustomDecrypt.sh lo pueden encontrar aquí. Quiero destacar que el Script es una "obra en progreso", por tanto, no pretende ser perfecto. Poco a poco lo he tenido que ir modificando para ir considerando nuevos escenarios. Los invito a seguir contribuyendo.

Una vez descarguen el archivo, lo deben dejar en /etc/nixos/. Tener cuidado en que el nombre del fichero debe ser CustomDecrypt.sh para que funcione correctamente con lo que realizaremos a continuación.

Ahora, como ya hemos realizado anteriormente, debemos disponibilizar CustomDecrypt.sh para que este presente durante el proceso de Boot. Para esto en boot.initrd.systemd.contents debemos agregar:

...
contents = {
  ...
  "/etc/nixos/CustomDecrypt.sh".source = "${/etc/nixos/CustomDecrypt.sh}";
};

Nota: Podrán notar que en este caso la sintaxis es distinta a la usada con los .crt. Esto se debe a que CustomDecrypt.sh es, efectivamente, un fichero. Mientras que los .crt son symlinks.

Con el archivo ya disponible en Boot, ahora crearemos un servicio para que ejecute este Script en el momento exacto. Para esto usaremos la declaración boot.initrd.systemd.services.

boot = {
  ...
  initrd = {
    ...
    systemd = {
      ...
      services = {
        ...
        CustomDecrypt = {
          enable = true;
          wants = [ "initrd-nixos-copy-secrets.service" ];
          after = [ "initrd-nixos-copy-secrets.service" ];
          before = [ "systemd-ask-password-console.service" ];
          wantedBy = [ "systemd-ask-password-console.service" ];
          unitConfig = { 
            Description = "CustomDecrypt";
            DefaultDependencies = false;
          };
          serviceConfig = {
            Type = "forking";
            ExecStart="${pkgs.bash}/bin/sh -c 'sh /etc/nixos/CustomDecrypt.sh \"https://ntfy.sh/UGaCGId_S4w-7rYxtg\" \"/etc/nixos/public_key.pem\" &'";
            TimeoutStopSec = "3700s";
          };
        };
      };
    };
  };
};

Es importante notar que en ExecStart pasamos dos parámetros a CustomDecrypt.sh. El primer parámetro es el canal de Ntfy que usaremos, tengan cuidado de usar https y de indicar correctamente la ID que corresponda a su canal. El segundo parámetro es el path a la clave publica .pem (par correspondiente a la clave privada que dejamos en nuestro "dispositivo remoto").

Nota 1: Usamos wants y after para ejecutar CustomDecrypt.sh luego que el proceso de copia de secretos de NixOS esta listo. Y usamos before y wantedBy para iniciar el Script antes de que NixOS pregunte, por el terminal, por la clave LUKS.

Nota 2: El servicio se ejecuta como forking. De esta manera CustomDecrypt.sh quedara en background mientras maneja las comunicaciones de enviado/recepción de mensajes con Ntfy y todos los otros procesos involucrados en el descifrado de LUKS.

Nota 3: El TimeoutStopSec de 3700s indica el tiempo máximo que CustomDecrypt.sh esperara una respuesta remota con la clave LUKS (es un poco mas que una hora). Luego de este tiempo el servicio de CustomDecrypt.sh terminara, haciendo imposible procesar respuesta remotas con la clave. Esto podrá parecer extraño e incomodo desde el punto de vista del usuario, pero luego veremos que tiene sentido... paciencia.

CustomDecrypt.sh recurre al uso de varios comandos como: ip, curl y sed (entre otros) para su funcionamiento. Normalmente estos comandos están integrados en el OS, pero resulta que en el proceso de Boot no. Esto se debe a que el proceso de Boot trata de cargar las mínimas dependencias necesarias para poder funcionar.

Por tanto, deberemos indicar en nuestro hardware-configuration.nix que deseamos usar una serie de paquetes "extras" durante el Boot. Esto lo podemos hacer usando la declaración boot.initrd.systemd.initrdBin. Incluiremos, usando la nomenclatura de NixOS para paquetes, los siguientes paquetes:

libuuid: Para el uso de lsblk y poder listar unidades de almacenamiento.
gnugrep: Para el uso de grep.
cryptsetup: Para poder manejar particiones que tengan LUKS.
openssl: Para crear y manipular claves RSA.
curl: Para comunicarnos con HTTPS con Ntfy.
iproute2: Para el uso del comando ip y validar algunas cosas relacionas a la red.
gnused: Para el uso de sed.

Para esto añadimos:

boot = {
  ...
  initrd = {
    ...
    systemd = {
      ...
      initrdBin = [ pkgs.libuuid pkgs.gnugrep pkgs.cryptsetup pkgs.openssl pkgs.curl pkgs.iproute2 pkgs.gnused ];
    };
  };
};

Nota: Si tienen la necesidad de añadir mas paquetes, simplemente los listan en este arreglo.

Con todo esto estamos listos para crear una nueva generación de NixOS:

sudo nixos-rebuild switch

Y luego reiniciamos. Si todo va bien, deberíamos ver que durante el proceso de Boot, nos llega a nuestro canal de Ntfy un mensaje.

Preparando el dispositivo remoto

Ahora que tenemos listo nuestro NixOS, nos toca ocuparnos del "dispositivo remoto", o sea, el dispositivo desde el cual digitaremos la clave LUKS.

En teoría nuestro "dispositivo remoto" puede ser cualquier cosa que tenga la capacidad de leer/enviar mensajes con Ntfy usando HTTPS y que pueda manipular claves de tipo RSA. O sea, este "dispositivo remoto" podría ser una aplicación de celular, un servidor con una rutina CRON o una plataforma web que hemos programado para este uso especifico... la imaginación es el limite.

En este articulo, nuestro "dispositivo remoto" sera un Windows donde ejecutaremos un Script Python. El Script lo pueden encontrar aquí. Es algo un poco "burdo" y "aburrido"... pero mas que suficiente en términos de funcionalidad practica.

De antemano, me quiero disculpar con lo básico y poco profesional del Script Python. Se que se puede ser mejorado mucho, pero la verdad, es que no he puesto mucho esfuerzo en esta parte del proyecto. Lo importante, es que funciona.

El Script para funcionar necesita del paquete requests y pycryptodome, los cules pueden instalar con pip install requests pycryptodome. También este Script necesita de dos configuraciones:

En la variable TOPIC, dejar la ID del canal de Ntfy que estemos usando.
En la variable PRIVATE_KEY_PATH el Path a la clave privada que hemos generado al inicio del guía.

Hora de probar todo:

Usaremos Python para ejecutar el Script. Mientras tengamos activo el Script de Python, vamos a reiniciar NixOS. Durante el proceso de Boot se enviara un mensaje de NixOS a Ntfy, el Script de Python va a reaccionar a dicho mensaje. Luego veremos que el Script de Python nos solicitará introducir la clave LUKS. Luego de digitarla y apretar enter, un nuevo mensaje sera enviado desde el Script de Python a Ntfy. CustomDecrypt.sh, que corre en NixOS, reaccionara a dicha respuesta y la analizará. Si todo va bien, luego de unos 10 a 15 segundos la unidad LUKS terminara de descifrarse y veremos como el proceso de Boot continuara y terminara de forma normal.

Y con eso ya estamos listos !

El Script de Python no necesariamente lo tenemos que tener previamente activo antes que NixOS se reinicie. Si deseamos, podemos primero reiniciar NixOS y luego podemos iniciar el Script de Python. El Script debería poder "recuperar" el ultimo mensaje enviado a Ntfy (el enviado por NixOS), para usarlo en el proceso de solicitar la calve LUKS.

Recordemos que el TimeoutStopSec de CustomDecrypt.sh es de 3700 segundos (un poquito mas de 1 hora), por tanto ese sera el plazo de tiempo que tenemos para digitar la clave LUKS desde el momento en que se reinicia NixOS.

Móvil Android como "dispositivo remoto"

Es fácil tener como "dispositivo remoto" nuestro celular Android. Solo debemos instalar la aplicación Pydroid 3. Esta app nos permite ejecutar scripts Python en el celular. Basta que copiemos la clave privada .pem y el Script .py a nuestro celular. Y luego usando Pydroid 3 ejecutar el Script. El uso del Script sera exactamente el mismo que en Windows. Recuerda instalar las dependencias de requests y pycryptodome en Pydroid 3.

Claramente seria mas elegante con una aplicación dedicada y nativa de celular... en vez de usar un Script de Python. Pero eso ya se los dejo a ustedes para que lo creen.

También pueden instalar la aplicación móvil oficial de Ntfy. Luego de instalarla pueden "subscribirse" al canal de comunicaciones usando su ID. De esta manera recibirán notificaciones en su celular cuando mensajes lleguen al canal. Esta es una buena manera de enterarse de forma oportuna si nuestro NixOS esta solicitando la clave LUKS. Luego podremos usar el Script de Python desde Pydroid 3 para digitar la clave LUKS, o acercarnos a nuestro computador de escritorio y usar el Script desde ahí.

En caso de iOS supongo que existe algo similar a Pydroid 3... pero la verdad no he probado.

Implementado un Watchdog en Stage1 del Boot

Hay un aspecto que aun debemos considerar en nuestra implementacion. Y es el uso de un Watchdog que se encargue de reiniciar el sistema operativo, de forma completa, en caso que dentro un periodo de tiempo determinado, no se desbloquee la unidad LUKS de forma exitosa. Esto lo hacemos por varias razones:

Siempre esta la posibilidad que durante el Boot algo falle. Por ejemplo que, luego de un corte energético, la arquitectura de red aun no esta totalmente restablecida. O que existe alguna falla en el arranque de Stage1 relacionada al hardware. Un reinicio siempre es la mejor opción para "purgar" y cargar todo limpiamente.
Nuestro CustomDecrypt.sh solo acepta claves LUKS durante 3700 segundos (TimeoutStopSec) desde el momento que iniciar. Si ese tiempo ya ha transcurrido, no hay forma de reiniciar CustomDrcrypt.sh. Nuestro equipo quedara sin poder terminar el Boot. Reiniciar es la única opción.
Esto también ayuda a que CustomDecrypt.sh genere nuevamente las claves RSA efímeras (de uso internas). Esto ayuda que los mensajes enviados por Ntfy siempre estén en un constante ciclo de "renovación criptográfica", haciendo que no exista tiempo suficiente para hacer ataques mas sofisticados. Mejor dicho, es buena practica permitir al sistema de CustomDecrypt.sh renovar sus claves efímeras de forma habitual... como por ejemplo cada 1 hora.
CustomDecrypt.sh solo acepta 1 vez una contraseña remota LUKS. Si esta es digitada de forma incorrecta, CustomDecrypt.sh no acepta reintentos. Y estos es apropósito. Es para evitar ataques de fuerza bruta desde el dispositivo remoto. Con el reinicio permitimos que CustomDecrypt.sh solicite nuevamente la clave, dandonos la opcion de tener "reintentos" de manera controlada y segura.

Para implementar nuestro Watchdog sera tan simple como agregar un nuevo servicio a nuestro hardware-configuration.nix. En la sección boot.initrd.systemd.services agregamos, junto a nuestro Script de CustomDecrypt, el nuevo servicio de CustomWatchdog:

services = {
  ...
  CustomWatchdog = {
    enable = true;
    after = [ "timer.target" ];
    requiredBy = [ "initrd.target" ];
    unitConfig = { 
      Description = "CustomWatchdog";
      DefaultDependencies = false;
    };
    serviceConfig = {
      Type = "forking";
      ExecStart="${pkgs.bash}/bin/sh -c 'sleep 3600 && reboot -f &'";
      TimeoutStopSec = "3700s";
    };
  };
};

Lo mas importante en este servicio es el valor de 3600 segundos (1 hora) que tiene asignado el comando sleep (localizado en la instrucción de ejecución ExecStart). Este sera el tiempo que CustomWatchdog esperara antes de reiniciar el sistema operativo.

Nota 1: Usamos after y requiredBy para ejecutar CustomWatchdog lo antes posible en la cadena de procesos de Stage1 del Boot.

Nota 2: CustomWatchdog se ejecuta en modo forking, ya que estará constantemente en background esperando ejecutar el reinicio (en caso que el proceso de Boot no logre superar la etapa de LUKS correctamente).

Nota 3: Usamos reboot con la flag -f (force) para asegurarnos que el sistema se reinicie, a pesar de que otros procesos lo bloqueen.

Nota 4: El TimeoutStopSec es muy importante. Pueden notar que tiene un valor un poco mayor al usado en el sleep. Este TimeoutStopSec es esencial para que SystemD no "crea" que CustomWatchdog esta "pegado" y termine el proceso antes de tiempo. Esto puede suceder, porque en algunas ocasiones, SystemD no sabe interpretar correctamente los sleep prolongados y "cree" que el servicio esta fallando por alguna razón y que esta "pegado" sin hacer nada.

En caso que deseemos ajustar los tiempos, deberemos ser cuidadosos. El TimeoutStopSec de CustomDecrypt y de CustomWatchdog siempre deben tener un valor ligeramente mayor al usado en el sleep de CustomWatchdog. Esto es importante para no entrar en condiciones de carrera. Por tanto, si queremos por ejemplo, reiniciar nuestro equipo cada 6 horas, deberemos dejar en el sleep de CustomWatchdog con un valor de 21600 (segundos en 6 horas); y en TimeoutStopSecde CustomDecrypt como CustomWatchdog, un valor un poco mayor, por ejemplo "21700s".

Con esto listo, podemos crear una nueva generación de NixOS sudo nixos-rebuild switch y luego reiniciar nuestro sistema. Es un poco difícil "probar" si nuestro Watchdog funciona... ya que deberemos esperar 1 hora. Pero si quieren pueden reducir el valor de los TimeoutStopSec y sleep a algo como 10 minutos para hacer una prueba completa.

Conclusión, primera parte, sistema de desbloqueo remoto

Listo, ya tenemos nuestro sistema de desbloqueo remoto LUKS completo, usando Ntfy como intermediario para los mensajes. Yupi!

Ahora inicia la segunda parte, totalmente opcional, de este articulo. Y esto es la implementación de OpenVPN, con el proveedor AirVPN, durante el proceso de Boot. Esto nos ayudara a anonimizar el trafico de red entre NixOS y Ntfy. Posteriormente vamos a abordar algunos temas relacionados a DNS leak para dejar todo perfectamente ajustado y anónimo.

Opcional: Implementación de VPN, con OpenVPN, en Stage1 del proceso de Boot

La razón por la cual yo deseo implementar una VPN durante el proceso de Boot, es que mi HomeLab se ejecuta siempre usando una VPN. Por tanto, es contraproducente, que durante el proceso de Boot me comunique con internet (en este caso con Ntfy) y que dicha conexión no pase por un túnel. Con esta implementación logro, realmente, que desde el inicio de OS, todo el trafico pase por la VPN... incluso durante el Boot.

Como he comentado en un inicio, yo usaré AirVPN como proveedor de VPN (de pago). Es mi servicio de VPN favorito (y por mucho). La política y respaldo que tiene la empresa de AirVPN es muy difícil de cuestionar. Y técnicamente son geniales. Si... soy un poco de "Fanboy". En un internet lleno de VPNs que son estafas y "trampas de tontos"... creadas específicamente para obtener dinero; AirVPN aparece como una opción "real" de lo que debe ser una VPN. Bueno, como sea. El punto es que usaré AirVPN, pero ustedes pueden usar cualquier proveedor que les permita usar OpenVPN como cliente (o sea, que el proveedor les de la posibilidad de genera un archivo .ovpn de conexión). Incluso pueden crear su propio servidor VPN usando algún servicio cloud u otro servidor que tengan disponible.

Creando el archivo .ovpn en AirVPN

Lo primero que haremos es crear nuestro .ovpn. Este es el archivo que tiene las credenciales para que el cliente OpenVPN pueda conectarse al servidor VPN.

Lo primero sera entrar a la web de AirVPN y crear un "Device" en el panel de "Client Area". Los Device permiten diferenciar distintos equipos que usen la misma cuenta de AirVPN. Por ejemplo, yo tengo un Device para mi celular, otro para mi notebook y ahora voy a crear uno para este proyecto. Yo le he puesto como nombre "NIX".

Con el Device ya creado, ahora vamos al panel de "Config Generator", que encontraran también en la Client Area.

En Config Generator vamos a activar la opción Advanced. Luego vamos a seleccionar el OS, o sea, Linux. Posteriormente el protocolo de conexión que usaremos. Yo generalmente uso "OpenVPN TCP 443". Y en la sección Advance vamos a marcar "Resolved hosts". Luego bajaremos y vamos a seleccionar el Device al cual vamos asignar este .ovpn, en mi caso "NIX". Finalmente vamos a seleccionar el servidor al cual nos conectaremos. Yo generalmente uso "Global". Al final de la pagina pueden darle a "Generate" para iniciar la descarga de su .ovpn.

Nota: La opción Resolved hosts nos sirve para que el .ovpn generado tenga definido el punto de acceso del servidor VPN con una dirección IP y no con un hostname. Esto lo necesitamos ya que durante Boot veremos que existen algunos problemas en la resolución de hostnames de manera consistente. Por tanto es mejor usar directamente la IP del servidor VPN.

Luego deberán copiar el .ovpn y dejarlo en /etc/nixos/ de su NixOS. Yo he usado como nombre para el archivo airvpn.ovpn.

Antes de continuar, no olvidemos que debemos disponibilizar dicho archivo para que este presente durante el Boot. Para esto en boot.initrd.secrets de nuestro hardware-configuration.nix añadimos:

secrets = {
  ...
  "/etc/nixos/airvpn.ovpn" = "/etc/nixos/airvpn.ovpn";
};

Configurando OpenVPN

Ahora vamos a indicar al sistema que permita el uso del paquete de OpenVPN en el Boot. Para esto vamos a añadir al arreglo boot.initrd.systemd.initBin el paquete pkgs.openvpn, o sea, nuestro initBin quedara así:

initrdBin = [ pkgs.openvpn pkgs.libuuid pkgs.gnugrep pkgs.cryptsetup pkgs.openssl pkgs.curl pkgs.iproute2 pkgs.gnused ];

Posteriormente deberemos habilitar unos "Módulos de Kernel" al proceso de Boot, para que el sistema tenga la capacidad de crear adaptadores de red de tipo túnel. En el arreglo de la declaración boot.initrd.availableKernelModules añadiremos tun y tap. Deberá quedar así:

boot.initrd.availableKernelModules = ["tun" "tap" ...<otros módulos>... ];

Lo único que nos falta es crear el servicio que se encargará de iniciar OpenVPN en el momento correcto. Para esto añadiremos un servicio mas a boot.initrd.systemd.services.

services = {
  ...
  Openvpn = {
    enable = true;
    wants = [ "network.target" "initrd-nixos-copy-secrets.service" ];
    after = [ "network.target" "initrd-nixos-copy-secrets.service" ];
    before = [ "CustomDecrypt.service" ];
    wantedBy = [ "CustomDecrypt.service" ];
    unitConfig = {
      Description = "OpenVPN";
      DefaultDependencies = false;
    };
    serviceConfig = {
      Type = "forking";
      ExecStart = "${pkgs.bash}/bin/sh -c 'openvpn --daemon --config /etc/nixos/airvpn.ovpn'";
    };
  };
};

Es muy importante prestar atención en el nombre del servicio: "Openvpn", ya que influye en un comportamiento de CustomDecrypt.sh que explicare mas adelante.

Nota 1: Usamos wants y after para iniciar Openvpn luego de tener el sistema de network básico listo y luego de tener los secretos disponibles. Usamos before y wantedBy para indicar que Openvpn inicie antes que el servicio de CustomDecrypt.

Nota 2: El Script inicia en modo forking, ya que el cliente de OpenVPN operara como un deamon durante el proceso de Boot.

Nota 3: En el comando de ejecución de ExecStart pasamos en --config el path al archivo de configuración .ovpn que hemos generado en AirVPN.

Con esto listo ya se iniciará de forma automática OpenVPN durante el Boot y se creará un túnel a los servidores de AirVPN.

Aprovecho de mencionar que CustomDecrypt.sh en su interior tiene una rutina donde, si detecta que un servicio llamado "Openvpn" (ojo, con "O" mayúscula, igual que el nombre usado en boot.initrd.systemd.services.Openvpn) activo, procurara que el túnel esta activo antes de proseguir con la comunicación con Ntfy. Este es un resguardo para que no se genere comunicación https con el servidor antes que el VPN este listo. En caso que el servicio de Openvpn lo llamarán de forma distinta, pueden cambiar el nombre en la variable OPENVPN_SERVICE_NAME localizada al inicio de CustomDecrypt.sh.

Una feature que me gustaría añadir en un futuro es la capacidad de tener distintos .ovpn (apuntando a distintos servidores). Y si uno falla, OpenVPN pase a usar otro .ovpn.

Arreglando bug que provoca DNS leak

El talón de Aquiles de los VPN es cuando nuestro OS no resuelve los hostname (nombres de dominio) usando un DNS "seguro". Esto se denomina DNS leak, donde el ISP puede analizar nuestro trafico usando la resolución de DNS. En este segmento nos aseguraremos que los DNS se usen de forma apropiada y no provoquen este problema que potencialmente des-anonimice nuestro trafico.

Generalmente cuando usamos una VPN, se usa un servidor DNS interno a dicha VPN para resolver hostname. Ese es el caso típico también con el servicio de AirVPN... ellos tienen servidores DNS que podemos usar una vez tengamos el túnel activo. Esta configuración de "selección de DNS" casi casi casi siempre es automática. Pero por alguna razón... en NixOS... específicamente en el sistema de red usado en Boot... no sucede.

Esto quiere decir, que aunque estemos conectados al VPN y tengamos el túnel activo, no siempre se usará el DNS de AirVPN. Resulta que si tenemos un DNS configurado a nivel interfaz física, este valor "sobrescribirá" al indicado por OpenVPN al configurar el túnel. Esto, en palabras simples, nos generará un catastrófico DNS leak.

Por suerte solucionarlo es sencillo. Deberemos ir a nuestro hardware-configuration.nix a la declaración boot.initrd.systemd.network y luego identificar la interfaz que usamos para conectarnos a internet. En mi caso es la llamada enp0s3.

Ahora, la forma de solucionar el problema depende de como se configura su interfaz:

La interfaz es configurada de forma estática (sin DHCP):

En este caso deberían ver algo como:

enp0s3 = {
  enable = true;
  name = "enp0s3";
  address = [ "192.168.4.152/24" ];
  gateway = [ "192.168.4.1" ];
  dns = [ "8.8.8.8" ]; 
};

La solución consiste en remover la definición de DNS. O sea, dejarlo así:

enp0s3 = {
  enable = true;
  name = "enp0s3";
  address = [ "192.168.4.152/24" ];
  gateway = [ "192.168.4.1" ];
};

La interfaz es configurada usando DHCP:

En este caso deberían ver algo como:

enp0s3 = {
  enable = true;
  name = "enp0s3";
  DHCP = "yes";
};

La solución consiste en añadir las siguientes declaraciones:

enp0s3 = {
  enable = true;
  name = "enp0s3";
  DHCP = "yes";
  dhcpV4Config = {
    UseDNS = false;
  };
  dhcpV6Config = {
    UseDNS = false;
  };
};

Con esto le indicamos a DHCP que solo configure de forma automática el address y gateway de la interfaz y que no defina ningún DNS.

Independiente del modo en que resuelvan la configuración esto solucionara el echo que, una vez conectados al VPN, se use efectivamente el DNS del VPN.

Otros problemas que pueden causar DNS leak

Resulta que existe otro "problema", que puede surgir, dada la solución que implementamos en el paso anterior. El escenario de este "problema" es el siguiente:

Nuestras interfaces no tienen asignado un DNS (ni manualmente ni por DHCP).
Por alguna razón la conexión a la VPN falla de forma catastrófica.
Por otra razón, totalmente anómala, nuestro sistema operativo intenta resolver un hostname.

¿Que pasará? Pues resulta que el servicio que se encarga de administrar la resolución de DNS del sistema operativo, llamado resolved, usara unos DNS denominados "FallbackDNS". Este es uno (o varios) DNS de emergencia que son usados en caso que no se puedan localizar a nivel interfaz (ni a nivel VPN). Si esto llega a suceder, puede que nuestro sistema intente resolver el hostname de "ntfy.sh" usando estos DNS de emergencia provocando un DNS leak.

Para solucionar esto podemos añadir una definición en configuration.nix. Específicamente en services.resolved.

services.resolved = {
  fallbackDns = [];
};

Con esto, ya no existirán fallbackDns que puedan ser usados. Nuestro sistema operativo quedara sin opciones de resolver hostname sin querer.

Esto claramente provoca un "restricción colateral". Si no estamos conectados a la VPN, no podemos resolver hostname. Pero dentro del contexto de la solución de "desbloqueo remoto", no debería haber ninguna razón lógica por la cual desearíamos hacer esto sin antes estar conectados a la VPN.

Ultimo ajuste a resolveD

Finalmente, ya que estamos en configuration.nix podemos aprovechar de hacer una ultima cosa en services.resolved:

services.resolved = {
  fallbackDns = [];
  extraConfig = ''
    MulticastDNS=no
    LLMNR=no
    DNSSEC=yes
  '';
};

Estas 3 opciones nos ayudan a terminar de configurar unos detalles finales. MulticastDNS y LLMNR son unos protocolos para que el sistema operativo encuentre dispositivos en la red local (como impresoras o carpetas compartidas). Personalmente no me gusta que mi sistema emita paquetes "porque si" a la red (aunque sea local). Con eso desactivamos esos protocolos. DNSSEC nos ayuda a que la resolución de DNS se realice con los parámetros de seguridad de DNSSEC. El servidor DNS privado de AirVPN soporta DNSSEC, así que de esta manera nos aseguramos que las consultas sean realizadas de manera segura.

Nota: Me gustaría mencionar que CustomDecrypt.sh, en su interior, tiene una parte de código que se encarga de sobre escribir, automáticamente, el valor de fallbackDns en caso que OpenVPN se este usando. El valor de fallbackDns queda configurado con la misma IP que la gateway del túnel generado con AirVPN. Esta es la IP que AirVPN recomienda usar en caso de querer configurar manualmente el uso del DNS privado de ellos. El motivo de reescribir el valor de fallbackDns es simplemente para asegurarnos que resolved use correctamente el DNS. Es una prevención extra, a lo que ya es una serie de bugs y comportamientos particulares. Si no desean que CustomDecrypt.sh toque el fallbackDns pueden desactivar esta configuración pasando el valor de la variable FORCE_FALLBACK_DNS_VPN (localizada al inicio de CustomDecrypt.sh) a 0. Esto puede que sea necesario en caso que usen otro proveedor de VPN (donde la configuración manual para el uso del DNS privado sea distinta).

Conclusión

Y con esto ya tenemos un sistema que nos permite desbloquear de forma remota nuestra unidad LUKS, durante el Boot, de forma segura y anomia. Usando como intermediario Ntfy hemos logrado crear un sistema de notificaciones y mensajes asíncronos, así que podemos usar un celular como nuestro dispositivo remoto autorizado. Ademas, la implementación de seguridad interna que usa CustomDecrypt.sh para gestionar los mensajes, nos protegen de múltiples vectores de ataque, haciendo que el uso de canales públicos de comunicación no sea un problema.

No olviden, en su Stage1, desactivar el servidor SSH... ya no lo van a necesitar. También recomiendo ejecutar sudo nix-collect-garbage -d para limpiar el cache :)

Nuevamente los invito a seguir mejorando esta propuesta. Creo que una gran contribución seria hacer que el sistema funcione de forma modular, permitiendo cambiar que el canal de comunicación sea Discord, Slack, un sistema basado en intercambio de emails firmados o incluso un comunicación directa entre servidores.

En los próximos días subiré un articulo donde explicaré, detalladamente, la lógica detrás de las decisiones de seguridad que usa CustomDecrypt.sh. Puede ser una lectura interesante si te apasiona la seguridad.

Un saludo a todos!

Red (wifi) y SSH en Stage1 (boot - initrd) de NixOS - Parte 2

Federico Jensen — Sun, 06 Apr 2025 22:40:17 +0000

Ninguna IA ha estado involucrada en la creación de este articulo

Contexto

Esta es la Parte 2 del articulo "Red y SSH en Stage1 (boot - initrd) de NixOS". La Parte 1 puede ser encontrada aquí.

Esta guiá forma parte de un compendio de clases/tutoriales para crear y gestionar un HomeLab usando NixOS.

Este articulo posee un video asociado donde se pueden encontrar mas detalles y el paso a paso:

Red y SSH en Stage1 de NixOS - Parte 2

Guiá donde habilitamos conexión a la red y un servidor SSH en la Stage1 (init ram disk) en NixOS.

odysee.com

Introducción

En esta segunda parte veremos como activar una interfaz inalámbrica (WiFi) durante la Stage1 del proceso de boot de NixOS. Exploraremos los desafíos de identificar e instalar drivers, de escanear redes wifi durante Stage1 y de automatizar el proceso de conexión durante el boot.

En esta segunda parte estoy asumiendo que ustedes poseen acceso por SSH a Stage1 usando una interfaz Ethernet. Si aun no han logrado configurar esto, puede ver la primera parte del articulo.

El Plan:

Verificando el funcionamiento normal de WiFi en NixOS
Activar drivers de interfaz inalámbrica en Stage1
Validar escaneo y conexión de redes WiFi en Stage1
Automatizar el proceso de conexión a WiFi en Stage1 y probar el acceso remoto usando SSH

Si... si comparan con lo expuesto en la Parte 1, he cambiado un poco los puntos de "El Plan" de la Parte 2 >.<

Vamos a ello!

1) Verificando el funcionamiento normal de WiFi en NixOS

Lo primero sera validar que nuestro NixOS pueda usar el adaptador WiFi de forma normal. Con esto me refiero a poder: ir a su interfaz de NetworkManager, escanear las redes WiFi, seleccionar una y conectarnos correctamente luego de indicar la contraseña asociada.

Si podemos hacer esto de forma normal, te invito a continuar con la siguiente sección de este artículo.

En caso que tengas conectado un adaptador inalámbrico, pero no lo puedas usar en su NixOS, quiere decir que faltan los drivers. A continuación exploraremos como instalar un adaptador WiFi.

1.1) Instalando drivers de interfaz inalámbrica en NixOS

He querido incluir este paso porque, en mis experimentaciones, he estado usando un dongle USB WiFi que, efectivamente, ha requerido una instalación de drivers manual... espero que este segmento le sea útil a alguien que este en una situación similar.

Nuestro objetivo es buscar el nombre del dispositivo inalámbrico. Con esto me refiero al modelo del hardware. Para esto, lo mejor es usar las herramientas pciutils y/o usbutils. Si vienen de la Parte 1 del articulo, estas herramientas ya las deberían tener en: /etc/nixos/configuration.nix.

Usando los comandos de lsusb -v y lspci -k podemos listar el hardware conectado por el bus USB y PCI a nuestro equipo. Una de estas dos opciones serán de utilidad para ustedes, ya que los adaptadores WiFi generalmente usan uno de estos dos bus de comunicación. En mi caso, como tengo un dongle USB, con lsusb -v he podido encontrar el nombre de mi dispositivo. Es: "Realtek RTL8188EUS".

Si su adaptador inalámbrico usa el bus PCI (por ejemplo si es una tarjeta pci-express) pueden usar lspci -k para localizar el nombre.

Usando este nombre debemos entregarnos a Google...y buscar... Nuestro objetivo ahora es encontrar el nombre del driver relacionado a este dispositivo. Luego de un poco de búsqueda, para mi dongle Realtek he encontrado que el driver correspondiente se llama "rtl8xxxu" y es parte de un paquete de drivers de llamado: "rtl8188eus-aircrack".

Claramente en su caso esto sera distinto, lamentablemente no existe una manera sistemática para encontrar el driver correcto... pero no tengan duda que alguien en internet ya ha pasado por lo mismo que ustedes. Con algo de investigación encontraran el nombre del driver.

Ahora nos toca incluir este driver en nuestro NixOS. Para esto en /etc/nixos/hardware-configuration.nix vamos a añadir:

boot.extraModulePackages = with config.boot.kernelPackages; [
  rtl8188eus-aircrack
];

Nota: Estoy usando extraModulePackages _ y no _availableKernelModules porque, en específico, este es un driver externo a los empaquetados con NixOS.

Ahora nos toca crear una nueva generación de NixOS con sudo nixos-rebuild switch y luego reiniciar el sistema. Luego del reinicio ya deberían poder usar su adaptador WiFi de forma normal en nuestro NixOS.

2) Activar drivers de interfaz inalámbrica en Stage1

Primero partiremos identificando el nombre de la interfaz inalámbrica. Usando ip link podemos listar los adaptadores del sistema. En mi caso se llama "wlp0s11u1" (desde ahora los ejemplos usaran este nombre para el adaptador, no olviden usar el de su interfaz).

Con esta información ahora veremos cual es el estado de la interfaz durante Stage1. Vamos a reiniciar nuestro sistema y conectarnos por SSH a Stage1 (de la forma expuesta en la Parte 1 del artículo). Una vez en Stage1 usaremos ip link para ver cuales adaptadores están siendo detectados en esta etapa del boot. Lo mas seguro es que no vean su interfaz inalámbrica... y esto es lo normal. En el extraño caso que si vean su interfaz inalámbrica listada, pueden continuar con la siguiente sección del artículo.

Bien, entonces ahora lo que debemos lograr es habilitar en Stage1 los mismos drivers que en Stage2 se están usando para el WiFi. La mejor forma para lograr esto es realizar una comparativa entre los drivers cargados en Stage1 y Stage2. Y luego deducir (con ayuda de Google si es necesario) cual es exactamente el que "nos esta faltando" en Stage1 "pero que si esta" en Stage2.

Para esto primero vamos a ir a nuestra Stage2 (escritorio de toda la vida) y usaremos los comandos lsmod y modinfo <nombre modulo> para listar y ver el detalle de los driveres cargados. Estamos buscando uno que tenga relación con la interfaz inalámbrica.

Dado el nombre de mi adaptador he logrado encontrar, usando lsmod, un modulo llamado "rtl8xxxu". Luego usando modinfo rtl8xxxu he podido ver que efectivamente se relaciona a la interfaz inalámbrica.

He aprovechado también de regresar por SSH a mi Stage1 para usar el mismo comando (lsmod) y confirmar que, efectivamente, "rtl8xxxu" no esta en Stage1.

Entonces, en teoría, si logramos cargar "rtl8xxxu" en Stage1 vamos a poder usar la interfaz inalámbrica.

Con esta información vamos a añadir "rtl8xxxu" al parámetro availableKernelModules en nuestro /etc/nixos/hardware-configuration.nix. Con esto habilitamos el uso del driver en Stage1:

boot.initrd.availableKernelModules = ["rtl8xxxu" … ];

En algunos casos puede ser necesario usar la opción enableRedistributableFirmware. Específicamente esto puede ser necesario si el driver que están cargando en availableKernelModules no es parte por defecto del sistema y ha sido instalado desde una fuente externa.

hardware.enableRedistributableFirmware = true;

Luego, creamos una nueva generación de NixOS y reiniciamos. De regreso a Stage1 por SSH he volvemos a usar ip link y ahora si veremos la interfaz listada! :)

Nota extra: En un momento use el driver "8188eu", el cual parecía ser el correspondiente a mi dongle WiFi. Pero, por alguna razón, eso solo funcionaba en Stage2 y no en Stage1. Por otro lado, el "rtl8xxxu" funciona en ambos contextos. La moraleja es que puede ser necesario un poco de prueba y error hasta lograr dar con el driver correcto.

3) Validar escaneo y conexión de redes WiFi en Stage1

Una vez que sabemos que en Stage1 la interfaz inalámbrica es detectada, toca usarla. En una primera instancia realizaremos algunas pruebas de conexión de forma manual. Y luego, en la siguiente sección del artículo, lo automatizaremos.

La primera prueba sera confirmar que la interfaz puede escanear redes en Stage1.

En primer lugar vamos a instalar unas herramientas que nos facilitaran el debugeo. En /etc/nixos/configuration.nix añadiéremos los paquetes:

También vamos a querer estas herramientas en Stage1, así que las añadiremos al parámetro initrdBin de nuestro /etc/nixos/hardware-configuration.nix:

boot.initrd.systemd.initrdBin = [ pkgs.iw pkgs.wirelesstools … ];

Aprovechando que estamos en hardware-configuration.nix también activaremos la interfaz inalámbrica de Stage1 en la sección network.networks:

...
wlp0s11u1 = {
  enable = true;
  name = "wlp0s11u1";
  DHCP = "yes";
}; 
...

Nota 1: Recuerda usar el nombre de tu interfaz.

Nota 2: Por ahora usaremos DHCP para que la IP, Gateway y DNS se configuren automáticamente desde nuestro router.

Bien, con esto listo vamos a crear una nueva generación de NixOS.

3.1) Probando el escaneo de redes

Primero realizaremos una prueba en Stage2 (escritorio típico). Usando los comandos:

ip link Deberíamos identificar la disponibilidad e la interfaz inalámbrica.
iw dev y/o iwconfig Deberíamos poder ver detalles de la interfaz inalámbrica.
iw <nombre interfaz> scan y/o iwlist <nombre interfaz> scan Deberíamos ver las redes WiFi disponibles.

Una vez comprobado que todo se ve "normal" en Stage2, vamos a repetir este proceso en Stage1. Si todo va bien, también deberíamos ser capaces de ver las señales WiFi disponibles.

Nos conectamos por SSH a Stage1 y usamos los mismos comandos: ip link, iw dev y iw <nombre interfaz> scan.

Con esto podemos confirmar que la interfaz inalámbrica en Stage1 es capaz de escanear redes. Genial !

3.2) Creado un supplicant con las configuraciones de red inalámbrica

Ahora que sabemos que podemos escanear redes en Stage1, debemos prepararnos para conectarnos a una. Para esto deberemos crear un archivo de configuración (denominado "wpa_passphrase") que posee en su interior el nombre de la red WiFi (SSID) y contraseña asociada.

Para generar el archivo de configuración podemos usar el siguiente comando en Stage2:

wpa_passphrase "SSID" "CONTRASEÑA" | sudo tee /etc/nixos/wpa_supplicant.conf

Recuerda indicar correctamente el nombre de tu señal (SSID) y la contraseña.

El archivo generado sera guardado en /etc/nixos/wpa_supplicant.conf. Este archivo de configuración lo vamos a necesitar en Stage1. Así que usaremos secrets para crear una "copia" que si este disponible en el ram disk del boot (esto ya lo vimos en la Parte 1 de este articulo). Para esto, añadiremos el fichero /etc/nixos/wpa_supplicant.conf a la lista de secrets de /etc/nixos/hardware-configuration.nix:

...
secrets = {
  ...
  "/etc/nixos/wpa_supplicant.conf" = "/etc/nixos/wpa_supplicant.conf";
};
...

En hardware-configuration.nix aprovecharemos de añadir el wpa_supplicant paquete a initrdBin para que pueda ser usado en Stage1. Este paquete es el responsable de hacer que el archivo de configuración, que hemos generado, pueda ser usado como parte del proceso de selección y autorización de una red WiFi:

boot.initrd.systemd.initrdBin = [ pkgs.wpa_supplicant … ];

Por ultimo, también añadiremos en hardware-configuration.nix 4 módulos a availableKernelModules necesarios para que Stage1 puede ser capaz de manejar las redes WiFi y entender sus protocolos de seguridad:

boot.initrd.availableKernelModules = ["ccm" "ctr" "iwlmvm" "iwlwifi" … ];

Con todos los cambios guardados ahora nos toca crear la nueva generación de NixOS y reiniciar el sistema.

3.3) Conectándonos a una red inalámbrica usando supplicant en Stage1

Finalmente vamos a conectarnos! Entraremos por SSH al Stage1 de NixOS y luego vamos a ejecutar este comando:

wpa_supplicant -i wlp0s11u1 -c /etc/nixos/wpa_supplicant.conf -B

Recuerda usar el nombre de tu interfaz

Si todo va bien, esto iniciara un proceso en background que usara la interfaz inalámbrica indicada en -i para enlazarnos a la red WiFi especificada por el archivo wpa_supplicant.conf.

Luego de esperar unos segundos podemos comprobar la conexión usando estos comandos:

ip link Se debería ver la interfaz inalámbrica "UP".
iw dev Deberíamos ver una serie de información que indica el estado de la conexión WiFi.
iw dev NOMBRE_INTERFAZ_WIFI link Deberíamos ver un mensaje donde se confirma que existe conectividad WiFi.
ip addr Tendríamos que ver la IP que ha sido asignada a la interfaz gracias a DHCP.

Si todo va bien ya tenemos WiFi en nuestra Stage1.

Por ultimo, si deseamos, podemos desactivar DHCP y asignar de manera estática los parámetros de IP (address), Gateway y DNS a nuestra interfaz. Esto se puede realizar de la misma manera en la cual lo logramos en la Parte 1 de este articulo con la interfaz Ethernet. Para esto modificamos en /etc/nixos/hardware-configuration.nix algunas cosas:

...
wlp0s11u1 = {
  enable = true;
  name = "wlp0s11u1";
  #DHCP = "yes"; #Comentamos para desactivar DHCP
  #Añadimos los parámetros de forma manual
  address = [ "192.168.4.151/24" ];
  gateway = [ "192.168.4.1" ];
  dns = [ "8.8.8.8" ]; 
};
...

Para saber que address y gateway digitar, podemos usar los comandos ip route y ip link para averiguar cual IP y Gateway son los que usa nuestro sistema de forma automática. Luego copiamos esos valores. Recuerda usar el nombre de tu interfaz inalámbrica.

Con esto sera mas fácil usar SSH, ya que nos aseguramos de tener siempre la misma IP.

4) Automatizar el proceso de conexión a WiFi en Stage1 y probar el acceso remoto usando SSH

En esta etapa final buscamos crear un script que realice el proceso de conexión a la red WiFi durante Stage1 de manera automática.

Para esto añadiremos el siguiente script a /etc/nixos/hardware-configuration.nix:

...
services = {
  ...
  ConnectWifi = {
    enable = true;
    wants = [ "systemd-udev-settle.service" "network.target" "initrd-nixos-copy-secrets.service" ];
    after = [ "systemd-udev-settle.service" "network.target" "initrd-nixos-copy-secrets.service" ];
    before = [ "systemd-ask-password-console.service" ];
    wantedBy = [ "systemd-ask-password-console.service" ];
    unitConfig = {
      Description = "ConnectWifi";
      DefaultDependencies = false;
   };
   serviceConfig = {
     Type = "forking";
     ExecStart="${pkgs.bash}/bin/sh -c 'wpa_supplicant -i wlp0s11u1 -c /etc/nixos/wpa_supplicant.conf -B || true'";
   };
 };
...
};
...

Recuerda cambiar en -i el nombre de la interfaz inalámbrica a la tuya.

Nota 1: Este script se va a ejecutar luego que el hardware (systemd-udev-settle.service), secretos (initrd-nixos-copy-secrets.service) y base de sistema de red (network.target) estén disponibles. Y antes de que LUKS pida la clave (systemd-ask-password-console.service). O sea, antes de Stage2.

Nota 1.1: En caso de no usar LUKS y estar usando el script "force-pause-script" (mencionado en la Parte 1 del artículo) para pausar Stage1; deberás cambiar: systemd-ask-password-console.service por force-pause-script.service en before y wantedBy.

Nota 2: El script corre en modo forking y con wpa_supplicant en background (-B) para no interrumpir otros procesos de Stage1. El || true se usa para evitar que systemd piense que wpa_supplicant "falló" mientras realiza re-intentos para lograr conectividad WiFi (algo normal en el protocolo de conexión WiFi).

Luego que generemos la nueva generación de NixOS y reiniciemos el sistema, podemos volver a confirmar que la conexión WiFi está bien usando SSH. De hecho, podemos conectarnos por SSH directamente usando la IP que hemos fijado al adaptador inalámbrico.

SSH por WiFi en Stage1 !!!

Si deseamos, podemos desactivar la interfaz Ethernet y solo usar WiFi. También puede ser buen momento para remover herramientas que solo utilizamos durante el proceso de configuración tales como: iw, wirelesstools, pciutils y usbutils. Un sudo nix-collect-garbage -d también puede ser útil para limpiar nuestro cache.

Finalmente un recordatorio: Solo usar SSH en Stage1 a modo de debugger... no es muy recomendado tener SSH en dicha etapa del boot.

Conclusión

Espero que este articulo de dos partes fuera de su utilidad para lograr tener Red y SSH en Stage1 de NixOS

Nuevamente quiero agradecer al blog de Spencer Balogh por su guiá indispensable en comprender como funciona el networking de Stage1.

Otras fuentes de información que he usado:

Wireless connection within initrd

Como comente en un inicio, esta guiá nace como un pre-requisito para la implementación de un sistema de desbloquear remoto y seguro de particiones LUKS durante el proceso de boot.

Salu2 :)

Red y SSH en Stage1 (boot - initrd) de NixOS - Parte 1

Federico Jensen — Fri, 04 Apr 2025 16:34:23 +0000

Ninguna IA ha estado involucrada en la creacion de este articulo

Contexto

En la siguiente guía veremos cómo configurar las interfaces de redes para poder tener conexión a internet durante la Stage1 (init ram disk o initrm) de NixOS. Más específicamente, en esta primera parte de la articulo veremos como configurar la interfaz Ethernet. Y luego nos conectaremos, de forma remota, con SSH a la Stage1. En la segunda parte del articulo veremos como lograr lo mismo usando una interfaz inalámbrica (algo que supone algunos otros desafíos).

¿Porque querer tener Red en Stage1?... bueno, esta guiá realmente es parte de un pre-requisito de un proyecto mas grande. Una implementación para lograr descifrar, de forma remota y segura, particiones cifradas con LUKS.

Esta guiá forma parte de un compendio de clases/tutoriales para crear y gestionar un HomeLab usando NixOS.

Este articulo posee un video asociado donde se pueden encontrar mas detalles y el paso a paso:

Red y SSH en Stage1 de NixOS - Parte 1

Guiá donde habilitamos conexión a la red y un servidor SSH en la Stage1 (init ram disk) en NixOS.

odysee.com

Introducción

La Stage1 de NixOS es una rutina de procesos, dentro del boot, que suceden antes que el sistema operativo esté totalmente cargado. Durante esta etapa se carga el Kernel, se detectan y configuran los distintos elementos del hardware y se montan los sistemas de archivos. Todo este proceso sucede “en memoria”, o sea, usando la RAM como espacio de almacenamiento. Esto hace que sea efímero... se destruye una vez se alcanza la Stage2 (momento donde realmente los procesos, de lo que será nuestro OS, inician). Debido a que Stage1 tiene una función muy específica: "preparar el hardware y sistemas de archivos para Stage2", esta etapa carga solo el mínimo de elementos necesarios para lograr su objetivo... Stage1 es una especie de "pre-linux mínimo auxiliar y efímero". Por ello, intervenir y dotar esta etapa de funcionalidades, como conectividad a internet o un servidor SSH, puede ser no trivial. Por suerte NixOS ya posee algunas configuraciones que nos ayudaran. Este desafió es una buena oportunidad para aprender mas de los proceso de boot, NixOS y linux en general.

El Plan:

Parte 1 (este post)

Lograr “pausar” el arranque del sistema al final de Stage1 (y antes que Stage2) para poder debugear nuestro trabajo de forma mas cómoda.
Lograr tener red en Stage1 mediante una interfaz Ethernet.
Implementar un servidor SSH en Stage1 para poder conectarnos desde un equipo remoto (mediante Ethernet) para poder interactuar con los procesos y sistema de archivo de initrm.

Parte 2 (...el la Parte 2)

Instalar, si es necesario, los drivers del adaptador inalámbrico para poder que sea detectado y cargado en Stage1.
Validar que en Stage1 podemos escanear redes y conectarnos a ellas de manera segura.
Automatizar el proceso de conexión a WiFi en Stage1 y probar el acceso remoto usando SSH.

1) “Pausar” el arranque en Stage1

Si tu NixOS esta cifrado con LUKS la "pausa" en Stage1 ya esta activa; no debes hacer nada. El momento, durante el boot, cuando se pregunta al usuario por la clave LUKS, es exactamente la frontera entre el Stage1 y Stage2.

Recordemos que LUKS es una manera de tener cifrado nuestro OS de forma completa. Es una opción que solo puede ser activada durante la instalación del OS y es muy recomendado usarla si la privacidad/seguridad son de tu interés.

Por lo tanto ya estas listo con el paso 1 si estas usando LUKS.

En caso que estés siguiendo esta guiá pero no estés usando LUKS, no temas, existe una forma "manual" de detener el proceso de boot entre Stage1 y Stage2. Para esto debemos usar un script, el cual llamaremos "force-pause-script", que se inicie al final de Stage1 y pause el proceso de boot hasta que nosotros lo indiquemos.

Puedes añadir este script a tu /etc/nixos/hardware-configuration.conf:

boot.initrd.systemd = {
  enable = true;
  services.force-pause-script = {
    enable = true;
    after = [ "basic.target" ];
    before = [ "default.target" ];
    wantedBy = [ "default.target" ];
    unitConfig = { 
      Description = "ForcePause";
      DefaultDependencies = false; 
    };
    serviceConfig = {
      Type = "oneshot";
      ExecStart = "${pkgs.bash}/bin/sh -c 'read'";
      StandardInput = "tty";
    };
  };
};

Nota: Quiero aclarar que esta guiá esta pensada para quienes usen LUKS principalmente. Por lo tanto, usar el script anterior puede implicar que debas cambiar algunas cosas mencionadas más adelante. Específicamente deberás cambiar donde uso systemd-ask-password-console.service, ya que tu sistema no tendrá este servicio.

Esto pausará tu boot durante Stage1, para continuar con el proceso de boot presiona cualquier tecla.

2) Activando la interfaz Ethernet en Stage1

Lo primero que necesitamos es identificar el nombre de nuestra interfaz Ethernet. Podemos usar el comando ip link para listar las interfaces disponibles. En mi caso la interfaz Ethernet tiene por nombre “enp0s3” (usare este nombre durante la guiá a modo de ejemplo).

Ahora podemos añadir lo siguiente en nuestro /etc/nixos/hardware-configuration.nix:

boot = {
  initrd = {
    systemd = {
      enable = true;
      network = {
        enable = true;
        networks = {
          enp0s3 = {
            enable = true;
            name = "enp0s3";
            DHCP = "yes";
          };
        };
      };
    };
  };
};

Recuerda usar reemplazar el nombre de tu interfaz Ethernet como corresponda.

Nota 1: Durante Stage1 pueden ver que usaremos “systemd”. Esto quiere decir que un “systemd” (independiente al normalmente usado en Stage2) estará encargado de gestionar los procesos de arranque de init ram disk. Es importante mencionar que el uso de systemd en initrd aun es experimental en NixOS; a pesar de esto, según mi experiencia funciona de forma estable.

Nota 2: Vamos a usar DHCP para asignar IP, Gateway y DNS a nuestra interfaz Ethernet. Luego lo cambiaremos a una definición estática para facilitar el proceso de conexión por SSH.

En teoría, con esto, ya deberíamos tener red en Stage1.

En Stage1 se usará la interfaz Ethernet para iniciar una conexión a la red. Comprobar si esto está funcionando de manera correcta puede ser algo mas complejo. Una opción puede ser revisar los dispositivos conectados en las opciones de nuestro router. Otra manera podría ser usar una herramienta para analizar la red local y detectar los dispsitivios participantes.

Nosotros vamos a optar poder añadir un script a Stage1 que imprimirá en el log de boot los detalles de nuestra conectividad. Luego vamos a revisar dicho log para asegurarnos que todo este bien.

El script lo vamos a guardar en /etc/nixos/hardware-configuration.nix:

boot = {
  initrd = {
    systemd = {
      ...
      initrdBin = [ pkgs.iproute2 ];
      services = {
        CustomScript = {
          enable = true;
          wants = [ "systemd-udev-settle.service" ];
          after = [ "systemd-udev-settle.service" ];
          before = [ "systemd-ask-password-console.service" ];
          wantedBy =  [ "systemd-ask-password-console.service" ];
          unitConfig = { 
            Description = "CustomScript"; 
            DefaultDependencies = false;
          };
          serviceConfig = {
            Type = "oneshot";
            ExecStart="${pkgs.bash}/bin/sh -c 'sleep 5 && ip addr'";
          }; 
        };
      };
      ...
    };
  };
};

Nota 1: En Stage1 muchos comandos no están disponibles. Debemos usar initrdBin para especificar los paquetes que queremos incluir en Stage1. Vamos a incluir iproute2 para poder usar el comando ip en el script.

Nota 2: El script se ejecutará antes que se nos solicite la clave LUKS en Stage1 y dejará el output de "ip addr" en el log. El sleep es para dar tiempo a que la interfaz este totalmente configurada. Las opciones de wants, after, before y wantedBy nos ayudan a que el script se ejecute el la secuencia y momento preciso. Específicamente esperar systemd-udev-settle.service nos asegura que el hardware esté disponible. Y systemd-ask-password-console.service a ejecutar el script antes que se pregunte por la contraseña LUKS (momento en que Stage1 queda “pausado”).

Nota 2.1: Si no estas usando LUKS y estas usando el script "force-pause-script" (indicando al inicio del post), cambia systemd-ask-password-console.service por force-pause-script.service tanto en before como wantedBy.

Nota 4: En caso que experimentes con scripts de systemd puede ser algo difícil saber sus "estados" y "orden de ejecución". Aquí te dejo algunos comandos (entre muchos otros) que pueden ser de utilidad para debugear:

systemctl list-units
systemctl status <nombre-del-servicio/target>
systemctl list-dependencies --all <nombre-del-servicio>
systemctl list-dependencies --reverse <nombre-del-servicio>

Con esto listo, ahora vamos a reiniciar el sistema… pasar por el proceso de boot… esperar unos segundos… introducir la clave LUKS… y volver a nuestro escritorio de NixOS.

Una vez en el escritorio usaremos el comando journalctl -b para ver el log de nuestro último proceso de boot.

Lo que queremos saber, es si por defecto, se ha encontrado y encendido la interfaz Ethernet ("enp0s3" en mi caso). Buscando en log del boot, deberemos encontrar el output de “ip addr”. Si todo va bien deberemos ver la interfaz Ethernet listada en dicho output. No solo eso, sino que también debería tener una IP asignada. Si esto es así, podemos seguir con el siguiente paso; configurar el servidor SSH.

En caso que no se encuentre la interfaz Ethernet en Stage1... tenemos un problema. Un problema de drivers. Para solucionar esto deberemos recorrer una tangente:

2.1) Buscando y cargando drivers Ethernet en Stage1 de NixOS

Si en Stage1 no vemos la interfaz Ethernet, pero en Stage2 (escritorio de toda la vida) si tenemos conexión... tenemos un indicativo que el driver relacionado no esta siendo "cargado completamente" durante Stage1.

Para solucionar esto deberemos hacer un poco de investigación. Objetivo: averiguar el nombre del driver de Ethernet que "si" esta presente en Stage2 pero que "no" esta cargado en Stage1. Para esto podemos hacer uso de un par de herramientas. Instalaremos en /etc/nixos/configuration.nix:

Cada una de estas herramientas nos ayudarán a listar y averiguar mas del hardware que use el bus PCI o USB. En mi caso, se que mi interfaz Ethernet usa el bus PCI, así que usare pciutils. Pero puede que ustedes necesiten usar usbutils si su interfaz usa USB. Una vez instaladas esta herramientas en NixOS:

Usando los comandos lspci -k o lsusb -t vamos a tratar de buscar nuestro adaptador Ethernet. Lo que estamos buscando es el nombre del “modulo”/“kernel” o “module”/“driver” relacionado al adaptador de red.

Leyendo el output de lspci -k yo he podido identificar claramente que el "kernel module" usado para mi interfaz de red se llama: "e1000". Dicho driver lo debemos incluir para que sea totalmente cargado en Stage1.

Para esto, debemos añadir el nombre del driver al listado de availableKernelModules definido en /etc/nixos/hardware-configuration.nix:

boot.initrd.availableKernelModules = [ "e1000" … ];

Luego de: construir nuestra nueva generación de NixOS, reiniciar el sistema y regresar a nuestro escritorio... entraremos nuevamente al log del boot con journalctl -b. Si examinamos nuevamente el output de “ip addr”, deberíamos ver que ahora efectivamente esta listada la interfaz Ethernet (enp0s3 en mi caso).... y más aun... también deberíamos tener una IP asignada.

Si por alguna razón no funciona, seguramente el nombre de nuestro driver esta incorrecto. En este caso el mejor aliado es Google. Buscando un poco deberíamos ser capaces de encontrar cual es el driver indicado para nuestra interfaz Ethernet.

3) Configurando SSH en Stage1

Nota previa: Durante todo el proceso hasta el momento (y lo que continúa) puede que nuestra partición boot (donde se almacenan todos los cambios relacionados a Stage1) se quede sin espacio. Para liberar el caché podemos usar el comando: sudo nix-collect-garbage -d (ojo, tiene que ir con sudo para que limpie correctamente). Generalmente la partición boot es bastante pequeña, así que termina siendo habitual limpiar el cache cada unas 5 a 10 generaciones de NixOS.

Es aconsejable usar sudo nix-collect-garbage -d antes de un sudo nixos-rebuild switch y no después. Limpiar el caché borra las generaciones anteriores del OS, usando los comandos en este orden nos aseguramos de siempre mantener “la versión previa” disponible (algo que puede ser necesario en caso de “romper” el OS).

Bien, ahora que tenemos Stage1 con red, vamos a querer conectarnos por SSH para poder ejecutar comandos y debuggear directamente Stage1.

Lo primero que vamos a necesitar es generar una dupla de claves privada-pública. En nuestro equipo remoto (desde donde nos vamos a conectar a Stage1) vamos a generar la dupla de claves RSA.

En Windows podemos usar PuttyGen y en linux ssh-keygen

La clave pública generada la dejamos en nuestro NixOs en el fichero /etc/nixos/authorized_keys. Si tienes dudas sobre como debe ser el formato de las claves guardadas en authorized_keys, puedes leer esto.

Debido a un bug, al cual no quiero entrar a explicar, vamos a tener que generar una “key de host”; sin esto el servidor SSH no va a iniciar. Para esto en nuestro NixOS ejecutamos: ssh-keygen -t rsa -N "" -f /etc/nixos/host_key.

Ahora ya tenemos los archivos con las credenciales necesarias listas y guardadas. Pero debemos recordar algo. Stage1 es un "espacio aislado" y se ejecuta en la ram durante el boot. O sea, Stage1 no tiene acceso directo a estas credenciales que hemos guardado en /etc/nixos. Debemos primero indicar a NixOS que genere una "copia" de estos "secretos" desde el sistema de archivos del usuario al espacio que puede ser accedido durante intird.

Para esto podemos usar secrets en nuestro /etc/nixos/hardware-configuration.nix:

boot = {
  initrd = {
    ...
    secrets = {
      "/etc/nixos/authorized_keys" = "/etc/nixos/authorized_keys";
      "/etc/nixos/host_key" = "/etc/nixos/host_key";
    };
    ...
  };
};

Con esto estaremos copiando los ficheros de directorio /etc/nixos/ del sistema de ficheros del usuario, a un directorio exactamente con el mismo nombre /etc/nixos/... pero que se montará en el ram disk durante Stage1

Nota 1: NixOS maneja los secretos en la Stage1 de una manera en la cual no se borran al crear una nueva generación de OS. Por lo tanto, siempre que cambiemos los secretos es buena practica usar: sudo nix-collect-garbage -d para eliminar/sobre-escribir las credenciales previas.

Nota 2: Con secrets hay tener cuidado de usar comillas (“”) al referenciar los paths. Esto es importante para que las credenciales se almacenen de forma segura.

Ahora activaremos el SSH en /etc/nixos/hardware-configuration.nix:

boot = {
  initrd = {
    ...
    network = {
      ssh = {
        enable = true;
        port = 2222;
        authorizedKeyFiles = [ "/etc/nixos/authorized_keys" ];
        hostKeys = [ "/etc/nixos/host_key" ];
      };
    };
    ...
  };
};

Los archivos referenciados en authorizedKeyFiles y hostKeys seran buscados en el sistema de archivos de ram disk del Stage1. Gracias al uso de secrets estos estarán disponibles en dicho lugar.

Ojo: Las definiciones de ssh van dentro del segmento boot.initrd.network no boot.initrd.systemd.network... es fácil confundirse entre ellos.

Y listo, ya deberíamos tener configurado nuestro servidor SSH en Stage1.

Pero... aprovechando que estamos en hardware-configuration.nix podemos:

Desactivar el CustomScript que usamos durante la primera etapa de este proceso... ahora que vamos a tener acceso por SSH no necesitamos mas dicho script.
Desactivar el DHCP de la interfaz Ethernet y asignar manualmente los parámetros de: IP (address), Gateway y DNS. Aunque varia de router a router, puede que cada vez que estemos iniciando NixOS se este asginando una IP distinta a la interfaz Ethernet. Esto puede ser algo molesto si usamos SSH. Lo mejor es fijar dichos valores. Para lograr esto debemos desactivar DHCP en hardware-configuration.nix (segmento de networks):

...
systemd = {
...
  network = {
    enable = true;
    networks = {
      ...
      enp0s3 = {
        enable = true;
        name = "enp0s3";
        #DHCP = "yes" #Comentamos DHCP para desactivarlo
        #Asignamos los valores manualmente
        address = [ "192.168.1.20/24" ];
        gateway = [ "192.168.1.1" ];
        dns = [ "8.8.8.8" ];
      };
      ...
    };
  };
  ...
};
...

Recuerda usar el nombre de tu interfaz Ethernet. La address y gateway dependerán de tu red local. Puedes usar los comandos: ip route y ip addr para saber que IP y Gateway tienes asignada y usar dichos valores en la configuración. Para el DNS puedes usar el de Google (8.8.8.8) a prueba... 1.1.1.1 también puede ser una alternativa.

Bien! Finalmente vamos a crear una nueva generación de NixOS con todos estos cambios y reiniciar el sistema.

Si todo va bien, cuando Stage1 se detenga para pedirnos la clave LUKS, vamos a tener la posibilidad de acceder de forma remota usando SSH. Recuerda usar la IP del NixOS que acabamos de configurar y puerto (2222) correcto. También recuerda usar la llave privada correspondiente a la llave publica que usamos para configurar el servidor SSH.

El usuario de Stage1 por defecto es: root

Nota: Recuerda que el propósito del SSH en Stage1 es meramente para debugear. Una vez tengas el Stage1 funcionando como quieras, es 100% recomendable desactivar el servidor y eliminar las credenciales asociadas.

bonus) Solucionando bug de red Stage1 -> Stage2

Puede que durante, o al finalizar esta guiá, se percataran de un extraño error. Cuando usamos network en Stage1, el NetworkManager de Stage2 se vuelve algo "tonto" y no se conecta automáticamente a las redes cuando se nos presenta el escritorio del OS. Al parece esto se debe a que determinadas configuraciones de redes son pasadas de Stage1 a Stage2 y el sistema no "refresca" correctamente la asignación de IP.

La manera mas fácil de solucionar esto es apagar y encender el NetworkManager cuando estemos en el escritorio de NixOS. Pero claramente es bastante incomodo tener que hacer esto en cada inicio.

Aquí presento un script (muy "bruto") que automáticamente realiza el proceso anterior. Para implementarlo en vamos a nuestro /etc/nixos/configuration.nix y añadimos el servicio:

systemd.services.reset-network = {
  enable = true;
  description = "Reinicia NetworkManager para evitar configuraciones duplicadas";
  wants = [ "network-manager.service" ];
  after = [ "network-manager.service" ];
  wantedBy = [ "multi-user.target" ];
  serviceConfig = {
    ExecStart = "${pkgs.bash}/bin/sh -c 'until systemctl is-active --quiet NetworkManager; do sleep 1; done && nmcli networking off && sleep 5 && nmcli networking on'";
    Type = "oneshot";
    RemainAfterExit = true;
    Environment = "PATH=${pkgs.networkmanager}/bin:${pkgs.bash}/bin:${pkgs.coreutils}/bin:${pkgs.systemd}/bin:$PATH";
  };
};

El script espera que el servicio de NetworkManager este "activo", para luego desactivarlo y volver a encenderlo. Esto limpia "sea lo que sea" que provoca el error.

También puede ser necesario agregar en /etc/nixos/hardware-configuration.nix esto:

boot.initrd.network.flushBeforeStage2 = false;

Esta declaración "originalmente" se supone que funcionaba, exactamente, para solucionar el bug que estamos comentando. Como dice el nombre: "network flush before stage2". Pero por alguna razón al usarlo en conjunto a boot.initrd.systemd no funciona. Por tanto lo mejor es dejarlo apagado para que no rompa nada.

Final primera parte

Espero que esta guiá los ayudara a obtener conexión a red durante el Stage1 de NixOS y/o a implementar un servidor SSH para poder debugear este segmento del proceso de boot.

Quiero agradecer al blog de Spencer Balogh por su guiá indispensable en comprender como funciona el networking de Stage1.

Como comente en un inicio, esta guiá nace como un pre-requisito para la implementación de un sistema de desbloquear remoto y seguro de particiones LUKS durante el proceso de boot.

En la Parte 2 de esta guiá veremos como lograr obtener red durante Stage1 pero usando una interfaz inalámbrica WiFi. Esto añade desafíos relacionados a drivers, protocolos de seguridad WiFi y uso de credenciales inalámbricas.