Blog de Pledin

Uno de mis cursos en awesome-extremadura

Mon, 13 Apr 2026 00:00:00 GMT

awesome-extremadura es una selección de software open source que da soporte específico a Extremadura, sus municipios, universidades e instituciones. Me han escrito para informarme que han incluido en la selección uno de mis cursos sobre Docker que impartí hace unos años para el CPR de Badajoz: Curso Docker CPR Badajoz.

Me ha hecho mucha ilusión. Gracias!!!

Feed RSS/Atom: Novedades del portal de educación de la Junta de Andalucía

Wed, 08 Apr 2026 00:00:00 GMT

Hace unos meses, posiblemente en la última actualización de la página de Novedades del portal de educación de la Junta de Andalucía, la opción de sindicación de contenidos mediante RSS desapareció y dejé de recibir actualizaciones en mi lector.

Como no soy dado a revisar la página periódicamente, he desarrollado un pequeño script en Python que genera automáticamente el archivo XML del feed. Al alojarlo en GitHub Pages, puedo volver a acceder a él desde mi cliente RSS habitual.

Gracias a GitHub Actions, el feed se actualiza automáticamente. Podéis suscribiros a las novedades accediendo a este link.

Para quienes tengan curiosidad o quieran ver el código, os dejo el repositorio.

Migración de Pledin a Astro

Wed, 01 Apr 2026 00:00:00 GMT

Desde septiembre de 2018, mi página Pledin - Plataforma Educativa Informática ha sido una web estática generada por Jekyll, si quieres más información de como fue construida te invito a leer el artículo: Bienvenidos a PLEDIN 3.0. Después de estos años usando Jekyll como generador de sitios estáticos para este blog, he decidido migrar a Astro. En este artículo explico qué es Astro, por qué lo he elegido y el proceso que he llevado a cabo para esta migración.

¿Qué es Astro?

Astro es un framework moderno para construir sitios web, especialmente pensado para sitios donde el contenido es lo más importante: blogs, documentación, portfolios...

La filosofía de Astro es sencilla: generar páginas HTML simples y rápidas, enviando al navegador solo lo imprescindible. Mientras otros frameworks cargan grandes cantidades de JavaScript aunque no haga falta, Astro hace justo lo contrario.

Algunas de sus características más interesantes:

Flexible: puedes usar componentes de React, Vue, Svelte... o simplemente los componentes propios de Astro, que tienen una sintaxis muy parecida al HTML de toda la vida.
Gestión de contenido integrada: permite organizar los ficheros Markdown de forma estructurada, con validación automática de los metadatos de cada página.
Extensible: dispone de un sistema de plugins oficial para añadir funcionalidades como generación de sitemap, feed RSS, soporte para MDX, etc.
Rendimiento: genera sitios extremadamente rápidos gracias a la eliminación de JavaScript innecesario.

¿Por qué migrar de Jekyll a Astro?

Jekyll ha sido una herramienta excelente durante años, pero tiene algunas limitaciones que con el tiempo se hacen evidentes:

Requiere Ruby y sus dependencias, lo que puede ser un problema en entornos modernos.
El sistema de plantillas Liquid, aunque funcional, es limitado comparado con componentes modernos.
La velocidad de build con muchos posts es lenta.
La integración con herramientas modernas de frontend es complicada.

Antes de pasarme a Astro, mi web funcionaba con Jekyll y la plantilla Minimal Mistakes, una de las más populares del ecosistema Jekyll. Con el tiempo empezaron a aparecer warnings en cada build, una señal de que mantener el sitio en pie iba a exigir cada vez más esfuerzo.

Los warnings eran de dos tipos. Por un lado, una deprecación en Ruby: alguna dependencia del proyecto usaba una API interna que ya había cambiado en versiones modernas. No rompía nada de momento, pero indicaba que el stack no estaba actualizado, y que una actualización de Ruby podía acabar rompiendo el build.

Por otro lado, una larga lista de warnings relacionados con Sass y la evolución de Dart Sass hacia versiones más estrictas:

Deprecación de @import: la plantilla cargaba sus estilos mediante reglas @import encadenadas. Esta forma de importar archivos Sass desaparecerá en Dart Sass 3.0.0.
Deprecación del operador / para divisiones: varias partes del código usaban / directamente para hacer operaciones matemáticas en Sass, algo eliminado en favor de math.div() o calc().
Deprecación de funciones globales de color: la plantilla usaba funciones como mix(), red(), green() o blue() en su forma global, que también están marcadas para desaparecer en Dart Sass 3.0.0.
Deprecación de mixed-decls: Sass va a cambiar cómo maneja propiedades CSS mezcladas con reglas anidadas, algo que afecta a varios archivos internos de la plantilla.

Frente a esto, Astro ofrece una experiencia de desarrollo moderna basada en JavaScript y TypeScript, con un ecosistema muy activo y una filosofía que encaja perfectamente con lo que necesitaba: generar HTML estático de forma eficiente, sin cargar JavaScript innecesario al navegador.

El proceso de migración

Debo mencionar que empecé probando distintas plantillas de astro como Starlight. Sin embargo, después de varios intentos de hacerlo encajar en lo que necesitaba (www es un blog, y ese tema está pensado para la documentación), volví a comenzar de nuevo sin utilizar ninguna plantilla, fui construyendo desde 0, los distintos elementos de la página:

Componentes: cabecera, pie de página, tarjetas de post, sistema de navegación...
Layouts: un layout base y layouts específicos para la portada, los posts y las páginas estáticas.
Páginas: índice, página de post individual, sección de etiquetas...
Estilos: sistema de variables CSS, tipografía, modo oscuro...

Durante todo este proceso usé la IA, principalmente Claude, como asistente. El flujo habitual era: yo definía qué quería construir, Claude proponía una implementación, y yo la revisaba, ajustaba y la integraba en el proyecto. Útil especialmente para no atascarse en detalles de sintaxis de Astro o en patrones que aún no conocía bien.

Estructura del proyecto

El sitio se ha organizado como un monorepo con tres aplicaciones independientes:

www → Blog personal (www.josedomingo.org)
plataforma → Catálogo de cursos (plataforma.josedomingo.org)
fp → Módulos de Formación Profesional (fp.josedomingo.org)

www-astro/
├── apps/
│   ├── www/          # Blog personal
│   ├── plataforma/   # Catálogo de cursos
│   └── fp/           # Módulos FP
└── packages/
    └── ui/           # Componentes y layouts compartidos

Puedes ver el código completo en el repositorio de GitHub.

Durante el desarrollo de la migración se han tenido que ir solucionando distintos problemas que enumeramos a continuación:

Componentes y layouts compartidos

Una de las ventajas de usar Astro es poder reutilizar código entre las tres aplicaciones. Para ello se ha creado el paquete @pledin/ui que contiene dos tipos de elementos:

Layouts: son las plantillas que definen la estructura general de cada tipo de página. Por ejemplo, BaseLayout define la cabecera, el menú de navegación y el pie de página común a todo el sitio. BlogLayout añade además una barra lateral con el índice del blog, y DocLayout está pensado para las páginas de documentación de los módulos FP, con navegación lateral y tabla de contenidos.
Componentes: son piezas reutilizables más pequeñas que se insertan dentro de los layouts o las páginas. Por ejemplo, PostCard muestra la vista previa de un post del blog, TagList muestra las etiquetas de un artículo, o PostNav muestra los enlaces al post anterior y siguiente.

Manteniendo las URLs

Uno de los requisitos más importantes era no romper las URLs existentes, ya que llevan años indexadas y referenciadas. En la gran mayoría de los casos las URLs se han mantenido exactamente igual. Para los pocos casos donde no fue posible, se añadieron redirecciones en el fichero .htaccess del servidor Apache.

Limpieza de directivas Liquid y Kramdown en los archivos Markdown

Otro de los trabajos previos a la migración fue revisar los archivos Markdown para eliminar directivas que son específicas de Jekyll y que Astro no entiende, por ejemplo, {: .center}.

Esta es una sintaxis propia de Kramdown, el procesador de Markdown que usa Jekyll. Permite aplicar atributos HTML directamente sobre un elemento, en este caso una clase CSS.

En Astro el procesador de Markdown es diferente (Remark), y esta sintaxis simplemente no existe. Había que eliminarla o sustituirla por la alternativa correspondiente.

En resumen, parte del trabajo de migración no fue solo mover archivos, sino limpiar los Markdown de todas estas dependencias con el ecosistema Jekyll, que en muchos casos estaban repartidas por decenas de archivos.

Conversión automática de bloques notice

En Jekyll, los bloques de aviso se construían con una combinación de etiquetas Liquid y HTML:

{% capture notice-text %}
## Título del aviso
Contenido del aviso.
{% endcapture %}
<div class="notice--info">{{ notice-text | markdownify }}</div>

En Astro, la forma equivalente es usando directivas de Remark, mucho más limpias:

:::tip[Título del aviso]
Contenido del aviso.
:::

Como este patrón se repetía en decenas de archivos, escribimos un script Python que recorría todos los Markdown del proyecto, detectaba estos bloques y los convertía automáticamente, traduciendo además las clases CSS de Minimal Mistakes (notice--info, notice--warning, notice--danger...) a sus tipos de directiva correspondientes en Remark. Con un solo comando, todos los archivos quedaban migrados sin intervención manual.

El frontmatter de los ficheros Markdown

Una de las buenas noticias de la migración es que el contenido apenas ha necesitado cambios. La mayoría de los ficheros Markdown se han podido reutilizar tal cual, con dos pequeños ajustes en el blog:

Se ha añadido el campo date de forma explícita.
El campo permalink se ha renombrado a slug.

En las otras dos aplicaciones (plataforma y fp) no ha sido necesario tocar ningún fichero de contenido.

Comentarios

En la versión anterior del sitio los comentarios funcionaban con Staticman, una herramienta que permite añadir comentarios a sitios estáticos guardándolos directamente en el repositorio Git como ficheros YAML o JSON. Era una solución elegante para un sitio sin backend, pero requería mantener un servidor propio con la aplicación Staticman funcionando.

Al migrar a Astro, todos los comentarios existentes se han conservado convirtiéndolos a ficheros JSON, uno por post. Cada fichero contiene un array con los comentarios del post, incluyendo nombre, fecha, mensaje y opcionalmente la URL y el email del autor.

Para mostrarlos se ha creado un componente Comments.astro que recibe esos comentarios como prop y los renderiza. El mensaje se procesa con marked para interpretar el Markdown que algunos comentarios podían contener. Para el avatar, si el comentario incluye email se usa Gravatar para obtener la imagen del usuario; si no, se muestra la inicial del nombre sobre un fondo de color.

Para los comentarios nuevos se ha adoptado Giscus, una solución que almacena los comentarios en las Discussions de GitHub. Cada post del blog tiene su propia discusión asociada en el repositorio, y Giscus se encarga de cargarla y mostrarla mediante un widget embebido.

Las ventajas respecto a Staticman son claras: no requiere ningún servidor propio, se autentica con GitHub, y el mantenimiento es prácticamente nulo. El único requisito es que el repositorio sea público y tenga las Discussions activadas.

En la página de cada post aparecen primero los comentarios históricos migrados desde Staticman y a continuación el widget de Giscus para nuevos comentarios, de forma que el histórico queda preservado y la sección sigue siendo funcional.

Búsqueda con Pagefind

Una de las funcionalidades que quería mantener en la migración era el buscador. En Jekyll lo tenía resuelto con un plugin, pero en Astro necesitaba una solución que funcionara con sitios estáticos, sin ningún servidor backend.

La solución elegida fue Pagefind, una librería de búsqueda estática que funciona de la siguiente manera: tras el build de Astro, se ejecuta Pagefind sobre el directorio dist/ generado, indexa todo el contenido HTML y genera un índice de búsqueda en formato binario optimizado. Ese índice se sirve junto con el resto de ficheros estáticos, y la búsqueda se realiza completamente en el navegador sin ninguna petición a un servidor.

