Category "Réseaux et Wi-Fi"

Illustration générée par IA — visuel conceptuel.

Objectif (exploitation « jour‑2 »)

En exploitation, un incident réseau n’est pas seulement une panne matérielle. C’est souvent une mauvaise manipulation, une mise à jour ratée, une dérive de configuration, ou une compromission qui impose un retour rapide à un état sain. L’objectif d’une procédure « backups & restauration » n’est donc pas de copier des fichiers, mais de garantir qu’une restauration complète et reproductible est possible, dans un délai compatible avec l’activité (hôtel, bureaux, site multi‑services).

Point clé : un backup non restauré en test reste une hypothèse.

Périmètre minimal à couvrir

Le périmètre doit rester pragmatique : on documente et on sauvegarde ce qui permet de rétablir le service. Le reste (dépendances, secrets, contrats opérateurs) est référencé dans le runbook.

Firewall / routeur edge

• Politiques de filtrage, NAT, objets/adresses, routage.
• VPN (site‑à‑site et accès distant), profils et politiques de sécurité.
• Certificats (si gérés par l’équipement) et paramètres associés.
• Comptes et rôles d’administration (sans exposer les mots de passe dans le DOE).

Switches (cœur, distribution, accès)

• VLAN, trunks, routage L3 (si applicable), ACL, policies.
• Spanning‑Tree / protections L2, agrégations (LACP), uplinks.
• PoE (politiques, priorités), ports critiques.

Contrôleur Wi‑Fi / plateforme de management

• SSID, sécurité, mapping VLAN, portail captif (si utilisé), RADIUS/802.1X (si utilisé).
• Templates et paramètres d’adoption des points d’accès.
• Certificats et identités (quand la solution en dépend).

Dépendances « invisibles » à référencer dans le runbook

Ces briques ne sont pas toujours dans le lot « réseau » (ou ne sont pas toujours sauvegardées au même endroit), mais elles conditionnent le retour en service : DNS/DHCP, NTP, AAA/RADIUS, portail captif, supervision/collecte de logs, bastion/VPN, etc. Sur un hôtel, cette cartographie s’inscrit dans une approche globale de convergence (Wi‑Fi, IPTV, VoIP, CCTV, GRMS). Vous pouvez recouper avec notre article Architecture réseau IP d’un hôtel : comment faire cohabiter Wi‑Fi, IPTV, VoIP, CCTV et GRMS ?.

Règles d’or (pragmatiques) : ce qui évite les mauvaises surprises

1) Distinguer « backup » et « restauration exacte »

Selon les constructeurs, certaines actions « rechargent » une configuration en la fusionnant avec l’existant, alors que l’exploitation attend souvent un remplacement strict (retour à l’état de référence). Cela doit être écrit dans le runbook, par famille d’équipement, avec une procédure validée.

2) Versionner (rotation) et indexer

Conservez plusieurs versions et, surtout, un index exploitable : quel fichier correspond à quel équipement, à quel site, à quelle version logicielle/firmware, et à quel changement. Sans cet index, on « a des backups » mais on ne sait pas lequel restaurer.

3) Anticiper les compatibilités modèle/plateforme/firmware

Une restauration peut être limitée par des contraintes de modèle ou de version. Par exemple, certains éditeurs documentent des limitations de restauration « inter‑plateformes » ou recommandent d’identifier explicitement la version firmware dans le nom du backup. Ces contraintes ne doivent pas être découvertes pendant un incident.

4) Traiter les backups comme des actifs sensibles

Une archive de configuration révèle souvent la topologie, l’adressage, les règles de sécurité et parfois des secrets (selon les produits et options). Protégez donc ces archives comme un actif de cybersécurité : chiffrement, droits minimaux, traçabilité. Sur les établissements hôteliers, ce sujet se rattache directement à la gouvernance des accès et à la segmentation. Pour une lecture plus large, voir Cybersécurité d’un hôtel connecté : comment protéger GRMS, PMS, GTB et réseau ? et VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ?.

Runbook « backup & restore » : structure recommandée (prête à intégrer au DOE)

Un runbook utile n’est pas un texte générique : c’est un document actionnable en astreinte. La structure ci‑dessous vise un minimum réaliste.

1) Fiche d’identité (par site / par baie)

• Nom du site, périmètre (bâtiments, étages, zones techniques), plages d’intervention.
• Contacts d’escalade (exploitation, prestataires, opérateurs, supports éditeurs).
• Contraintes d’exploitation (fenêtres de maintenance, périodes à éviter).

2) Inventaire « restaurable » (table obligatoire)

Pour chaque équipement : rôle, modèle, numéro de série, version logicielle/firmware, IP de management, méthode de backup, emplacement des archives, et procédure de restauration (résumée + lien vers documentation constructeur).

3) Procédures normalisées (SOP) : backup et restore

• Procédure backup (quoi, comment, à quel moment, comment vérifier le fichier).
• Procédure restore (pré‑checks, étapes, post‑checks, et conditions de retour arrière).
• Pré‑requis : accès d’admin, serveur de stockage, compte « break‑glass » (si prévu), méthode d’accès distant (VPN/bastion).

4) Check‑list de validation « retour en service »

Prévoyez une check‑list orientée service (et pas seulement « ping OK ») : Internet/failover, VLAN critiques, Wi‑Fi (SSID + authentification), services métiers dépendants, journaux/supervision, etc. Pour structurer la supervision et rendre les alertes actionnables, voir aussi Supervision réseau : quels équipements et indicateurs faut-il réellement surveiller ?.

