Sépare un Wi-Fi invité avec un portail captif

Intégration BTS

« Un portail captif sécurise le Wi-Fi invité. »

Le portail contrôle une étape d’accès. Il ne remplace ni le chiffrement radio, ni la séparation du réseau invité, ni les règles de pare-feu. Un invité authentifié ne doit pas devenir un utilisateur du LAN interne.

01Réutilise le cours Wi-Fi au lieu de le dupliquer

Les fondamentaux sont déjà traités dans :

cybersecurity/utiliser-wifi-vpn-tunnel-identite-autorisation
reseaux/segmenter-lan-vlan
reseaux/filtrer-flux-inter-vlan-nftables
reseaux/diagnostiquer-service-bout-en-bout

Tu dois déjà savoir distinguer :

SSID visible
≠ preuve d'identité du réseau

chiffrement radio
≠ autorisation d'accéder au SI

portail captif
≠ segmentation

Le geste nouveau est pratique : mettre en service un réseau invité borné, le soumettre à un portail captif puis vérifier qu’il reste isolé du SI interne.

02Scénario SORIA Distribution

Le site reçoit des visiteurs qui doivent accéder à Internet sans atteindre les postes, serveurs ou interfaces d’administration.

Architecture de laboratoire :

SSID / zone         : GUEST-LAB
VLAN                : 60
réseau              : 10.60.60.0/24
passerelle          : 10.60.60.1
DHCP                : 10.60.60.50 - 10.60.60.199
DNS                 : résolveur autorisé par le scénario
pare-feu / portail  : OPNsense ou équivalent

LAN interne         : 10.50.0.0/16
management          : 10.50.99.0/24

Toutes les adresses sont synthétiques. Aucun équipement ni identifiant de production SORIA n’est utilisé.

03Écris le contrat d’acceptation avant la configuration

Le réseau invité n’est validé que si les six conditions suivantes sont prouvées :

Exigence	Preuve attendue
adressage	le client reçoit une adresse, une passerelle et un DNS attendus
portail	une première navigation déclenche le mécanisme d’accès prévu
Internet	après validation du portail, le client atteint une ressource Internet autorisée
isolation interne	LAN et management restent inaccessibles
DNS	la résolution nécessaire fonctionne sans exposer un DNS interne non prévu
retour arrière	la désactivation du portail et des règles temporaires est documentée

Un seul test positif ne suffit pas. L’isolation se prouve par des tests négatifs.

04Crée d’abord la zone invitée

Avant le portail, le réseau doit exister comme zone séparée.

Vérifie :

interface / VLAN invité créé
adresse de passerelle appliquée
scope DHCP borné
aucun chevauchement avec LAN ou management
DNS prévu explicitement
aucune règle implicite vers le LAN interne

Depuis un client invité, conserve :

adresse reçue
masque / préfixe
passerelle
destination DNS
heure du bail

Si le client n’obtient pas d’adresse, ne commence pas par modifier le portail captif. La panne est encore au niveau de l’accès ou du DHCP.

05Construis une politique de flux minimale

Le besoin métier est simple : invité vers Internet, pas invité vers SI interne.

Matrice logique de départ :

Source	Destination	Service	Décision	Raison
GUEST	service DHCP de la zone	DHCP	ALLOW	configuration du client
GUEST	DNS autorisé	DNS	ALLOW	résolution de noms
GUEST	mécanisme du portail	selon implémentation	ALLOW	authentification / acceptation
GUEST	Internet	web et flux explicitement retenus	ALLOW après politique	besoin visiteur
GUEST	LAN interne	any	DENY	isolation
GUEST	MANAGEMENT	any	DENY	protection administration
LAN / Internet	console du pare-feu	administration	DENY sauf zone admin	moindre exposition

L’ordre des règles compte. Une règle large placée avant le refus peut annuler l’isolation attendue.

06Valide le réseau sans portail avant de l’activer

Établis une baseline courte :

T0-A : DHCP fonctionne
T0-B : DNS prévu fonctionne
T0-C : LAN interne refusé
T0-D : management refusé
T0-E : console d'administration non accessible depuis GUEST

Cette baseline évite d’attribuer au portail une panne qui existait déjà dans l’adressage ou le filtrage.

