oriolrius.cat

Des del 2000 compartiendo sobre…

Inicio

Gestión de certificados (PKI) – easy-rsa

2025/01/31 05:55

Serie

  1. Gestión de certificados (PKI) – easy-rsa
  2. MQTT Broker (Mosquitto) con certificado servidor (self-signed)
  3. MQTT Broker (Mosquitto) con certificado servidor (self-signed) y certificado en los clientes
  4. MQTT Broker (Mosquitto) con certificado servidor (Let’s Encrypt)
  5. Formatos de Certificados: PEM, DER y PKCS#12 y Manipulación de Claves Privadas

Introducción a la Infraestructura de Clave Pública (PKI)

Una PKI, o Infraestructura de Clave Pública, es un sistema que gestiona certificados digitales y claves para garantizar comunicaciones seguras. Vamos a desglosar los conceptos básicos.

Conceptos Clave

  • PKI: Es el sistema completo que conecta Certificados de Autoridad (CA), claves y certificados para garantizar la confianza entre entidades.
  • CA (Certificate Authority): Es el “jefe” de la PKI. Firma y valida certificados, garantizando que son de confianza.
  • Certificado: Documento digital que incluye una clave pública, información sobre la entidad, y la firma del CA. Es como un pasaporte digital.
  • Solicitud de Certificado: Es un “borrador” del certificado que una entidad envía al CA para que lo firme.
  • Par de Claves (Keypair): Un conjunto de dos claves: una pública (para compartir) y otra privada (secreta). Por ejemplo, la pública es como tu dirección de correo y la privada como la contraseña.

¿Qué es un CA y por qué es importante?

El CA es el núcleo de una PKI y su clave privada es extremadamente sensible porque firma todos los certificados. Para protegerla, se recomienda mantenerla en un entorno seguro, como un sistema dedicado o incluso desconectado de la red.

¿Cómo funciona todo esto?

  1. Creación del CA: Se genera un par de claves y la estructura necesaria para gestionar certificados.
  2. Solicitud de Certificado: Un cliente (por ejemplo, un servidor VPN) crea un par de claves y envía su solicitud al CA.
  3. Firma y Certificado: El CA verifica la solicitud y utiliza su clave privada para firmar el certificado, que luego devuelve al cliente.

¿Cómo se verifica un certificado? Ejemplos prácticos

La verificación de certificados varía según el contexto, y quiero explicarlo con dos ejemplos claros: una conexión a una VPN, donde yo tengo un par de claves y un certificado, y una conexión a un banco, donde no necesito un par de claves, solo la confianza en la CA.

Ejemplo 1: Conexión VPN (yo tengo mi par de claves y certificado)

Cuando me conecto a una VPN, tanto el cliente como el servidor necesitan un par de claves (pública y privada) y certificados firmados por la misma CA. El proceso es el siguiente:

  1. Yo genero mi par de claves y solicito un certificado al CA, que verifica mi identidad y firma mi certificado.
  2. Cuando intento conectar al servidor VPN, este me presenta su certificado.
  3. Yo verifico que el certificado del servidor fue firmado por el CA en el que confío.
  4. Luego, envío mi propio certificado al servidor, que hace la misma verificación con su copia del CA.
  5. Si todo es válido, ambos usamos nuestras claves privadas para intercambiar información cifrada y establecer una conexión segura.

Por ejemplo, si trabajo remotamente y necesito acceder a la red de mi empresa, configuro un cliente VPN con mi certificado y claves. El servidor verifica que yo soy quien digo ser y me deja entrar solo si la verificación es correcta.

Ejemplo 2: Conexión a un banco (sin par de claves, solo confianza en la CA)

Cuando accedo a la web de mi banco desde mi navegador, no necesito un par de claves personal. Simplemente, confío en los certificados emitidos por las CA incluidas en la lista de confianza de mi navegador. Así funciona:

  1. El servidor del banco me envía su certificado.
  2. Mi navegador verifica que el certificado fue firmado por una CA en su lista de confianza y que este no está caducado ni revocado.
  3. Si la verificación es exitosa, se establece una conexión segura mediante TLS/SSL.
  4. Durante la conexión, el banco usa su clave privada para demostrar que es legítimo, firmando datos que mi navegador valida con la clave pública incluida en el certificado del banco.

Por ejemplo, cuando accedo a https://mi-banco.com, mi navegador me muestra un candado en la barra de direcciones. Esto significa que ha validado el certificado del banco y ahora la conexión es segura. Aunque yo no tengo claves en este caso, confío en la autoridad que firmó el certificado del banco.

Vamos a crear nuestra propia PKI y la gestión de certificados usando easy-rsa

Easy-RSA es una herramienta poderosa y sencilla para gestionar una infraestructura PKI (Infraestructura de Clave Pública). Con ella puedo emitir certificados para servidores VPN, páginas web, y clientes que necesiten conexiones seguras. Aquí explicaré cómo utilizar Easy-RSA para construir esta infraestructura y cómo interpretar sus resultados.

Importante mencionar que easy-rsa no son más que unos scripts que simplifican el uso de OpenSSL que es la verdadera herramienta que hay por detrás gestionando los certificados, claves y demás.

Configuración del archivo vars en Easy-RSA

El archivo vars permite configurar parámetros básicos y avanzados antes de iniciar el PKI con init-pki, ahorrando tiempo y garantizando consistencia. Para empezar, copio vars.example a vars y relleno las partes que me interesen, como:

  • Datos del certificado: País, ciudad, organización, etc.
  • Claves y algoritmos: Tamaño (2048 bits) y tipo (RSA o EC).
  • Duración: Expiración de la CA y certificados.
set_var EASYRSA_REQ_COUNTRY "ES"
set_var EASYRSA_REQ_ORG "MiEmpresa"
set_var EASYRSA_KEY_SIZE 2048
set_var EASYRSA_CA_EXPIRE 3650
set_var EASYRSA_CERT_EXPIRE 825

Paso 1: Preparar Easy-RSA

Primero, descargo Easy-RSA desde su repositorio oficial. Como no requiere instalación, simplemente extraigo el archivo comprimido (.tar.gz para Linux/Unix o .zip para Windows) en el directorio que prefiera.

Para comenzar, inicializo el directorio de PKI con:

./easyrsa init-pki

Esto crea una estructura de directorios básica para gestionar los certificados. El directorio pki incluye:

  • private/: Guarda claves privadas (debe mantenerse muy seguro).
  • reqs/: Contiene solicitudes de certificados.
  • issued/: Almacena certificados emitidos.
  • ca.crt: El certificado de la CA (Autoridad Certificadora).
  • private/ca.key: La clave privada de la CA, crítica para la seguridad de toda la infraestructura.

Paso 2: Crear la Autoridad Certificadora (CA)

La CA es el corazón de mi PKI. Es quien firma los certificados y garantiza su validez. Creo la CA con:

./easyrsa build-ca

