Zum Hauptinhalt springen

ASCEND WLAN-Bridge

WLAN-Bridge-Lösungen für Digital Signage und Remote-Geräte

Kabelgebundene Geräte per WLAN ans Netz bringen – auch in fremden, restriktiven Gastnetzwerken. Inklusive Wake-on-LAN-Forwarding, damit Sie Displays und Terminals aus der Ferne aufwecken können.

Beratung anfragen

Was ist eine WLAN-Bridge – und wie funktioniert sie?

Eine WLAN-Bridge verbindet kabelgebundene Netzwerkgeräte über eine bestehende WLAN-Verbindung mit dem Internet oder einem übergeordneten Netzwerk. Technisch ist das eine Client-Bridge: Ein Router meldet sich am vorhandenen WLAN an – genau wie ein Laptop oder Smartphone es täte – und stellt auf seiner Rückseite ein eigenes, kabelgebundenes LAN mit Ethernet-Ports bereit. Alles, was Sie an diese Ports anschließen, ist damit indirekt am WLAN angebunden, ohne selbst über eigene WLAN-Hardware zu verfügen.

Man nennt diesen Betriebsmodus WLAN-Client-Modus oder „WiFi as WAN“: Der Router nutzt sein WLAN-Modul nicht, um selbst ein Netz aufzuspannen, sondern um sich – wie ein gewöhnliches Endgerät – in ein fremdes Netz einzuwählen. Die eigentliche Herausforderung liegt in der nächsten Frage: Wie werden die Geräte hinter der Bridge im fremden Netz sichtbar?

Die naheliegende Antwort wäre transparentes Bridging auf Schicht 2 (Layer 2) – die Bridge würde dann für jedes angeschlossene Gerät dessen eigene MAC-Adresse (die eindeutige Hardware-Kennung eines Netzwerkgeräts) unverändert ins WLAN weiterreichen, sodass jedes Gerät wie ein eigenständiger Teilnehmer erscheint. In der Praxis scheitert das regelmäßig: Fremde und restriktive Netzwerke – Unternehmens-WLANs, Gastnetze in Hotels, Hallen oder auf Baustellen – sind selten darauf ausgelegt, beliebig viele fremde MAC-Adressen und IP-Anfragen aus einem einzelnen Anschluss zu akzeptieren.

Der robustere Weg ist NAT-Routing (Network Address Translation): Die Bridge tritt nach außen als ein einziges Gerät auf – eine MAC-Adresse, eine IP-Adresse – und übersetzt intern zwischen dieser einen Außenadresse und den vielen Adressen der Geräte in ihrem eigenen LAN dahinter. Für das fremde Netz sieht das aus wie ein einzelnes, unauffälliges Endgerät. Genau diese Eigenschaft macht NAT-basierte WLAN-Bridges auch in Netzen einsetzbar, die für echtes Layer-2-Bridging nie freigegeben würden.

Kurz zur Abgrenzung, weil die Begriffe oft verwechselt werden: Ein Repeater oder ein Mesh-System verlängert lediglich die Reichweite desselben WLANs, ohne ein neues Netz oder eine Adressumsetzung einzuführen, und Richtfunk (Punkt-zu-Punkt-WLAN) verbindet zwei Standorte – etwa zwei Gebäude – über größere Distanzen. Das sind zwei andere Aufgaben als die einer Client-Bridge, die ein fremdes WLAN für kabelgebundene Geräte nutzbar macht.

Der Praxisfall: Digital-Signage-Displays im fremden Gastnetz

So sah eine reale Anfrage aus, die den Ausschlag für diese Lösung gab: Ein Kunde wollte an einem Remote-Standort mehrere Digital-Signage-Displays betreiben – kabelgebunden angeschlossen an einen Teltonika-WLAN-Router, der als Bridge ins vorhandene Netz vor Ort eingebunden war. Das Netz vor Ort war jedoch kein eigenes, sondern ein fremdes Gäste- oder Unternehmens-WLAN, auf dessen Konfiguration der Kunde keinen Zugriff hatte. Zusätzlich sollten sich die Displays per Wake-on-LAN – einem Signal, das ein schlafendes Gerät übers Netzwerk reaktiviert – aus der Ferne aufwecken lassen, etwa um sie außerhalb der Nutzungszeiten in einen Sparmodus zu schicken und rechtzeitig vor dem nächsten Einsatz wieder hochzufahren.

Restriktive Gastnetze bringen dabei typischerweise fünf Hürden mit, die eine einfache Bridge scheitern lassen:

1. Fehlende WDS-Unterstützung. Das Wireless Distribution System (WDS) ist ein Verfahren, mit dem sich mehrere Access Points zu einem gemeinsamen, transparenten Netz verbinden. Viele Gastnetze unterstützen es gar nicht – eine Bridge, die auf WDS setzt, kommt dort erst gar nicht ins Netz.