07Active le portail sur la zone invitée uniquement

Dans OPNsense ou l’environnement équivalent :

1. sélectionne exclusivement l'interface / zone GUEST ;
2. choisis le mécanisme d'accès demandé par le TP ;
3. définis une durée de session raisonnable pour le laboratoire ;
4. conserve l'administration du pare-feu hors de la zone invitée ;
5. applique puis teste avec un client neuf ou une session nettoyée.

Le TP accepte plusieurs mécanismes de laboratoire :

acceptation simple de conditions
compte local synthétique
voucher de laboratoire
source d'identité dédiée au lab

Le choix doit être documenté. Aucun compte réel ni mot de passe de production n’entre dans le dossier de preuves.

08Ne confonds pas redirection et connectivité

Quand le portail ne s’affiche pas, sépare les hypothèses :

le client a-t-il une adresse ?
la passerelle est-elle joignable ?
le DNS fonctionne-t-il ?
le client tente-t-il un flux interceptable par le portail ?
la zone correcte est-elle associée au portail ?
une règle bloque-t-elle le chemin nécessaire ?
une session précédente est-elle encore active ?

Un site HTTPS moderne peut ne pas se comporter comme une simple page HTTP de test. Utilise la méthode de détection prévue par le laboratoire et observe la chaîne réelle au lieu de conclure « le portail est cassé » après une seule URL.

09Teste avant authentification

Avant validation du portail, produis les preuves suivantes :

adresse DHCP correcte
portail présenté selon le scénario
LAN interne refusé
management refusé
Internet non disponible ou limité selon la politique définie

Le refus du LAN doit être testé sur une cible de laboratoire connue. L’absence de réponse d’une machine inconnue n’est pas une preuve de filtrage.

10Teste après authentification

Après validation du portail :

Internet autorisé selon la politique
DNS toujours fonctionnel
session du portail identifiable
LAN interne toujours refusé
management toujours refusé
client invité voisin non accessible si l'isolation client est exigée et disponible

La réussite est donc :

PORTAIL OK + INTERNET OK + INTERNE REFUSE

et non simplement :

PORTAIL OK

11Provoque une panne contrôlée

L’évaluateur choisit une seule anomalie :

A — scope DHCP erroné
B — DNS non autorisé par la règle de pare-feu
C — portail associé à la mauvaise zone
D — règle interne trop permissive
E — règle Internet absente après authentification

Pour chaque cas, applique la méthode :

symptôme
→ hypothèses
→ test discriminant
→ cause confirmée
→ correction minimale
→ preuve positive
→ preuve négative

Si la panne est résolue en créant une règle any/any, la correction n’est pas validée tant que cette règle n’est pas remplacée par une politique bornée.

12Prépare le rollback

Avant le TP, note l’état initial. À la fin, le retour arrière doit pouvoir supprimer uniquement ce qui a été créé pour l’exercice :

désactiver le portail de la zone GUEST
supprimer comptes/vouchers synthétiques si présents
retirer les règles temporaires devenues inutiles
conserver ou supprimer le VLAN selon le scénario du formateur
vérifier que l'administration reste accessible depuis sa zone autorisée
contrôler qu'aucune règle large n'est restée active

Le rollback n’est pas « restaurer l’usine ». Il est ciblé sur le changement.

13Constitue la fiche d’intervention

Remets :

1. schéma logique de la zone invitée ;
2. plan d'adressage ;
3. matrice de flux ;
4. preuve DHCP/DNS ;
5. preuve du portail avant authentification ;
6. preuve Internet après authentification ;
7. deux preuves de refus vers les réseaux internes ;
8. incident contrôlé et diagnostic ;
9. correction ;
10. procédure de rollback ;
11. limite de la conclusion.

Limite minimale :

Le TP valide l'isolation et le parcours du portail dans le laboratoire.
Il ne constitue pas à lui seul une étude radio, une homologation de sécurité ni une preuve de conformité d'un réseau Wi-Fi de production.

✓À retenir

Le portail captif est une brique d’accès. La sécurité du Wi-Fi invité repose surtout sur la séparation de zone, les flux minimaux et les tests négatifs qui prouvent que l’authentification n’ouvre jamais le SI interne.