Experiment / PoC Veröffentlicht 26. Oktober 2026

Captive Portal für UniFi-Gäste-WLAN: serverlos, mit einem winzigen Redirector als Brücke

UniFi akzeptiert als externen Portal-Server nur eine IPv4-Adresse, CloudFront hat keine feste IP. Ein zustandsloser Kleinst-Redirector vor einem serverlosen Backend löst das – ein Muster für jede Hersteller-Einschränkung dieser Art.

Für das offene Gäste-WLAN an einem meiner Standorte wollte ich eine eigene Anmeldeseite: Nutzungsbedingungen bestätigen, Gerät freischalten, fertig. Das Netz läuft auf UniFi. Der Fall ist klein, das Muster begegnet mir bei Kunden ständig: Ein Hersteller-Produkt stellt eine Bedingung, die nicht zur Architektur passt, und man braucht eine möglichst dünne Brücke. Ein Anwendungsfall, kein Showcase.

Hypothese

Ein Captive Portal für UniFi lässt sich fast vollständig serverlos betreiben – statische Seite, API, Funktion, Zähler-Tabelle –, ohne dass ich einen Server mit Zustand pflegen muss. Die einzige Hürde, die ich vorab kannte: UniFi nimmt im Feld „External Portal Server“ ausschließlich eine IPv4-Adresse an. Ein CDN wie CloudFront hat keine feste IP. Meine Annahme war, dass ein winziger, zustandsloser Redirector mit statischer Adresse diese Lücke schließt und sonst nichts zu tun hat.

Drei Fragen: Funktioniert die Weiterleitungskette von UniFi bis zur Seite? Erreicht das Backend das Gateway über den Cloud-Connector des Herstellers? Und bleibt der nicht serverlose Teil wartungsarm?

Aufbau

Der Ablauf hat vier Stationen:

UniFi fängt den ersten HTTP-Aufruf eines noch nicht freigeschalteten Gastes ab und leitet ihn an die konfigurierte IPv4-Adresse weiter mit Geräte-Kennung und Ziel-URL als Query-Parameter.
Der Redirector – eine ARM-Kleinst-Instanz (t4g.nano) mit nginx und fester öffentlicher Adresse – antwortet auf jede Anfrage mit einer 302-Weiterleitung auf die HTTPS-Portalseite und reicht den Query-String unverändert durch.
Die Portalseite liegt als statische Seite in S3 hinter CloudFront. API-Aufrufe gehen über denselben Origin an ein HTTP-API-Gateway und von dort an eine Lambda-Funktion.
Die Lambda-Funktion spricht über den UniFi Site Manager Cloud-Connector mit dem Gateway: Sie prüft, ob das Gerät gerade als Gast im Hotspot-Netz angemeldet ist, und schaltet es nach Zustimmung zu den Nutzungsbedingungen frei.

Ein paar bewusste Entscheidungen:

Der Redirector ist Wegwerfware. Kein SSH, Zugriff nur über SSM, keine Daten auf der Platte, Sicherheitsupdates automatisch. Ändert sich seine Startkonfiguration, ersetzt CDK die Instanz, statt sie nachzupflegen. Nur die statische Adresse bleibt erhalten, weil UniFi auf sie zeigt.
Datensparsamkeit. Der Query-String enthält die Geräte-Kennung des Gastes, deshalb ist das Access-Log von nginx abgeschaltet. Die Logs der Lambda-Funktion werden nach 14 Tagen gelöscht.
Kein Login-Dienst. Offenes Gäste-WLAN; die einzige Hürde ist die Bestätigung der Nutzungsbedingungen.
Die Seite zeigt den Login nur, wenn er Sinn ergibt. Beim Laden fragt sie das Backend, ob das Gerät wirklich ein Gast im Hotspot ist. Wer die Seite aus einem anderen Netz aufruft, sieht nur einen Hinweis. Der Freischalt-Aufruf prüft dieselbe Bedingung noch einmal serverseitig.
Rate-Limits ohne IP-Bezug. Alle Gäste teilen sich eine WAN-Adresse, ein Limit pro IP wäre also sinnlos. Stattdessen zählt die Funktion in DynamoDB Freischaltungen pro Gerät und global, jeweils mit einer Obergrenze pro Minute; davor liegt ein Throttle auf Stufe des API-Gateways.
Freischaltung zeitlich begrenzt. Ein Gast bekommt 8 Stunden Zugang, danach erscheint die Seite erneut.

Alles, einschließlich Zertifikat und Redirector, ist CDK-Code. Außerhalb liegen nur der API-Schlüssel für den Cloud-Connector (in einem Secret) und die Hotspot-Einstellungen in UniFi.

Messung

Eine Lasttest-Messung habe ich nicht gemacht – bei einem Gäste-WLAN wäre sie wenig aussagekräftig. Geprüft habe ich die Funktionskette und die Stolpersteine:

Die IPv4-Einschränkung ist real. Einen Hostnamen im Feld „External Portal Server“ lehnt UniFi mit einem Validierungsfehler ab.
Die Weiterleitungskette steht. Ein Aufruf an den Redirector mit einer Test-Geräte-Kennung liefert die erwartete 302-Antwort auf die Portalseite mit unverändertem Query-String; die Seite rendert.
Der Weg zum Gateway funktioniert. Die Status-Abfrage für eine erfundene Geräte-Kennung liefert „nicht verbunden“. Das beweist, dass Lambda, Secret und Cloud-Connector zusammenspielen; ein fehlender oder falscher Schlüssel würde als Upstream-Fehler sichtbar.
Betrieb. Seit Anfang Oktober ist das Portal produktiv geschaltet.

Zwei Lessons learned:

Auch die kleinste Instanz braucht Rücksicht. Mit 512 MiB Arbeitsspeicher wurde schon die Paketinstallation beim ersten Start vom OOM-Killer beendet. Seitdem legt das Startskript als Erstes eine 1-GiB-Swap-Datei an.
Caching bei statischen Portalseiten. Nach einer Änderung an CSS und JavaScript sahen Geräte teils noch die alte Fassung. Die Assets tragen jetzt eine Versionsnummer in der URL, die bei jeder Änderung hochgezählt wird.

Zur Wirtschaftlichkeit: Den größten Teil der laufenden Kosten machen die Kleinst-Instanz und ihre öffentliche IPv4-Adresse aus, beide in der Größenordnung weniger Dollar im Monat. Der serverlose Teil fällt bei Gäste-Traffic praktisch nicht ins Gewicht. Der Redirector läuft rund um die Uhr – würde er nachts gestoppt, bekämen Gäste keine Anmeldeseite.

Fazit

Hypothese bestätigt, mit einer Einschränkung: Ganz ohne Server geht es nicht, weil der Hersteller eine feste IPv4 verlangt. Aber der Server ist auf das absolute Minimum reduziert – eine Weiterleitung, kein Zustand, keine Daten, jederzeit ersetzbar. Die Logik bleibt serverlos, versioniert und testbar.

Übertragbar ist das Muster weit über WLAN hinaus: Wenn ein Altsystem, ein Gerät oder ein Partner nur eine feste IP, nur HTTP oder nur ein bestimmtes Format akzeptiert, lohnt sich ein schmaler, zustandsloser Adapter an genau dieser Stelle, statt die ganze Architektur nach der Einschränkung auszurichten. Für diesen Fall bleibt es bei der Kleinst-Instanz: Updates spielt sie selbst ein, und jede Konfigurationsänderung ersetzt sie einfach.

Stack: AWS CDK · CloudFront · S3 · API Gateway · Lambda · DynamoDB · EC2 · nginx · UniFi

← Alle Beiträge