2. 802.1X-Pflicht. 802.1X ist ein Authentifizierungsstandard, bei dem sich jedes Gerät vor dem Netzzugang per Zertifikat oder Zugangsdaten gegenüber dem Netzwerk ausweisen muss. Unternehmens-WLANs verlangen das häufig für jeden einzelnen Teilnehmer – eine Hürde, die eine einfache Bridge nicht ohne Weiteres nimmt.

3. MAC-Adress-Beschränkungen. Viele Netzwerke lassen nur eine begrenzte Anzahl von MAC-Adressen pro Anschluss zu. Eine Bridge, die versucht, die MAC-Adressen aller angeschlossenen Geräte unverändert durchzureichen, wird schnell blockiert.

4. Captive Portals. Ein Captive Portal ist die Anmeldeseite, die sich bei vielen Hotspots und Gastnetzen beim ersten Verbindungsversuch automatisch öffnet und erst nach Bestätigung oder Login den eigentlichen Netzzugang freischaltet. Ein Gerät ohne Bildschirm – wie ein Router oder ein Digital-Signage-Player – kann dieses Portal nicht selbst bedienen.

5. DHCP-Eigenheiten. DHCP (Dynamic Host Configuration Protocol) ist der Dienst, der Geräten im Netzwerk automatisch eine IP-Adresse zuweist. Sollen mehrere Geräte hinter der Bridge jeweils eine eigene Adresse aus dem fremden Netz bekommen, braucht es zusätzliches DHCP-Relaying – in einem Netzwerk mit unbekannten Firewall-Regeln oft ein Fass ohne Boden.

Für den Kunden bedeutete das: Ohne eine durchdachte Lösung hätte jede dieser fünf Hürden das Projekt zum Stillstand bringen können – und selbst wenn die Bridge ins Netz gekommen wäre, hätte das Aufwecken der Displays per Wake-on-LAN aus der Ferne ein eigenes Problem dargestellt. Dazu mehr im nächsten Abschnitt.

Die Ascend-Lösung: NAT-Bridge plus Wake-on-LAN-Scripte

Die Antwort auf die fünf Hürden ist die NAT-basierte Client-Bridge aus dem Grundlagenteil oben: Ein Teltonika-Router aus der RUT-Serie meldet sich im WLAN-Client-Modus am Gastnetz an – als ein einziges Gerät, mit einer MAC-Adresse und einer IP-Adresse. WDS-Unterstützung wird nicht benötigt, weil kein transparentes Bridging stattfindet. Die 802.1X-Anmeldung übernimmt der Router selbst, stellvertretend für alle Geräte dahinter. MAC-Beschränkungen laufen leer, weil nach außen ohnehin nur eine Adresse sichtbar ist. Ein Captive Portal kann, wo nötig, im Vorfeld einmalig abgearbeitet werden, und ein periodischer erneuter Login lässt sich über Monitoring und Scripte unterstützen – ein Versprechen auf hundertprozentige Automatisierung bei jedem denkbaren Portal-Typ geben wir dabei nicht, sehr wohl aber eine geprüfte Lösung für den konkreten Zielstandort. Und DHCP-Relaying erübrigt sich, weil die Geräte hinter der Bridge ihre Adressen aus dem eigenen, von Ascend verwalteten LAN bekommen statt aus dem fremden Netz.

Bleibt die Frage aus dem Praxisfall: Wie weckt man Geräte hinter einer solchen Bridge aus der Ferne auf? Wake-on-LAN (WOL) funktioniert im Ursprung denkbar einfach – ein sogenanntes Magic Packet, ein spezielles Broadcast-Datenpaket auf Netzwerkschicht 2, wird ins lokale Netz gesendet und weckt das passende Gerät anhand seiner MAC-Adresse aus dem Ruhezustand. Das Problem: Ein Broadcast-Paket überschreitet Netzgrenzen nicht von selbst – erst recht nicht die NAT-Grenze einer Bridge, auch nicht über einen Tunnel ins Internet hinweg. Ein Magic Packet, das aus der Ferne losgeschickt wird, kommt hinter der Bridge schlicht nicht an, wenn niemand es dort gezielt einspielt.

Genau dafür haben wir eigene WOL-Forwarding-Scripte entwickelt: Sie nehmen das Aufweck-Kommando über den gemanagten Uplink der Bridge entgegen und senden das Magic Packet anschließend gezielt in das lokale LAN hinter der Bridge – dorthin, wo es tatsächlich ankommen muss. So lässt sich ein Display oder Terminal am Remote-Standort aus der Ferne aufwecken, ohne dass jemand vor Ort etwas tun muss. Voraussetzung auf Geräteseite: Wake-on-LAN muss im BIOS beziehungsweise auf dem Netzwerkadapter (NIC) des Zielgeräts aktiviert sein – das prüfen wir vor dem Rollout gemeinsam mit Ihnen.

Ascend liefert dabei alles aus einer Hand: die Hardware (vorkonfigurierte Teltonika-Router), die Software (die WOL-Forwarding-Scripte und die NAT-Konfiguration), die Beratung zum passenden Setup für Ihren Zielstandort und die komplette Konfiguration – vorbereitet im Ascend-Rechenzentrum, bevor das Gerät den Einsatzort überhaupt sieht.