La integración en el proceso de build es muy sencilla. En el package.json de cada aplicación, el script de build encadena Astro y Pagefind:

astro build && npx pagefind --site dist

Para mostrar el buscador en la interfaz se usa el componente oficial PagefindUI, que se integra directamente en el layout base. En desarrollo el buscador no funciona porque el índice no existe hasta que se hace un build — es el único inconveniente, pero es perfectamente asumible.

El resultado es un buscador rápido, sin dependencias externas, que funciona igual en los tres sitios del monorepo: www, plataforma y fp.

Revistas Libres de Software Libre

Aprovechando la migración, se ha rescatado y renovado una sección que llevaba años bastante abandonada: la colección de Revistas Libres de Software Libre.

Esta sección recoge revistas digitales gratuitas sobre Software Libre, Linux, educación y tecnología. Muchas de ellas ya no están activas, pero forman parte de la historia del movimiento del software libre hispanohablante: publicaciones como TuxInfo, ATIX, Papirux o Begins que nacieron de comunidades locales de Argentina, Bolivia, Chile, Colombia, Cuba o México, y que durante años fueron una referencia para sus lectores.

La lista se ha reorganizado en dos secciones: revistas activas, con su último número publicado actualizado, y un archivo histórico con las que ya no publican, indicando el número de ejemplares y los años en que estuvieron en activo.

La implementación técnica es sencilla: toda la información está centralizada en un fichero revistas.json que la página de Astro lee directamente y renderiza en forma de tarjetas. Cada tarjeta incluye la portada de la revista, una descripción, el último número disponible y enlaces para acceder a la colección y a la página web original. Añadir o actualizar una revista es tan simple como editar ese fichero JSON.

Los PDFs de todas las revistas están alojados en un servidor Nextcloud propio, garantizando que los enlaces no dejen de funcionar aunque las páginas originales desaparezcan — algo que ya ha ocurrido con varias de ellas.

Desarrollo y despliegue

Servidor de desarrollo

Durante el desarrollo, Astro incluye un servidor web local que recarga automáticamente el navegador cada vez que se modifica un fichero. Para arrancar cada aplicación:

npm run dev:www
npm run dev:plataforma
npm run dev:fp

Proceso de build y despliegue

Cuando el sitio está listo para publicar, Astro genera todos los ficheros HTML estáticos mediante el proceso de build:

npm run build:www
npm run build:plataforma
npm run build:fp

Para automatizar el despliegue se ha creado un script que realiza tres acciones en orden: hace un commit con los cambios, los sube a GitHub, construye la aplicación en local y finalmente sincroniza los ficheros generados con el servidor mediante rsync.

Migración a Astro 6

Poco después de terminar la migración de Jekyll a Astro 5, se publicó Astro 6. El proceso de actualización fue sencillo, aunque requirió resolver algunos detalles.

Astro 6 requiere Node.js 22.12.0 o superior. Para actualizar en Debian:

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt-get install -y nodejs

Zod es una librería de validación de esquemas para TypeScript. En Astro se usa para definir y validar la estructura del frontmatter de los ficheros Markdown: qué campos son obligatorios, qué tipo tiene cada uno, cuáles son opcionales... z es el objeto principal de Zod a partir del cual se construyen todos los esquemas: z.string(), z.boolean(), z.array()...

En Astro 6, z ya no se importa desde astro:content sino desde astro/zod. El cambio afecta a los ficheros content.config.ts de las tres aplicaciones:

- import { defineCollection, z } from 'astro:content';
+ import { defineCollection } from 'astro:content';
+ import { z } from 'astro/zod';

Los schemas en sí no necesitaron ningún cambio, ya que son simples (z.string(), z.boolean(), z.array()...) y son totalmente compatibles con Zod 4.

Astro dispone de un comando oficial que detecta y actualiza automáticamente todas las integraciones:

cd apps/www && npx @astrojs/upgrade
cd ../plataforma && npx @astrojs/upgrade
cd ../fp && npx @astrojs/upgrade

También hay que actualizar la versión de Astro declarada en packages/ui/package.json, que al ser un monorepo actúa como versión de referencia para todo el workspace. Tras hacer el cambio, hay que limpiar e instalar de nuevo las dependencias:

rm -rf node_modules
npm install
npx astro --version

Conclusiones

La migración de Jekyll a Astro ha sido un proceso largo pero satisfactorio. El resultado es un sitio más moderno, más rápido y mucho más fácil de mantener y extender.

Desde el punto de vista técnico, los cambios más significativos han sido:

Velocidad de build: el tiempo de construcción se ha reducido drásticamente. Lo que antes tardaba varios minutos en Jekyll ahora se resuelve en segundos en local.
Mantenibilidad: prescindir de Ruby y sus dependencias y trabajar con un stack basado en JavaScript/TypeScript, simplifica enormemente el mantenimiento.
Reutilización de código: la organización en monorepo con un paquete @pledin/ui compartido entre las tres aplicaciones evita duplicar componentes y estilos, y garantiza una experiencia coherente en los tres sitios.
Buscador integrado: gracias a Pagefind, los tres sitios disponen ahora de un buscador estático que funciona sin ningún servidor backend, generado automáticamente tras cada build.

Desde el punto de vista del proceso, la experiencia de usar IA como asistente durante el desarrollo ha sido muy positiva. No como sustituto del criterio propio, sino como herramienta para avanzar más rápido en los detalles de implementación, resolver dudas de sintaxis y explorar alternativas sin tener que detenerse a buscar en la documentación en cada paso.

El código fuente del proyecto está disponible en GitHub por si puede ser de utilidad para alguien que esté pensando en hacer una migración similar.

Galería Pledin 3.0

Dejo por aquí algunas capturas de pantalla de las páginas web antes de la migración.

Seguridad y control de acceso en una VPN tailscale/headscale: ACLs y Tags

Tue, 17 Mar 2026 00:00:00 GMT

Hasta ahora, nuestra red mesh ha funcionado bajo una confianza total: cualquier dispositivo que uníamos a nuestra red podía comunicarse con los demás. Sin embargo, en entornos educativos o profesionales, necesitamos aplicar el principio de mínimo privilegio. En este artículo aprenderemos a usar las ACLs y los Tags para crear una red donde los alumnos puedan acceder a los recursos del aula, pero estén aislados entre sí.

Conceptos claves: ACLs y Tags

Las ACLs (Listas de Control de Acceso) son un conjunto de reglas en formato JSON (o HuJSON) que definen quién puede hablar con quién. Si no hay una regla que permita la conexión, Headscale la denegará por defecto.
Los Tags (etiquetas) nos permiten agrupar dispositivos por su función en lugar de por su nombre o usuario. Por ejemplo, podemos etiquetar un equipo como tag:servidor y otros como tag:alumno. Cuando un dispositivo se registra con un Tag, deja de "pertenecer" al usuario que lo registró y pasa a ser propiedad del sistema, lo que facilita la gestión de permisos globales.

Caso práctico: El Aula Aislada

Para entender los conceptos de seguridad usando ACLs y Tags vamos a ver un ejemplo concreto. en este ejemplo vamos a estudiar dos aproximaciones distintas para tener un conjunto de clientes (en nuestro caso alumnos) que acceden a una red local (en nuestro caso una red de un aula). Los objetivos a cumplir son los siguientes:

Los alumnos se conectan a la VPN.
Existe un Router que anuncia la red local del aula (192.168.100.0/24).
Los alumnos pueden acceder a los equipos de la red local.
Los alumnos NO pueden verse ni hacerse ping entre ellos.

Para conseguir dichos objetivos, vamos a estudiar dos aproximaciones distintas:

Estrategia 1: Red Unificada con Control por Etiquetas (Tags)
Estrategia 2: Segmentación por Usuarios (Namespaces Aislados)

Estrategia 1: Red unificada con control por Etiquetas (Tags)

Esta estrategia se basa en mantener a todos los nodos dentro de un mismo espacio compartido (el mismo usuario), pero diferenciando sus capacidades mediante el uso de etiquetas lógicas. Al asignar un tag:alumno o tag:router, el motor de seguridad de Headscale deja de aplicar permisos basados en quién inició sesión y pasa a aplicar reglas estrictas definidas en el archivo de política: si una regla no autoriza explícitamente que un "alumno" hable con otro, el sistema bloquea esa comunicación de forma nativa. Es la opción más escalable y profesional, ya que permite gestionar cientos de dispositivos con apenas un par de líneas de configuración centralizada, manteniendo un control granular sobre puertos y protocolos.

Lo primero que tenemos que hacer es activar la configuración de las ACLs, para ello en el fichero de configuración indicamos el fichero donde vamos a escribir nuestras ACLs, para ello en tu config.yaml, añadimos el parámetro path y reiniciamos el servicio:

policy:
  mode: file
  path: /etc/headscale/acl.hujson

Headscale utiliza un formato llamado HuJSON (JSON con comentarios y comas finales permitidas), lo que facilita mucho su mantenimiento. El archivo de políticas se divide en bloques lógicos que el motor de Headscale procesa de arriba hacia abajo para decidir si permite o bloquea un paquete:

Grupos (groups): Permiten agrupar usuarios reales bajo un alias. Es muy útil para no repetir nombres de personas en las reglas.
Propietarios de Etiquetas (tagOwners): Esta es una sección de seguridad crítica. Define qué usuarios tienen permiso para asignar qué etiquetas (tags) a sus dispositivos. Sin esto, cualquier usuario podría etiquetarse como "servidor" para saltarse las reglas.
Reglas de Acceso (acls): Es el corazón del archivo. Cada regla define una acción, un origen, y un destino:
- Action: Actualmente solo existe accept. Todo lo que no esté explícitamente aceptado, se deniega (Deny por defecto).
- Src (Source): Quién origina la conexión. Puede ser un usuario, un grupo, un tag, una IP o * (todos).
- Dst (Destination): A qué se intenta acceder. Se define como objetivo:puerto.

El funcionamiento general del sistema de seguridad es el siguiente:

Denegación implícita: Si no escribes ninguna regla, ningún nodo puede hablar con nadie.
Unidireccionalidad: Las reglas definen quién inicia la conexión. Si permites que A conecte con B, Tailscale gestiona automáticamente el tráfico de retorno, pero B no podrá iniciar una nueva conexión hacia A a menos que exista otra regla.
Evaluación de Tags: Cuando un dispositivo tiene un Tag, las reglas basadas en su "usuario original" dejan de aplicarse. El Tag tiene prioridad absoluta para el control de tráfico.

A continuación ya podemos escribir nuestras políticas de seguridad, para ello creamos el archivo acl.hujson en nuestra carpeta de configuración de Headscale (si estamos usando docker como en los artículos anteriores este fichero sería config/acl.hujson):

{
  // Definimos los grupos y etiquetas
  "groups": {
    "group:profesores": ["admin"]
  },

  "tagOwners": {
    "tag:router-aula": ["group:profesores"],
    "tag:alumno": ["group:profesores"]
  },

  "acls": [
    // 1. Permitir que los alumnos accedan a la red local anunciada por el router
    {
      "action": "accept",
      "src":    ["tag:alumno"],
      "dst":    ["192.168.100.0/24:*"]
    },
    // 2. Permitir que el profesor tenga acceso total (opcional)
    {
      "action": "accept",
      "src":    ["group:profesores"],
      "dst":    ["*:*"]
    }
    // NOTA: Al no haber una regla que permita "src: tag:alumno" a "dst: tag:alumno",
    // el tráfico entre alumnos queda bloqueado automáticamente.
  ]
}

Esta política de seguridad utiliza un modelo de confianza cero (Zero Trust). Siguiendo la sintaxis de Headscale, cada bloque cumple una función específica para garantizar que los alumnos estén aislados entre sí pero tengan acceso a los recursos necesarios.