Rotation & stockage : un modèle minimal (à adapter au projet)

Il n’existe pas une seule « bonne » rotation : elle dépend de la criticité, du volume de changements, et de la capacité à restaurer rapidement. En revanche, la logique doit être explicite, documentée et testée.

Bon repère d’exploitation : s’inspirer d’une approche de type « 3‑2‑1 » (plusieurs copies, supports distincts, et au moins une copie hors site), en y ajoutant, quand c’est pertinent, une copie immuable (protection contre suppression/ransomware). Cette logique est notamment présentée dans une publication NCCoE/NIST sur la protection des données.

Nommage recommandé (exemple)

Adoptez un nommage qui évite les ambiguïtés :

• Site + rôle + modèle + numéro de série
• version firmware
• date/heure + éventuellement référence de ticket

Recommandation pratique : inclure la version firmware dans le nom aide à contrôler les compatibilités lorsque le constructeur les impose ou les recommande.

Coffre à secrets : séparer « configurations » et « identifiants »

Dans un DOE, on évite de disperser des mots de passe dans des PDF, des emails, ou des tableurs non maîtrisés. La bonne approche consiste à séparer :

• Les fichiers de configuration (exports, snapshots, backups) ;
• Les secrets d’exploitation (comptes admin, clés API, RADIUS shared secret, PSK VPN, certificats/keys, SNMP, etc.).

Un coffre à secrets (outil dédié ou mécanisme DSI) permet d’organiser les accès, la traçabilité, et parfois la gestion de versions. Par exemple, HashiCorp Vault propose un secrets engine « KV » ; dans sa version KV v2, Vault conserve un nombre configurable de versions d’un secret, et la commande vault kv rollback permet de revenir à une version précédente (si ce mode KV v2 fait partie de votre architecture et de vos procédures internes).

Attention : le coffre n’est pas « une obligation produit ». C’est une recommandation d’exploitation à cadrer avec la gouvernance du client (IT/RSSI/exploitant), et à recetter (accès nominal + procédure d’urgence « break‑glass »).

Tester la restauration : le protocole d’exercice (le seul moyen d’être sûr)

La recommandation NIST (SP 800‑209) insiste sur l’importance de procédures (SOP) de backup incluant le fait de tester périodiquement les backups et, selon les exigences de restauration, de réaliser un test end‑to‑end vers un environnement de test (sandbox).

Scénarios de test utiles (réseau hôtel / tertiaire)

• Restauration sur équipement « spare » (quand la compatibilité modèle/firmware l’exige).
• Restauration après factory reset (simulation réaliste « matériel remplacé »).
• Avant / après upgrade (snapshot pré‑upgrade + retour arrière documenté).

Preuve de test (livrable interne)

• Date/heure, opérateur, équipement, version firmware, fichier restauré.
• Étapes réalisées + temps de retour service (mesuré).
• Écarts constatés + actions correctives (ce qui change dans le runbook).

Exemples documentés (constructeurs) : points de vigilance à connaître

Les exemples ci‑dessous ne sont pas des « standards universels » : ils illustrent des mécanismes décrits dans des documentations éditeurs, utiles pour écrire un runbook concret selon les marques réellement déployées.

Cisco IOS / IOS‑XE : « merge » vs « restauration exacte »

La documentation Cisco précise que charger une configuration dans la running-config revient à appliquer des commandes (fusion, sans effacement complet). Pour une restauration « exacte », le principe documenté consiste à copier vers la startup-config puis redémarrer (reload) l’équipement.

ArubaOS (contrôleurs) : restauration via copie sur flash puis vers la configuration système

Le guide CLI ArubaOS documente une méthode de restauration qui passe par une copie du fichier sur la flash, puis une copie vers la configuration système, afin d’éviter d’écraser par erreur certains états.

Aruba AOS‑CX (switches) : copie de running‑config

La documentation AOS‑CX décrit la copie de la running configuration via plusieurs protocoles (SCP/SFTP/TFTP) ou support USB, ce qui se traduit en runbook par un export contrôlé, daté et associé à la version logicielle.

UniFi Network Application : sauvegarde/restore via backup « controller level »

La documentation « Cloud UniFi Support » décrit une migration/restauration via un backup (et précise notamment la différence entre un controller level backup et un export partiel selon les cas), ainsi que le fait que la restauration écrase la configuration existante sur la cible. Côté runbook, cela implique de documenter la méthode exacte et d’éviter une restauration « au hasard » pendant une crise.

Ruckus (ZoneDirector / SmartZone) : compatibilité et nommage

Des documentations Ruckus mentionnent des contraintes de restauration selon les plateformes, ainsi qu’une recommandation pratique d’inclure la version firmware dans le nom du fichier de backup. Ces points doivent être recopiés tels quels dans le runbook du site concerné, avec la procédure officielle du produit réellement installé.

Palo Alto Networks (PAN‑OS) : snapshot + export/import via SCP

La documentation PAN‑OS décrit une procédure de sauvegarde en « configuration snapshot » nommé, puis d’export/import via Secure Copy (SCP). En exploitation, cela donne une méthode claire pour tracer le bon fichier et le rejouer sur un équipement cible (si compatible).

Fortinet : restauration de backups chiffrés (exigences à vérifier selon version)

Fortinet publie des informations techniques (selon versions et contextes) dans Fortinet Community et dans des documents FortiOS Best Practices, indiquant que la restauration d’un backup chiffré peut imposer des contraintes strictes de modèle et de version (et nécessiter le mot de passe de chiffrement). Ce point doit être confirmé sur la version exacte du firewall en place, puis testé en exercice.