Durante este proceso, defino un nombre común (Common Name, CN) para identificar mi CA, y se me pedirá configurar una frase de contraseña fuerte para proteger la clave privada (ca.key). Este archivo es extremadamente sensible, y su seguridad es crítica.

El resultado principal de este paso es:

  • ca.crt: El certificado público de la CA, que compartiré con clientes y servidores para verificar certificados.

Paso 3: Generar claves y solicitudes de certificados

Para que un cliente o servidor VPN funcione, primero genero un par de claves (privada y pública) junto con una solicitud de certificado (CSR). Esto se hace con:

./easyrsa gen-req <nombre-del-certificado|FQDN>
# muy importante usar FQDN (Fully Qualified Domain Names) para evitar
# problemas de matching con los hostnames usados en la conexión.

Por ejemplo, para un servidor VPN:

./easyrsa gen-req vpn-server.example.tld

El comando genera dos archivos:

  1. private/<nombre-del-certificado>.key: La clave privada. Este archivo debe permanecer en el servidor o cliente correspondiente y nunca compartirse.
  2. reqs/<nombre-del-certificado>.req: La solicitud de certificado (CSR). Este archivo se envía al CA para ser firmado.

Paso 4: Firmar solicitudes de certificados

Una vez que tengo la solicitud (.req), la importo en el CA y la firmo. Esto se realiza con:

1. Importar la solicitud

# solo hay que hacer este paso si el certificate request 
# lo hemos copiado de otra máquina. Esto lo coloca en path
# para que todo vaya automático, incluidas futuras 
# renovaciones.
./easyrsa import-req /the-path/vpn-server.example.tld.req vpn-server.example.tld

2. Firmar la solicitud

./easyrsa sign-req server vpn-server.example.tld

Easy-RSA generará un certificado firmado en pki/issued/servidor-vpn.crt. Este archivo es lo que el servidor VPN utiliza para identificarse de forma segura ante sus clientes.

Paso 5: Configuración de un servidor y cliente VPN

Servidor VPN

Para configurar un servidor VPN (como OpenVPN), necesitaré los siguientes archivos generados por Easy-RSA:

  1. Clave privada (private/servidor-vpn.key): Usada por el servidor para encriptar las comunicaciones.
  2. Certificado firmado (issued/servidor-vpn.crt): Garantiza que el servidor es confiable.
  3. Certificado de la CA (ca.crt): certificado y clave pública de nuestra PKI.

Estos archivos se colocan en el directorio de configuración del servidor VPN y se referencian en su configuración.

Cliente VPN

Hay que repetir el paso 4, en este caso una buena práctica es poner como “nombre-del-certificado” el nombre del usuario, o el cliente, que pide el certificado de acceso. En algunos casos de uso, eso permite no tener que pasar por un proceso de autenticación.

Después de generar la petición y haberla importado, como indica la primera parte del paso 5. Hay que ir muy en cuidado con el segundo paso. Al firmar el certificate request hay que hacerlo indicando que su uso será de cliente, no de servidor.

# creamos el certificate request
./easyrsa gen-req mi-nombre-de-usuario

# importamos el certificado si es necesario en la PKI
./easyrsa import-req /the-path/mi-nombre-de-usuario.req mi-nombre-de-usuario

# firmamos el certificate request indicando el uso como cliente
./easyrsa sign-req client mi-nombre-de-usuario

Después de firmar el certificate-request ya tenemos los ficheros que deberá usar el cliente para conectarse al servidor:

  1. Clave privada (private/mi-nombre-de-usuario.key): Usado por el cliente para encriptar las comunicaciones.
  2. Certificado firmado (issued/mi-nombre-de-usuario.crt): Garantiza que el servidor es confiable.
  3. Certificado de la CA (ca.crt): certificado y clave pública de nuestra PKI.

NOTA:

Cuando se firma un certificado las posibles opciones a seleccionar son:

  • client – es para TLS client, típicamente usado para usuarios de VPN, o para navegadores Web
  • server – para TLS server, típicamente servidores Web y servidores VPN.
  • ca – cuando queremos crear CA (Certificate Authorities) en cascada, esto emite un certificado intermedio. Técnicamente, lo llaman chaining certificate.
  • serverClient – certificado que serve tanto para cliente como para servidor TLS.

Paso 6: Configuración para servidores web

El proceso es similar para un servidor web (HTTPS). Genero una solicitud de certificado para el dominio del servidor (por ejemplo, mi-servidor.com) y la firmo con la CA. Los archivos necesarios serán:

  1. Clave privada (private/mi-servidor.key): Exclusiva del servidor web.
  2. Certificado firmado (issued/mi-servidor.crt): Identifica al servidor web.
  3. Certificado de la CA (ca.crt): Permite a los navegadores validar la conexión.

Estos archivos se configuran en el servidor web (como Apache o Nginx) para habilitar HTTPs.

Gestión de certificados emitidos, CRL y Validación en Tiempo Real con OCSP

Easy-RSA no solo permite emitir y revocar certificados, sino que también facilita la gestión de la revocación mediante la generación de listas de certificados revocados (CRL) y la implementación de validación en tiempo real a través de OCSP. Cuando se detecta que una clave privada ha sido comprometida o un certificado ya no es necesario, se procede a su revocación:

  1. Revocar un certificado:
    Utiliza el comando: ./easyrsa revoke <nombre-del-certificado> Esto marca el certificado como revocado dentro de la base de datos de la PKI.
  2. Generar la CRL:
    Una vez revocados los certificados, es necesario generar una nueva lista de revocación. Esto se realiza con: ./easyrsa gen-crl Este comando genera dos ficheros:
    • crl.pem: La CRL en formato Base64.
    • crl.der: La CRL en formato binario.
      Estos archivos deben publicarse en un servidor accesible para que los clientes puedan descargarlos y comprobar el estado de los certificados.

Aunque la CRL es la solución tradicional para gestionar certificados revocados, presenta limitaciones como el tamaño de la lista y la necesidad de descargarla por completo en cada comprobación. Para solventar estas deficiencias, se puede implementar OCSP (Online Certificate Status Protocol).

OCSP es un protocolo definido en el RFC 2560 que permite a un cliente consultar el estado de un certificado de forma puntual y en tiempo real, sin tener que procesar toda la CRL. Entre sus ventajas destacan:

  • Información actualizada: Permite obtener el estado de revocación de un certificado al momento de la consulta.
  • Eficiencia: Reduce el tráfico y la carga de procesamiento en el cliente, ya que se consulta solo el certificado específico.
  • Privacidad: Evita la exposición de información potencialmente sensible contenida en la CRL.
  • Escalabilidad: Emplea mecanismos optimizados (a menudo basados en motores de base de datos) para gestionar consultas incluso en entornos con un gran número de certificados.

Implementación de un Servidor OCSP con OpenSSL:

Para poner en marcha un servidor OCSP, utiliza el siguiente comando:

openssl ocsp -index /ruta/a/tu/index.txt -port 2560 -ignore_err -rsigner /ruta/a/tu/ocsp.crt -rkey /ruta/a/tu/ocsp.key -CA /ruta/a/tu/ca.crt -text -out /ruta/a/tu/log_ocsp.txt &

