Bienvenidos a la página personal de José Domingo Muñoz Rodríguez, aquí podrás encontrar…

Accede a las entradas de mi blog donde escribo de Informática y Educación.

Accede a los materiales de los cursos que he impartido.

Plataforma Pledin

Accede a los contenido de los módulos de FP que estoy impartiendo en la actualidad.

Módulos FP

Microblog

Habilitar IP Forwarding en Debian 13

En Debian 13 (Trixie) el IP forwarding ya no se configura en /etc/sysctl.conf, sino en un archivo bajo /etc/sysctl.d/.

Crea /etc/sysctl.d/99-forward.conf con:

net.ipv4.ip_forward=1  
net.ipv6.conf.all.forwarding=1  

Aplica y reinicia servicios:

sudo sysctl --system
sudo systemctl restart systemd-sysctl

Con esto el reenvío queda habilitado de forma persistente.

Detalle

Publicado Debian 13 Trixie

Hoy, 9 de agosto, se ha publicado la última versión de mi distribución favorita: Debian 13 Trixie. Habrá que pensar en ir actualizando. Os dejo las Notas de publicación.

Detalle

Mi última camiseta…

Detalle

Blog

Contenedores Docker para la creación de páginas web estáticas usando Jekyll

docker

Como ya saben, mis páginas web son páginas estáticas que genero utilizando Jekyll, una herramienta muy popular en el ecosistema de Ruby. Para quienes no estén familiarizados, Jekyll es un generador de sitios estáticos que toma contenido escrito en Markdown o HTML y lo convierte en un sitio web completo, listo para ser servido en cualquier servidor web. Entre sus principales ventajas se encuentran la simplicidad, la velocidad de carga de las páginas generadas, la facilidad para trabajar con plantillas y layouts, y la posibilidad de mantener el contenido separado del diseño.

Hasta ahora, en mi servidor tenía instalado Ruby y Jekyll directamente, lo que me permitía generar mis sitios sin problemas. Sin embargo, al manejar distintos proyectos Jekyll, este enfoque puede traer ciertos inconvenientes: diferentes proyectos pueden requerir versiones distintas de gemas, que son librerías o paquetes de Ruby que Jekyll y sus extensiones utilizan para funcionar correctamente. Además, las actualizaciones de Ruby, Jekyll o de las gemas siempre pueden complicarse, generando conflictos o problemas de compatibilidad.

En este artículo vamos a presentar una alternativa más flexible y ordenada: la construcción de una imagen Docker con Jekyll ya instalado, que nos permitirá crear distintos contenedores para generar cada uno de nuestros proyectos de manera aislada.

Este enfoque tiene varias ventajas: garantiza que cada proyecto use la versión exacta de Jekyll y de sus gemas, evita conflictos entre proyectos, simplifica el proceso de actualización y facilita la portabilidad del entorno de desarrollo o generación de sitios, ya que basta con tener Docker instalado para ponerlo en marcha.

Seguir leyendo...

Creación de un box para vagrant

vagrant

Vagrant es una herramienta que facilita la creación y gestión de entornos de desarrollo virtualizados de forma reproducible. Su funcionamiento se basa en el uso de box, imágenes preconfiguradas que sirven como punto de partida para desplegar máquinas virtuales de manera rápida y coherente. Estas box pueden estar disponibles para distintos proveedores de virtualización —como VirtualBox, VMware o libvirt, entre otros—, lo que permite a los desarrolladores trabajar con la tecnología que mejor se adapte a sus necesidades.

En mi caso, utilizo libvirt como proveedor, lo que me permite crear y administrar máquinas virtuales sobre KVM con un buen rendimiento. Sin embargo, en los últimos días he revisado el Vagrant Box Registry, el repositorio oficial de box disponibles públicamente, y me he dado cuenta que todavía no existen box oficiales de Debian 13, la nueva versión estable de la distribución.

Por esta razón, en esta entrada del blog vamos a presentar el proceso completo que he seguido de creación de una box personalizada de Debian 13 para Vagrant, de forma que podamos disponer de un entorno base actualizado y listo para ser usado en nuestros proyectos.

Creación de la imagen base

Mi primer enfoque fue crear una imagen base de Debian 13 desde cero en KVM, con la idea de construir la box partiendo de una instalación mínima totalmente limpia. Sin embargo, en la práctica me encontré con varios problemas:

Resolución de nombres y configuración de red: la máquina no conseguía resolver nombres de dominio de forma estable.
Gestión de interfaces de red: al parecer, Vagrant espera que la red se gestione mediante ifupdown y dhclient, pero incluso después de instalarlos y ajustar la configuración, la red no funcionaba de forma fiable en mis pruebas. Las interfaces conectadas a una red con un servidor DHCP funcionaban sin problemas, pero al conectarlas a redes privadas con direccionamiento estáticos, la configuración no se hacía de forma correcta.

Después de dedicarle un tiempo a resolver estos inconvenientes sin éxito, decidí cambiar de estrategia para simplificar el proceso y garantizar la compatibilidad con Vagrant.

El nuevo enfoque consiste en crear la máquina virtual directamente con Vagrant a partir de la box oficial debian/bookworm64, y posteriormente:

Actualizar el sistema desde Debian 12 (Bookworm) a Debian 13.
Generalizar la máquina eliminando datos temporales y preparando el entorno.
Convertir esta máquina actualizada en una nueva box que servirá como base para futuros proyectos.

De esta forma, aprovecho una box oficial y probada como punto de partida, pero obtengo al final una imagen totalmente actualizada a Debian 13 y lista para empaquetar.

Seguir leyendo...

El problema del enrutamiento asimétrico

De forma general, hablamos de enrutamiento asimétrico cuando se da la situación donde los paquetes de ida y vuelta entre dos dispositivos no siguen el mismo camino. En el enrutamiento asimétrico, el paquete de ida toma un camino y la respuesta toma otro distinto. Recientemente me he encontrado un escenario concreto donde se presenta. Lo podemos ver gráficamente en el siguiente esquema:

enrutamiento

No puedo acceder a un servidor web que tengo en mi red local porque no tengo acceso a la configuración del router y no puedo configurar las reglas DNAT para abrir los puertos de navegación Web.

enrutamiento

La solución pasa por evitar el acceso directo al router local. En su lugar, accedemos a una máquina remota (VPS) con dirección IP pública. Esta máquina actúa como router intermedio, ya que le configuramos una regla DNAT que redirige los paquetes al servidor web local, conectado a la VPS a través de una VPN. Es decir, los paquetes entrantes llegan al servidor web por la interfaz de la VPN (tun0).

El problema: La ruta por defecto del servidor web está configurada para enviar el tráfico saliente a través del router físico local, no por la VPN. Como resultado, la respuesta no vuelve por el mismo camino, y el cliente no puede acceder correctamente al servidor web. Esto ocurre porque el router local no puede realizar el cambio de dirección de origen (SNAT) para paquetes que no vio llegar. Lo vemos claramente en este esquema:

enrutamiento

Lo deseable sería que el tráfico de respuesta también saliera por la VPN, manteniendo la simetría en la ruta. Es decir, que tanto los paquetes de ida como los de vuelta pasen por el túnel VPN, como se muestra aquí:

enrutamiento