Recette « retour en service » : check‑list orientée hôtel

Une restauration réussie n’est pas « le firewall répond ». C’est un retour en service des flux critiques. Une check‑list simple, adaptée à la convergence d’un hôtel, couvre généralement :

• WAN principal + bascule (si présente) ;
• VLAN essentiels (invités, staff, administration, CCTV, GRMS/GTB…) ;
• DHCP/DNS (si dans le périmètre) ;
• Wi‑Fi invités : portail captif / isolation / accès Internet (si applicable). Voir Wi‑Fi invités : sécurité, portail captif, isolation et expérience client.
• Wi‑Fi staff / métiers : accès aux services nécessaires, stabilité ;
• Logs (syslog) et supervision (alertes cohérentes après restauration) ;
• Validation par tests « service » (et pas uniquement ICMP), selon le niveau d’exigence du site.

Livrables : ce qu’il faut pouvoir remettre (et reprendre) proprement

Sur des projets hôteliers ou tertiaires, la maintenabilité dépend autant des fichiers que de la documentation d’exploitation. Deux livrables se complètent :

• DOE réseau (schémas, inventaire, exports, méthode de restauration) — voir Documentation réseau : quels schémas et sauvegardes remettre au client ?.
• Runbook jour‑2 (procédures, check‑lists, preuves de tests, scénarios de panne, escalade).

Sans runbook, le DOE reste « descriptif ». Sans DOE, le runbook devient vite incomplet et dépendant d’une seule personne.

Conclusion : le minimum vital, c’est « restaurer en confiance »

Pour sécuriser l’exploitation, concentrez-vous sur un socle simple : sauvegardes versionnées, stockage protégé, secrets gérés séparément, compatibilités explicitées, et tests de restauration avec preuves.

Si vous souhaitez cadrer ce sujet dans un établissement (hôtel, siège, site multi‑bâtiments), un audit « jour‑2 » (inventaire, runbook, exercice de restauration) permet généralement d’identifier rapidement les points de fragilité. Contactez-nous pour structurer une démarche proportionnée à vos risques et à vos contraintes d’exploitation.

Sources (sélection) utilisées pour les exemples documentés

• NIST SP 800‑209 (tests périodiques de backups et test end‑to‑end selon criticité)
• NCCoE/NIST – Protecting Data: Implementing a Data-Centric Approach (repères de protection des données ; approche de type 3‑2‑1 citée dans la publication)
• Cisco IOS‑XE – Managing Configuration Files
• ArubaOS CLI Guide – commande copy / restauration
• AOS‑CX – copy running-config
• Cloud UniFi Support – Move a UniFi controller using Backup and Restore
• Ruckus Support – SmartZone configuration backup restoration (plateformes)
• Ruckus – ZoneDirector backup (recommandation nommage)
• Palo Alto – SCP import/export
• Fortinet Community – Restoring a configuration file with a lower firmware version (pré‑requis de restauration, selon cas et versions)
• FortiOS – Best Practices (PDF) (repères migration/restauration selon versions)
• HashiCorp Vault – KV secrets engine
• HashiCorp Vault – Versioned KV (KV v2) (gestion de versions des secrets)
• HashiCorp Vault – commande kv rollback (KV v2) (retour à une version antérieure)

Illustration générée par IA — visuel conceptuel.

Dans un hôtel, on parle souvent Wi‑Fi, VLAN, switching et couverture radio. Pourtant, une grande partie des incidents visibles côté client ou réception (“Wi‑Fi connecté mais pas d’Internet”, portail captif qui ne s’affiche pas, authentification WPA‑Enterprise/802.1X impossible, services IP instables) viennent d’une couche plus discrète : DHCP, DNS et AAA (souvent via RADIUS).

Ce guide est orienté exploitation hôtelière (runbook + conception + modes dégradés). Il complète nos dossiers sur l’architecture réseau IP d’un hôtel, le Wi‑Fi invités et le portail captif, et la supervision réseau.

La chaîne de dépendances (vue exploitation)

Parcours typique d’un client Wi‑Fi invité (avec portail captif)

1. Association Wi‑Fi (802.11) : le terminal rejoint le SSID.
2. Configuration IP via DHCP : sans bail DHCP, pas de service IP exploitable (DHCPv4 : RFC 2131).
3. Paramètres réseau fournis par DHCP (au minimum) :
   • Passerelle : option DHCP 3 (“Router”).
   • DNS : option DHCP 6 (“Domain Server”).

   Références pratiques : définition des options dans RFC 2132 et registre IANA (IANA — BOOTP/DHCP Parameters).

4. DNS fonctionnel : indispensable pour la navigation, et souvent pour la détection de connectivité/captive portal côté OS.
5. Détection captive portal : le terminal teste la connectivité et peut ouvrir automatiquement l’écran de login (comportement variable selon OS et versions).
6. Portail captif / politique d’accès : redirection, CGU, voucher, paiement… selon la stratégie retenue.
7. AAA / RADIUS (si utilisé) : contrôle d’accès et/ou attributs de politique (RADIUS : RFC 2865 ; points d’attention d’implémentation : RFC 5080).

Traduction “hôtel” : si vous dimensionnez très bien la radio Wi‑Fi mais que DHCP/DNS/AAA (ou leurs dépendances IP) sont fragiles, l’expérience client restera instable. Et en exploitation, la panne “ressemble” souvent à un problème Wi‑Fi alors qu’elle est en réalité un problème de service d’infrastructure.

Qui dépend de quoi (exemples fréquents)