Donde:

  • -index indica el archivo que contiene el índice de certificados emitidos.
  • -port define el puerto en el que el servidor OCSP escuchará (en este ejemplo, 2560).
  • -ignore_err permite que el servidor continúe operando incluso si recibe peticiones malformadas.
  • -rsigner y -rkey especifican el certificado y la clave privada del OCSP responder.
  • -CA señala el certificado de la CA emisora.
  • -text -out guarda un log detallado de las operaciones.

Para consultar el estado de un certificado (por ejemplo, newcert.pem), ejecuta:

openssl ocsp -CAfile /ruta/a/tu/ca.crt -issuer /ruta/a/tu/ca.crt -cert newcert.pem -url http://tu-dominio:2560 -resp_text

Esta consulta permite verificar de forma inmediata si el certificado está revocado o sigue siendo válido.

Integrar la generación y publicación de CRL con un servidor OCSP proporciona un mecanismo completo para la gestión de certificados emitidos. Mientras que la CRL ofrece una solución tradicional basada en la descarga de una lista completa, OCSP permite a los clientes obtener el estado de un certificado de forma ágil y en tiempo real, optimizando el proceso de validación y reduciendo la carga en la red. Este enfoque combinado asegura que, tanto en entornos de pruebas como en producción, se disponga de mecanismos robustos para mantener la integridad y seguridad de la infraestructura PKI.

Renovar un certificado

Normalmente, poco antes de caducar un certificado se pide su renovación. Esto emitirá otro fichoero de certificado firmado por la CA como el que se emetió la primera vez, pero con una nueva fecha de caducidad: 

./easyrsa renew <nombre-del-certificado>

una vez generado el nuevo certificado en:

  • issued/mqtt.example.tld.crt – certificado renovado

es buena idea ejecutar el siguiente comando para asegurarse que el viejo certificado queda obsoleto: 

./easyrsa revoke-renewed <nombre-del-certificado>

esto nos acaba forzando a generar una nueva lista de certificados revocados. O sea, hay que ejecutar:

./easyrsa gen-crl

y en consecuencia distribuir el nuevo fichero CRL.

Conclusión

Easy-RSA simplifica la creación y gestión de una infraestructura PKI, lo que me permite emitir y administrar certificados para VPNs y servidores web. Sus outputs, como las claves privadas, certificados firmados, y el certificado de la CA, son los componentes esenciales para garantizar conexiones seguras. Con esta herramienta, puedo construir mi propia red confiable para asegurar tanto servidores como clientes en diferentes escenarios.

Referencias

WireGuard Over TCP Using udp2raw: Securing and Expanding Connectivity – Point-to-Multipoint – CookBook

2025/01/30 16:23

Scenario Overview

The architecture for this setup is illustrated below:

Install udp2raw, Wireguard and generate keys

cd /tmp
wget https://github.com/wangyu-/udp2raw/releases/download/20230206.0/udp2raw_binaries.tar.gz
tar xvfz udp2raw_binaries.tar.gz
cp udp2raw_amd64 /usr/local/bin/udp2raw
rm udp2raw*
# based on Ubuntu
apt install wireguard
# we'll work on /etc/wireguard
cd /etc/wireguard
# generate privatekey
wg genkey | sudo tee /etc/wireguard/private.key
sudo chmod go= /etc/wireguard/private.key
# obtain public key
sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key

When eveything is installend and configured, just run in all endpoints next commands:

sudo wg-quick up wg0
# for status check:
wg
# udp2raw logs at:
tail -f /var/log/udp2raw.log
# enable automatic wireward service in Ubuntu
sudo systemctl enable wg-quick@wg0.service
# start and stop service like always
sudo systemctl start wg-quick@wg0.service
sudo systemctl stop wg-quick@wg0.service
sudo systemctl status wg-quick@wg0.service

Configuration Files

Endpoint A /etc/wireguard/wg0

# local settings for Endpoint A
[Interface]
PrivateKey = WMUerfcUpSxUlOp1UmaS2uwelnk8AxhAFrlIWpjheWM=
Address = 192.168.111.1/24
ListenPort = 51822

# receive wg through udp2raw
MTU = 1342
PreUp = udp2raw -s -l 167.99.130.97:55055 -r 127.0.0.1:51822 -k "The2password." -a >/var/log/udp2raw.log 2>&1 &
PostDown = killall udp2raw || true

# Enable NAT for traffic forwarding (corporate and fallback internet access)
PreUp = echo 1 > /proc/sys/net/ipv4/ip_forward || true
PreUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE || true
PreDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE || true

# remote settings for Endpoint B
[Peer]
PublicKey = XWl8HeAinHlAZTvaCXDlmO9n/CQLg5qH8jmtROK4jBg=
AllowedIPs = 192.168.111.2/32
PersistentKeepalive = 120

# remote settings for Endpoint C
[Peer]
PublicKey = I+gi8l9QRe00W8pTpp8CSoIabz/RXXQXwquXj7eKNwU=
AllowedIPs = 192.168.111.3/32
PersistentKeepalive = 120

Endpoint B /etc/wireguard/wg0

# Endpoint B
[Interface]
PrivateKey = +BB3NI2SUYeKcRoPrZE2+Ot5KnLZJBycPzJ17kfbn34=
Address = 192.168.111.2/24

# Route configuration for public IP
PreUp = ip route del default || true
PreUp = ip route add 167.99.130.97 via 10.2.0.1 dev eth0 || true
PostDown = ip route del 167.99.130.97 via 10.2.0.1 dev eth0 || true
PostDown = ip route add default via 10.2.0.1 || true

MTU = 1342
PreUp = udp2raw -c -l 127.0.0.1:50001 -r 167.99.130.97:55055 -k "The2password." -a >/var/log/udp2raw.log 2>&1 &
PostDown = killall udp2raw || true

# Endpoint A
[Peer]
PublicKey = z73wM1b7fhMRA8fmeQw4FntRvgJ9JwTdsQHssXHg3DE=
Endpoint = 127.0.0.1:50001
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 120

Endpoint C /etc/wireguard/wg0

# Endpoint C
[Interface]
PrivateKey = YCGzsfeed8QumpfE8bdWRheMzBiUsTB7vXj0YVOQQX0=
Address = 192.168.111.3/24

# Route configuration for public IP
PreUp = ip route del default || true
PreUp = ip route add 167.99.130.97 via 10.2.0.1 dev eth0 || true
PostDown = ip route del 167.99.130.97 via 10.2.0.1 dev eth0 || true
PostDown = ip route add default via 10.2.0.1 || true

MTU = 1342
PreUp = udp2raw -c -l 127.0.0.1:50001 -r 167.99.130.97:55055 -k "The2password." -a >/var/log/udp2raw.log 2>&1 &
PostDown = killall udp2raw || true

# Endpoint A
[Peer]
PublicKey = z73wM1b7fhMRA8fmeQw4FntRvgJ9JwTdsQHssXHg3DE=
Endpoint = 127.0.0.1:50001
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 120

