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)
- Association Wi‑Fi (802.11) : le terminal rejoint le SSID.
- Configuration IP via DHCP : sans bail DHCP, pas de service IP exploitable (DHCPv4 : RFC 2131).
- 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).
- DNS fonctionnel : indispensable pour la navigation, et souvent pour la détection de connectivité/captive portal côté OS.
- Détection captive portal : le terminal teste la connectivité et peut ouvrir automatiquement l’écran de login (comportement variable selon OS et versions).
- Portail captif / politique d’accès : redirection, CGU, voucher, paiement… selon la stratégie retenue.
- 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 :
- 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.
- 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).
- 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).
- 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)
- Choisir trois postes de test : un filaire (si possible), un Wi‑Fi invités, un Wi‑Fi staff.
- Vérifier IP / passerelle / DNS (avant de toucher aux réglages radio).
- Tester la résolution DNS (interne + externe selon politique).
- Tester HTTP/HTTPS et le comportement portail (redirection, walled-garden).
- Si authentification : tester AAA (NAS→RADIUS) et isoler le problème (réseau vs secret vs politiques vs dépendances).
- 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.