• Wi‑Fi invités : DHCP + DNS + portail (HTTP/HTTPS) + éventuellement RADIUS.
• Wi‑Fi staff : DHCP + DNS + souvent 802.1X/RADIUS.
• Services IP convergés (VoIP, IPTV, CCTV, GRMS, contrôle d’accès, supervision) : très souvent DHCP et DNS (même si une partie des équipements est en IP fixe, de nombreux services et intégrations utilisent des noms DNS, des APIs, des certificats, etc.).

Symptômes → hypothèses → tests rapides (triage opérationnel)

L’objectif n’est pas de “tout tester”, mais de séparer très tôt un problème radio (association / roaming), un problème IP (DHCP), un problème de résolution (DNS), un problème d’accès (pare-feu, walled-garden), et un problème d’authentification (AAA/RADIUS).

Symptôme A — « Wi‑Fi connecté mais pas d’Internet »

Posez quatre questions, dans cet ordre :

1. Le terminal a-t-il une IP valide dans le bon VLAN ?
   • Non → piste DHCP (service arrêté, relais DHCP, VLAN mal taggé, pool épuisé, ACL…).
   • Oui → continuez.
2. La passerelle par défaut est-elle cohérente ?
   • Vérifier l’option DHCP 3 (Router), puis le routage réel (références : RFC 2132 et IANA — BOOTP/DHCP Parameters).
3. Le DNS fonctionne-t-il réellement ?
   • Un incident DNS peut donner exactement l’impression “pas d’Internet” alors que l’IP/routage sont corrects.
   • Sous Windows, l’état de connectivité (NCSI) s’appuie notamment sur des probes DNS/HTTP ; Microsoft documente ces probes et des cas d’échecs liés au DNS, proxy, interception, etc. (voir Microsoft — NCSI FAQ).
4. Le portail captif se déclenche-t-il (si applicable) ?
   • Si la redirection ou les probes OS sont bloquées, l’utilisateur ne verra pas forcément l’écran de login, ou verra un message “No Internet”.

Pour remettre ce diagnostic dans l’architecture globale, voir aussi Wi‑Fi invités : portail captif, isolation et expérience client.

Symptôme B — « Portail captif en panne / ne s’affiche pas »

Vérifiez d’abord l’infrastructure (dans cet ordre) :

• DHCP : pas d’IP = pas de portail.
• DNS : si l’OS ne résout pas ses destinations de test ou le FQDN du portail, le parcours se dégrade (ou ne démarre pas).
• Filtrage pré-auth (walled garden) : ACL trop restrictive (DNS, HTTP/HTTPS…).
• Certificats et dépendances TLS (à recetter) : si vous utilisez un portail/API en HTTPS, certains terminaux peuvent avoir besoin d’accéder à des services de validation de certificats (par ex. OCSP/CRL) et à une source de temps (NTP) pour valider correctement les certificats. L’IETF explicite ce point dans l’architecture et l’API de captive portal (voir RFC 8952 et RFC 8908).
• Interception / proxy / inspection : peut perturber les probes OS ; Microsoft cite notamment proxy/VPN/DNS/firewall comme causes de comportements NCSI inattendus (voir Microsoft — NCSI FAQ).

Symptôme C — « Échec d’authentification Wi‑Fi (WPA‑Enterprise / 802.1X) »

• RADIUS injoignable (IP/ACL/routage) ou secret partagé erroné.
• Timeouts / retransmissions / latence : RFC 5080 décrit des problèmes d’implémentation courants et des correctifs suggérés.
• Hypothèse à tester (dépendances DNS) : selon votre stack AAA/NAC (annuaire, PKI, NTP, politiques…), si certains composants résolvent des noms (AD, endpoints internes…), un DNS instable peut contribuer à des lenteurs ou à des timeouts perçus. À traiter par corrélation (logs AAA/RADIUS + logs DNS + latence réseau), pas comme une règle universelle.

DHCP en hôtel : conception résiliente et modes dégradés

Pourquoi DHCP “n’est pas juste des IP”

DHCP fournit la configuration réseau (RFC 2131). Dans un hôtel, cela inclut très souvent :

• l’adresse IP,
• la passerelle (option 3),
• les DNS (option 6),
• et selon les cas, d’autres options utiles à des équipements spécifiques (options : RFC 2132 ; registre : IANA — BOOTP/DHCP Parameters).

Un DHCP “qui répond” mais qui annonce une passerelle ou des DNS erronés peut produire les mêmes symptômes qu’une panne Wi‑Fi.

Deux exemples d’approches HA documentées (à choisir selon votre stack)

• Windows Server DHCP failover : Microsoft documente un failover DHCPv4 entre deux serveurs, avec modes hot standby et load balance, et des règles/limites (voir Microsoft Learn — DHCP failover). Point d’exploitation important : la documentation Microsoft indique que si des changements sont faits sur un scope activé en failover, il faut répliquer manuellement ces changements vers le serveur partenaire afin de synchroniser les scopes.
• ISC Kea : ISC documente une haute disponibilité via mécanisme “HA hooks”, explicitement différent d’un “DHCP Failover” historique (voir ISC Kea — High Availability Hooks Library).

Conseil exploitation : ne traitez pas la “HA DHCP” comme une case marketing. Exigez une recette de bascule (arrêt d’un serveur, perte de lien, reprise) et un runbook de rétablissement, au même titre que le failover Internet (voir Deux connexions Internet : comment assurer le failover).

Modes dégradés DHCP (approches projet)