discovering mDNS/DNS-SD

2025/01/30 07:33

mdns-scan is a simple tool that scans for mDNS/DNS-SD announcements on the local network and lists discovered services. It doesn’t require the full Avahi daemon; it directly uses multicast DNS queries.

$ sudo mdns-scan
+ nas [44:0e:be:62:58:a5]._workstation._tcp.local
+ nas._http._tcp.local
+ nas._smb._tcp.local
+ nas._qdiscover._tcp.local

In the past I used avahi-browse but it requires dbus, and in some systems I don’t use dbus.

WireGuard Over TCP Using udp2raw: Securing and Expanding Connectivity

2025/01/27 17:36

In this post, I’ll share how I set up a WireGuard VPN over TCP using udp2raw, which provides secure access to corporate networks and serves as a fallback for internet access when customer networks impose heavy restrictions. Inspired by Pro Custodibus, this solution enables IoT gateways to seamlessly connect to both the company’s internal services and the broader internet under constrained conditions.

Scenario Overview

The architecture for this setup is illustrated below:

Key Features of the Solution:

  1. Access to Corporate Networks: IoT Gateways securely connect to the corporate network for accessing internal services.
  2. Fallback Internet Access: When the customer’s network restricts internet access but allows TCP connections to the company infrastructure, the IoT Gateway routes its internet traffic through the company’s network.

How It Works:

  • Endpoint A (Client): An IoT Gateway connects through the restrictive customer network.
  • Endpoint B (Server): The WireGuard server is accessible via a public IP (134.122.74.29) on TCP port 55055.
  • Traffic flows through a TCP tunnel created with udp2raw, enabling the gateway to securely access the corporate network or relay internet traffic via the company’s infrastructure.

This dual-purpose setup ensures robust connectivity for IoT devices even in challenging environments.

Video Demonstration (in Spanish)

I’ve created a video demonstration in Spanish showcasing the entire setup and functionality of this scenario. The video walks through the following steps:

  1. Explaining the problem and network constraints.
  2. Demonstrating the configuration of both endpoints (client and server).
  3. Showing the connection initiation and testing, including how traffic flows through the VPN tunnel.
  4. Verifying fallback internet access through the company network.

This video is ideal for those who prefer visual explanations or need extra guidance in implementing this solution.

Configuration Files

1. Endpoint B (server, /etc/wireguard/wg0.conf)

This configuration allows Endpoint B to act as a gateway for both corporate access and fallback internet connectivity:

# local settings for Endpoint B
[Interface]
PrivateKey = EMqyADu4Xeu95ZpNZE97FET5eKzN1WSwBkeBWtX1yGg=
Address = 192.168.111.1/32
ListenPort = 51822

# receive wg through udp2raw
MTU = 1342
PreUp = udp2raw -s -l 134.122.74.29:55055 -r 127.0.0.1:51822 -k "The2password." -a >/var/log/udp2raw.log 2>&1 &
PostDown = killall udp2raw || true

# Enable NAT for traffic forwarding (corporate and fallback internet access)
PreUp = echo 1 > /proc/sys/net/ipv4/ip_forward || true
PreUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE || true
PreDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE || true

# remote settings for Endpoint A
[Peer]
PublicKey = Xt70DJy8ldPcDNW4YM2Dt94n16pTQKFxhmvpgKvJyng=
AllowedIPs = 192.168.111.2/32
PersistentKeepalive = 120

Key Points:

  • NAT Rules: These rules enable traffic originating from Endpoint A to use Endpoint B for accessing the internet.
  • MTU Adjustment: The MTU is set to 1342 to prevent fragmentation issues over the TCP tunnel.

Assumptions:

  • eth0, is the name of the interface for reaching Internet.
  • 192.168.111.0/24 is available for point-to-point connections in the tunnels.
  • ud2raw is in PATH.
  • Don’t re-use my pub and private keys. Neither the pre-shared key of used by udp2raw.
Endpoint A (client, /etc/wireguard/wg0.conf)

This configuration sets up Endpoint A to route all traffic (corporate and internet) through Endpoint B:

[Interface]
PrivateKey = yAxByb468bAuMdg5S6AlfYkxbeYDOMEKxdaJ7d2p83g=
Address = 192.168.111.2/32

# Route configuration for public IP
PreUp = ip route del default || true
PreUp = ip route add 134.122.74.29 via 10.2.0.1 dev eth0 || true
PostDown = ip route del 134.122.74.29 via 10.2.0.1 dev eth0 || true
PostDown = ip route add default via 10.2.0.1 || true

MTU = 1342
PreUp = udp2raw -c -l 127.0.0.1:50001 -r 134.122.74.29:55055 -k "The2password." -a >/var/log/udp2raw.log 2>&1 &
PostDown = killall udp2raw || true

[Peer]
PublicKey = VUN2JqZiGQ1V46PDoFECw/nMs3/o6n8PvGMV+ad+Hww=
Endpoint = 127.0.0.1:50001
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 120

Key Points:

  • Fallback Internet Routing: The AllowedIPs = 0.0.0.0/0 directive ensures all traffic is routed through Endpoint B, including internet traffic.
  • Dynamic Route Adjustments: The PreUp and PostDown commands manage routes for efficient fallback connectivity.

Here’s the improved Implementation Steps section based on your feedback and expertise in WireGuard and udp2raw:

Implementation Steps

This section outlines the precise steps required to set up the WireGuard VPN over TCP using udp2raw. Follow these instructions carefully for both Endpoint A (client) and Endpoint B (server).

1. Pre-requisites

  • WireGuard Installation: Ensure WireGuard is installed on both systems. This can usually be done via the package manager of your operating system (e.g., apt install wireguard for Debian-based distributions).
  • udp2raw Binary: Download the appropriate udp2raw binary from its GitHub Releases Page. Binaries are available for various architectures. For simplicity:
    1. Extract the binary from the tarball (e.g., udp2raw_amd64 for most x86_64 systems).
    2. Place the binary in a directory accessible from your PATH (e.g., /usr/local/bin).
    3. Verify the installation: which udp2raw udp2raw -h # Should display the help menu

2. Prepare the Configuration Files

The configuration files should be located at /etc/wireguard/wg0.conf. Each endpoint has its own specific configuration:

  • Endpoint A: Use the wg0.conf provided earlier, replacing placeholders like keys and IPs as needed.
  • Endpoint B: Use the wg0.conf provided earlier.

Ensure both files reflect the IP addresses, MTU settings, and public/private keys accurately.

3. Generate WireGuard Keys

WireGuard requires public-private key pairs for secure communication. Generate them as follows:

  1. Generate the Private Key: wg genkey > privatekey
  2. Generate the Public Key from the private key: cat privatekey | wg pubkey > publickey
  3. Place the private key in the [Interface] section of the respective configuration file (PrivateKey = ...) and the corresponding public key of the peer in the [Peer] section (PublicKey = ...).

Note: Never share your private keys.