Die Bridge-Architektur und der Weg des Wake-on-LAN-Signals

Die Grundlagen von oben in zwei Bildern: links die Architektur der NAT-Bridge, rechts der Weg des Magic Packets von der Fernsteuerung bis zum Display. Klicken Sie auf ein Diagramm für die Vollansicht.

  • Die Bridge tritt im fremden Netz als ein einziges Gerät auf – 802.1X, Captive Portal und MAC-Beschränkungen bleiben unsichtbar für die Geräte im eigenen LAN dahinter.
  • Das Ascend-WOL-Script empfängt das Aufweck-Kommando aus der Ferne und sendet das Magic Packet gezielt ins lokale LAN – dorthin, wo das Gerät tatsächlich wartet.

Vom Rechenzentrum zum Einsatzort

Der Deployment-Workflow vom Ascend-Rechenzentrum bis zum Einsatzort – drei Schritte, kein IT-Personal vor Ort erforderlich.

Konfiguration im RZ

Jede Bridge wird vor dem Versand im Ascend-Rechenzentrum vorkonfiguriert: WLAN-Zugangsdaten für das Zielnetz, NAT-Regeln und die WOL-Forwarding-Scripte sind eingerichtet, bevor das Gerät den Einsatzort sieht.

Plug & Play vor Ort

Vor Ort wird die Bridge lediglich mit Strom und dem vorhandenen Netzwerk beziehungsweise dem WLAN-Signal verbunden. Kein Konfigurationsdialog, kein IT-Personal nötig – einstecken, warten bis die Verbindung steht, fertig.

Remote-Management

Nach der Inbetriebnahme überwacht und pflegt Ascend die Bridge remote: Firmware-Updates, Anpassungen an NAT- und WOL-Regeln, Monitoring der Verbindung – ohne Vor-Ort-Termin.

Wo NAT-WLAN-Bridges mit Wake-on-LAN überzeugen

Der Praxisfall Digital Signage steht exemplarisch für einige verwandte Szenarien, in denen kabelgebundene Geräte über ein fremdes oder bestehendes WLAN angebunden werden müssen.

Digital Signage

Displays an Remote-Standorten, in Filialen oder auf Messeflächen – über die Bridge ins vorhandene WLAN eingebunden und bei Bedarf per Wake-on-LAN aus dem Sparmodus geholt.

Kiosk- und SB-Terminals

Selbstbedienungsterminals in Einzelhandel, Gastronomie oder öffentlichen Einrichtungen – kabelgebunden angeschlossen, ohne dass vor Ort ein eigenes WLAN-Modul eingerichtet werden muss.

IoT-Sensorik in Bestandsgebäuden

Sensoren und Aktoren in Gebäuden, in denen eine nachträgliche Verkabelung unwirtschaftlich wäre – die Bridge übernimmt die WLAN-Anbindung, die Geräte selbst bleiben kabelgebunden.

Messestand und Baustellencontainer

Temporäre Standorte, an denen nur ein fremdes Gastnetzwerk zur Verfügung steht – Bridge einstecken, Geräte anschließen, nach Abbau wieder mitnehmen.

Bewährte Praxis für den Rollout

Aus zahlreichen Bridge-Rollouts haben sich einige Praktiken bewährt, die sich auf jedes Projekt übertragen lassen.

WLAN-Profil vorab prüfen. Teilen Sie uns möglichst vor der Konfiguration mit, welche Authentifizierung am Zielstandort verlangt wird, ob es MAC-Beschränkungen gibt und ob ein Captive Portal existiert. Je genauer wir das Zielnetz kennen, desto zuverlässiger arbeitet die Bridge ab dem ersten Tag.

Wake-on-LAN vor dem Rollout testen. Prüfen Sie an einem Pilotgerät, ob Wake-on-LAN im BIOS beziehungsweise auf dem Netzwerkadapter aktiviert ist, bevor Sie mehrere Standorte gleichzeitig ausrollen.

Monitoring von Anfang an nutzen. Eine Bridge, die unbemerkt offline geht, ist schlimmer als eine, die von vornherein nicht funktioniert – weil niemand merkt, dass sie fehlt. Das Remote-Management ist ab der Inbetriebnahme aktiv.

Reicht eine Leitung nicht aus? Wenn ein einzelner Anschluss nicht genügt und Sie mehrere Leitungen zu einer gebündelten Bandbreite zusammenführen möchten, lesen Sie mehr über unser Multi-WAN Bonding mit Viprinet.

FAQ

Beratung anfragen

Erzählen Sie uns von Ihrem Deployment-Szenario. Wir melden uns innerhalb eines Werktages und prüfen, ob eine WLAN-Bridge-Lösung für Ihre Remote-Standorte passt.

Antwort in der Regel innerhalb eines Werktags · keine Weitergabe an Dritte

Weiterführende Lösungen