Control de ESP8266 sin redirección de puertos: una ruta MQTT de salida

El dispositivo está detrás de un router doméstico sin redirección de puertos y sin dirección pública, y aun así tiene que recibir la configuración en cuestión de segundos. El truco no es un agujero en el cortafuegos. Es una conexión que el dispositivo abre hacia fuera hacia un broker al que puede llegar, y que después devuelve los mensajes por ese mismo camino ya establecido. Todas las propiedades que gustan de este diseño, y todas las trampas que contiene, vienen de esa inversión.

Qué atraviesa realmente el NAT

Cuando el dispositivo abre una conexión TCP al broker, el router de casa crea una asignación y la mantiene viva mientras dura el flujo. Las respuestas de ese flujo vuelven al dispositivo porque la asignación ya existe. El broker nunca inicia nada hacia la casa, así que no hay ningún paquete entrante no solicitado que el router deba rechazar. Ese es todo el argumento de red, y por eso el enfoque funciona en redes que no controlas.

El dispositivo debe mantener viva la conexión o restablecerla, lo que se convierte en la cuestión de fiabilidad una vez fijada la arquitectura.

El broker enruta temas, no hace de proxy HTTP

MQTT define intercambios de publicación y suscripción: el dispositivo se suscribe a un filtro de temas que tiene permiso para leer, y un controlador autorizado publica en un tema coincidente. El broker empareja las publicaciones con las suscripciones y entrega copias. No sabe qué es una petición de navegador y no reenviará un HTTP GET al servidor web del dispositivo. Si el firmware existente solo habla HTTP, el diseño con broker necesita un cambio de aplicación o un componente de traducción deliberado.

Los nombres de los temas tampoco son autorización. La mayoría de los brokers admiten listas de control de acceso por cliente, y los dispositivos deberían limitarse a sus propios árboles de publicación y suscripción en lugar de compartir un único espacio de nombres global.

Los recursos del dispositivo deciden la forma de TLS

El ESP8266 tiene RAM limitada, y el handshake TLS es lo más caro que hace. El núcleo de Arduino incluye BearSSL precisamente por esta restricción, y la elección entre verificar una CA y fijar una huella digital cambia tanto el consumo de memoria como lo que puede hacer un atacante con un certificado válido para otro nombre. Verificar la CA del broker es la opción más fuerte cuando el heap lo permite. El tamaño de la carga útil también importa: el cliente MQTT mantiene un búfer, y los mensajes mayores que él se truncan en silencio a menos que el búfer se aumente deliberadamente.

El keepalive y los tiempos de espera del socket forman parte del mismo presupuesto, porque un cliente que nunca nota una conexión muerta deja de recibir órdenes sin informar de un error.

La semántica de los mensajes que muerde

Un mensaje retenido lo guarda el broker y se entrega a suscriptores coincidentes posteriores, lo cual es excelente para el estado actual y peligroso para órdenes de un solo uso: un dispositivo que se reconecta puede recibir la orden de ayer como si fuera nueva. QoS 1 garantiza la entrega al menos una vez, así que los duplicados son normales y la aplicación debe ser segura ante repeticiones, idealmente con un identificador o una marca de tiempo que pueda rechazar. El último testamento te da una señal de estado cuando el dispositivo cae, pero solo si la conexión falla de verdad en lugar de quedarse colgada.

El comportamiento de sesión limpia decide si el broker conserva tus suscripciones mientras estás fuera, y equivocarse en eso es la razón por la que algunos dispositivos pierden el primer mensaje después de cada reconexión.

TLS protege el tramo hasta el broker. No es cifrado de la carga útil de extremo a extremo frente al operador del broker, que puede leer todo lo que publicas a través de él.

Limita el ciclo de vida y pruébalo con datos inocuos

Planifica la reconexión con retroceso en lugar de un bucle de reintentos apretado, vuelve a suscribirte explícitamente si la sesión no es persistente, y registra el resultado de la conexión para que un dispositivo silencioso fuera de línea deje pruebas. Prueba el camino de reconexión con cargas de ejemplo que no hagan nada, porque la primera prueba de producción de un canal de órdenes no debería ser una orden real. Después confirma qué hace un mensaje retenido obsoleto al reconectar, y decide si ese comportamiento es aceptable para cada tema.

Hecho así, el diseño elimina un requisito de red de entrada y deja el software del dispositivo, la política del broker y la semántica de los mensajes como trabajo visible en lugar de suposiciones ocultas.