4. Start the VPN Tunnel

  1. Start the Server First (Endpoint B):
    • Bring up the WireGuard interface using wg-quick: sudo wg-quick up wg0
    • Verify that the interface is active: wg show
  2. Start the Client (Endpoint A):
    • Bring up the client WireGuard interface: sudo wg-quick up wg0
    • Verify that the interface is active: wg show

5. Test the Connection

Once both endpoints are active, initiate traffic from Endpoint A to Endpoint B. This step ensures the udp2raw TCP socket is properly established and functioning:

  1. Ping Endpoint B’s WireGuard IP: ping 192.168.111.1
    • If the ping succeeds, the connection is working as expected.
    • If it fails, check the logs for udp2raw and WireGuard on both endpoints for errors: less /var/log/udp2raw.log
  2. Once the initial handshake completes, the tunnel will remain active as long as PersistentKeepalive is configured in the client configuration (e.g., PersistentKeepalive = 120).

6. Validate Fallback Internet Access

To confirm the fallback internet routing through Endpoint B:

  1. On Endpoint A, run a test to confirm external connectivity: curl -I https://www.google.com
    • If the response headers are received, the internet routing through Endpoint B is functioning.
    • Verify that the traffic is routed through the WireGuard tunnel: traceroute google.com
  2. If fallback internet access fails, ensure that NAT is correctly configured on Endpoint B: iptables -t nat -L -n

7. Troubleshooting

  • Log Files:
    • Check the udp2raw logs on both endpoints for issues (e.g., MTU mismatches, handshake failures).
    • Review WireGuard logs for additional details.
  • MTU Issues:
    • If large packets fail but small packets (e.g., ping) succeed, reduce the MTU (e.g., to 1280).

8. Automate Startup

To ensure the VPN starts automatically on boot:

  1. Enable the WireGuard service: sudo systemctl enable wg-quick@wg0
  2. Add udp2raw commands to a systemd service or the PreUp directive in wg0.conf (as shown in the configuration files).

With these steps, you now have a fully operational WireGuard tunnel over TCP, enabling secure communication between endpoints and fallback internet connectivity via the company’s infrastructure.

Conclusion

This configuration provides a robust solution for IoT Gateways operating in restrictive environments. By leveraging udp2raw, WireGuard traffic is tunneled over TCP, enabling:

  1. Seamless Corporate Access.
  2. Fallback Internet Connectivity through the company network when customer environments impose constraints.

This versatile setup ensures uninterrupted operations and secure communications for IoT devices. Explore the Pro Custodibus guide and udp2raw GitHub repository for additional insights.

References

Resumen 2024

2025/01/25 08:00

El 2024 ha sido un año pleno de contrastes, donde las lecciones aprendidas, los retos profesionales y la alegría familiar han convivido para dar forma a una experiencia inolvidable. A lo largo de estos doce meses, he reforzado valores como la paciencia y la comunicación, y he vivido momentos que han marcado mi crecimiento tanto personal como laboral.

Aprendizajes

Este 2024 me ha reafirmado en la idea de que la paciencia y la comunicación efectiva son aliados imprescindibles en cualquier ámbito, desde la familia hasta el trabajo. He comprendido mejor la importancia de gestionar el estrés sin perder la empatía hacia quienes me rodean; he tenido que aprender a escuchar más y no lanzarme a conclusiones precipitadas. Aunque sigue siendo un reto, cada pequeño avance en estos aspectos marca una diferencia real en mi día a día.

También he valorado la simplificación de procesos y la gestión del tiempo. En ocasiones, realizar un par de pasos de menos es más productivo que desplegar una estrategia hipercompleja que termine por abrumarme. En este sentido, la reflexión sobre mis emociones me ha ayudado a diferenciar lo urgente de lo realmente importante, equilibrando mejor mis prioridades.

Otro aprendizaje inusual que he incorporado es el de saber conjugar mi dependencia de la tecnología con la necesidad de criterio propio. Interactuar a diario con mi “amigo GePeTo” (GPT) me enseñó que la IA puede aportar mucha eficiencia y creatividad, pero también que uno debe mantener un espíritu crítico y saber cuándo seguir la intuición personal. Curiosamente, volver a proyectos técnicos complejos y resolverlos con un enfoque más sencillo me hizo redescubrir el valor de la “solución mínima viable”.

Por último, me he dado cuenta de que, al igual que en la docencia, es clave dejar margen para el crecimiento autónomo de los demás. Ver a mis hijos y estudiantes encontrar sus propias respuestas, e incluso superarme en algunas soluciones, me ha recordado lo gratificante que es dar espacio a la colaboración y al aprendizaje compartido. Esto, al final, es lo que convierte la vida en un viaje continuo de descubrimiento.

Proyectos y marca pesonal

Este 2024 ha sido un año de contrastes. Por un lado, la actividad en Industry 4.0 Systems sigue en alza: mantener la regularidad en las publicaciones y profundizar en temas técnicos poco explorados se ha convertido en nuestro principal logro. Este esfuerzo continuado me enorgullece y refuerza mi pasión por la divulgación tecnológica.

Por otro lado, mi marca personal ha estado casi en pausa. El exceso de trabajo y los proyectos de gran envergadura con clientes me han absorbido por completo. Aun así, quiero romper con esta dinámica en 2025, retomar mi presencia en redes y potenciar mi visibilidad. Un primer intento para ello fue G33k.team: registré un piloto, pero la falta de compromiso del socio que encontré dejó el proyecto en standby. Confío en poder darle forma cuando encuentre el momento y el equipo adecuado.

En cuanto a formación, ha sido un año con pocas lecturas y apenas algún webinar suelto; no conseguí terminar ningún libro. La explosión de las IA ha transformado la manera en que consumo información: mi “nuevo amigo” es GePeTo (GPT), como en broma llamo a ChatGPT y sus derivadas (Gemini, Claude Sonnet, etc.). Me paso horas interactuando con estos modelos, lo que ha desplazado parte de mi tiempo de lectura tradicional.

Finalmente, mencionar a Joan Verdaguer, un profesor de secundaria retirado que me ha inspirado profundamente. Su pasión por seguir aprendiendo, su agenda repleta de eventos y la forma en que comparte conocimiento —incluso a través de papers basados en experimentos que realiza con otros colegas— son un ejemplo de energía incombustible. Ver su mente despierta, su mirada crítica y sus ganas de aportar me recuerda que nunca es tarde para seguir creciendo.

Familia y temas personales

Este año cumplí mis 47, con el recuerdo de aquel accidente de coche de hace 21 años muy presente. Un regalo que enamoró fue recibir “47 motius per estimar-te” de mi mujer, un detalle que me hizo reflexionar sobre el paso del tiempo y el valor de cada día. Gracias Meumins.

Los niños cumplieron 6 y 8 años: Nil ya va a Primero y Roc a Tercero. Me asombra lo rápido que crecen; en solo tres años, Roc tendrá que ir estudiar fuera del pueblo, algo que todavía no termino de asimilar. A la vez, poder razonar con ellos y hacer planes juntos se ha convertido en una de mis mayores alegrías. Nos quedará siempre el recuerdo de Pol, que habría cumplido 10.