• Repli DHCP “de secours” sur un équipement réseau (pare-feu/routeur) pour un VLAN critique, si votre architecture et vos règles de sécurité l’autorisent. Recommandation de projet à valider au cas par cas : l’objectif est de rétablir un service minimal, pas de “refaire toute l’architecture” en incident.
• Baux plus longs sur des réseaux stables (terminaux fixes, certains services) : cela peut retarder l’impact d’une indisponibilité DHCP pour des clients déjà configurés, car un client peut continuer à utiliser son adresse actuelle jusqu’à l’expiration du bail (et selon son état de renouvellement) comme décrit dans RFC 2131. En contrepartie, certaines évolutions (renumérotation, changements d’options, nettoyage d’adresses “fantômes”) peuvent prendre plus de temps à se propager. À cadrer.
• Supervision de l’épuisement de pool : le serveur attribue une adresse depuis son pool d’adresses disponibles (voir RFC 2131) ; en exploitation, si aucune adresse n’est disponible, l’attribution de nouveaux baux échoue et les clients restent sans bail. Côté client, le symptôme typique reste l’absence de bail DHCP ; selon l’OS, un poste peut aussi s’auto-attribuer une adresse IPv4 link-local en 169.254/16 (parfois appelée APIPA sous Windows) — ce mécanisme est défini par RFC 3927 et documenté côté Windows (ex. Microsoft — Automatic Private IP Addressing). Pour des pistes de dépannage APIPA (causes possibles, checks), voir aussi Cisco — Troubleshoot APIPA Address Failure.

DNS en hôtel : un scénario classique du “connecté sans Internet”

DNS : rôle opérationnel

DNS (RFC 1034/1035) conditionne la navigation, mais aussi une partie des mécanismes de détection de connectivité/captive portal des OS. En exploitation, vous devez surveiller DNS comme un service, pas seulement comme un port ouvert.

Résilience côté résolveur : “serve-stale” (à cadrer)

RFC 8767 décrit un mécanisme permettant à un résolveur récursif de servir des réponses périmées (stale) quand les autorités ne sont pas joignables, afin d’amortir certains outages. C’est un arbitrage disponibilité vs fraîcheur à décider (et à documenter), pas une “optimisation automatique”.

Modes dégradés DNS (approches projet)

• Deux résolveurs locaux (physiques/VM séparées) et DHCP option 6 pointant vers les deux (références options : RFC 2132 ; registre : IANA — BOOTP/DHCP Parameters).
• Repli temporaire documenté (ex. bascule vers un resolver de secours) en tenant compte des impacts sur les zones internes, le split-horizon, les intégrations et la cybersécurité.
• Supervision DNS orientée symptômes : taux de SERVFAIL, latence de résolution, incohérences selon VLAN (invités vs staff vs technique).

RADIUS / AAA : quand l’authentification tombe, tout “a l’air réseau”

Ce qui est établi par des sources primaires

• RADIUS est spécifié par RFC 2865.
• Des problèmes d’implémentation courants et des recommandations sont discutés dans RFC 5080.

Décision de conception : fail-open vs fail-closed

En cas d’indisponibilité AAA, votre accès doit-il être :

• Fail-closed (sécurité) : pas d’accès sans authentification.
• Fail-open (continuité) : accès minimal et très filtré (ex. Internet-only), avec procédure d’incident stricte.

Important : cette décision se prend par zone (staff, administration, technique, invités) et doit être alignée avec vos objectifs de cybersécurité (voir cybersécurité d’un hôtel connecté).

Portail captif : pourquoi ça casse “sans erreur claire”

Ce que documentent les OS (exemples utiles en exploitation)

• Windows (NCSI) : Microsoft documente le principe des probes actives et des causes d’échec (DNS, proxy, interception, VPN, etc.), ainsi que le comportement attendu de certains tests HTTP/DNS (voir Microsoft — NCSI FAQ).
• Android : Google décrit la détection par probes et, à partir d’Android 11, la prise en charge d’un mécanisme plus explicite basé sur une option DHCP fournissant une URL d’API captive portal (voir Android 11 — Captive portal support).
• Standard IETF : RFC 8910 formalise l’annonce d’un captive portal via DHCPv4/DHCPv6 et Router Advertisements, et clarifie notamment le passage de l’option 160 vers 114 suite à conflit.

Conséquence projet : le walled-garden “pré-auth” doit être conçu comme une liste de dépendances (DNS, HTTP/HTTPS et services associés) et recetté avec plusieurs OS représentatifs, pas seulement avec un navigateur de test.

Modes dégradés “portail captif” (approches projet)

• Bypass temporaire contrôlé (Internet-only, limitations adaptées, traçabilité si applicable) le temps de rétablir le portail.
• SSID “incident” (PSK) géré par une procédure interne (communication à la réception + rotation post-incident). À traiter comme une procédure d’exploitation, pas comme un SSID permanent “de confort”.
• Réduction de dépendances (si votre solution le permet) en s’alignant sur les mécanismes normalisés, tout en conservant un comportement compatible avec les terminaux plus anciens.

Checklist « dépendances & plans de repli » (à intégrer dans le DOE exploitation)

Cette checklist vise un objectif simple : rendre vos services réseau rétablissables par l’exploitation (ou par un mainteneur) sans “réinventer l’architecture” en incident.

DHCP

• Architecture : qui délivre DHCP sur quel VLAN ? Où sont les relais DHCP ?
• Disponibilité : redondance ou repli défini (selon criticité).
• Capacité : pools dimensionnés + alerte d’épuisement.
• Options minimales : passerelle (opt 3), DNS (opt 6) cohérents (options : RFC 2132 ; registre : IANA — BOOTP/DHCP Parameters).
• Procédures : runbook de bascule, runbook de retour arrière, et responsabilités (qui peut agir, comment tracer le changement).

