Solutions de pont Wi-Fi pour l'affichage dynamique et les appareils distants

Un pont Wi-Fi connecte des appareils réseau filaires à Internet ou à un réseau supérieur via une connexion Wi-Fi existante. Techniquement, il s'agit d'un pont client : un routeur se connecte au Wi-Fi existant – exactement comme le ferait un ordinateur portable ou un smartphone – et met à disposition, à l'arrière, son propre LAN filaire avec des ports Ethernet. Tout ce que vous branchez sur ces ports est ainsi indirectement relié au Wi-Fi, sans disposer de son propre matériel Wi-Fi.

Ce mode de fonctionnement est appelé mode client Wi-Fi ou « WiFi as WAN » : le routeur n'utilise pas son module Wi-Fi pour créer lui-même un réseau, mais pour se connecter – comme un terminal ordinaire – à un réseau tiers. Le véritable défi se pose dans la question suivante : comment les appareils situés derrière le pont deviennent-ils visibles dans le réseau tiers ?

La réponse évidente serait le bridging transparent en couche 2 (Layer 2) – le pont transmettrait alors, pour chaque appareil connecté, sa propre adresse MAC (l'identifiant matériel unique d'un appareil réseau) inchangée vers le Wi-Fi, de sorte que chaque appareil apparaisse comme un participant autonome. Dans la pratique, cela échoue régulièrement : les réseaux tiers et restrictifs – Wi-Fi d'entreprise, réseaux invités dans les hôtels, halls ou chantiers – sont rarement conçus pour accepter un nombre quelconque d'adresses MAC et de requêtes IP étrangères depuis un seul port.

La voie la plus robuste est le routage NAT (Network Address Translation) : le pont se présente vers l'extérieur comme un appareil unique – une adresse MAC, une adresse IP – et traduit en interne entre cette adresse externe unique et les nombreuses adresses des appareils de son propre LAN situé derrière. Pour le réseau tiers, cela ressemble à un simple terminal discret. C'est précisément cette propriété qui rend les ponts Wi-Fi basés sur le NAT utilisables même dans des réseaux qui n'autoriseraient jamais un vrai bridging de couche 2.

Une brève distinction, car les termes sont souvent confondus : un répéteur ou un système Mesh ne fait qu'étendre la portée du même Wi-Fi, sans introduire de nouveau réseau ni de traduction d'adresses, et une liaison radio point à point relie deux sites – par exemple deux bâtiments – sur de plus grandes distances. Ce sont deux missions différentes de celle d'un pont client, qui rend un Wi-Fi tiers exploitable pour des appareils filaires.

Voici à quoi ressemblait une demande réelle qui a motivé cette solution : un client souhaitait exploiter plusieurs écrans d'affichage dynamique sur un site distant – raccordés en filaire à un routeur Wi-Fi Teltonika, intégré comme pont au réseau local existant. Or, le réseau local n'était pas le sien, mais un Wi-Fi invité ou d'entreprise tiers, dont le client n'avait pas accès à la configuration. Les écrans devaient en outre pouvoir être réveillés à distance par Wake-on-LAN – un signal qui réactive via le réseau un appareil endormi – par exemple pour les mettre en veille hors des heures d'utilisation et les rallumer à temps avant la prochaine utilisation.

Les réseaux invités restrictifs présentent typiquement cinq obstacles qui font échouer un simple pont :

1. Absence de support WDS. Le Wireless Distribution System (WDS) est un procédé permettant de relier plusieurs points d'accès en un réseau commun et transparent. De nombreux réseaux invités ne le prennent pas en charge du tout – un pont qui repose sur le WDS n'accède alors même pas au réseau.

2. Obligation 802.1X. 802.1X est une norme d'authentification qui impose à chaque appareil de s'identifier auprès du réseau par certificat ou identifiants avant l'accès au réseau. Les Wi-Fi d'entreprise l'exigent souvent pour chaque participant individuel – un obstacle qu'un simple pont ne franchit pas facilement.

3. Restrictions d'adresses MAC. De nombreux réseaux n'autorisent qu'un nombre limité d'adresses MAC par port. Un pont qui tente de transmettre sans modification les adresses MAC de tous les appareils connectés est rapidement bloqué.

4. Captive Portals. Un Captive Portal est la page de connexion qui s'ouvre automatiquement lors de la première tentative de connexion sur de nombreux hotspots et réseaux invités, et qui ne débloque l'accès réseau proprement dit qu'après confirmation ou identification. Un appareil sans écran – comme un routeur ou un lecteur d'affichage dynamique – ne peut pas utiliser ce portail lui-même.