Con los niños, he tenido varios motivos de orgullo: en la Wedo Party hicieron una presentación de robótica increíble, y Nil ganó el premio de dibujo de Sant Jordi. Eso sí, no han faltado sustos: Nil se rompió un diente a principios de año y más tarde se fracturó cúbito y radio en el campus de hockey de Pedro Gil. Afortunadamente, gracias a un molde 3D de la comunidad IP, la recuperación fue más llevadera.

Viajamos con la familia de Valencia a Besseit, Arnes y Vall-de-roures. Descubrimos un restaurante que es un joya en La Ràpita, te recomiendo “Celleteca Cal Bayó”. Además de descubrir que el mejor bocadillo de país lo sirven a 5km de casa, oportunidad que no dejé escapar para probarlo. Pero el gran viaje del año fue a Florida, un plan que me llevó horas de preparación y que abarcó desde el circuito de Daytona 500 hasta Key West, pasando por Cabo Cañaveral (instalaciones de la NASA), Orlando (parques de Disney), Naples, Sarasota, Everglades y Miami. Una experiencia inolvidable.

Año con grandes cambios en lo que se refiere al hockey. Tanto Roc como Nil se han movido al club de hockey de Sant Pere de Riudebitlles. Una lástima tener que dejar el pueblo pero no se puede tener todo. Esta nueva etapa esta siendo todo un placer y una oportunidad para los niños. Aunque esto haya implicado despedirnos de su entrenadora de toda la vida, Carla. Gracias de nuevo por tu gran trabajo con los niños.

De acuerdo con el análisis de un modelo de IA sobre mis notas del diario personal, la mayoría de los días se registraron con un estado de ánimo positivo y salud estable (60-70%), quedando un grupo menor con altibajos y solo unos pocos marcados por molestias considerables. En general, la sensación predominante fue de bienestar, sin quejas demasiado frecuentes a lo largo del año.

El mismo análisis sugiere que dediqué una parte relevante del tiempo al trabajo (50%), seguida de un bloque amplio dedicado a la familia (45%), mientras que el ocio personal quedó en un espacio más reducido (5%).

Charlas y escuelas de negocios

Este 2024 ha estado marcado por el cierre del Master of Science in Digital Business de ESADE, donde he continuado impartiendo Digital Technology, Digital LABs y Accelerating Innovation. Además, tuve la suerte de tutorizar dos tesis, una de las cuales obtuvo la calificación más alta de toda la universidad, centrada en el “Impact of Neobanks on Traditional Banks in the Swiss Banking Industry”. También participé como miembro de tribunal de tesis, una experiencia que me ha permitido ver de cerca el talento y la dedicación de los estudiantes en sus proyectos de investigación.

Por otro lado, he mantenido mi colaboración con la escuela de tecnología Zigurat, impartiendo tres módulos en el Master en Digital Business. En ISDI, di una masterclass para DAMM enfocada en empresas data-driven y otra sobre Internet of Things en su Master of Internet Business.

Fuera del entorno puramente académico, quiero destacar la conferencia sobre IA que ofrecí en Sallent, donde el éxito de asistencia me alegró especialmente, y la charla in-company en ISDIN, gracias a la invitación de mi viejo amigo Rod, para abordar la problemática de los silos de datos en las organizaciones. En conjunto, ha sido un año de intensa actividad formativa, con oportunidades para compartir conocimientos y aprender cada día un poco más.

Según el análisis que hizo la IA sobre mis notas, Nexiona concentró gran parte de mi tiempo, seguida por i2Cat, donde dediqué un bloque igualmente significativo a automatizaciones y despliegues. Sàbat ocupó un espacio más moderado, principalmente por el desarrollo del nuevo IoT Gateway NG. Mientras tanto, las colaboraciones en docencia (ESADE, Zigurat, ISDI) y otros proyectos complementaron la agenda con un porcentaje menor.

Proyectos profesionales

Año de extremos en mi faceta como consultor y mentor. Con Nexiona hemos superado retos técnicos importantes y logrado un proyecto internacional de gran envergadura con fábricas repartidas por todo el mundo. Aun así, he sentido la marcha de Yev y Néstor, compañeros clave que dejan un vacío tanto a nivel profesional como personal en mi día a día con el cliente.

En i2Cat, mi labor se ha centrado en la automatización de documentación y despliegues usando Ansible AWX y Ansible Forms, contribuyendo a agilizar procesos internos. Mientras tanto, en Sàbat, uno de los grandes hitos fue el desarrollo del nuevo “IoT Gateway NG”, ya implantado en casi todas sus líneas de producción y con planes de completarlo en 2025.

La nota amarga del año la pone AKO, una empresa con la que colaboraba desde hacía más de una década y que he perdido como cliente tras un cambio de responsable. Por otro lado, también he aprendido que debo gestionar mejor los picos de trabajo: este año asumí volúmenes excesivos que no deseo repetir en 2025.

Resumen Técnico

A diferencia del 2023 el 2024 mi dedicación a temas técnicos se ha incrementado notablemente, vamos a decir que por exigencias del guión. En mi opinión la gran diferencia entre este trabajo y el que había hecho en otras epocas de mi vida es la fuerte vocación de compartir y ayudar a terceros con todo este esfuerzo. Hasta me permitiría añadir la palabra inspirar. Realmente siento como una gran recompensa cuando noto que mi trabajo es la semilla de desarrollos de otras personas. Realment es una gran motivación personal a estas alturas de mi vida.

Hay que destacar también un cambio muy relevante en la arquitectura de la infraestructura doméstica. Hace unos años tomé la decisión de reducir los servidores domésticos al extremo y concentré todas mis necesidades en un NAS y un servidor de videovigilancia. Lamentablemente, las capacidades de computación del NAS con todos los servicios que requiero para el día a día lo hacían difícil y caro de mantener, sobretodo en tiempo dedicado cada vez que había que reiniciar por actualizaciones o similares. Se hacía raro no acabar invirtiendo una mañana, o una tarde enteras, para una actualización de sistema rutinaria.

Así pues, me decidí a comprar un Minisforum MS-01. Mucha potencia, poco espacio, poco ruido y buen precio.

  • CPU: 14-core (6-mt/8-st) 13th Gen Intel Core i9-13900H [MST AMCP] speed (MHz): avg: 929 min/max: 400/5200:5400:4100
  • Disk SSD NVMe 1TB – Kingston model: OM3PGP41024P-A0
  • RAM DDR5 32GiB – 2xSODIMM Synchronous 5600 MHz (Crucial CT16G56C46S5.M8G1)
  • Graphics: Intel Raptor Lake-P [Iris Xe Graphics]
  • Network:
    • 2x Intel Ethernet X710 for 10GbE SFP+
    • 2x Intel Ethernet I226-V
    • Intel Wi-Fi 6 AX210/AX211/AX411 160MHz