Aquí tienes la explicación detallada de cada sección:

Definición de Roles (groups): Se crea un grupo llamado group:profesores que incluye al usuario admin. Esto permite asignar permisos a un conjunto de personas sin tener que escribir sus nombres uno por uno en cada regla.
Control de Etiquetas (tagOwners): Esta es la capa de seguridad de identidad. Establece que solo los miembros de group:profesores tienen autoridad para asignar las etiquetas tag:router-aula y tag:alumno a los dispositivos. Esto evita que un alumno malintencionado intente cambiarse de etiqueta para obtener más privilegios.
Acceso Restringido para Alumnos (acls - Regla 1): Define que cualquier dispositivo etiquetado como tag:alumno puede iniciar conexiones hacia la subred física del aula (192.168.100.0/24) en cualquier puerto (*).
Privilegios de Administración (acls - Regla 2): Se otorga al group:profesores acceso total a cualquier destino (*:*). Esto asegura que el personal docente pueda gestionar todos los nodos y recursos de la VPN sin restricciones.
Aislamiento Automático (Deny implícito): Es la parte más importante del funcionamiento. Al no existir una regla que diga que tag:alumno puede conectar con tag:alumno, el tráfico entre los dispositivos de los estudiantes es bloqueado por defecto. Aunque estén en la misma VPN, son invisibles entre sí.
Tráfico Unidireccional: Las reglas definen quién puede "abrir" la conexión. Los alumnos pueden acceder a la red local, pero los equipos de la red local no pueden iniciar conexiones hacia los alumnos (a menos que añadas una regla inversa).

Para que las reglas se apliquen, debemos usar los tags al conectar los equipos:

En el Router de la red local

sudo tailscale up --login-server https://vpn.example.org \
  --advertise-routes=192.168.100.0/24 \
  --advertise-tags=tag:router-aula

Recuerda que en el servidor headscale habrá que aceptar la ruta anunciada, como estudiamos en el post: Configuración del enrutamiento y DNS en una VPN tailscale/headscale.

En el equipo de cada Alumno

Para simplificar, puedes generar una Pre-Auth Key etiquetada para que los alumnos no tengan que hacer nada manual:

docker exec headscale headscale preauthkeys create --user vpn1 --reusable --tag tag:alumno

El alumno solo tendrá que ejecutar:

sudo tailscale up --login-server https://vpn.example.org --authkey hskey-auth-XXXXX

Resultado final

El alumno ahora tiene una interfaz tailscale0 que le permite llegar a 192.168.100.50 (un equipo del aula), pero si intenta hacer ping a la IP de la VPN de su compañero de al lado, el tráfico será descartado silenciosamente por el motor de filtrado de Tailscale.

Estrategia 2: Segmentación por usuarios (Namespaces Aislados)

Esta estrategia aprovecha la arquitectura nativa de Headscale para crear compartimentos estancos mediante la creación de un usuario independiente para cada entidad (por ejemplo, uno por cada alumno). En este modelo, el aislamiento es el estado por defecto: los nodos de diferentes usuarios no pueden verse entre sí porque pertenecen a redes lógicas totalmente separadas. Para permitir el acceso a los recursos comunes, como el router del aula, se definen reglas de visibilidad transversales en las ACL que "perforan" estos muros de forma controlada. Es una solución muy intuitiva y robusta para escenarios donde se busca un aislamiento total y sencillo, ya que evita que un error en el etiquetado de un nodo pueda exponerlo accidentalmente al resto de la malla.

En este escenario, crearíamos alumno1, alumno2, alumno3, etc. El Router de la red local (donde están los recursos) se quedaría en un usuario administrativo, por ejemplo infra:

docker exec headscale headscale users create infra
docker exec headscale headscale users create alumno1
docker exec headscale headscale users create alumno2

A continuación, registramos el Router en el usuario infra, por lo tanto en el router (en el nodo que hace de pasarela a la red local (192.168.100.0/24)) ejecutamos:

sudo tailscale up --login-server https://vpn.example.org --advertise-routes=192.168.100.0/24

Recuerda que en el servidor Headscale habrá que aceptar la ruta anunciada, como estudiamos en el post: Configuración del enrutamiento y DNS en una VPN tailscale/headscale.

Configuramos la ACL para "romper" el aislamiento. Como cada alumno está en un usuario distinto, ahora mismo no pueden ver el Router (porque el Router está en infra). Necesitamos una regla en acl.hujson que permita este cruce:

{
  "acls": [
    // Permitir que cualquier usuario (alumnos) acceda a la subred del router
    {
      "action": "accept",
      "src":    ["*"], 
      "dst":    ["192.168.100.0/24:*"]
    }
  ]
}

Al usar src: ["*"], permitimos que todos los usuarios de Headscale lleguen a esa red, pero como no hay ninguna regla que diga que alumno1 puede hablar con alumno2, el aislamiento entre ellos se mantiene intacto.

Por último, cada usuario registra sus propios dispositivos usando el registro interactivo o usando una Pre-Auth Key y aceptando las rutas.

# Para el alumno 1
sudo tailscale up --accept-routes --login-server https://vpn.example.org --authkey hskey-auth-XXXXX

Recuerda que en los clientes linux tenemos que aceptar las reglas de encaminamiento con el parámetro --accept-routes, como estudiamos en el post: Configuración del enrutamiento y DNS en una VPN tailscale/headscale.

Resultado final

Al finalizar esta configuración, cada dispositivo se encuentra en una burbuja lógica definida por su usuario (Namespace). Un alumno conectado como alumno1 podrá alcanzar cualquier servicio dentro de la red del aula 192.168.100.0/24 gracias a la regla de "cruce" que hemos definido en las ACL. Sin embargo, dado que no existe ninguna política que autorice el tráfico entre usuarios distintos, el aislamiento es absoluto: la red mesh se comporta como una estrella donde el centro son los recursos compartidos y las puntas son nodos totalmente independientes.

Conclusiones

Hemos explorado dos formas de alcanzar un mismo objetivo: seguridad y aislamiento. Aunque ambas son eficaces, la elección dependerá de la complejidad y el propósito de tu red:

Característica	Estrategia 1: Tags	Estrategia 2: Usuarios (Namespaces)
Escalabilidad	Alta. Ideal para cientos de nodos.	Media. Tedioso si hay muchos usuarios.
Control	Granular (por puertos y protocolos).	Grueso (aislamiento total por defecto).
Gestión	Centralizada en un solo archivo JSON.	Descentralizada en la base de datos.
Uso ideal	Entornos profesionales y corporativos.	Entornos pequeños o laboratorios rápidos.

La Estrategia 1 (Tags) es la que más se acerca al modelo Zero Trust moderno, ya que permite definir políticas basadas en la función del dispositivo y no en quién es su dueño. Es la opción que ofrece mayor flexibilidad a largo plazo, permitiéndote, por ejemplo, que un alumno acceda al servidor web del aula (puerto 80) pero no al SSH del router (puerto 22) con una simple modificación en las ACL.

Por otro lado, la Estrategia 2 (Usuarios) es perfecta por su robustez ante errores humanos; es casi imposible que un alumno acceda accidentalmente a otro dispositivo si están en usuarios distintos, lo que la convierte en una opción muy segura para configuraciones rápidas donde no queremos mantener un archivo de políticas complejo.

Independientemente del camino elegido, Headscale demuestra ser una herramienta extremadamente potente para gestionar la seguridad de red sin la rigidez de los firewalls tradicionales.

Nuevo editor Zed

Mon, 16 Mar 2026 00:00:00 GMT

En los últimos días estoy usando un nuevo editor de texto llamado ZED y la experiencia está siendo bastante interesante. ZED es un editor de código construido desde cero en Rust, lo que lo hace increíblemente rápido y ligero. Arranca en milisegundos y no consume apenas memoria, algo que se nota mucho si vienes de editores más pesados.

Algunas de las características que más me están gustando:

Alto rendimiento..
Colaboración en tiempo real.
IA integrada.
Minimalista pero potente.
Extensiones para aportar más funcionalidades.

Página web

Próximo curso de Kubernetes

Fri, 13 Mar 2026 00:00:00 GMT

Quinta edición del curso: Introducción a Kubernetes para profesores de la Junta de Andalucía. Más información

NoSubscription.org: Herramientas propias, no alquiladas

Mon, 09 Mar 2026 00:00:00 GMT

NoSubscription.org es un directorio y manifiesto para profesionales que rechazan el modelo de suscripción mensual. Su objetivo es ayudar a freelancers y empresas a recuperar la propiedad de su flujo de trabajo.

¿Para qué sirve?: Para localizar software profesional sin cuotas recurrentes, eliminando costes fijos y el control de las grandes corporaciones SaaS.
¿Qué encontrarás?: Un catálogo verificado de herramientas divididas en:
- One-time purchase: Pago único con licencia perpetua.
- Open source: Código abierto y soberanía técnica.
- Free tools: Alternativas gratuitas de alta calidad.

El Manifiesto: "Creemos que las personas deben ser dueñas de sus herramientas, no alquilarlas. Las suscripciones agotan los recursos de los profesionales."

Dominando journalctl: Filtra logs como un pro con Unidades y Tags

Wed, 04 Mar 2026 00:00:00 GMT

journalctl es la herramienta de línea de comandos que permite consultar y administrar de forma centralizada todos los registros (logs) del sistema y de los servicios gestionados por systemd en Linux.

En journalctl, una etiqueta o tag (técnicamente llamado SYSLOG_IDENTIFIER) es el nombre breve que identifica al programa o servicio que ha generado un mensaje, permitiendo filtrar rápidamente los logs por su procedencia.

Podemos leer los dos logs de dos formas distintas:

journalctl -u (Unit): Se usa para filtrar por una unidad de systemd (normalmente archivos .service). Es ideal cuando quieres ver todo lo que ha pasado con un demonio específico (arranque, paradas y errores), como por ejemplo apache2, mysql o nginx.
journalctl -t (Tag/Identifier): Se usa para filtrar por el identificador de syslog (SYSLOG_IDENTIFIER). Es ideal para localizar mensajes enviados por scripts personalizados, comandos manuales (usando logger) o aplicaciones que no tienen un servicio propio pero "firman" sus logs con un nombre.

Para ver qué etiquetas (SYSLOG_IDENTIFIER) tienes disponibles y cuáles puedes usar para filtrar, el comando más directo y limpio es el siguiente:

sudo journalctl -F SYSLOG_IDENTIFIER

Configuración del enrutamiento y DNS en una VPN tailscale/headscale

Tue, 24 Feb 2026 00:00:00 GMT

En el post anterior, Construcción de VPN mesh con tailscale/headscale, logramos conectar varios dispositivos mediante una VPN mesh.

En este artículo, profundizaremos en tres capacidades críticas que transforman una red privada virtual en una solución de conectividad integral:

Subnet Routers: Implementaremos el concepto de VPN Site-to-Site, permitiendo que nodos específicos actúen como gateways para exponer subredes completas (LAN) a la malla, integrando así dispositivos sin capacidad de instalar software (como impresoras, servidores NAS,...).
Exit Nodes: Configuraremos nodos de salida para centralizar el tráfico de internet de la red mesh, permitiendo una navegación segura y controlada a través de un punto de confianza (similar a una VPN de acceso remoto tradicional).
Split DNS y Global Nameservers: Optimizaremos la resolución de nombres dentro de la red mediante la integración de DNS internos, facilitando el acceso a servicios mediante FQDNs en lugar de direcciones IP estáticas.

Subnet Router

Un Subnet Router es un nodo de nuestra red que actúa como pasarela, permitiendo que el resto de los dispositivos de la VPN "salten" a una red local física (por ejemplo, la red de tu oficina o de tu casa). Cualquier nodo Linux en el que ya tengas Tailscale funcionando puede servir como Subnet Router.

El escenario desde el que partimos es el siguiente:

docker exec headscale headscale nodes list
ID | Hostname | Name    | MachineKey | NodeKey | User | Tags | IP addresses                  | Ephemeral | Last seen           | Expiration          | Connected | Expired
1  |  nodo1   | nodo1   | [qatKd]    | [fMe1N] | vpn1 |      | 100.64.0.1, fd7a:115c:a1e0::1 | false     | 2026-02-13 18:09:45 | N/A                 | online    | no     
2  |  nodo2   | nodo2   | [G1VUT]    | [9wBm+] | vpn1 |      | 100.64.0.2, fd7a:115c:a1e0::2 | false     | 2026-02-13 18:30:17 | 0001-01-01 00:00:00 | online    | no     
3  |  nodo3   | nodo3   | [asFdw]    | [8qDba] | vpn1 |      | 100.64.0.3, fd7a:115c:a1e0::3 | false     | 2026-02-13 18:35:17 | 0001-01-01 00:00:00 | online    | no

Vamos a suponer que el nodo2 es el Subnet Router. Para configurar este nodo lo primero es habilitar el reenvío de paquetes en ese nodo, para ello activamos el bit de forwarding en nodo2:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Anuncio de las rutas de encaminamiento

A continuación, el nodo2 tiene que anunciar la ruta, suponemos que la red local a la que nos da acceso el nodo2 es la 192.168.18.0/24. Para anunciar la ruta de encaminamiento que permita a los otros nodos acceder a dicha red, ejecutamos en nodo2:

sudo tailscale up --login-server https://vpn.example.org --advertise-routes=192.168.18.0/24

Si el nodo ya estaba iniciado:

sudo tailscale set --advertise-routes=192.168.18.0/24

Podemos comprobar que el nodo está anunciando nuevas rutas desde el servidor Headscale, ejecutando:

docker exec headscale headscale nodes list-routes
ID | Hostname | Approved        | Available       | Serving (Primary)
2  | nodo2    | 192.168.18.0/24 | 192.168.18.0/24 |

Aprobación de las rutas de encaminamiento

Por seguridad, Headscale no permite que un nodo "inyecte" rutas en la red mesh sin permiso del administrador. Tenemos dos formas de aprobar la ruta anunciada: de forma manual o de forma automática.

La forma automática está pensada cuando tenemos pensado añadir muchos nodos o redes. Headscale permite definir reglas de "auto-aprobación" en su configuración, modificando el archivo de configuración config.yml como nos indica la documentación.

En nuestro caso estudiaremos la aprobación manual. Desde el servidor Headscale, ejecutamos la siguiente instrucción para habilitar la ruta que se está anunciando:

docker exec headscale headscale nodes approve-routes --identifier 2 --routes 192.168.18.0/24

Si volvemos a ver las rutas desde el servidor, comprobamos que se ha aprobado:

docker exec headscale headscale nodes list-routes
ID | Hostname | Approved        | Available       | Serving (Primary)
2  | nodo2    | 192.168.18.0/24 | 192.168.18.0/24 | 192.168.18.0/24

Configuración de la ruta de encaminamiento en el cliente

Una vez que la ruta está aprobada en el servidor, los clientes (nodos) de la VPN ya saben que esa red existe, pero los clientes Linux son precavidos y no la añadirán a su tabla de rutas local a menos que se lo pidas. Por ejemplo en el nodo1 ejecutamos:

sudo tailscale up    --login-server=https://vpn.example.org

Si el cliente ya está iniciado, podemos ejecutar:

sudo tailscale set --accept-routes

En dispositivos en otros sistemas operativos, este paso no suele ser necesario, ya que el cliente oficial acepta las rutas del servidor automáticamente.

Verificación de la conectividad

Desde el nodo nodo1 hacemos ping a un dispositivo de la red local que no tenga Tailscale instalado:

ping 192.168.18.1  # La IP del router de tu casa
64 bytes from 192.168.18.1: icmp_seq=1 ttl=63 time=50.6 ms

Veamos donde se declara la ruta de encaminamiento. Tailscale crea una nueva tabla de encaminamiento para introducir las rutas que necesita, para ver las tablas de encaminamiento ejecutamos: ip rule show. Entre varias tablas que encontramos, tenemos que tener en cuenta que la tabla de encaminamiento por defecto se llama main y la tabla de encaminamiento de Tailscale es la llamada 52. Por lo tanto si vemos las rutas de esta tabla, encontramos la ruta de encaminamiento que hemos aceptado:

ip route show table 52
... 
192.168.18.0/24 dev tailscale0

Exit Node

Por defecto, Tailscale solo encamina a través de la VPN el tráfico destinado a otros nodos de tu red. El resto del tráfico (tu navegación por internet) sale por la conexión local del dispositivo en el que estás.

Al configurar un Exit Node, puedes indicar a tus dispositivos que todo su tráfico de internet pase primero por un nodo específico de la VPN antes de salir a la red pública. Esto es ideal para:

Navegar de forma segura desde redes Wi-Fi públicas sospechosas.
Acceder a servicios que solo permiten IPs de un país determinado (si tienes el Exit Node allí).
Centralizar el filtrado de tráfico en un solo punto.

Anuncio del exit node

En nuestro ejemplo, vamos a configurar como exit node nuestro nodo nodo3. Lo primero activaremos el bit de forwarding en ese nodo:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Una vez preparado, le indicamos que se anuncie como nodo de salida:

sudo tailscale up --login-server https://vpn.example.org --advertise-exit-node

Si el nodo ya está funcionando, podemos ejecutar:

sudo tailscale set --advertise-exit-node

Podemos comprobar que el nodo está anunciando nuevas rutas desde el servidor Headscale, ejecutando:

docker exec headscale headscale nodes list-routes
ID | Hostname | Approved        | Available       | Serving (Primary)
2  | nodo2    | 192.168.18.0/24 | 192.168.18.0/24 | 192.168.18.0/24
3  | nodo3    | 0.0.0.0/0       | 0.0.0.0/0       |         
   |          | ::/0            | ::/0            |

Aprobación del exit node

Al igual que con los subnet routers, ahora debemos aprobar la ruta por defecto desde el servidor Headscale. A aunque podemos hacerlo de forma automática, vamos a ver el procedimiento manual. Para ello ejecutamos desde el servidor Headscale:

docker exec headscale headscale nodes approve-routes --identifier 3 --routes 0.0.0.0/0,::/0

Y volvemos a comprobar las rutas aprobadas:

docker exec headscale headscale nodes list-routes
ID | Hostname | Approved        | Available       | Serving (Primary)
2  | nodo2    | 192.168.18.0/24 | 192.168.18.0/24 | 192.168.18.0/24
3  | nodo3    | 0.0.0.0/0       | 0.0.0.0/0       | 0.0.0.0/0        
   |          | ::/0            | ::/0            | ::/0

Cómo usar el Exit Node desde los clientes

Una vez aprobado, el nodo de salida no se usa automáticamente. Cada cliente debe elegir activarlo. Para empezar a navegar a través del nodo de salida, ejecutamos en el nodo1:

sudo tailscale up --exit-node=nodo3 --login-server https://vpn.example.org

Si el nodo ya está funcionando, ejecutamos:

sudo tailscale set --exit-node nodo3

En las aplicaciones oficiales de otros sistemas operativos, aparecerá una nueva opción en el menú llamada "Exit Node". Al pulsarla, verás una lista de los nodos disponibles que has aprobado en el paso anterior. Solo tienes que seleccionar uno.

Verificación del nodo de salida

Para comprobar que realmente estás saliendo a internet a través de tu nodo de confianza, puedes usar cualquier servicio de geolocalización de IPs desde tu navegador o CLI:

curl ifconfig.me

La dirección IP devuelta debería ser la IP pública de tu Exit Node, no la de la red a la que estás conectado físicamente. Además podemos ver que se ha creado una ruta por defecto en la tabla de encaminamiento 52:

ip route show table 52
default dev tailscale0

DNS y MagicDNS

Hasta ahora, nos hemos comunicado entre nodos usando direcciones IP (como 100.64.0.1). Pero, ¿no sería mejor acceder a nuestro servidor simplemente escribiendo su nombre? Aquí es donde entra MagicDNS y la configuración de DNS en Headscale.

MagicDNS es una función que registra automáticamente los nombres de tus dispositivos en un servidor DNS interno gestionado por Headscale. Si tienes un nodo llamado servidor, MagicDNS te permitirá hacerle un ping o acceder a su web usando un nombre de dominio.

Configuración del DNS en Headscale

Para que esto funcione, debemos editar el archivo de configuración de nuestro servidor Headscale (config/config.yaml). Busca la sección dns_config y ajústala:

dns_config:
  # El dominio base para tu red mesh
  magic_dns: true
  base_domain: vpn.example.org

  # Servidores DNS que usarán los nodos para resolver internet
  nameservers:
    - 1.1.1.1
    - 1.0.0.1
...

magic_dns: true: Activa la resolución automática de nombres de nodos.
base_domain: Es el nombre de dominio que vamos a usar. En nuestro caso vpn.example.org.
nameservers: Servidores DNS que se usan para resolver otros dominios.

Tras cambiar el fichero, recuerda reiniciar el contenedor: docker-compose restart headscale

Con esta configuración tenemos un servidor DNS en la dirección 100.100.100.100 que resolverá los nombres de nuestros nodos de la VPN usando el dominio configurado y que funciona como DNS forward para resolver otros nombres.

Podemos comprobar la configuración del servidor DNS de uno de nuestro nodos:

cat /etc/resolv.conf

nameserver 100.100.100.100
search vpn.example.org

Y podemos acceder a los nodos usando su nombre FQDN o hostname, ya que tenemos configurado el parámetro search:

ping nodo2
PING nodo2.vpn.example.org (100.64.0.2) 56(84) bytes of data.
64 bytes from nodo2.vpn.example.org (100.64.0.2): icmp_seq=1 ttl=64 time=17.7 ms

ping nodo2.vpn.example.org
PING nodo2.vpn.example.org (100.64.0.2) 56(84) bytes of data.
64 bytes from nodo2.vpn.example.org (100.64.0.2): icmp_seq=1 ttl=64 time=17.7 ms

Split DNS (DNS dividido)

Esta es una de las funciones más potentes. Imagina que tienes un servidor DNS en tu red local que solo resuelve dominios internos (ej: *.josedomingo.org). Puedes decirle a Headscale que solo las consultas para ese dominio se envíen a ese servidor.

El Split DNS es la capacidad de Tailscale/Headscale para actuar como un "semáforo" de peticiones DNS. En lugar de enviar todas tus consultas a un único servidor DNS, el cliente decide a quién preguntar basándose en el dominio de la dirección que intentas resolver.

En nuestro ejemplo, vamos a configurar un Split DNS para que las consultas de josedomingo.org vayan al servidor 192.168.18.3, Para ello en la configuración de Headscale, en el fichero config.yaml, en la sección dns_config:

dns_config:
...
  split:
    josedomingo.org:
      - 192.168.18.3

Recuerda que para que el cliente pueda alcanzar la IP 192.168.18.3 (que es el servidor DNS), esa IP debe estar anunciada por algún Subnet Router en tu red y aprobada en Headscale.

Para comprobar el funcionamiento, podemos hacer una consulta desde el nodo1:

dig home.josedomingo.org +short
192.168.18.3

Conclusión

La integración de Subnet Routers, Exit Nodes y Split DNS transforma una red mesh básica en una infraestructura de red corporativa completa y eficiente. Esta arquitectura permite consolidar topologías Site-to-Site para integrar dispositivos sin agente, centralizar el tráfico de salida bajo políticas de seguridad unificadas y optimizar la resolución de nombres mediante una gestión inteligente de consultas DNS. En conjunto, estas capacidades proporcionan una abstracción de capa 3 que garantiza una conectividad transparente, segura y escalable, eliminando la complejidad del enrutamiento tradicional en entornos híbridos.