DNS

• Deux résolveurs (ou service HA) + supervision latence/SERVFAIL.
• Scénario WAN down documenté (cache, éventuel serve-stale selon résolveur et politique).
• Tests par VLAN : invités vs staff vs technique (symptômes parfois différents).

AAA / RADIUS

• Redondance : au minimum deux serveurs AAA ou un mécanisme documenté de continuité.
• Décision explicite fail-open/fail-closed par SSID/VLAN (et justification).
• Supervision : taux d’échecs, timeouts, latence NAS↔RADIUS.

Portail captif

• Pré-auth/walled-garden : DNS + HTTP/HTTPS nécessaires, clairement listés et versionnés.
• Si portail/API HTTPS : inclure dans la recette (et dans la liste de dépendances) les besoins éventuels de validation de certificats (OCSP/CRL) et de synchronisation de l’heure (NTP) selon les clients ; référence IETF la plus explicite : RFC 8908 (contexte architecture captive portal : RFC 8952).
• Recette multi-terminaux : au moins Windows + Android + un échantillon représentatif du parc réel.
• Mode dégradé : bypass contrôlé ou SSID incident (procédure + retour à la normale).

Pour structurer les livrables, voir aussi DOE réseau : schémas et sauvegardes à remettre et DOE & maintenance d’un hôtel connecté. Et, pour la phase projet, notre checklist de pré‑ouverture hôtel aide à recetter les dépendances avant l’arrivée des premiers clients.

Runbook d’incident (structure simple, à adapter à votre hôtel)

1. Choisir trois postes de test : un filaire (si possible), un Wi‑Fi invités, un Wi‑Fi staff.
2. Vérifier IP / passerelle / DNS (avant de toucher aux réglages radio).
3. Tester la résolution DNS (interne + externe selon politique).
4. Tester HTTP/HTTPS et le comportement portail (redirection, walled-garden).
5. Si authentification : tester AAA (NAS→RADIUS) et isoler le problème (réseau vs secret vs politiques vs dépendances).
6. Activer le mode dégradé documenté (si nécessaire), puis documenter le retour arrière.

Point projet Domocasa (discret)

Si vous préparez une pré‑ouverture, une rénovation courant faible ou un plan directeur réseau d’hôtel, l’enjeu n’est pas seulement “un Wi‑Fi qui couvre”. C’est de concevoir des services d’infrastructure rétablissables (DNS/DHCP/AAA), avec un DOE exploitable et des modes dégradés recettés. Pour cadrer le périmètre et les dépendances, vous pouvez vous appuyer sur notre guide d’architecture IP hôtel et notre approche supervision orientée services.

Illustration générée par IA — visuel conceptuel.

Pourquoi la “capacité” Wi‑Fi compte autant que la couverture

Un réseau peut afficher un excellent niveau de signal et pourtant offrir une expérience médiocre dès qu’on ajoute de la simultanéité (beaucoup de clients actifs), de la voix/visioconférence (sensibles aux pertes et à la latence), ou de la mobilité (roaming). En hôtellerie, c’est typiquement ce qui se produit dans un lobby, un restaurant, une salle événementielle… et parfois même à l’étage lorsque l’occupation monte.

L’objectif d’une recette “capacité” n’est pas de produire un seul chiffre de débit. C’est de répondre à une question exploitable : à charge réaliste, le service reste-t-il stable ? Et si non : est-ce un manque de points d’accès, un réglage radio à revoir, ou un goulot d’étranglement côté LAN (uplinks, switching, PoE, pare-feu, accès Internet) ?

Ce qu’on teste réellement (et comment le relier à une décision)

Pour rester simple et actionnable, on peut structurer la recette autour de cinq axes. Chacun doit être mesuré en condition “au repos” puis sous charge.

• Simultanéité / densité : combien de clients actifs dans une zone avant dégradation (et surtout comment la dégradation se manifeste).
• Throughput utile : débit observé “côté application” (souvent en TCP), et comportement quand on injecte de l’UDP (puisque l’UDP révèle rapidement pertes et gigue).
• Latence sous charge : la latence ne se juge pas seulement “réseau vide”. Elle doit rester maîtrisée quand le réseau travaille.
• Pertes / jitter : particulièrement critique pour la voix et la vidéo temps réel.
• Roaming : interruption lors d’un changement de point d’accès, et stabilité pendant un déplacement (data et voix).

Repère voix (utile, mais à interpréter avec prudence)

Pour les applications interactives, l’ITU‑T recommande des limites de délai aller simple (one-way) : 0 à 150 ms est indiqué comme acceptable pour la plupart des usages, et 150 à 400 ms comme acceptable sous réserve de connaître l’impact sur la qualité perçue. (ITU‑T G.114)

En pratique, dans un bâtiment (hôtel/bureaux), on n’a pas toujours un outil simple pour mesurer l’aller simple de bout en bout sur un terminal utilisateur. On suit donc souvent le RTT (ping) vers des cibles LAN puis WAN, et on observe surtout la dérive sous charge (ce qui met en évidence une saturation radio ou un goulot LAN/WAN).

Préparer la recette : ce qu’il faut figer avant de lancer les tests

1) Définir des scénarios d’usage (par zone)

Avant d’ouvrir iperf3, décrivez qui fait quoi et où. En hôtel, il est utile de distinguer (au minimum) :