Toda esta potencia para correr un Proxmox que me permita gestionar los contenedores con los servicios de red y todavía más importante el Home Assistant que controla la casa.

Gracias a las herramientas de IA he podido rastrear en mis notas todas las tecnologías que he tocado este año y de las que he hablado en mi diario personal. Aquí dejo una lista por si pueden servirle a alguien.

💡 NOTA: Te recomiendo que te fijes espcialmente en los proyectos que he desarrollado que te he marcado con este icono: 👷

oriolrius.cat

Este año he tenido que tomar medidas drásticas con el Blog por qué los agujeros de seguirdad de WordPress han llegado a nivels insospechables. Había semanas que tenía más de un haqueo por semana, no daba abasto a recuperar las copias de seguridad. Por suerte este tema parece haber quedado atrás con estas medidas que comento.

Infraestructura y Virtualización

  • Docker, contenedores y derivados; continuo avanzado hasta niveles de conocimiento muy profundos del funcionamiento. Cosa que me lleva a usar estas herramientas al extremo de su funcionalidad.
    • Portainer para gestión de contenedores. A pesar de ser fan cada día estoy un poco más cansado de las incompatibilidades que genera y lo poco amigable que es para depurar problemas. IMHO ahora mismo lo mejor es usarlo para gestionar Docker SWARM y quizás algunos Kubernetes pequeños.
    • Dockge cada día lo uso más como alternativa a Portainer si de lo que se trata es de gestionar Docker Compose.
    • Traefik como proxy inverso y balanceador. Finalmente me lancé a montarlo en diferentes de las arquitecturas en las que estoy involucrado sobretodo pro su flexibilidad en la configuración en caliente. Honestamente estoy muy contento, aunque nada es perfecto, claro.
    • NGINX Unit, también tiene una pinta excelente y es muy poco conocido. Lo he podido probar pero no lo suficiente para decir que lo controlo, aunque vale mucho la pena seguir invirtiendo tiempo.
    • NGINX Proxy Manager (NPM), aquí si que he invertido muchísimo tiempo. Hasta llegar a tracear su código para entender como hacía múltiples funciones para poder personalizarlo hasta extremos muy interesantes.
    • Crowdsec – the open-source and participative security solution offering crowdsourced protection against malicious IPs and access to the most advanced real-world CTI. Lo he montado junto a NPM y añade una capa de filtrado potente.
  • Virtualización y Gestión:
    • Multipass para máquinas virtuales ligeras, lo he estado usando en Windows 11. Llegué a tener en marcha más de 15 VMs con Ubuntu para mis estudiantes de ESADE, concretamente para hacer prácticas de IoT.
    • Proxmox para virtualización de infraestructura combinado con ZeroTier y VLANs, este es el uso que le estoy dando dentro de mi infraestructura personal.
  • Inventario
    • GLPI una solución muy antigua y se nota cada vez que debemos desplegarlo. Pero a la vez que antigua también viva y en plena evolución. Se nota que esta generando negocio a su alrededor y eso también se nota al usarlo, ya que su covertura y funcionalidad de los invetarios no para de crecer. Además también destacar la capacidad de integrarse con Zabix. Seguro que poco a poco su API lo reflejará, por qué ahora es uno de los puntos más débiles que le encuentro.

Automatización y DevOps

  • Ansible: hace muchos años que empecé a automatizar con Ansible y la verdad es que el producto nunca deja de sorprenderme positivamente.
    • Ansible Forms, permite crear formularios para definir las variables de entrada de los Playbooks de Ansible y esto es una maravilla para usarlo como interface de gestión de procesos para usuarios con un perfil menos técnico.
    • AWX; además Ansible Forms se funciona a la perfección con AWX. También quero d
    • Semaphore también es la herramienta que usaba como alternativa a Ansible Forms, es una herramienta muy interesante y a tener en cuenta ya que ahora mismo no solo permite hacer automatismos con Ansible, sino también Terraform, OpenTofu, Python y mucho más.
  • CI/CD y Control de Versiones:
    • GitLab CI/CD workflows; incontables las horas que pasé perfeccionando procesos con este sistema. Aunque muy potente y versátil hay que reconocer que todavía muy lejos de la siguiente referencia.
    • GitHub workflows, especialmete enamorado del siguiente workflow por su simplicidad y utilidad a la hora de crear mis imágenes docker cuando hago un desarrollo: .github/workflows/publish.yml
    • Implementación de Docsify para documentación automatizada

Seguridad y Redes

  • Autenticación y Acceso:
    • Keycloak y Authelia para gestión de identidades; honestamente tenía muchas esperanzas en Authelia pero rápidamente vi que es algo muy pequeño y de recorrido muy limitado sobretodo al lado del monstruo todopoderoso que es Keycloak. Curiosamente este 2024 ha sido el año de los IAM, IDM y todo este tipo de herramientas. Llevo almenos 8 años intentado apostar per este tipo de soluciones pero hasta ahora no explotó.
    • Cloudflare Zero Trust Tunnel – Cloudflare Tunnel provides you with a secure way to connect your resources to Cloudflare without a publicly routable IP address. With Tunnel, you do not send traffic to an external IP — instead, a lightweight daemon in your infrastructure (cloudflared) creates outbound-only connections to Cloudflare’s global network. Cloudflare Tunnel can connect HTTP web servers, SSH servers, remote desktops, and other protocols safely to Cloudflare. This way, your origins can serve traffic through Cloudflare without being vulnerable to attacks that bypass Cloudflare.
      Relativo a este punto añadir que me he quedado con las ganas de probar la solució self-hosted que en teoría hace lo mismo: pangolin.
    • 👷 SSH Stealth (github repos); he creado esta simple herramienta de port knocking. Si te interesa el tema te recomiendo una herramienta mucho más sofisticada, pero todo tiene sus pros y contras.
  • Monitorización y Seguridad:
    • Stack de observabilidad self-hosted: Grafana Alloy + Keycloak + Grafana Mimir + Grafana Loki + Grafana Dashboards + NPM con OAuth2-proxy. He dedicado infinidad de horas en perfeccionar la infraestrctura que se describe a continuación.
      Si te interesa el tema te recomiendo muchísimo la serie de vídeos publicados al respecto en industry40.systems.
    • Grafana dashboard para monitorizar Linux con Docker usando logs en Loki y métricas en Mimir; lo publiqué en abierto por si puede ayudar a alguien.
    • Grafana Grizzly – una simple herramienta para la consola que vale la pena mencionar ya que es ideal para hacer provisioning de Grafana; permite interactuar con la API de forma sencilla y escalable, ideal para automatizar el despliegue de data sources, dashboards, alarmas y mucho más.
    • Wazuh para seguridad – a pesar de la experiencia y sufrimientos acumulados poniéndolo en marcha no me quedé a aprender los detalles de su funcionamiento. Solo decir que es un XDR y SIEM que tienen una pinta excelente. IMHO estás herramientas siempre tienen el mismo drama que es la gestión de falsos positivos.
    • Uptime Kuma para monitorización, este es uno de los grandes descubrimientos. Herramienta muy sencilla de configurar y con funciones fáciles de entender, además de ser pequeño y con un set de datos limitado. Pero con una gran función y es que las metrics generadas se exportan directamente en formato Prometheus y se pueden integrar fácilmente con Grafana Alloy.
      • Autokuma, además integré este servicio que añade monitores a Uptime Kuma de forma automática al parsear las labels de contenedores que se levantan. Así pues se hace el provisionamiento de la monitorización automàticamente. De este mismo paquete también mencionar otra herramienta muy útil: kuma-cli que permite interactuar con los monitores desde línea de comandos.
      • Aunque no es una herramienta en si no puedo dejar de mencionar los monitores push y los agentes que hay disponibles para monitorizar elementos personalizados, o remotos, que podamos tener en nuestra infraestructura. Realmente una herramienta muy útil.
    • VPNs
      • ZTNet la Web UI definitiva para gestionar los controladores de red de ZeroTier en nuestras redes privadas. Espectacular, simple y muy potente. Gran combinación.
      • Wireguard, dentro de este inmenso mundo comentar que pude probar un par de herramientas interesantes y que vale la pena tener en el mapa para diferentes soluciones: netbird para accesos roadwarrior y netmaker ideal para gestionar site2site.

