Öffnet euer Netzwerk für LobbyFlight-Displays

Öffnet euer Netzwerk für LobbyFlight-Displays

Dieser Artikel richtet sich an alle, die das Hotelnetzwerk betreuen. Er sagt euch genau, welche Hosts ein LobbyFlight-Display kontaktiert, wie oft es das tut und welche gut gemeinten Firewall-Regeln das Board auf eine Weise lahmlegen, die sich nur schwer als Netzwerkproblem erkennen lässt.

Was ihr tatsächlich durchlasst

Ein LobbyFlight-Display ist kein Gerät und kein Agent. Es ist ein Browser, der auf einer Webseite steht — /display/<hotelId> —, sich Daten über HTTPS holt und daraus eine Flugtafel zeichnet. Alles, was es tut, ist eine ausgehende Anfrage von diesem Browser an einen Webserver.

Daraus folgen zwei Dinge, und es sind genau die beiden, nach denen IT-Abteilungen am häufigsten fragen. Ihr müsst keinen eingehenden Port öffnen, denn nichts verbindet sich jemals *zum* Bildschirm hin. Und ihr müsst keine WebSockets erlauben, denn das Produkt benutzt keine: Die Tafel fragt auf Timern nach, statt eine Verbindung offen zu halten. Wenn euer Monitoring eine dauerhaft offene Verbindung auf Port 443 von einem Display meldet, sind wir das nicht.

Ihr braucht auch kein VPN, keinen Tunnel und kein Protokoll außer schlichtem HTTPS.

Hosts, die freigegeben sein müssen

Gebt ausgehendes HTTPS zu lobbyflight.com und *.lobbyflight.com frei. Damit sind die Display-Seite selbst, der Konfigurations-Endpunkt, die Flugdaten, der Wetter-Endpunkt und das Lebenszeichen abgedeckt — all das kommt vom eigenen Origin des Produkts.

Läuft euer Hotel im Premium-Plan und nutzt Portal → White-Label → Eigene Domain, um die Tafel unter einem eigenen Hostnamen zu betreiben, zum Beispiel flights.euerhotel.com, dann muss dieser Hostname ebenfalls auf der Freigabeliste stehen. Das ist der mit Abstand häufigste Grund dafür, dass eine korrekt aussehende Firewall-Regel trotzdem einen schwarzen Bildschirm hinterlässt: Eine Regel für *.lobbyflight.com greift nicht bei einem Display, das von eurer eigenen Domain ausgeliefert wird.

Über die Domains des Produkts hinaus wendet sich der Browser des Displays an eine kleine Zahl von Hosts Dritter:

Zwei Hosts, die ältere Fassungen dieses Artikels aufgeführt haben, existieren nicht und gehören nicht in eure Regeln: Es gibt kein api.lobbyflight.com und kein cdn.lobbyflight.com. Die öffentliche API liegt unter https://lobbyflight.com/api/v1. Hochgeladene Bilder — Hotellogo, Display-Logo, Infoslides — werden über das eigene Origin des Produkts unter /_next/image ausgeliefert, es gibt also keinen separaten CDN-Host freizugeben. Google Fonts braucht ihr ebenfalls nicht: Die Schriften des Displays werden beim Build mit einkompiliert und von unserer eigenen Domain ausgeliefert, und die Content-Security-Policy der Website setzt font-src 'self' data: — eine Anfrage an fonts.googleapis.com käme also gar nicht erst zustande.

Ports

Port 80 ist kürzer relevant, als man denkt. Die Website sendet Strict-Transport-Security mit zwei Jahren max-age, includeSubDomains und preload; nach dem ersten erfolgreichen Kontakt wechselt der Browser also von sich aus auf HTTPS und fragt nie wieder nach Port 80. Alles, was Verkehr auf einfaches HTTP herunterstuft, scheitert, statt darauf zurückzufallen.

Wie oft das Display spricht

Das ist der Teil, mit dem eine IT-Abteilung wirklich planen kann, deshalb hier das echte Anfrageprofil eines Bildschirms:

Bilder cacht der Browser großzügig: Logos, Slide-Bilder, Symbole und Schriften kommen mit einem unveränderlichen Cache-Header von einem Jahr, werden also einmal geholt und danach nicht mehr. Beachtet, dass das gewöhnliches HTTP-Caching ist. Auf der Display-Route ist kein Service Worker registriert, es steckt also kein Offline-Puffer dahinter; ist das Netz weg, scheitern die obigen Anfragen einfach, bis es zurück ist.