• Chambres : usage “résidentiel” dispersé, mais répété à l’échelle d’un étage.
• Lobby / restaurant : zones denses, clients + staff + parfois TV/casting.
• Salles de réunion / événementiel : pointes fortes et exigences élevées (visioconférence, partage d’écran, streaming).
• Back-office / staff : outils métier, téléphonie/softphones, stabilité en journée.

Ce cadrage complète naturellement une étude radio Wi‑Fi (site survey) : la couverture “carte de chaleur” ne suffit pas si la charge n’est pas définie.

2) Figer le périmètre technique (pour des tests reproductibles)

• Liste des AP par zone (nom, emplacement, VLAN/SSID servis).
• Chemin LAN (switch d’accès, uplink(s), cœur, pare-feu) pour savoir où un goulot peut apparaître.
• Paramètres Wi‑Fi majeurs : SSID, sécurité, bands activées, canaux/puissances (attention aux mécanismes d’auto-optimisation qui changent la radio pendant la recette).

Si vous êtes en phase de conception, ce travail s’inscrit dans la démarche décrite dans Wi‑Fi hôtelier et Wi‑Fi professionnel : capacité radio et infrastructure filaire doivent être dimensionnées ensemble.

Définir des KPI (sans inventer des “seuils universels”)

Les KPI doivent être liés à une décision. Un KPI utile n’est pas “un beau débit”, c’est un indicateur qui vous permet de décider : ajout d’AP, changement de plan radio, renforcement d’uplink, segmentation, ajustement de QoS, etc.

Plutôt que d’imposer des chiffres identiques à tous les projets, utilisez une matrice simple par zone :

Outillage minimal (terrain) : simple, mais robuste

iperf3 (débit TCP et tests UDP)

iperf3 est un outil courant pour générer et mesurer du trafic. Il permet notamment :

• le mode UDP (-u) ;
• un débit cible en UDP (-b) ;
• plusieurs flux parallèles en TCP (-P).

Ces options sont documentées dans des manpages (ex. iperf3(1)) et guides de référence. (manpage iperf3)

Ping continu (latence, dérive sous charge)

Un ping “OK” ne garantit pas une bonne expérience, mais un ping qui se dégrade sous charge est un signal très utile. L’idée est de pinguer plusieurs cibles :

• la passerelle du VLAN (cible LAN très proche),
• un serveur interne (si disponible),
• puis une cible Internet (pour distinguer LAN vs WAN).

Test voix/visioconférence en conditions réelles

Le protocole doit inclure au moins un test applicatif (Teams/Zoom/softphone/VoWiFi selon le site). Le but n’est pas de “mesurer pour mesurer”, mais de valider le ressenti sur un scénario métier (ex. appel en déplacement entre réception et back-office, ou entre deux salles).

Pourquoi il faut parler roaming “côté clients”

Le roaming n’est pas seulement une décision de l’infrastructure : le terminal garde une part importante du contrôle. Sur les appareils Apple, la documentation de déploiement indique notamment la prise en charge de 802.11k/802.11r/802.11v et rappelle que l’absence de mécanismes d’aide (comme le Neighbour Report 802.11k) peut obliger l’appareil à scanner plus largement. (Apple — Wi‑Fi roaming support)

Protocole de tests en 6 étapes (capacité + voix + roaming)

Les étapes ci-dessous forment une “recette” reproductible. Elles peuvent être réalisées sur un hôtel comme sur des bureaux, en adaptant simplement la sélection des zones et le niveau de charge.

Étape A — Baseline “1 client, réseau calme” (par zone)

Objectif : vérifier que la chaîne complète (radio + LAN + cœur + pare-feu) est saine avant de parler densité.

• TCP download / upload (plusieurs itérations).
• UDP à débit progressif (pour observer pertes/jitter).

Exemples iperf3 (à adapter au plan IP) :

# TCP (plusieurs flux)
iperf3 -c <IP_SERVEUR> -t 20 -P 4

# UDP (débit cible)
iperf3 -c <IP_SERVEUR> -u -b 50M -t 20

Étape B — Multi-clients “sur une même zone”

Objectif : identifier le point de bascule lorsque plusieurs clients actifs partagent la même ressource radio.

• Constituer un groupe de clients (PC/smartphones) réellement représentatif.
• Lancer des sessions iperf3 en parallèle.
• En parallèle, faire tourner un ping continu pour voir la latence sous charge.

Lecture : si la latence (RTT) grimpe fortement déjà vers la passerelle LAN, la saturation est proche de l’accès (radio ou uplink d’accès). Si elle grimpe surtout vers Internet, le WAN/pare-feu est suspect.

Étape C — “Zone dense” (plusieurs AP, trafic mixte)

Objectif : simuler un lobby, un restaurant, une salle de réunion : plusieurs AP couvrent la même zone et les clients doivent se répartir “naturellement”.

• Répartir physiquement les clients (pas tous au même endroit).
• Mélanger TCP (usage “data”) et UDP (flux sensibles).
• Observer si un AP devient “hotspot” saturé alors que d’autres sont peu chargés.

Étape D — Test latence “sous charge” (le test qui révèle souvent les uplinks)

Objectif : différencier manque de capacité radio vs goulot LAN/uplink/pare-feu.

• Lancer un ping continu (LAN puis WAN).
• Injecter une charge progressive avec iperf3.
• Comparer la dérive de latence et la stabilité (pics, pertes).

Étape E — Roaming “data” (trajet réaliste)