Desarrollo y APIs

  • Python:
  • LowCode / NoCode, los que me conocen saben que soy un gran fan de este tipo de herramientas
    • Oracle APEX, gracias a mi colaboración con ESADE pude entrar a fondo a tocar este grandísimo producto enfocado a la parte más corporativa de las herramientas LowCode. Realmente espectacular.
    • NodeRED y Flowfuse, sigo siendo un fiel enamorado de NodeRED y este año su complemento Flowfuse en mi opinión la ha estado petando. Dando un salto de gigante en la gestión masiva de instalaciones NodeRED, simplemente espectacular.
    • Kestra.io, ha sido un descubrimiento y una promesa. No he pasado del hello world pero le tengo unas ganas tremendas a esta maravilla.
    • Apache Flink se especializa en el procesamiento distribuido y en tiempo real de flujos de datos (streaming) y análisis continuo. Al empezar a usar Kafka en algunos proyectos estuve estudiando la posibilidad de ponerme con Flink a pesar de que pinta muy pontente al final me decidí por meterme más en NiFi con las necesidades que tenía. Pero Flink hay que tenerlo siempre presente.
    • Apache NiFi se centra en la gestión, orquestación y enrutamiento de datos, facilitando la recolección, transformación y traslado (ETL) entre diferentes sistemas. Además viene con todo un ecosistema de herramientas que para muchas soluciones lo hacen mucho más óptimo que NodeRED. NiFi es mejor cuando necesitas manejar grandes volúmenes de datos con alta disponibilidad, seguridad y trazabilidad. Ideal para entornos empresariales y flujos complejos. Node-RED es más apropiado para proyectos IoT o prototipos donde la facilidad de uso y la rapidez de desarrollo son prioritarias, especialmente con volúmenes y complejidad de datos menores.
  • Herramientas de Desarrollo:
    • Migración a AutoHotkey v2, en Windows usaba AHK v1 para automatizar varias tareas repetitivas y me vi forzado a actualizar a la nueva versión. Hay que decir que a pesar de los años esta herramienta sigue siendo difícil de superar. Eso si, su desarrollo sigue siendo austero y tedioso.
    • 👷 README2Notion, con la ayuda de Nestor creamos una herramienta para conversión de documentación de Markdown README a documentos en Notion. El proposito es integrarlo con un pre-hook de Git, así convierte los README.md de los proyectos en documentación de Notion centralizada. Este pre-hook esta documentado aquí.

IoT y Automatización del Hogar

  • Home Assistant; a pesar de la gran necesidad que tengo de mejoras en los automatismos de casa la verdad es que le hice pocos cambios. Lo más importante es la migración a HASS y he dejado de usar la versión con docker, tener una VM con todos los procesos de backup y actualización me ahorra una de tiempo increible. Lo recomiendo muchísimo esto de usar HA con su S.O. y una VM, o en su defecto hardware dedicado.
    • En casa tenemos una chimenea de pellets marca Edilkamin que la he integrado con HA, lo malo es que solo lo he hecho a través de su API Cloud no en local e independizándola de Internet.
    • Integración de RTL_433, he contectado un SDR (Software Defined Radio) que monitoriza los PIR (sensores de presencia) y a través del NodeRED que lleva HA lo he integrado. Ahora me falta conectar la sirena para tener la Alarma completada.
  • IoT y Comunicaciones:
    • RabbitMQ, he seguido muy de certa las nuevas versiones de este producto en el que aposté hace más de 10 años para mis arquitecturas. Este año, por fin, se han puesto las pilas y han sacado nuevas versiones con mejoras relevantes y cambios estructurales que lo llevan a un nuevo nivel. Cuidado, Kafka no es su competencia aunque se solapen en algunos aspectos.
    • EMQX, mientras esperaba que RabbitMQ se pusiera las pilas el gran descubrimiento en brokers de MQTT ha sido este producto Chino. Resaltar que una de las funciones a las que más partido le he sacado es a la capacidad de conectarse en modo bridge con Mosquitto y sincronizar bidireccionalmente partes del árbol del Unified Namespace. Realment espectacular lo bien y fácil que es de implementar.

👷 IoT Gateway NG, el gran desarrollo del año

Debido a mi trabajo una de las aportaciones típicas que hago en los proyectos es aportar el diseño de la arquitectura de una solución tecnológica. Pues bien, en 2024 he rematado la unión de un montón de tecnologías y funcionalidades en un producto. En Industry 4.0 Systems dediqué muchos vídeos a explicar configuraciones de muchas piezas que acostumbro a integrar en muchos proyectos. Este producto es una evolución que sube la apuesta un orden de magintud. Mi idea era montar todas estas piezas que había documentado en Industry 4.0 Systems y unas cuantas más sobre un OpenWRT, no para un equipo embedded, para un equipo con una buena potencia para desarrollar tareas importantes y simplificando su gestión gracias a la interface web de gestión del sistema operativo. Sin renunciar a la shell, claro.

Como este no es lugar para extenderme más dejo la referencia del proyecto aquí.

Conclusión y cierre

Al mirar hacia atrás, siento un profundo agradecimiento por cada oportunidad, desafío y pequeño instante que ha hecho de este año un periodo tan enriquecedor. Desde ver a mis hijos crecer, hasta colaborar en grandes proyectos y encontrar inspiración en la pasión de quienes me rodean, cada paso dado me ha acercado más a la vida que deseo construir.

Sobre todo, quiero expresar mi gratitud más sincera a la vida por permitirme disfrutar de momentos tan mágicos y transformadores. Llevo conmigo la convicción de que cada día es un regalo y, con esta energía, me preparo para seguir aprendiendo, creando y compartiendo en el camino que me depare el futuro. ¡Gracias, 2024, por todo lo que me has enseñado!

Scroll to Top