5. Particularités DHCP. DHCP (Dynamic Host Configuration Protocol) est le service qui attribue automatiquement une adresse IP aux appareils du réseau. Si plusieurs appareils derrière le pont doivent chacun obtenir leur propre adresse depuis le réseau tiers, un relayage DHCP supplémentaire est nécessaire – dans un réseau aux règles de pare-feu inconnues, souvent un puits sans fond.

Pour le client, cela signifiait : sans solution réfléchie, chacun de ces cinq obstacles aurait pu bloquer le projet – et même si le pont était parvenu à accéder au réseau, réveiller les écrans à distance par Wake-on-LAN aurait représenté un problème à part. Plus de détails dans la section suivante.

La réponse à ces cinq obstacles est le pont client basé sur le NAT décrit dans la section de base ci-dessus : un routeur Teltonika de la série RUT se connecte en mode client Wi-Fi au réseau invité – comme un seul appareil, avec une adresse MAC et une adresse IP. Le support WDS n'est pas nécessaire, car aucun bridging transparent n'a lieu. L'authentification 802.1X est prise en charge par le routeur lui-même, au nom de tous les appareils situés derrière. Les restrictions MAC deviennent sans effet, puisque seule une adresse est visible vers l'extérieur de toute façon. Un Captive Portal peut, si nécessaire, être traité une seule fois au préalable, et une reconnexion périodique peut être prise en charge par du monitoring et des scripts – nous ne promettons pas une automatisation à 100 % pour chaque type de portail imaginable, mais bien une solution validée pour le site cible concret. Et le relayage DHCP devient superflu, car les appareils derrière le pont obtiennent leurs adresses depuis leur propre LAN géré par Ascend, et non depuis le réseau tiers.

Reste la question posée par le cas pratique : comment réveiller à distance des appareils situés derrière un tel pont ? Wake-on-LAN (WOL) fonctionne à l'origine de façon très simple – un Magic Packet, un paquet de diffusion spécial au niveau 2 du réseau, est envoyé dans le réseau local et réveille l'appareil correspondant de son état de veille grâce à son adresse MAC. Le problème : un paquet de diffusion ne franchit pas de lui-même les limites d'un réseau – encore moins la frontière NAT d'un pont, ni même à travers un tunnel vers Internet. Un Magic Packet envoyé à distance n'arrive tout simplement pas derrière le pont si personne ne l'y introduit de façon ciblée.

C'est exactement pour cela que nous avons développé nos propres scripts de transfert WOL : ils reçoivent la commande de réveil via l'Uplink géré du pont, puis envoient le Magic Packet de façon ciblée dans le LAN local situé derrière le pont – là où il doit réellement arriver. Il est ainsi possible de réveiller à distance un écran ou un terminal sur le site distant, sans que personne n'ait besoin d'intervenir sur place. Condition côté appareil : Wake-on-LAN doit être activé dans le BIOS ou sur l'adaptateur réseau (NIC) de l'appareil cible – nous le vérifions avec vous avant le déploiement.

Ascend fournit ici tout en un seul interlocuteur : le matériel (routeurs Teltonika préconfigurés), le logiciel (les scripts de transfert WOL et la configuration NAT), le conseil pour la configuration adaptée à votre site cible, et la configuration complète – préparée dans le datacenter Ascend avant même que l'appareil ne voie le site d'exploitation.

De nombreux déploiements de ponts ont permis de dégager quelques bonnes pratiques, transposables à tout projet.

Vérifier le profil Wi-Fi au préalable. Indiquez-nous si possible, avant la configuration, quelle authentification est requise sur le site cible, s'il existe des restrictions MAC et si un Captive Portal est présent. Plus nous connaissons précisément le réseau cible, plus le pont fonctionne de manière fiable dès le premier jour.

Tester Wake-on-LAN avant le déploiement. Vérifiez sur un appareil pilote que Wake-on-LAN est activé dans le BIOS ou sur l'adaptateur réseau, avant de déployer plusieurs sites simultanément.

Utiliser le monitoring dès le début. Un pont qui se déconnecte sans être détecté est pire qu'un pont qui ne fonctionne pas du tout dès le départ – car personne ne remarque son absence. La gestion à distance est active dès la mise en service.

Une seule ligne ne suffit pas ? Si un seul accès ne suffit pas et que vous souhaitez regrouper plusieurs lignes en une bande passante mutualisée, découvrez notre solution Multi-WAN Bonding avec Viprinet.