DevOps

TTL (Time To Live) — es un campo de 8 bits en la cabecera IP que determina la cantidad máxima de “saltos” (nodos) que un paquete puede recorrer antes de ser descartado. Al pasar por cualquier enrutador, el valor TTL se decrementa en 1.

Valores de TTL típicos por defecto

Diferentes sistemas operativos usan valores iniciales distintos. Esto permite determinar remotamente el tipo de SO (OS Fingerprinting).

¿Por qué cambiar el TTL? Patrones de uso

1. Eludir las restricciones de tethering (compartir Internet)

El escenario más común. Los operadores móviles analizan el tráfico entrante.

Si todavía haces next build directamente en el servidor de producción — tu servidor realmente sufre. CPU al máximo, OOM-kill, errores 502 y largos tiempos de inactividad — es un clásico que ya es hora de terminar.

En 2026, el estándar de la industria es la construcción separada:

1. Construimos una imagen standalone mínima en la nube con GitHub Actions.
2. La empujamos a GHCR (GitHub Container Registry).
3. En el servidor solo hacemos pull + reinicio atómico.

Capítulo 1. Dockerfile ideal (multietapa + standalone)

Todo el secreto de una imagen pequeña y rápida está en el modo standalone. Next.js calcula por sí mismo qué archivos y partes de node_modules son realmente necesarios para que funcione el servidor, y copia solo esos.

Cuando la tecnología Docker apareció, la adoraron por el lema: «Build once, run anywhere» (Construye una vez, ejecuta en cualquier lugar). Los desarrolladores dejaron de escuchar la frase «en mi máquina funciona, pero en el servidor no». Pero junto con la comodidad llegó una nueva amenaza.

Un contenedor no es solo tu aplicación. Es todo un mini-sistema operativo (SO) con sus propias bibliotecas, utilidades y llamadas al sistema. Y si no vigilas ese SO, dejas a los atacantes una puerta enorme completamente abierta.

Imagina que estás construyendo una casa. Tú mismo diseñaste las paredes, revisaste cada ladrillo y te aseguraste de no haber olvidado las llaves en la cerradura. Pero ¿y si el hormigón que compraste a un proveedor externo con el tiempo empieza a desmoronarse? ¿O si en los marcos de las ventanas que instalaste hay defectos ocultos?

En el desarrollo moderno la situación es exactamente así. Una aplicación promedio hoy en día está formada en un 80–90% por bibliotecas de código abierto. Solo escribes una pequeña parte del código (la punta del iceberg), que gestiona un enorme volumen de código ajeno oculto «bajo la superficie».

¿Alguna vez te has preguntado cómo los programadores experimentados encuentran errores en el código ajeno con solo mirarlo? Buscan patrones. Saben que si los datos del usuario entran directamente en una consulta SQL —eso es malo. Si la contraseña se compara con un == en lugar de una función segura —es un riesgo.

Pero una persona no puede revisar 100 000 líneas de código sin pasar algo por alto. Aquí entra en escena SAST (Static Application Security Testing).

Imagine la situación: trabajas en un proyecto genial toda la noche. A las 4 de la mañana todo está listo, haces un git push final y te vas a dormir tranquilo. Y por la mañana descubres que tu balance en AWS está a cero y que hay un minero corriendo en tus servidores. ¿Qué pasó? Resulta que en uno de los archivos dejaste la línea: AWS_ACCESS_KEY_ID = "AKIA...".

Es un error clásico por el que han pasado miles de desarrolladores. En este artículo veremos por qué «simplemente borrar la contraseña» no ayuda y cómo configurar una protección automática que físicamente te impedirá cometer el error.

Escribir un Dockerfile simple: FROM node, COPY ., CMD run. Esto funciona, y para pruebas locales a menudo es suficiente. Pero cuando tal imagen llega al CI/CD o, Dios no lo quiera, a producción, empiezan los problemas: la construcción dura una eternidad, la imagen pesa gigabytes y los de seguridad se llevan las manos a la cabeza.

La diferencia entre “funciona” y “funciona correctamente” es colosal. Vamos a analizar cuatro niveles de optimización que separan una chapuza aficionada de una solución de ingeniería fiable.

OpenVPN — es un protocolo VPN fiable y probado, que permite organizar acceso remoto protegido a la red local. MikroTik RouterOS soporta OpenVPN en modo servidor desde la versión 6.x (TCP), y desde la versión 7+ — también UDP, pero con una serie de limitaciones arquitectónicas:

• autenticación obligatoria por usuario/contraseña incluso al usar certificados;
• lista limitada de cifrados y algoritmos;
• ausencia de algunas funcionalidades del OpenVPN “clásico”.

A pesar de ello, OpenVPN en MikroTik sigue siendo una solución demandada — especialmente en escenarios donde los clientes no soportan WireGuard o se requiere compatibilidad con sistemas antiguos.

Si te ocupas de self-hosting, tienes un laboratorio doméstico o administras un VPS pequeño, seguramente conoces Portainer. Es el estándar de facto: una navaja suiza potente y completa para Docker.

Pero seamos honestos: a veces la navaja suiza es demasiado pesada cuando solo necesitas pelar una manzana.

Recientemente descubrí Dockge — una herramienta del mismo desarrollador del popular Uptime Kuma. Me hizo replantear por completo el enfoque para gestionar contenedores. En este artículo cuento por qué Dockge puede ser el reemplazo ideal de Portainer para muchos escenarios.

Al trabajar con proyectos reales (cambio de CDN, migración, refactorización) a menudo es necesario reemplazar en masa una URL por otra.

A primera vista la tarea parece trivial: sed -i 's|old|new|g' **/* — y listo.

En realidad ese enfoque es una ruleta rusa.

Un reemplazo descuidado conduce a:

• 💀 Daño de archivos binarios (imágenes, pdf, archivos);
• 📉 Basura en el historial de git (los binarios aparecen como modificados);
• 🚫 Imposibilidad de una reversión limpia si no se hizo un respaldo.

En esta nota analizaremos un algoritmo apto para producción: cambiamos solo texto, no tocamos binarios, hacemos un respaldo puntual.