Construcción de VPN mesh con tailscale/headscale

Sat, 14 Feb 2026 00:00:00 GMT

Tailscale es una VPN de red en malla (mesh) basada en el protocolo WireGuard. A diferencia de las VPN tradicionales (donde todo el tráfico pasa por un servidor central), en una red mesh los dispositivos establecen conexiones directas punto a punto () entre sí. Para lograr esto, utiliza técnicas de NAT Traversal, permitiendo que los nodos se comuniquen aunque estén detrás de firewalls o routers sin necesidad de abrir puertos manualmente.

La arquitectura de Tailscale se divide en dos capas:

Control Plane: Es el "cerebro" de la red. No toca tus datos; su función es autenticar usuarios, intercambiar las llaves públicas de cifrado y distribuir la tabla de rutas a todos los nodos.
Data Plane: Es el tráfico real cifrado que fluye directamente entre los dispositivos una vez que el Control Plane los ha "presentado".

Tailscale opera bajo un modelo Open Core: el software del cliente (lo que instalas en tus dispositivos) es de código abierto, pero el servidor de coordinación (Control Plane) es software propietario alojado en su nube.

Headscale es la alternativa libre y autoalojable (self-hosted) al Control Plane oficial. Es un proyecto de código abierto que implementa las mismas APIs, permitiéndote:

Mantener la soberanía total sobre tus metadatos y la gestión de la red.
Utilizar los clientes oficiales de Tailscale simplemente apuntándolos a tu propia instancia.
Eliminar los límites de usuarios o dispositivos de los planes comerciales.

Instalación de Headscale

Para que Headscale pueda coordinar las conexiones entre todos tus dispositivos, necesitamos alojarlo en una máquina que actúe como punto de encuentro permanente. A diferencia de los nodos de la VPN, que pueden entrar y salir de la red o cambiar de ubicación, el servidor de Headscale debe ser el ancla de la infraestructura.

Características de la máquina

El servidor donde instales Headscale (normalmente un VPS o un servidor dedicado) debe cumplir con tres condiciones fundamentales para garantizar la estabilidad de la red:

Accesibilidad Global: La máquina debe tener una IP pública estática o un nombre de dominio (FQDN) asociado. Esto permite que cualquier nodo, esté donde esté, pueda localizar el Control Plane para solicitar instrucciones de conexión.
Seguridad mediante HTTPS: Es obligatorio que el tráfico entre los clientes y Headscale viaje cifrado. Necesitarás un certificado SSL (puedes usar Let's Encrypt) para que la comunicación se realice de forma segura a través del puerto 443.
Disponibilidad (Uptime): Si el servidor de Headscale se apaga, los nodos nuevos no podrán unirse y los existentes no podrán actualizar sus tablas de rutas si hay cambios en la red.

Para una configuración básica y funcional, no es necesario complicar el firewall. Según la documentación oficial de requisitos de Headscale, solo necesitas asegurar la apertura de los siguientes puertos:

443/tcp:Tráfico de control (API) y autenticación mediante HTTPS.
80/tcp: Generalmente usado para la validación de certificados (Let's Encrypt).

Headscale es extremadamente ligero. Para una red pequeña o mediana, una máquina con 1 vCPU y 1 GB de RAM es más que suficiente para gestionar el panel de control.

En la página anterior puedes encontrar distintos métodos de instalación, en este artículo utilizaremos un contenedor Docker para realizar la instalación, para ello y siguiendo la documentación Running headscale in a container:

mkdir -p ./headscale/{config,lib}
cd headscale

Bajamos el fichero de configuración por defecto según la versión con la que vamos a trabajar, podemos encontrar las instrucciones para descargarlo en la documentación. En este caso usamos la versión 0.28.0:

cd config
curl -o config.yaml https://raw.githubusercontent.com/juanfont/headscale/v0.28.0-beta.2/config-example.yaml

A continuación modificamos la configuración para que el servidor escuche en todos las direcciones, para ello en el fichero config/config.yaml modificamos el siguiente parámetro de la siguiente forma:

listen_addr: 0.0.0.0:8080

Ahora creamos el fichero docker-compose.yaml:

services:
  headscale:
    image: docker.io/headscale/headscale:${HEADSCALE_VERSION}
    restart: unless-stopped
    container_name: headscale
    read_only: true
    tmpfs:
      - /var/run/headscale
    ports:
      - "127.0.0.1:8080:8080"
      - "127.0.0.1:9090:9090"
    volumes:
      - ${HEADSCALE_PATH}/config:/etc/headscale:ro
      - ${HEADSCALE_PATH}/lib:/var/lib/headscale
    command: serve
    healthcheck:
        test: ["CMD", "headscale", "health"]

Y el fichero .env:

# La versión de headscale que deseas utilizar
HEADSCALE_VERSION=0.28.0

# La ruta absoluta a tu directorio de headscale
HEADSCALE_PATH=.

Iniciamos el contenedor y comprobamos que funciona:

docker-compose up -d
Starting headscale ... done

curl http://127.0.0.1:8080/health
{"status":"pass"}

Ahora configuramos el proxy inverso, para ello tenemos ejemplos de configuración en Running headscale behind a reverse proxy. Y comprobamos que funciona:

curl https://vpn.example.org/health
{"status":"pass"}

Finalmente cambiamos el parámetro de la configuración para indicar la url de acceso, para ello en el fichero config/config.yaml modificamos:

server_url: https://vpn.example.org

Reiniciamos el contenedor:

docker-compose restart

Creación de usuarios

En Headscale, un usuario es una entidad lógica que agrupa un conjunto de dispositivos.

Los dispositivos que pertenecen al mismo usuario pueden verse entre sí de forma predeterminada.
Sirve para aislar entornos: puedes tener un usuario para tus dispositivos personales y otro para servidores de trabajo, manteniendo las redes separadas dentro de la misma instancia de Headscale.

No puedes registrar ningún nodo (dispositivo) en Headscale si no existe al menos un usuario al que asignárselo. Para crear tu primer usuario (por ejemplo, "mi-red"), utiliza el siguiente comando:

docker exec headscale headscale users create vpn1
User created

docker exec headscale headscale users list
ID | Name | Username | Email | Created            
1  |      | vpn1     |       | 2026-02-13

Podemos eliminar un usuario ejecutando:

docker exec headscale headscale users destroy vpn1

En este caso se realiza una limpieza total de los recursos asociados a esa identidad:

Eliminación de Nodos: Todos los dispositivos (nodos) registrados bajo ese usuario son expulsados de la red inmediatamente.
Revocación de Claves: Las claves de cifrado y los certificados asociados a esos nodos quedan invalidados.

Registro de Nodos: conectando tus dispositivos

Una vez que el servidor está listo y el usuario creado, el siguiente paso es registrar los dispositivos (nodos). Mientras que Headscale opera exclusivamente en el Control Plane (gestionando la lógica de red y la distribución de llaves), la conectividad efectiva requiere el despliegue del cliente oficial de Tailscale en cada nodo. Este cliente actúa en el Data Plane, integrándose con el stack de red del sistema operativo a través de una interfaz virtual TUN y gestionando el cifrado y encapsulamiento de paquetes mediante WireGuard.

Puedes instalar el cliente de Tailscale en prácticamente cualquier sistema operativo moderno (Windows, macOS, Android, iOS, etc.), cuyas descargas están disponibles en la página oficial de Tailscale.

Para este artículo, nos centraremos en Linux, donde la instalación es tan sencilla como ejecutar su script automatizado:

curl -fsSL https://tailscale.com/install.sh | sh

Una vez que el cliente de Tailscale está instalado en el nodo, debemos vincularlo al Control Plane de Headscale. Existen dos métodos de registro principales para realizar esta tarea.

Método interactivo

Este es el método estándar para estaciones de trabajo o dispositivos con intervención humana. El flujo se basa en un desafío-respuesta manual:

Solicitud de registro: En el nodo cliente, se inicia la conexión apuntando a nuestra instancia:
Desafío: El cliente no podrá autenticarse automáticamente y devolverá una URL de registro.
Autorización: Al abrir esa URL, Headscale mostrará un comando preformateado que incluye la nodekey. Debes ejecutar ese comando en el servidor Headscale para validar el nodo y asignarlo a un usuario:

Veamos un ejemplo:

Desde el cliente solicitamos el registro:

sudo tailscale up --login-server https://vpn.example.org

To authenticate, visit:

        https://vpn.example.org/register/STqfQR4wnKr-eerDXam3_RYi

Abrimos el enlace en un navegador web y nos dará la instrucción (que incluye el nodekey) que tenemos que ejecutar en Headscale para autorizar el dispositivo:

headscale nodes register --key STqfQR4wnKr-eerDXam3_RYi --user USERNAME

En nuestro caso, ejecutamos:

docker exec headscale headscale nodes register --key STqfQR4wnKr-eerDXam3_RYi --user vpn1
Node registered

En headscale podemos ver los nodos registrados:

docker exec headscale headscale nodes list
ID | Hostname | Name    | MachineKey | NodeKey | User | Tags | IP addresses                  | Ephemeral | Last seen           | Expiration | Connected | Expired
1  |  nodo1   | nodo1   | [qatKd]    | [fMe1N] | vpn1 |      | 100.64.0.1, fd7a:115c:a1e0::1 | false     | 2026-02-13 18:09:45 | N/A        | online    | no     ```

Y podemos comprobar que el cliente tiene la ip asignada en la VPN:

ip addr show tailscale0
2: tailscale0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none 
    inet 100.64.0.1/32 scope global tailscale0
       valid_lft forever preferred_lft forever
    inet6 fe80::c26f:e628:12cb:72c9/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

Método no interactivo

Para despliegues automatizados, contenedores o servidores donde no queremos realizar una validación manual, Headscale permite el uso de Pre-Auth Keys.

Generación de la clave: Primero, generamos un token de autorización en el servidor Headscale asociado a un usuario específico:
Registro automático: Usamos esa clave en el nodo cliente para completar el registro en un solo paso, sin necesidad de confirmación manual en el servidor:

Veamos un ejemplo:

En primer lugar generamos la clave en el Control Plane:

docker exec headscale headscale preauthkeys create --user 1 --reusable
hskey-auth-Db1RF5n7gSk3-NzIu0vDgXi8yewFjq5w4rczR-uZD-J_RfYnUDSjCmrgRHKXnGaXj_HK3jJfvnhk0

Con el parámetro --reusable la clave se puede usar varias veces, si no se pone, la clave solo se puede usar una vez.

Podemos usar el parámetro --expiration 24h para que la clave expire en 24 horas (por defecto, solo dura una hora), o --ephemeral para que la clave expire cuando el dispositivo se desconecte.

Con el parámetro --user debemos indicar el ID del usuario.

Y luego la usamos para conectar el cliente:

sudo tailscale up --login-server https://vpn.example.org --authkey hskey-auth-Db1RF5n7gSk3-NzIu0vDgXi8yewFjq5w4rczR-uZD-J_RfYnUDSjCmrgRHKXnGaXj_HK3jJfvnhk0

Y comprobamos que el cliente se ha conectado:

docker exec headscale headscale nodes list
ID | Hostname | Name    | MachineKey | NodeKey | User | Tags | IP addresses                  | Ephemeral | Last seen           | Expiration          | Connected | Expired
1  |  nodo1   | nodo1   | [qatKd]    | [fMe1N] | vpn1 |      | 100.64.0.1, fd7a:115c:a1e0::1 | false     | 2026-02-13 18:09:45 | N/A                 | online    | no     
2  |  nodo2   | nodo2   | [G1VUT]    | [9wBm+] | vpn1 |      | 100.64.0.2, fd7a:115c:a1e0::2 | false     | 2026-02-13 18:30:17 | 0001-01-01 00:00:00 | online    | no

Comprobación de la conectividad

Con los nodos registrados y visibles en el listado de Headscale, la red mesh ya está construida. Ahora debemos verificar que el tráfico fluye correctamente entre ellos utilizando las herramientas que proporciona el ecosistema de Tailscale.

El comando `status` en el cliente

Desde cualquier nodo (por ejemplo, desde nodo1), podemos verificar cómo ve este a sus "pares" (peers) en la red:

tailscale status

100.64.0.1  nodo1  vpn1  linux  -                      
100.64.0.2  nodo2  vpn1  linux  idle, tx 468 rx 348

Este comando te mostrará una lista de los demás dispositivos de tu usuario, su dirección IP interna y las características de la conexión.

Prueba de latencia con `tailscale ping`

Aunque el ping tradicional funciona, Tailscale ofrece una herramienta especializada que nos indica cómo se está realizando la conexión:

tailscale ping nodo2
pong from nodo2 (100.64.0.2) via DERP(mad) in 777ms
pong from nodo2 (100.64.0.2) via DERP(mad) in 18ms
pong from nodo2 (100.64.0.2) via DERP(mad) in 16ms
pong from nodo2 (100.64.0.2) via 143.47.53.108:41641 in 13ms

A diferencia del ping estándar, este comando te informará si ha logrado establecer una conexión directa P2P (atravesando con éxito el NAT) o si está usando un servidor intermedio. Es la prueba definitiva de que el Data Plane está operando de forma óptima.

Cualquier servicio que levantes en el puerto 80, 22 o cualquier otro en nodo2 será accesible desde nodo1 (y viceversa) de forma totalmente cifrada y privada, como si estuvieran conectados al mismo switch físico.

Conclusión

La implementación de Headscale como plano de control (Control Plane) independiente permite explotar todo el potencial del protocolo WireGuard sin las limitaciones de un modelo SaaS propietario. Al desacoplar la gestión de identidades y la distribución de rutas de la infraestructura de Tailscale, hemos consolidado una red mesh con topología dinámica capaz de garantizar comunicaciones P2P cifradas con una sobrecarga (overhead) mínima. Esta arquitectura no solo optimiza el rendimiento mediante la negociación directa de túneles tras entornos de NAT complejo, sino que establece un entorno de Zero Trust donde la soberanía de los metadatos y la integridad del tráfico permanecen bajo control absoluto del administrador.

Cursos de virtualización con KVM/libvirt

Sat, 27 Dec 2025 00:00:00 GMT

Este año también he tenido la oportunidad de desarrollar y publicar en OpenWebinars dos cursos centrados en la virtualización con KVM y libvirt, abordando tanto una introducción accesible para principiantes como una profundización orientada a un uso más avanzado y profesional.

Ambos cursos forman parte de un itinerario pensado para entender la virtualización en sistemas Linux desde una perspectiva práctica, progresiva y alineada con el uso real en servidores y entornos de producción.

¿Qué es la virtualización con KVM y libvirt?

KVM (Kernel-based Virtual Machine) es la tecnología de virtualización integrada en el kernel de Linux que permite convertirlo en un hipervisor de tipo 1. Gracias a KVM, un sistema Linux puede ejecutar máquinas virtuales con un rendimiento muy cercano al nativo, aprovechando las extensiones de virtualización por hardware (Intel VT-x / AMD-V).

Por su parte, libvirt es una capa de abstracción que facilita la gestión de máquinas virtuales y otros recursos de virtualización. Proporciona una API unificada y herramientas tanto gráficas como de línea de comandos para administrar hipervisores como KVM de forma coherente y segura.

En conjunto, KVM + libvirt constituyen una de las soluciones de virtualización más utilizadas en entornos Linux, tanto en laboratorios como en infraestructuras profesionales.

Cursos publicados

Para cubrir distintos niveles de experiencia, he preparado dos cursos complementarios, publicados en OpenWebinars y acompañados de material práctico en GitHub.

Curso 1: Introducción a la virtualización con KVM/libvirt usando virt-manager

Accede al curso en Pledin
Repositorio del curso: https://github.com/josedom24/curso_kvm_ow/blob/main/curso1

Este primer curso está orientado a principiantes que desean iniciarse en la virtualización sobre Linux sin necesidad de conocimientos previos avanzados.

Características principales del curso:

Introducción a los conceptos básicos de virtualización
Instalación y configuración de KVM y libvirt
Uso de virt-manager como herramienta gráfica
Creación y gestión básica de máquinas virtuales
Redes y almacenamiento a nivel introductorio

Es un curso ideal para romper la barrera de entrada y comenzar a trabajar con máquinas virtuales de forma visual e intuitiva.

Curso 2: Profundización en la virtualización con KVM/libvirt

Accede al curso en Pledin
Repositorio del curso: https://github.com/josedom24/curso_kvm_ow/blob/main/curso2

El segundo curso está pensado para quienes ya conocen los fundamentos y desean profundizar en la virtualización usando herramientas de línea de comandos.

En este curso se trabaja, entre otros aspectos:

Gestión avanzada de máquinas virtuales con virsh
Definición y modificación de dominios mediante XML
Redes virtuales avanzadas
Gestión de almacenamiento con libvirt
Automatización y administración más cercana a entornos de servidor

Este enfoque resulta especialmente útil para administradores de sistemas, laboratorios avanzados o escenarios donde no se dispone de entorno gráfico.

Cursos de preparación para obtener las certificaciones Python PCEP y PCAP

Fri, 26 Dec 2025 00:00:00 GMT

Este año he tenido la oportunidad de preparar y publicar dos cursos orientados a la obtención de certificaciones oficiales de Python, pensados tanto para personas que se inician en el lenguaje como para quienes desean consolidar sus conocimientos y dar un paso más en su formación.

Siguiendo la misma filosofía que en otros cursos que he desarrollado, el objetivo principal ha sido ofrecer un itinerario claro, progresivo y muy práctico, alineado con los contenidos oficiales de los exámenes y acompañado de abundantes ejemplos y ejercicios.

Certificaciones PCEP y PCAP

Las certificaciones PCEP y PCAP forman parte del itinerario oficial de certificación en Python y están ampliamente reconocidas como una forma sólida de validar conocimientos en este lenguaje.

PCEP – Certified Entry-Level Python Programmer

La certificación PCEP está orientada a personas que comienzan a programar en Python. Evalúa los fundamentos del lenguaje, tales como:

Sintaxis básica y semántica
Tipos de datos fundamentales
Variables y operadores
Control de flujo (if, bucles)
Funciones básicas
Manejo elemental de errores

Es una excelente puerta de entrada para quien quiere demostrar que domina los conceptos esenciales de Python y que está preparado para seguir avanzando.

PCAP – Certified Associate Python Programmer

La certificación PCAP da un paso más y está dirigida a programadores con cierta experiencia previa en Python. En este nivel se profundiza en aspectos como:

Programación estructurada y modular
Colecciones y estructuras de datos avanzadas
Manejo de excepciones
Programación orientada a objetos
Uso más avanzado de funciones y módulos
Buenas prácticas en Python

Superar esta certificación demuestra una comprensión sólida y práctica del lenguaje, adecuada para entornos profesionales o académicos más exigentes.

Cursos publicados

Para cubrir ambos niveles he desarrollado dos cursos completos de preparación, con contenidos teóricos, ejemplos explicados paso a paso y ejercicios específicos orientados al examen.

Curso de preparación para el examen PCEP

Accede al curso en Pledin
Repositorio del curso: https://github.com/josedom24/python_pcep_pcap/tree/main/PCEP
Repositorio de ejercicios: https://github.com/josedom24/ejercicios_python_pcep
Curso en OpenWebinars: https://openwebinars.net/cursos/certificacion-python-pcep/

Este curso está pensado para quienes se inician en Python y quieren una preparación guiada, clara y práctica para afrontar el examen PCEP con garantías.

Curso de preparación para el examen PCAP

Accede al curso en Pledin
Repositorio del curso: https://github.com/josedom24/python_pcep_pcap/tree/main/PCAP
Repositorio de ejercicios: https://github.com/josedom24/ejercicios_python_pcap
Curso en OpenWebinars: https://openwebinars.net/cursos/certificacion-python-pcap/

En este segundo curso se profundiza en Python, con un enfoque más cercano al uso real del lenguaje y a los requisitos del examen PCAP.

Historia de Linux

Mon, 27 Oct 2025 00:00:00 GMT

Historia de Linux desde los años 60 hasta el día de hoy.

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

Wed, 01 Oct 2025 00:00:00 GMT

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.

Construyendo la imagen Docker para Jekyll

Para gestionar múltiples proyectos Jekyll de forma aislada, construimos una imagen basada en Ruby 3.2 que incluya Jekyll y Bundler (herramienta de gestión de dependencias (gemas) para proyectos Ruby). Esta imagen servirá como base para todos nuestros contenedores.

Dockerfile explicado

FROM ruby:3.2

ENV LANG=C.UTF-8 \
    LC_ALL=C.UTF-8 \
    TZ=UTC

RUN apt-get update && apt-get install -y \
    build-essential \
    nodejs \
    git \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /srv/jekyll

RUN gem install jekyll bundler

COPY build-site.sh /usr/local/bin/build-site.sh
RUN chmod +x /usr/local/bin/build-site.sh
COPY install-gem.sh /usr/local/bin/install-gem.sh
RUN chmod +x /usr/local/bin/install-gem.sh

CMD ["bash"]

Esta imagen se crea a partir de la imagen base ruby:3.2 para asegurar compatibilidad con Jekyll, instalamos los paquetes necesarios para construir gemas y manejar proyectos Jekyll. Lo más importante, instalamos Jekyll y Bundler. En esta imagen copiamos dos scripts bash que utilizaremos para gestionar nuestros proyectos Jekyll:

install-gem.sh: Será el encargado de instalar las gemas a partir del fichero Gemfile del proyecto Jekyll. Se ejecuta sólo una vez, cuando se crea el contenedor.
build-site.sh: Lo ejecutaremos cada vez que que queramos generar nuestra página estática a partir del proyecto Jekyll.

Hay que tener en cuenta que el contenedor que vamos a crear tendrá dos volúmenes:

El directorio del proyecto: que será la ruta al repositorio donde se encuentra el proyecto Jekyll.
El directorio de salida: que será la ruta del directorio donde hay que guardar el contenido estático generado.

De manera gráfica sería:

Gestión de contenedores con `run.sh`

Para simplificar la creación y actualización de contenedores, usamos un wrapper bash llamado run.sh. Cuando usemos este script tendremos que indicar 3 parámetros en la línea de comandos:

El nombre del contenedor: de esta manera podremos tener distintos contenedores para gestionar distintos proyectos Jekyll, cada uno de ellos podrá requerir dependencias distintas.
El directorio del proyecto.
El directorio de salida.

El script hace las siguientes operaciones:

Si no existe la imagen, la genera a partir del fichero Dockerfile.
Si el contenedor ya existe, se arranca si estaba parado y se ejecuta build-site.sh. Es decir, se genera la página estática.
Si no existe el contenedor, se crea un contenedor con el nombre indicado y los volúmenes del proyecto y del HTML, se ejecuta install-gem.sh y luego build-site.sh. Es decir, se crea el contenedor, se instalan las gemas a partir del fichero Gemfile del proyecto y se genera, por primera vez, la página estática.

Para mantener el contenedor activo se ejecuta bash -c "tail -f /dev/null", permitiendo ejecutar comandos adicionales mediante docker exec sin detenerlo.

El contenido del fichero run.sh es:

#!/bin/bash
set -e

if [ $# -lt 3 ]; then
  echo "Uso: $0 <nombre-contenedor> <ruta-repositorio-jekyll> <ruta-salida-html>"
  exit 1
fi

CONTAINER_NAME="$1"
REPO_DIR=$(realpath "$2")
OUT_DIR=$(realpath "$3")

docker image inspect docker-jekyll >/dev/null 2>&1 || \
  docker build -t docker-jekyll .

if docker ps -a --format '{{.Names}}' | grep -q "^$CONTAINER_NAME\$"; then
  echo "Contenedor existente '$CONTAINER_NAME', ejecutando build-site.sh..."
  if ! docker ps --format '{{.Names}}' | grep -q "^$CONTAINER_NAME\$"; then
    docker start "$CONTAINER_NAME"
  fi
  docker exec -i "$CONTAINER_NAME" /usr/local/bin/build-site.sh "$REPO_DIR" "$OUT_DIR"
else
  echo "Creando contenedor '$CONTAINER_NAME' y ejecutando install-gem.sh..."
  docker run -dit --name "$CONTAINER_NAME" \
    -v "$REPO_DIR":"$REPO_DIR" \
    -v "$OUT_DIR":"$OUT_DIR" \
    docker-jekyll \
    bash -c "tail -f /dev/null"
  docker exec -i "$CONTAINER_NAME" /usr/local/bin/install-gem.sh "$REPO_DIR" 
  docker exec -i "$CONTAINER_NAME" /usr/local/bin/build-site.sh "$REPO_DIR" "$OUT_DIR"
fi

Scripts para gestionar proyectos

Sólo nos queda explicar el funcionamiento de los dos script que hemos copiado en la imagen y nos ayudan a gestionar nuestros proyectos Jekyll.

`install-gem.sh`

Este script se encarga de instalar las gemas que cada proyecto Jekyll necesita según su Gemfile. Solo se ejecuta, como hemos visto, cuando se crea el contenedor.

#!/bin/bash
set -e

if [ $# -lt 1 ]; then
  echo "Uso: $0 <ruta-repositorio-jekyll>"
  exit 1
fi

SRC_DIR="$1"

echo "Instalando Gemfile de: $SRC_DIR"

cd "$SRC_DIR"

if [ -f "Gemfile" ]; then
  bundle install
fi

`build-site.sh`

Este script genera el HTML estático del proyecto Jekyll en el directorio de salida. Se ejecuta cada vez que queremos generar la página. Permite mantener separados el código fuente y el resultado generado, usando un volumen para la salida HTML.

#!/bin/bash
set -e

if [ $# -lt 2 ]; then
  echo "Uso: $0 <ruta-repositorio-jekyll> <ruta-salida-html>"
  exit 1
fi

SRC_DIR="$1"
DEST_DIR="$2"

echo "Usando repositorio en: $SRC_DIR"
echo "Generando HTML en: $DEST_DIR"

cd "$SRC_DIR"

bundle exec jekyll build -d "$DEST_DIR"

Ejemplo de uso

Supongamos que tenemos un proyecto Jekyll llamado proyecto-jekyll y queremos generar el HTML resultante en el directorio html. Además, queremos crear un contenedor llamado contenedor-jekyll para gestionar este proyecto de forma aislada.

Con el script run.sh que hemos definido, el proceso es muy sencillo. Basta con ejecutar:

./run.sh contenedor-jekyll ./proyecto-jekyll ./html

El comportamiento será el siguiente:

Creación de la imagen Docker (si no existe): El script comprobará si la imagen docker-jekyll ya existe. Si no, la construirá a partir del Dockerfile.
Creación del contenedor (si no existe): Si el contenedor contenedor-jekyll no existe, se creará, montando los volúmenes:
- ./proyecto-jekyll dentro del contenedor, para acceder al código fuente.
- ./html dentro del contenedor, para guardar el HTML generado.
A continuación se ejecutará install-gem.sh para instalar las gemas necesarias según el Gemfile del proyecto.
Generación del sitio: Finalmente, se ejecutará build-site.sh, generando el HTML en el directorio ./html.
Contenedor activo para futuras ejecuciones: El contenedor permanecerá en ejecución en segundo plano, lo que permite generar de nuevo el sitio simplemente volviendo a ejecutar run.sh o utilizando docker exec para ejecutar comandos adicionales dentro del contenedor.

Después de ejecutar el comando, el directorio ./html contendrá todo el sitio estático generado por Jekyll, listo para ser servido por cualquier servidor web. Además, el contenedor contenedor-jekyll estará disponible para regenerar el sitio cuando hagamos cambios en el proyecto.

ls html
# index.html  about.html  css/  assets/ ...

Este enfoque permite gestionar múltiples proyectos Jekyll con distintas versiones de gemas sin que haya conflictos entre ellos, manteniendo cada proyecto completamente aislado dentro de su propio contenedor Docker.

Ventajas de este enfoque

Aislamiento completo: cada proyecto Jekyll tiene su propio contenedor con gemas específicas.
Evita conflictos de versión: distintas gemas o versiones de Jekyll no interfieren entre proyectos.
Portabilidad: basta con Docker para levantar el entorno, sin necesidad de instalar Ruby ni Jekyll en el host.
Reutilización: la misma imagen sirve para cualquier proyecto Jekyll futuro.
Flexibilidad: puedes mantener contenedores “vivos” listos para actualizar o regenerar sitios en cualquier momento.

Trucos y buenas prácticas

Regenerar el sitio tras cambios: Si modificas el contenido del proyecto Jekyll, basta con ejecutar de nuevo:
```
./run.sh contenedor-jekyll ./proyecto-jekyll ./html
```
Esto ejecutará build-site.sh dentro del contenedor, actualizando el HTML.
Actualizar gemas o dependencias: Si quieres instalar nuevas gemas o actualizar las existentes, puedes ejecutar:
```
docker exec -i contenedor-jekyll /usr/local/bin/install-gem.sh ./proyecto-jekyll
```
Eliminar contenedores antiguos: Para borrar un contenedor sin perder los datos generados en los volúmenes:
```
docker rm -f contenedor-jekyll
```
Inspeccionar o ejecutar comandos adicionales: Puedes abrir una shell dentro del contenedor:
```
docker exec -it contenedor-jekyll bash
```

Conclusiones

El uso de contenedores Docker para gestionar proyectos Jekyll ofrece una solución flexible, ordenada y reproducible. Cada proyecto puede mantenerse aislado, evitando conflictos de versiones de gemas o problemas de compatibilidad con Ruby y Jekyll. Además, la portabilidad y la facilidad de regenerar sitios estáticos hacen que este enfoque sea ideal tanto para desarrollo como para despliegue. Con esta metodología, se logra un flujo de trabajo más limpio, seguro y escalable, permitiendo concentrarse en el contenido y el diseño de las páginas, sin preocuparse por el entorno subyacente. Puedes encontrar los ficheros listos para probarlo en el siguiente repositorio de GitHub.

Habilitar IP Forwarding en Debian 13

Wed, 01 Oct 2025 00:00:00 GMT

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.

Creación de un box para vagrant

Sat, 20 Sep 2025 00:00:00 GMT

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.

Actualización de la máquina base

Utilizando un Vagrantfile con el siguiente contenido:

# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure("2") do |config|
    config.vm.box = "debian/bookworm64"
    config.vm.hostname="maquina_base"
    config.vm.synced_folder ".", "/vagrant", disabled: true
end

Creamos una nueva máquina con Debian12:

vagrant up
vagrant ssh

A continuación vamos a hacer la actualización a Debian 13, para ello actualizamos el sistema actual, ejecutando como root:

apt update && apt upgrade -y

A continuación, modificamos los repositorios de paquetes, para ello en el fichero /etc/apt/source.list cambiamos la palabra bookworm a trixie que es el nombre de la nueva versión de debian. Y a continuación actualizamos a la nueva versión:

apt update && apt upgrade -y
apt full-upgrade
apt autoremove

Reiniciamos la máquina y seguimos trabajando en ella.

Generación de la máquina base

Ya tenemos Debian 13 instalado en nuestra máquina base. A continuación, vamos a ejecutar distintas operaciones para preparar la máquina para convertirla en un nuevo box de Vagrant. En primer lugar podemos instalar los paquetes de las utilidades que queremos tener en nuestras máquinas, en mi caso sólo voy a instalar curl:

sudo apt install curl

A continuación, voy a borrar la clave pública que se ha inyectado en la creación de la máquina base, y la voy a sustituir por la clave pública de Vagrant. De esta manera cuando se creen nuevas máquinas se detectará que tienen una clave insegura y serán sustituidas por una nueva clave pública que se genera, junto a la clave privada, en la creación de las máquinas. Para ello, con el usuario vagrant:

curl -L https://raw.githubusercontent.com/hashicorp/vagrant/master/keys/vagrant.pub -o /home/vagrant/.ssh/authorized_keys

El siguiente paso es realizar una limpieza de la máquina, para que cuando la convirtamos a box tenga el menor tamaño posible, para ello ejecutamos:

sudo apt clean
sudo rm -rf /tmp/*
sudo rm -rf /var/tmp/*
sudo dd if=/dev/zero of=/EMPTY bs=1M
sudo rm -f /EMPTY

El tamaño virtual del disco de la máquina que hemos creado es de 100Gb, con el comando dd creamos un fichero que ocupará todo el disco lleno de 0, que finalmente borraremos. Este paso, cuya ejecución es muy lenta, no es obligatorio, pero nos permite que posteriormente en el paso de compresión de la imagen consigamos que el box sea muy liviano ya que el espacio libre del disco esté lleno de facilita la compresión.

Por último eliminamos el historial del usuario vagranty del root:

history -c
rm -f ~/.bash_history
unset HISTFILE
sudo su -
history -c
unset HISTFILE
rm -f /root/.bash_history

Por último podemos apagar la máquina para continuar con el proceso de conversión.

Convertir la máquina a un nuevo box

Suponemos que la máquina que hemos creado tiene un disco que corresponde al fichero debian12.qcow2. En primer lugar vamos comprimir el disco utilizando la utilizada qemu-img. El fichero resultante lo tenemos que llamar box.img, para ello nos dirigimos al directorio donde esta guardado el fichero correspondiente al disco (normalmente /var/lib/libvirt/images, aunque puede estar en otro directorio) y como root ejecutamos:

qemu-img convert -c -O qcow2 debian13.qcow2 box.img

La opción -c indica la operación de compresión que se va a realizar.

El box que vamos a crear es un fichero comprimido que contiene 3 ficheros: la imagen de la máquina que se debe llamar box.img, un fichero de metadatos llamado metadata.json donde hay información del proveedor, del formato de la imagen base y su tamaño y un fichero Vagrantfile.

Basado en la documentación del plugin vagrant-libvirt, el contenido del fichero metadata.json es:

{
  "provider"     : "libvirt",
  "format"       : "qcow2",
  "virtual_size" : 100
}

Y el contenido del fichero Vagrantfile es:


# frozen_string_literal: true

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

  # Example configuration of new VM..
  #
  #config.vm.define :test_vm do |test_vm|
    # Box name
    #
    #test_vm.vm.box = "centos64"

    # Domain Specific Options
    #
    # See README for more info.
    #
    #test_vm.vm.provider :libvirt do |domain|
    #  domain.memory = 2048
    #  domain.cpus = 2
    #end

    # Interfaces for VM
    #
    # Networking features in the form of `config.vm.network`
    #
    #test_vm.vm.network :private_network, :ip => '10.20.30.40'
    #test_vm.vm.network :public_network, :ip => '10.20.30.41'
  #end

  # Options for Libvirt Vagrant provider.
  config.vm.provider :libvirt do |libvirt|

    # A hypervisor name to access. Different drivers can be specified, but
    # this version of provider creates KVM machines only. Some examples of
    # drivers are KVM (QEMU hardware accelerated), QEMU (QEMU emulated),
    # Xen (Xen hypervisor), lxc (Linux Containers),
    # esx (VMware ESX), vmwarews (VMware Workstation) and more. Refer to
    # documentation for available drivers (http://libvirt.org/drivers.html).
    libvirt.driver = "kvm"

    # The name of the server, where Libvirtd is running.
    # libvirt.host = "localhost"

    # If use ssh tunnel to connect to Libvirt.
    libvirt.connect_via_ssh = false

    # The username and password to access Libvirt. Password is not used when
    # connecting via ssh.
    libvirt.username = "root"
    #libvirt.password = "secret"

    # Libvirt storage pool name, where box image and instance snapshots will
    # be stored.
    libvirt.storage_pool_name = "default"

    # Set a prefix for the machines that's different than the project dir name.
    #libvirt.default_prefix = ''
  end
end

Una vez que tenemos los tres ficheros, lo comprimimos para crear nuestro box que hemos llamado debian13-libvirt.box:

tar cvzf debian13-libvirt.box metadata.json Vagrantfile box.img

Probando nuestro nuevo box

Ya podemos utiliza nuestro box en nuestro equipo local, para ello tenemos que añadir el box a nuestro repositorio, ejecutando:

vagrant box add debian13-libvirt debian13-libvirt.box --provider=libvirt

Y crear un fichero Vagrantfile para crear una máquina virtual, podemos ejecutar:

vagrant init debian13-libvirt

Distribuyendo nuestro box

Si queremos que otros usuarios puedan usar nuestro box (por ejemplo, mis alumnos) es necesario subirlo al catálogo oficial de boxes de vagrant. Para ello tenemos que crear una cuenta en el catálogo en la página https://portal.cloud.hashicorp.com/vagrant/discover.

Una vez logueado escogemos la opción Vagrant Registry y creamos un nuevo registro usando el botón Create a Box Registry, donde indicaremos un nombre y una descripción:

Una vez creado el registro, accedemos a él y creamos un nuevo box usando el botón Create box. En la primera pantalla indicaremos el nombre, que en mi caso será josedom24/debian13, indicaremos si es público o privado y podremos poner una descripción:

En la siguiente pantalla podremos indicar la versión del box y una descripción de la misma:

Continuamos, y en la nueva pantalla pondremos el proveedor, en nuestro caso libvirt, podremos subir el fichero .box que hemos creado e indicar la arquitectura:

Se sube la imagen:

Y por último, podemos comprobar que tenemos dado de alta nuestro nuevo box en el registro:

Ahora cualquier usuario podría usar nuestro box, ejecutando:

vagrant init josedom24/debian13 --box-version 13.0.1
vagrant up

Conclusiones

La creación de un box personalizado para Vagrant puede parecer un proceso complejo al inicio, pero siguiendo una estrategia adecuada es posible obtener imágenes estables y adaptadas a nuestras necesidades. En este caso, partimos de la box oficial de Debian 12, la actualizamos a Debian 13 y la preparamos para su uso como nueva box, lista para automatizar entornos de desarrollo sobre KVM/libvirt.

Además, vimos cómo publicar el resultado en el Vagrant Box Registry, lo que permite reutilizarlo fácilmente en distintos proyectos o compartirlo con la comunidad. Con ello disponemos de una base moderna, coherente y mantenible que simplifica enormemente el despliegue de máquinas virtuales en entornos de desarrollo.

Publicado Debian 13 Trixie

Sat, 09 Aug 2025 00:00:00 GMT

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.

El problema del enrutamiento asimétrico

Wed, 11 Jun 2025 00:00:00 GMT

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:

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.

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:

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í:

Veamos dos posibles soluciones a este problema:

Primera solución: SNAT en la interfaz VPN

Cuando un cliente accede desde Internet a la IP pública del VPS, este reenvía el tráfico por la VPN al Servidor Web (192.168.100.2). Pero el servidor responde a través de su ruta por defecto (salida local, 192.168.0.1). Esto rompe la conexión porque:

La IP de origen del cliente (pública) no puede ser alcanzada desde el servidor a través de su red local.
El firewall/NAT intermedio puede bloquear la respuesta porque no corresponde al flujo original.

Para solucionar esto, en el VPS aplicamos Source NAT (SNAT) sobre el tráfico que se reenvía al servidor. Es decir, modificamos la IP de origen del paquete antes de enviarlo por la VPN, de modo que el servidor web ve como origen la IP de la VPN del VPS, en lugar de la IP real del cliente.

De esta forma, el servidor responde por la misma VPN (tun0), y la respuesta llega correctamente al cliente.

En este caso en la VPN tendríamos dos reglas NAT:

Una Destination NAT (DNAT): para redirigir el tráfico entrante (puertos 80 y 443) al servidor web local por la VPN.
Otra SNAT: para modificar la IP de origen del cliente por la IP VPN del VPS, asegurando así que el servidor devuelva la respuesta por la misma VPN.

iptables -A PREROUTING -i eth0 -p tcp -m multiport --dports 80,443 -j DNAT --to-destination 192.168.100.2
iptables -A POSTROUTING -s 192.168.100.0/24 -o tun0 -j MASQUERADE

El principal problema de esta solución es que al reescribe la dirección IP de origen del paquete para que parezca que viene del VPS, el Servidor Web no concoe la dirección IP del cliente real y esto puede causar problemas secundarios: el servidor web no puede registrar en los log las IP reales de los clientes, no puede aplicar restricciones por la IP de origen,...

Segunda solución: Políticas de enrutamiento (Policy-Based Routing - PBR)

Para solucionar el problema de que le Servidor Web no conoce la dirección IP de los clientes reales, vamos a explorar otra solución. En este caso, asumimos que hemos borrado la regla SNAT que explicamos en el punto anterior.

Por defecto, Linux enruta según la tabla de rutas global (basada en destino). Pero con las políticas de enrutamiento, podemos definir rutas de este estilo: "Si el tráfico viene desde cierto origen o llega por cierta interfaz, usa una tabla de rutas distinta." De forma concreta en nuestro ejemplo: "Si el tráfico viene de la VPN (192.168.100.0/24), responde por la VPN, no por la ruta por defecto."

Esta configuración se tiene que realizar en el Servidor Web. Veamos los pasos que tenemos que seguir para conseguirlo:

Vamos a crear una nueva tabla de enrutamiento que llamaremos vpnroute. Para ello editamos el fichero /etc/iproute2/rt_tables y añadimos la siguiente línea:
```
100 vpnroute
```
Añadimos una ruta por defecto para esta tabla.Indicamos que para la tabla vpnroute, la salida por defecto es la interfaz VPN tun0:
```
sudo ip route add default dev tun0 table vpnroute
```
Añadimos una regla de enrutamiento condicional. Configuramos la siguiente regla: Si un paquete viene desde la IP de la VPN, usa la tabla vpnroute.
```
sudo ip rule add from 192.168.100.2 lookup vpnroute
```

Verificamos la configuración:

ip rule
...
32765:    from 192.168.98.2 lookup vpnroute

ip route show table vpnroute
default dev tun0 scope link

Ya estaría funcionando, pero esta configuración no es persistente. Para hacer la persistente si estamos usando la configuración de red con la herramienta ifupdown, podríamos hacer un script ejecutable que guardaríamos en el directorio/etc/network/if-up.d/ para que se ejecutase al levantar la interfaz. El fichero se puede llamar /etc/network/if-up.d/policy-routing-vpn con el siguiente contenido:

#!/bin/sh

# Solo ejecutar si la interfaz es tun0
[ "$IFACE" = "tun0" ] || exit 0

# Añadir ruta por defecto en la tabla 'vpnroute'
ip route add default dev tun0 table vpnroute 2>/dev/null

# Añadir regla de enrutamiento si no existe
ip rule list | grep -q "from 192.168.100.2 lookup vpnroute" || \
  ip rule add from 192.168.100.2 lookup vpnroute

exit 0

Y finalmente, le damos permiso de ejecución:

sudo chmod +x /etc/network/if-up.d/policy-routing-vpn

Conclusión

Aunque podríamos explorar otras soluciones, como instalar un proxy inverso en el VPS o modificar directamente la ruta por defecto del servidor web (lo cual podría afectar otras comunicaciones), con esta descripción queda claro cuáles son las dos soluciones principales al problema del enrutamiento asimétrico en este escenario concreto.

Por un lado, la solución basada en SNAT es sencilla de implementar y permite resolver el problema de forma rápida, aunque con la limitación de perder la IP real del cliente.
Por otro, la solución mediante enrutamiento por políticas (policy-based routing) es más limpia y preserva la información del cliente, pero requiere mayor control sobre el sistema y una configuración algo más avanzada.

Elegir una u otra dependerá de las necesidades específicas del entorno: si prima la simplicidad o si es esencial mantener la trazabilidad de los clientes.

En definitiva, entender cómo funciona el enrutamiento asimétrico y cómo corregirlo es fundamental en redes modernas, especialmente cuando combinamos VPNs, NAT y servicios web expuestos desde redes locales a través de máquinas intermedias como VPS.

Mi última camiseta...

Sun, 01 Jun 2025 00:00:00 GMT

Me ha encantado... muchas gracias

Sun, 25 May 2025 00:00:00 GMT

Blog de Pledin

Uno de mis cursos en awesome-extremadura

Feed RSS/Atom: Novedades del portal de educación de la Junta de Andalucía

Migración de Pledin a Astro

¿Qué es Astro?

¿Por qué migrar de Jekyll a Astro?

El proceso de migración

Estructura del proyecto

Componentes y layouts compartidos

Manteniendo las URLs

Limpieza de directivas Liquid y Kramdown en los archivos Markdown

Conversión automática de bloques notice

El frontmatter de los ficheros Markdown

Comentarios

Búsqueda con Pagefind

Revistas Libres de Software Libre

Desarrollo y despliegue

Servidor de desarrollo

Proceso de build y despliegue

Migración a Astro 6

Conclusiones

Galería Pledin 3.0

Seguridad y control de acceso en una VPN tailscale/headscale: ACLs y Tags

Conceptos claves: ACLs y Tags

Caso práctico: El Aula Aislada

Estrategia 1: Red unificada con control por Etiquetas (Tags)

En el Router de la red local

En el equipo de cada Alumno

Resultado final

Estrategia 2: Segmentación por usuarios (Namespaces Aislados)

Resultado final

Conclusiones

Nuevo editor Zed

Próximo curso de Kubernetes

NoSubscription.org: Herramientas propias, no alquiladas

Dominando journalctl: Filtra logs como un pro con Unidades y Tags

Configuración del enrutamiento y DNS en una VPN tailscale/headscale

Subnet Router

Anuncio de las rutas de encaminamiento

Aprobación de las rutas de encaminamiento

Configuración de la ruta de encaminamiento en el cliente

Verificación de la conectividad

Exit Node

Anuncio del exit node

Aprobación del exit node

Cómo usar el Exit Node desde los clientes

Verificación del nodo de salida

DNS y MagicDNS

Configuración del DNS en Headscale

Split DNS (DNS dividido)

Conclusión

Construcción de VPN mesh con tailscale/headscale

Instalación de Headscale

Características de la máquina

Creación de usuarios

Registro de Nodos: conectando tus dispositivos

Método interactivo

Método no interactivo

Comprobación de la conectividad

El comando status en el cliente

Prueba de latencia con tailscale ping

Conclusión

Cursos de virtualización con KVM/libvirt

¿Qué es la virtualización con KVM y libvirt?

Cursos publicados

Curso 1: Introducción a la virtualización con KVM/libvirt usando virt-manager

Curso 2: Profundización en la virtualización con KVM/libvirt

Cursos de preparación para obtener las certificaciones Python PCEP y PCAP

Certificaciones PCEP y PCAP

PCEP – Certified Entry-Level Python Programmer

PCAP – Certified Associate Python Programmer

Cursos publicados

Curso de preparación para el examen PCEP

Curso de preparación para el examen PCAP

Historia de Linux

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

Construyendo la imagen Docker para Jekyll

Dockerfile explicado

Gestión de contenedores con run.sh

Scripts para gestionar proyectos

El comando `status` en el cliente

Prueba de latencia con `tailscale ping`

Gestión de contenedores con `run.sh`

`install-gem.sh`

`build-site.sh`