Die Regel, die das Unauffälligste kaputt macht

Ist eure Freigabeliste zu eng und nur das Lebenszeichen blockiert, sieht alles gut aus. Der Bildschirm zeigt weiter Flüge, Gäste sehen eine funktionierende Tafel, und niemand in der Lobby merkt etwas. Aber das Portal hört nichts mehr vom Display und führt es nach 12 Minuten als Offline.

Dieser Schwellenwert ist Absicht. Das Display sendet alle 5 Minuten ein Lebenszeichen, ein Fenster von 12 Minuten sind also zwei verpasste Schläge plus etwas Luft — weit genug, dass ein Neuladen oder ein kurzer Aussetzer keinen Fehlalarm auslöst. Zeigt ein Bildschirm einen Status, der nicht zu dem passt, was ihr in der Lobby seht, prüft erst, ob /api/analytics/heartbeat erreichbar ist, bevor ihr euch den Bildschirm selbst vornehmt.

Proxys und SSL-Inspection

Das Display ist ein Browser, ein im Browser konfigurierter expliziter Proxy wird also benutzt. Worauf ihr euch nicht verlassen könnt, ist, dass ein Proxy harmlos ist.

Die Website bringt eine strenge Content-Security-Policy mit: default-src 'self', font-src 'self' data: sowie geschlossene Listen für img-src und connect-src. Alles, was dazwischensitzt und HTML umschreibt, ein Skript einschleust oder Inhalte von einem Host ausliefert, der nicht auf diesen Listen steht, blockiert der Browser selbst — unabhängig davon, was eure Firewall erlaubt. Ein Proxy, der nur Bytes weiterreicht, ist in Ordnung. Ein Proxy, der sie verändert, nicht.

Dasselbe gilt für SSL-Inspection. Setzt die Hosts, die das Display braucht, auf die Bypass-Liste der Inspection — lobbyflight.com, *.lobbyflight.com, eure eigene White-Label-Domain, falls ihr eine nutzt, und openweathermap.org. Es gibt kein LobbyFlight-Zertifikat zum Importieren; die Zertifikate stellt die Hosting-Plattform aus, das Umgehen der Inspection für diese Hosts ist also die einzige Möglichkeit. Lasst ihr die Inspection an und das Lebenszeichen gehört zu den Opfern, habt ihr genau den stillen Offline-Fall von oben.

Gäste laufen über einen zweiten Weg

Displays sind nicht der einzige LobbyFlight-Verkehr im Haus. Nutzt euer Hotel den Gäste-Companion, scannen Gäste einen QR-Code und öffnen /guest/<token> auf ihrem eigenen Telefon — eine kleine Progressive Web App, die für den Gästebereich einen Service Worker registriert. Dieser Verkehr kommt aus dem Gäste-WLAN, nicht aus dem Display-VLAN, und geht an dieselben Domains. Ein Regelwerk, das das Signage-VLAN abriegelt, betrifft ihn nicht — ein Captive Portal oder ein Filter im Gästenetz aber sehr wohl.

Prüfen, ob es funktioniert

Fragt aus dem Netzsegment des Displays heraus den Health-Endpunkt ab und erwartet 200 OK:

curl -s -o /dev/null -w "%{http_code}\n" https://lobbyflight.com/api/health

Mit ?detailed=true bekommt ihr statt eines einzelnen Gesamtstatus eine Aufschlüsselung pro Dienst, was nützlicher ist, wenn etwas nur teilweise kaputt ist. Es gibt außerdem https://lobbyflight.com/api/status. Richtet euer Monitoring auf diese Adressen, auf der Hauptdomain — eine Prüfung gegen api.lobbyflight.com wird für immer scheitern, weil dieser Host nicht existiert.

Kommt ein Bildschirm auch mit den fertigen Regeln nicht hoch, arbeitet euch in dieser Reihenfolge durch: Prüft, ob DNS den Host auflöst, den das Display tatsächlich benutzt (eure White-Label-Domain, falls ihr eine habt), prüft, ob Port 443 dorthin offen ist, und schaltet dann die SSL-Inspection für diesen Host ab und versucht es erneut.

Wenn ihr uns braucht

Schreibt an info@lobbyflight.com mit dem Betreff IT/Netzwerk-Konfiguration und legt eure Firewall-Regeln und alle Fehlerausgaben bei, die ihr habt. Nennt uns die Display-ID und ob das Portal den Bildschirm als online oder offline führt — das spart eine Rückfrage, weil wir sofort wissen, ob das Lebenszeichen durchkommt.

Nächste Schritte