Abrid vuestra red a las pantallas de LobbyFlight
Lo que una pantalla de LobbyFlight necesita de vuestra red: qué hosts contacta, con qué frecuencia y qué reglas de firewall la rompen sin hacer ruido.
Abrid vuestra red a las pantallas de LobbyFlight
Este artículo es para quien administra la red del hotel. Os dice exactamente qué hosts contacta una pantalla de LobbyFlight, con qué frecuencia lo hace y qué reglas de firewall bienintencionadas rompen el tablero de una forma que cuesta reconocer como un problema de red.
Qué estáis dejando pasar en realidad
Una pantalla de LobbyFlight no es un aparato ni un agente. Es un navegador abierto en una página web — /display/<hotelId> — que pide datos por HTTPS y dibuja con ellos un tablero de vuelos. Todo lo que hace es una petición saliente de ese navegador a un servidor web.
De ahí se derivan dos cosas, y son justo las dos por las que más preguntan los departamentos de IT. No hace falta abrir ningún puerto entrante, porque nada se conecta nunca *hacia* la pantalla. Y no hace falta permitir WebSockets, porque el producto no usa ninguno: el tablero consulta por temporizador en lugar de mantener un socket abierto. Si vuestra monitorización marca una conexión de larga duración en el puerto 443 desde una pantalla, no somos nosotros.
Tampoco necesitáis una VPN, un túnel ni ningún protocolo más allá de HTTPS a secas.
Hosts que hay que permitir
Permitid HTTPS saliente hacia lobbyflight.com y *.lobbyflight.com. Eso cubre la propia página de la pantalla, el endpoint de configuración, los datos de vuelos, el endpoint del tiempo y el latido: todo se sirve desde el origen del propio producto.
Si vuestro hotel está en el plan Premium y usáis Portal → Marca Blanca → Dominio Personalizado para servir el tablero bajo vuestro propio nombre de host, por ejemplo flights.vuestrohotel.com, ese nombre también tiene que estar en la lista de permitidos. Este es, con diferencia, el motivo más habitual de que una regla de firewall que parece correcta deje aun así una pantalla en negro: una regla para *.lobbyflight.com no cubre una pantalla servida desde vuestro propio dominio.
Más allá de los dominios del producto, el navegador de la pantalla se dirige a un puñado de hosts de terceros:
www.googletagmanager.com, www.google-analytics.com, region1.google-analytics.com, connect.facebook.net, *.posthog.com, *.vercel-insights.com y *.vercel-analytics.com. Ninguno forma parte del camino de los datos de vuelos. Si vuestra política es bloquear rastreadores en las VLAN de cartelería, bloqueadlos.js.stripe.com, api.stripe.com, hooks.stripe.com, checkout.stripe.com) solo hace falta si el personal abre las páginas de facturación del portal desde el mismo segmento de red. Las pantallas no lo tocan nunca.Dos hosts que versiones antiguas de este artículo listaban no existen y no deberían estar en vuestras reglas: no hay api.lobbyflight.com ni cdn.lobbyflight.com. La API pública vive en https://lobbyflight.com/api/v1. Las imágenes subidas — logotipo del hotel, logotipo de la pantalla, diapositivas informativas — se sirven desde el origen del propio producto bajo /_next/image, así que no hay ningún host de CDN aparte que abrir. Google Fonts tampoco hace falta: las tipografías de la pantalla se compilan en la aplicación y se sirven desde nuestro propio dominio, y la Content-Security-Policy del sitio fija font-src 'self' data:, de modo que una petición a fonts.googleapis.com ni siquiera llegaría a producirse.
Puertos
| Puerto | Protocolo | Para qué hace falta |
| -------- | ----------- | --------------------- |
| 443 | TCP / HTTPS | Todo: la página, la configuración, los datos de vuelos, el latido |
|---|---|---|
| 80 | TCP / HTTP | Solo la redirección a HTTPS en la primerísima petición a un host |
| 53 | UDP / DNS | Resolución de nombres |
El puerto 80 importa durante menos tiempo del que parece. El sitio envía Strict-Transport-Security con un max-age de dos años, includeSubDomains y preload, así que tras el primer contacto correcto el navegador pasa a HTTPS por su cuenta y no vuelve a pedir el puerto 80 nunca más. Cualquier cosa que degrade el tráfico a HTTP plano fallará en lugar de servir de alternativa.
Con qué frecuencia habla la pantalla
Esta es la parte con la que un departamento de IT puede planificar de verdad, así que aquí está el perfil real de peticiones de una pantalla:
El navegador cachea las imágenes con generosidad: logotipos, imágenes de diapositivas, iconos y tipografías se sirven con una cabecera de caché de un año e inmutable, así que se piden una vez y ya no más. Tened en cuenta que esto es caché HTTP corriente. En la ruta de la pantalla no hay ningún service worker registrado, así que detrás no hay ningún búfer sin conexión; cuando la red desaparece, las peticiones de arriba simplemente fallan hasta que vuelve.
La regla que rompe lo menos visible
Si vuestra lista de permitidos es demasiado estrecha y lo único bloqueado es el latido, nada parece ir mal. La pantalla sigue mostrando vuelos, los huéspedes ven un tablero que funciona y nadie en el vestíbulo nota nada. Pero el portal deja de recibir señales de la pantalla y, a los 12 minutos, la muestra como Sin conexión.
Ese umbral es deliberado. La pantalla envía un latido cada 5 minutos, así que una ventana de 12 minutos son dos latidos perdidos más un pequeño margen: lo bastante amplia para que una recarga o un microcorte no den una falsa alarma. Si una pantalla muestra un estado que no cuadra con lo que veis en el vestíbulo, comprobad si /api/analytics/heartbeat es accesible antes de poneros a mirar la pantalla en sí.
Proxies e inspección SSL
La pantalla es un navegador, así que se usará cualquier proxy explícito configurado en ese navegador. Lo que no podéis dar por hecho es que un proxy sea inofensivo.
El sitio lleva una Content-Security-Policy estricta: default-src 'self', font-src 'self' data: y listas cerradas para img-src y connect-src. Cualquier cosa que se interponga y reescriba el HTML, inyecte un script o sirva contenido desde un host que no esté en esas listas la bloquea el propio navegador, independientemente de lo que permita vuestro firewall. Un proxy que solo reenvía bytes está bien. Un proxy que los edita, no.
Lo mismo vale para la inspección SSL. Poned los hosts que la pantalla necesita en la lista de exclusión de la inspección: lobbyflight.com, *.lobbyflight.com, vuestro propio dominio de marca blanca si lo usáis y openweathermap.org. No hay ningún certificado de LobbyFlight que importar; los certificados los emite la plataforma de alojamiento, así que excluir esos hosts de la inspección es la única opción. Si dejáis la inspección activada y el latido cae entre las bajas, tendréis exactamente el caso silencioso de «sin conexión» descrito arriba.
Los huéspedes van por un segundo camino
Las pantallas no son el único tráfico de LobbyFlight del edificio. Si vuestro hotel usa el companion para huéspedes, estos escanean un código QR y abren /guest/<token> en su propio teléfono: una pequeña aplicación web progresiva que registra un service worker para el área de huéspedes. Ese tráfico sale de la wifi de huéspedes, no de la VLAN de las pantallas, y va a los mismos dominios. Un conjunto de reglas que blinda la VLAN de cartelería no le afecta, pero un portal cautivo o un filtro en la red de huéspedes sí.
Comprobar que funciona
Desde el propio segmento de red de la pantalla, pedid el endpoint de salud y esperad 200 OK:
curl -s -o /dev/null -w "%{http_code}\n" https://lobbyflight.com/api/healthAñadir ?detailed=true devuelve un desglose por servicio en lugar de un único estado global, lo que resulta más útil cuando algo está roto solo en parte. También existe https://lobbyflight.com/api/status. Apuntad vuestra monitorización a estas direcciones, en el dominio principal: una comprobación contra api.lobbyflight.com fallará para siempre, porque ese host no existe.
Si una pantalla sigue sin arrancar con las reglas ya puestas, id en este orden: confirmad que el DNS resuelve el host que la pantalla usa de verdad (vuestro dominio de marca blanca, si tenéis uno), confirmad que el puerto 443 está abierto hacia él y después desactivad la inspección SSL para ese host y probad otra vez.
Cuando nos necesitéis
Escribid a info@lobbyflight.com con el asunto Configuración de IT/Red e incluid vuestras reglas de firewall y cualquier salida de error que tengáis. Decirnos el ID de la pantalla y si el portal la muestra en línea o sin conexión ahorra una ida y vuelta, porque nos dice de inmediato si el latido está llegando.