Objectif : mesurer les interruptions lors d’un passage d’AP à AP sur un trajet réel (couloir → chambre, accueil → bureaux, open space → salle).

• Ping continu (intervalle court) vers une cible LAN.
• Petit flux UDP.
• Déplacement contrôlé (plusieurs passages) pour vérifier la répétabilité.

Étape F — Roaming “voix” (ce que l’utilisateur ressent)

Objectif : valider la continuité d’un appel en déplacement. C’est ici que la recette devient “métier”.

• Appel réel (softphone / VoWiFi / Teams audio) + trajet identique à l’étape E.
• Noter : coupures audio, “robotisation”, déconnexions, nécessité de rappeler.

Interpréter les résultats : diagnostiquer radio vs LAN (et décider)

Symptôme : “bon à 1 client, mauvais en multi-clients”

Hypothèse dominante : saturation radio (airtime, réessais, plan de canaux/puisances, taille de cellule). Décision typique : revoir le design radio (souvent plus d’AP, cellules mieux contenues, planification mieux maîtrisée) plutôt que “changer la box”.

Ce diagnostic s’inscrit dans la logique d’une étude radio Wi‑Fi : capacité et roaming sont des objectifs de conception, pas des “effets secondaires” de la couverture.

Symptôme : “débit plafonné” + “latence qui gonfle sous charge”

Hypothèse dominante : goulot LAN/uplink/pare-feu (ou WAN). Décision typique : audit d’uplinks et de distribution, PoE, cœur réseau, et mise en place de supervision.

En hôtel, cette lecture doit être cohérente avec l’infrastructure globale : architecture réseau IP d’un hôtel (cohabitation Wi‑Fi, VoIP, IPTV, CCTV, GRMS).

Symptôme : “roaming instable” / “appels qui décrochent”

Hypothèse dominante : combinaison de design radio (cellules, recouvrement) + choix de mécanismes d’aide au roaming. La documentation Apple mentionne la prise en charge de 802.11k/802.11r/802.11v sur plusieurs appareils et rappelle l’intérêt des informations de voisinage pour réduire la charge de scan côté client. (Apple — Wi‑Fi roaming support)

Point de vigilance : 802.11r peut améliorer… ou casser des clients

Activer 802.11r n’est pas une “case à cocher” sans recette. Cisco indique que certains clients anciens peuvent ne pas s’associer à un SSID où 802.11r est activé, même en mode mixte, ce qui amène parfois à séparer les SSID ou à utiliser des modes adaptés selon parc clients. (Cisco — 802.11r (compatibilité clients))

Conclusion pratique : dans un hôtel, on teste toujours l’activation (ou non) des mécanismes de roaming avec un panel représentatif de terminaux clients avant généralisation.

Point de vigilance : 802.11v est une “suggestion” au client

802.11v peut aider l’infrastructure à proposer des candidats de roaming, mais Cisco rappelle qu’une requête de transition BSS est une suggestion que le client peut suivre… ou ignorer. (Cisco — 802.11v (BSS Transition))

Voix et “jitter” : comprendre ce qu’on mesure

Dans un rapport, il est utile de distinguer :

• jitter applicatif/voix (souvent RTP) : la RFC 3550 définit le jitter d’inter-arrivée comme une moyenne lissée de la variation d’espacement des paquets. (IETF RFC 3550)
• jitter mesuré par iperf3 en UDP : très utile pour comparer des scénarios, mais ce n’est pas exactement la même chose qu’une métrique de qualité audio “de bout en bout”.

Pour décider, l’approche la plus robuste reste : métriques réseau + test voix réel (en mouvement si nécessaire).

Modèle de rapport de recette (format simple à copier-coller)

Contexte

• Site, zones testées, date/heure, conditions (occupation réelle, événements).
• Inventaire AP/contrôleur (modèles/versions), switches, uplinks, PoE (synthèse).
• SSID/VLAN concernés, options roaming (si pertinentes), politiques particulières.

Hypothèses de charge

• Scénarios par zone : simultanéité visée, profils de trafic (data/vidéo/voix).
• Terminaux utilisés (type + OS) : l’acceptation roaming dépend aussi du client.

Résultats (table de synthèse)

Plan de remédiation (lié aux symptômes)

• Actions radio : ajustements (canaux/puissances), repositionnement, AP additionnels, stratégie de cellules.
• Actions LAN : uplinks, switching, PoE, chemins critiques, segmentation, élimination d’un goulot identifié.
• Actions exploitation : supervision, alertes utiles, re-tests périodiques.

Sur l’aspect exploitation/indicateurs, voir aussi : Supervision réseau : quels équipements et indicateurs faut‑il réellement surveiller ?

Où ce protocole s’insère dans une démarche Domocasa

• Avant : conception et site survey Wi‑Fi (couverture + capacité + interférences + roaming).
• Pendant : recette capacité (ce protocole) + tests roaming voix dans les zones où c’est un usage réel.
• Après : remédiation ciblée (radio, LAN, uplinks, PoE) et re-recette sur les mêmes scénarios, pour prouver l’amélioration.

Besoin d’une recette “capacité” sur site (hôtel ou bureaux) ?

Si vos utilisateurs se plaignent surtout aux heures de pointe, dans les zones denses ou en déplacement, une recette orientée capacité permet généralement d’identifier rapidement si la limite vient de la radio, du LAN/uplink, ou d’une combinaison des deux. Pour cadrer une intervention (site survey, protocole de recette, remédiation et re-tests), vous pouvez aussi vous appuyer sur nos guides Wi‑Fi hôtelier et Wi‑Fi professionnel.