Routage Multicast IP -trèèèèèèès intéressant ( formation animée pour le compte des ingénieurs d'Ooredoo)

Objectifs : 
– communications point à multipoint
• exemples
    – diffusion d’un canal vidéo/audio
    – visioconférences ( N sources, interactif)
    – jeux en réseau
    – diffusion de logiciels/données/…

– utilisation efficace du réseau
    • 1 seule copie des données sur un lien
    • => réalisé par le réseau au niveau IP
    • extensible (Nb récepteurs, de sources, de groupes, interdomaine)

Hypothèses:

•Réseau de type IP
• Envoyer le même paquet à plusieurs destinations en minimisant le trafic et les délais
• Le paquet IP parcourt (au moins) un arbre dont la racine est la source et les feuilles les récepteurs

Multicast de niveau 2 

• Dans un réseau à diffusion comme ethernet
– tout le monde reçoit (diffusion) puis sélection par les récepteurs
• Interconnexion de réseaux à diffusion au niveau 2 (pont, switch ethernet)
– construction d’un arbre de recouvrement (spanning tree) pour supprimer les boucles
– diffusion comme dans un réseau unique

– Multicast consomme des ressources
     • problème du filtrage (802.1 GARP) : GMRP ?
– Partiellement résolu en partitionnant le domaine de broadcast
– => utilisation des VLAN
    • Broadcast/multicast limité au VLAN de l’émetteur

Modèle de Deering (1991) 
• Multicast non défini dans IP d’origine
• Travaux de Deering :
    – Paquets IP multicast même format que unicast
    – Adresse multicast identifie un ensemble de récepteurs (classe D IPv4 : 224.0.0.0-239.255.255.255 = 224.0.0.0/4)
    – Groupe = adresse multicast – récepteurs se déclarent au routeur voisin (IGMP) – Pas de connaissance exhaustive des membres du groupe
• Les sources ne se déclarent pas
    – Emission spontanée, sources « bursty »
    – Difficulté du contrôle
• Multipoint à multipoint si les sources sont aussi réceptrices
    – possibilité d’un seul arbre pour N sources
    – possible grâce au mode datagramme (# ATM)
 • Séparation des signalisations IGMP, routage

Adhésion aux groupes

• Protocole spécifique (IGMP) au dessus d’IPv4
        – inclus dans ICMPv6 pour IPv6 (MLD)
• Objectif : connaître les groupes qui ont des récepteurs sur une interface de routeur donnée
    – pas de connaissance exhaustive des récepteurs
• Principe
    – routeur interroge cycliquement IGMP-Query (défaut 125s)
    – récepteurs de G répondent IGMP-Reply (G)

• Mécanismes
   – éviter les réponses multiples :
      • réponses retardées un temps aléatoires
      • supprimées si redondantes
              – idéal = 1 réponse par groupe qui a des récepteurs)
      • => Report IGMP envoyé en multicast
           – à l’adresse du groupe considéré
    – « soft state » : pas de réponse pour G = supprimer info

  – Retrait d’un groupe
       • sur délai (IGMPv1, RFC 1112)
       • retrait explicite : IGMP-leave (IGMPv2, RFC 2236)
  – IGMP protocole datagramme (non fiable)
       • mécanismes de robustesse
       • routeur envoie Plusieurs Query Spécifiques (G) à G
       • avant de supprimer groupe
– traite pertes IGMP, autres récepteurs du groupe

– Choisir les sources d’un groupes
     • une source vidéo dans visioconférence
     • filtrer source indésirable
 – Possible avec IGMPv3, RFC 3376, (2002)
    • mode INCLUDE = liste des sources voulues
    • mode EXCLUDE = liste des sources non voulues
    • synthèse (conservatrice) par le routeur
– Les reports ne sont plus envoyés au groupe mais à
      • 224.0.0.22 = all IGMPv3 capable routeurs
– un report pour plusieurs groupes
– tous les récepteurs répondent
      • permet host tracking facultatif

Listes de sources 

– Ex synthèse de deux Reports,
    même groupe
    listes de sources L1 et L2
    include(L1) et include(L2) => include(L1 ∪ L2)
    include(L1) et exclude (L2) => exclude (L2 \ L1)
    exclude(L1) et exclude (L2) => exclude(L1 ∩ L2)
– IGMPv3 complexe
    messages toIN, toEX, isIN, isEX
    compatibilité avec versions 1 et 2

Quelques adresses prédéfinies 

• 224.0.0.0 Base Address (Reserved)
• 224.0.0.1 All Systems on this Subnet [RFC1112]
• 224.0.0.2 All Routers on this Subnet
• 224.0.0.4 DVMRP Routers [RFC1075]
 • 224.0.0.11 Mobile-Agents
• 224.0.0.12 DHCP Server / Relay Agent [RFC1884]
• 224.0.0.13 All PIM Routers
• 224.0.0.22 All IGMPv3 Routers [RFC 3376]

Lien avec le niveau liaison (1) 

• Lien point-à-point : pas de problème
• Lien à diffusion (ex : ethernet)
– encapsuler paquet IP multicast dans trame ethernet multicast
– mise en correspondance d’adresses
    • 23 derniers bits @ IP => 23 derniers bits @ 802
    • 25 premiers bits 01-00-5E-00-00-00 224.1.2.3 => 01-00-5E-01-02-03
    • collision d’@ possible : filtrage en réception 225.129.2.3 => 01-00-5E-01-02-03
    • en IPv6 : 33.33. Suivi des 4 derniers octets @ IPV6

IP multicast et bridging 

• Dans un réseau avec ponts
    – par défaut multicast = broadcast
    – risque de saturation du réseau
• VLAN = découpage domaine broadcast
• Solutions de niveau 2 type GARP/GMRP
   – en pratique peu ou pas implémentées
• Solutions de niveau 2+3
   – IGMP snooping

IGMP snooping 

• Principe : – les ponts espionnent (snooping) 

• paquets IGMP (et routage multicast) 

• déterminent où sont les récepteurs 

   – IGMP report et routeurs multicast 

• Problèmes 

– éviter la suppression de Report IGMP 

        • filtrer IGMP vers autres membres 

– départ implicite => timeout – calculs switchs (examiner entêtes MAC + IP + IGMP) 

– changer logiciels switch si changements IGMP/MLD

Routage multicast

 • Permettre l’acheminement d’un paquet multicast de la source vers les récepteurs 

 • Arbre construit par signalisation entre les routeurs 

     – semi-explicite (inondation/élagage) 

     – explicite (adhésion/retrait) 

 • Distinction entre 

     – mode dense ou épars 

     – intra ou inter domaine

Routage en mode dense 

• Inondation du réseau (flood) et élimination des branches inutiles (prune) 

    – DVMRP (sur routage unicast spécifique à la RIP) RFC 1075

    – PIM-DM (sur routage unicast « quelconque ») 

• Un arbre par source (pas scalable) 

     – O(S*G) entrées par routeur 

         • une entrée par couple S,G même si hors de l’arbre 

• Repose sur le RPF check

     – utilise le chemin vers la source « chemin inverse »

RPF Check

• B accepte un paquet multicast venant de A s’il arrive par la route unicast (interface) de B vers A

   – permet d’éviter les boucles 

   – la route unicast de B vers A est connue de B 

   – problème en cas de routes asymétriques 

 • Inondation/Elagage périodique (soft state)

Inondation/élagage 

• Reverse Path Flooding ou Broadcasting (RPF check)  

      – problème : les données encombrent tout le réseau 

• Truncated RPB – supprimer les réseaux feuilles inutiles (IGMP) 

• Reverse Path Multicasting – élagage (initial et périodique)

MOSPF 

• Extension de OSPF (RFC 1584) 

     – spécifique à OSPF 

• chaque routeur connaît les liens du réseau(routage par état des liens) 

    – nécessite de connaître l’existence des membres de chaque groupe sur chaque lien 

            • = nouvel attribut de l’état du lien, diffusé

 – calcul des arbres multicast à la volée (coûteux) 

      • calcul de l’arbre de S vers tous les membres (Dijkstra) 

      • suis-je sur cet arbre et avec quels successeurs ? 

      • Résultat mis en cache

 – chemins calculés dans le « bon sens »

Mode dense: conclusion 

• Adapté dans un petit domaine si la majorité des réseaux contiennent des membres 

• coûteux en signalisation (PRUNE) si groupe épars 

• coûteux en états dans TOUS les routeurs du domaine : proportionnel au nombre de couples sources*groupes (DVMRP)

Protocoles en mode épars 

• Un arbre partagé par toutes les sources 

• Construit autour d’un point central (RP) 

• Signalisation explicite (join) des récepteurs vers le centre 

• Arbre en général construit à l’envers « chemin inverse » 

• Localisation du centre ? Panne du centre ? 

• un protocole normalisé et utilisé : PIM-SM

Construction de l’arbre PIM-SM 

RFC 4601 (Standard Track, août 2006) 

• Le routeur d’attachement du nouveau récepteur 

    – à réception d’un Report IGMP – calcule l’adresse du RP 

    – transmet le join au routeur voisin vers le RP 

• Le join remonte vers le RP jusqu’à rencontrer un routeur sur l’arbre 

• messages de retrait (prune) analogues

PIM-SM mécanismes 

• Table de routage PIM-SM : types d’entrées 

      – (S,G) si arbre par source 

      – (*,G) si arbre centré vers un RP 

      – (*,*,RP) pour tous les G partageant un RP (interdomaine)

      – choix de l’entrée (interface d’arrivée, …)

 • informations par entrée de la table : 

      – iif : une interface d’entrée (déterminée par RPF) 

      – oif : n interfaces de sorties ( n >0) – des indicateurs, timers, …

• Adhésion 

– nouveau groupe présent (IGMP Report) sur interface oi 

– si entrée (*,G) existe • ajouter oi à oifs – sinon • calculer interface ii vers le RP de G 

• créer entrée (*,G) avec oif = {oi} et iif = ii 

• envoyer PIM join/prune vers RP par ii

– à réception Pim-Join(G) 

     • si (*,G) existe ajouter interface de sortie 

     • sinon : similaire à adhésion locale : 

                – créer entrée

                – propager PIM-Join 

– le PIM-join est propagé de proche en proche 

        • jusqu’à un routeur « on tree » ou éventuellement le RP

Retrait 

– quand le dernier membre de G sur un LAN 

      • quitte explicitement (IGMP-done) ou implicitement 

      • le routeur supprime l’interface de la liste oif 

– si oif devient vide 

       • envoyer PIM-prune vers RP et supprimer entrée

 – le PIM prune remonte de proche en proche 

       • jusqu’au premier routeur à plusieurs fils ou le RP

• Message périodique PIM-Hello (30s) 

• connectivité entre routeurs voisins 

     – indépendant des arbres 

• Maintenance de l’arbre 

    – message PIM-join périodique fils -> père (60s) 

            • rafraîchissement de l’arbre 

            • suppression des entrées (sur le père) sur timeout 

    – Remarque : pas de message « downstream »

Passage à un arbre (ou branche) par source

 – décidé 

      • par un routeur feuille (débit) 

      • ou par le RP pour la branche source => RP 

• envoi d’un message PIM-join(S,G) vers S 

• création d’une entrée (S,G) en plus de l’entrée (*,G) et avec les mêmes oif

– à réception de données par la branche spécifique = élagage par le côté RP
– pas de repassage explicite à l’arbre partagé
– sur DR timeout sur (S,G) : pas de données => (*,G)
• Plusieurs routeurs sur le même LAN
– mécanisme Assert (si réception de données par oif)
– élection du routeur qui propage sur le LAN
• métrique + identificateur

PIM-SM : choix du centre

• Algorithme du bootstrap

– bootstrap router (BSR) élu parmi les candidats BSR

    • chaque candidat diffuse son identité à tous les routeurs PIM

    • tant qu’il n’en connaît pas un meilleur

– un candidat RP envoie au BSR élu

    • liste des plages adresses multicast et priorité

– le BSR élu

    • choisit parmi candidats

    • diffuse une liste de points de rendez-vous (RP) valides

– sur chaque routeur

    • une fonction de hachage associe adresse de groupe => RP

Commentaires

• Nombre d’entrées en O(g) où g = nombre de

groupes « On tree », plus arbres (S,G)

• mécanisme de sélection du RP n’est pas scalable:

    – la liste de tous les RP doit être connue de tous les

routeurs (diffusion de cette liste)

    – placement non optimal dans un grand réseau

• a priori devrait dépendre de la topologie (variable) des

membres

    – panne du RP = reconstruction de tout l’arbre

Déploiement actuel

• Implémentations de DVMRP, PIM

• Multicast utilisé en interne

     – entreprises : visioconférence, cours bourse

     – FAI : exemple canaux TV chez Free

• Beaucoup d’opérateurs ne routent pas le multicast

     – encore peu de solutions viables à grande échelle

     – disponible chez quelques opérateurs : Sprint, …

• Réseau expérimental Mbone (FMBone)

     – tunnels entre routeurs multicast à travers routeurs non multicast

     – allocation d’adresse manuelle (ou GLOP)

Problèmes de l’inter-domaine

• Extensibilité

       – en nombre de groupes

            • potentiels, existants, existants à un endroit

       – taille des groupes

       – état à mémoriser, signalisation

• Allocation des adresses

       – unicité à l’échelle d’Internet

       – dynamicité

                • si nombreux groupes transitoires

                • espace d’adressage limité (en IPv4)

• Interaction protocoles de routage intra/inter

       – en unicast : protocoles différents

• Respect des politiques de routage

       – contrôle des flux multicast en transit

       – minimiser la « third party dependency »

• Accounting

       – essentiel si applications multicast commerciales

• diffusion vidéo, diffusion d’infos,...

• Fiabilité du routage

      – liée à la taille

      – importance si applications commerciales

Adressage multicast IPv4

• Choix manuel + annonce -> risque de collision

• allocation hiérarchique (architecture MASC, liée au routage)

• allocation par AS : GLOP (RFC 2770)

      – préfixe 233.0.0.0/8, ASN, groupID (8 bits)

• locale à la source (SSM) préfixe 232/8

• Scope (étendue)

     – avec le TTL ( 1 = lien, …)

     – préfixe

          • 239.255.0.0/16 (local)

          • 239.192.0.0/14 (site)

Adressage multicast IPv6

• FF, flags (4 bits), scope (4bits), réservé (80 bits), GroupeID (32 bits)

• flag 0000 = permanent 0001 = transitoire

• scope IPv6

       – 1 = node-local, 2 = link-local, 5 = site-local,

       – 8 = organization-local, E = global

        • ex : FF02:0:0:0:0:0:0:D All PIM Routers (perm., link)

        • FF05:0:0:0:0:0:1:3 All-dhcp-servers (perm., site)

L’architecture BGMP/MASC (Thaler et al, ietf)

• Un protocole d’allocation d’adresses multicast inter- domaine (MASC), + protocoles intra

domaine (AAP, MDHCP)

• Un protocole d’annonce des blocs d’adresses multicast et des politiques multicast (BGP4+)

• Un protocole de construction d’arbre multicast inter-domaine (BGMP)

• Un modèle d’interaction aux frontières

• Des protocoles de routage multicast intra-domaine

BGP4+ (MBGP)

• Extensions de BGP4 (routage interdomaine), RFC 2283

• Introduit de nouveaux attributs

     – Adresse multicast (pour BGMP)

     – Adresse unicast

• Si topologies unicast et multicast différentes

     – Permet le RPF check

     – MSDP, PIM-SSM

MASC (Multicast Address Set Claim)

• Domaines organisés en une hiérarchie

• Allocation unique, dynamique et temporaire

• Chaque domaine

     – demande une (ou plusieurs) plages d’adresses dans une plage affectée à son domaine père

     – résolution de conflit

• Les plages d’adresses utilisées par un domaine sont annoncées à l’extérieur via BGP

– association plage d’adresse <-------> Root Domain

– pas (encore ?) implémenté

MSDP ( Multicast Source Discovery Protocol)

– Solution provisoire en attendant une vraie solution inter-domaine

– RFC 3618 (2003)

– existe seulement pour IPv4

– Implémentée (cisco, ….) et utilisée

– But : relier des domaines PIM-SM entre eux

• Les domaines PIM-SM sont interconnectés

    – Chaque RP (domaine) participant

• a au moins une connexion avec un autre RP (domaine) participant

• graphe de domaine

     – Connexions TCP (fiable)

     – Installées manuellement

     – Servent à transmettre les annonces de sources

• SA(RP-annonçant, Source, Groupe)

• Quand un RP apprend une nouvelle source locale à son domaine

      – Via un PIM-Register

      – Construit un SA

– L’envoie à tout ses voisins MSDP (flooding)

• A réception d’un SA, un RP

      – Propage le SA, en faisant un RPF check (flood)

• SA ré-émis cycliquement (soft state)

• Traitement du SA(RP, S, G)

     – Si entrée (*,G) dans sa table de routage

• Groupe G actif

• Envoyer un join(S,G) vers S

• Construction d’une branche (S,G) inter-domaine

• S’arrête au premier routeur ayant une entrée (S,G)

    – Arbre (S,G) inter-domaine

    – construction utilise MBGP

Le modèle SSM

• Issu de l’architecture Express

• canal identifié par couple (source, ident)

• ident utilisée comme IP destination

    – adresse de groupe

    – unicité de l’ident simple à garantir (par source)

• construction d’arbres par source (S,G), unidirectionnels

• Insertion dans Pim-SM

    – utilise le mécanisme d’arbre par source de SM

    – ne nécessite plus de mécanisme de RP

    – => forte simplification si SSM uniquement

    – traitement SM (modèle ASM) ou SSM suivant plage d’adresse

    – IPv4 SSM = 232.0.0.0/8

    – nécessite l’utilisation d’IGMPv3 mode INCLUDE : abonnement à un couple source, groupe

             • G, include(S)

• Avantages

   – simple, déjà implémenté (PIM-SM)

   – allocation d’adresse triviale (inter-domaine)

   – Permet de faire de l’inter-domaine

• Inconvénients

   – pas de multipoint à multipoint direct

   – contrôle des récepteurs ?

Routage multicast et IPv6

• adresses IPv6 multicast

champs :FF, Flags, Portée, réservés, Group-ID

bits :       8     4           4          80           32

Portée : 1(noeud), 2(lien), 5(site), E(globale)

Flags xyzt :

t (0 = permanente, 1 = transitoire)

z (1 = adresse basée sur préfixe unicast)

               réservés(80) = 0(8), plen(8), prefix(64)

adresse « appartient » au préfixe prefix/plen

y (1 = RPembedded)

réservés = 0(4), RPad(4), plen(8), prefix(64)

adresse du RP = prefix/plen::Rpad

exemples adresses IPv6

• FF02:0::D : permanente locale au lien (tous les routeurs PIM)

• FF05:0::1:3 : permanente locale au site (tous les serveurs dhcp)

• FF1E::7777 : transitoire globale (groupe transitoire 7777)

• FF3E:40:2001:660:220:102::7777 : globale transitoire basée sur le préfixe 2001:660:220:102 (de longueur 64 = 0x40)

• cas particulier SSM : basée sur un préfixe unicast de longueur nulle

• FF3E:0::7777 : canal SSM global 7777

• FF7E:540:2001:660:220:102::7777 : adresse RP_embedded adresse du RP : 2001:660:220:102::5

multicast V6

• PIM étendu à IPv6

• MLDv1 (Multicast Listener discovery)

     – correspond à IGMPv2

     – MLDv2 correspond à IGMPv3

• Possibilité SSM comme en V4

• Pour ASM :

    – MSDP non disponible (mais non extensible)

    – possibilité de RP-Embedded

          • a priori extensible inter-domaine

          • gestion des RP, allocation des adresses ?

          • panne RP ?

Etat des lieux

• En IPv4,

– pas de bonne solution pour ASM interdomaine

        • MSDP, allocation d’adresses

– SSM OK (pour applis type canal TV)

        • mais IGMPv3 pas encore universel (Mac :-((

• En IPv6

– solution RP embedded pour ASM interdomaine

– SSM

– mais IPv6/MLDv2 pas encore universels

Au dessus d’IP multicast

• Transport UDP (TCP point à point)

• Non-fiable

• Fiabilité : problème difficile à grande échelle (PGM, …)

– codes correcteurs de pertes (Flute, …)

• Contrôle

– RTP/RTCP pour flux temps réel

– Contrôle de session (SAP, SIP, …)

MISE EN PLACE D'UNE ZONE-BASED POLICY FIREWALL-[blog Cédric ROBERT]

Dans cet article nous allons voir comment sécuriser notre réseau, en filtrant le trafic sur le réseau grâce à ZPF.

Pré-requis

• Connaitre le fonctionnement et les différents modes d’IOS.
• Avoir des bases en réseau (IP, masque de sous réseau…)
• Connaitre les bases des ACL (voir article ici.).

Qu’est-ce que ZPF ?

ZPF permettant de filtrer nos communications en nous basant sur des zones, en effet lors de l’implémentation de ZPF nous allons segmenter notre réseau en plusieurs zones.
Puis, nous allons définir la politique à appliquer entre chaque zones c’est-à-dire qu’on va spécifier le trafic autorisé ou interdit entre la zone A et la zone B mais aussi le trafic entre B et A.

ZPF présente plusieurs avantages :

• ZPF ne dépend pas des interfaces
• Nous permet de visualiser notre réseau facilement grâce aux différentes zones.
• Utilise le C3PL (Cisco Common Classification Policy Language) ce qui rend la configuration de notre politique facile à comprendre et à débugger.

ATTENTION : Le traffic au sein d’une même zone n’est pas filtré par nos règles ZPF

Dans cet exemple nous avons 2 zones, une qui définit l’intérieur de notre réseau et l’autre l’extérieur du réseau.

Voici un exemple un peu plus complexe.

Les actions de ZPF:

Lors de l’analyse du trafic, ZPF peut appliquer 3 actions :

• Inspect (inspecter le paquet)
• Drop (supprimer le paquet)
• Pass (autoriser le paquet)

Configurer ZPF

La configuration de ZPF se fait en plusieurs étapes :

• Création des zones.
• Création d’une class-map.
• Création d’une policy-map.
• Création des zones paire.
• Affecter les interfaces à une zone.

Création des zones

Pour les besoins de l’article j’ai réalisé une simulation sous packet tracer. Voilà mon réseau :

Mon réseau est séparé en deux zones, en rouge la zone interne et en bleu la zone externe.
Nous allons donc configurer ZPF sur le router R3 :

R3(config)#zone security INTERNE
R3(config-sec-zone)#exit
R3(config)#zone security EXTERNE
R3(config-sec-zone)#exit

Ces commandes vont nous permettre de créer nos zones, nous avons donc nos deux zones créées.

Création de la class-map

La class-map va nous permettre de spécifier quel trafic nous allons analyser. Nous pouvons analyser le trafic selon le protocole utilisé ( TCP, UDP, ICMP…), mais aussi en fonction d’une ACL.
Pour mon exemple je vais créer une ACL étendue qui va spécifier le trafic sortant de mon réseau interne (192.168.3.0/24) vers tous les autres réseaux.

R3(config)#access-list 101 permit ip 192.168.3.0 0.0.0.255 any

Voilà mon ACL est créée je vais donc pouvoir créer ma class-map :

R3(config)#class-map type inspect INTERNE-EXTERNE-CMAP
R3(config-cmap)#match access-group 101
R3(config-cmap)#match protocol ftp

Ces commandes vont me permettrent de créer ma class-map nommer INTERNE-EXTERNE-CMAP et spécifier qu’il faut analyser le trafic correspondant à mon ACL précédemment créée et le trafic correspondant au protocole ftp.
Voilà notre class-map est prête, nous pouvons bien sûr en créer d’autre pour spécifier d’autres types de trafic.

Création de la policy-map

Nous allons maintenant créer notre policy-map qui va contenir notre class-map et préciser quelle action appliquer à chaque class-map.

R3(config)#policy-map type inspect INTERNE-EXTERNE-PMAP
R3(config-pmap)#class INTERNE-EXTERNE-CMAP
R3(config-pmap-c)#inspect

Ces commandes nous permettent de créer notre policy-map nommer INTERNE-EXTERNE-PMAP, et qui va définir l’action inspect pour notre class-map précédemment créer (nous pouvons bien sûr utiliser une autre des 3 actions possibles).

Création de la zone paire

Nous allons créer une zone-pair qui va nous permettre de définir une zone source et une zone de destination sur lequel nous allons appliquer notre policy-map.

R3(config)#zone-pair security INTERNE-2-EXTERNE source INTERNE destination EXTERNE
R3(config-sec-zone-pair)#service-policy type inspect INTERNE-EXTERNE-PMAP

Ces commandes nous permettent de créer une zone paire nommer INTERNE-2-EXTERNE qui a pour zone source INTERNE et destination EXTERNE c’est-à-dire que cette zone-pair spécifie la politique à appliquer pour le trafic circulant de la zone INTERNE vers la zone EXTERNE, ce trafic sera alors soumis aux politiques définies dans notre policy-map.

Affectation des interfaces a une zone

Nous allons maintenant voir notre dernière étape qui consiste à affecter nos interfaces à une zone.

R3(config)#interface fastEthernet 0/1
R3(config-if)#zone-member security INTERNE
R3(config)#interface se0/0/1
R3(config-if)#zone-member security EXTERNE

Ces commandes nous permettent d’affecter l’interface fastEthernet 0/1 à la zone INTERNE et l’interface se0/0/1 à la zone EXTERNE.
Voilà notre configuration de ZPF est fonctionnelle.

Conclusion

Cet article se termine et nous avons vu ce qu’est ZPF et comment configurer ZPF sur nos équipements Cisco. Cette nouvelle manière de filtrer nos communications et avantageuse dans la mesure où nous n’avons plus à segmenter notre réseau selon des interfaces physiques mais selon un raisonnement logique basées sur des zones. Dans ce cas, uniquement le traffic ayant pour source INTERNE et pour destination EXTERNE ont été traité mais n’oubliez pas créer une autre zone-pair pour autoriser le traffic EXTERNE à revenir vers le traffic INTERNE.
Avez-vous des questions? Utilisez-vous d’autres manières de filtrer vos communications ?

Après l’annonce d’Apple, la Tunisie doit trouver en urgence un plan de passage à l’IPv6-[sourceTHD.tn]

Le 4 mai 2016, Apple a annoncé qu’à partir du 1er juin 2016, les applications développées pour figurer dans l’App Store doivent être fonctionnelles nativement sur l’IPv6 et non l’IPv4.

Dans cette note diffusée aux développeurs, Apple invite donc les ingénieurs qui ont développé des applis pour l’iOS avec support natif de l’IPv4, à recoder leur produit afin de le rendre compatible avec l’IPv6. 

Ceci en réalité n’est qu’un rappel de la part de la firme de Cupertino au monde des développeurs d’applis puisque lors du Worldwide Developers Conference (WWDC) 2015, Apple a déjà annoncé qu’à partir de 1er juin de la même année, les applications doivent supporter les deux réseaux. Ce qui change donc pour cette année, est que Apple ne va plus tolérer la présence d’applications fonctionnelles uniquement sur l’IPv4 sur son Store.

Pour les non initiés, l’IPv4 est une adresse numérique d’une machine connectée à un réseau comme Internet (l’adresse 192.168.1.1 utilisée généralement pour les modems ADSL est une adresse IPv4). Mais avec la multiplication des services/machins connectées, la quantité des IPv4 disponibles dans le monde ne cessent de se réduire. Aux Etats Unis, par exemple, il n’y a plus d’IPv4 disponibles ce qui causera de sérieux problème de connexions aux abonnés qui peuvent se voir refuser l’accès à Internet par manque d’IPv4 libre sur le réseau. 

Voyant ce problème venir, un nouveau réseau a alors été mis en place qui se base sur l’IPv6. Cette IP est composée de 28 caractères (des chiffres et des lettres). Les possibles combinaisons sont pratiquement illimitées avec ce type de format, il est donc pratiquement impossible (dans le futur moyen du moins) d’arriver à saturation. 

Si dans le monde, surtout les pays développés, le passage à l’IPv6 est une urgence absolue, en Afrique et en Tunisie plus particulièrement, le stock d’IPv4 n’a pas encore était épuisé. Certes, il y a toujours un risque d’avoir un monde à deux vitesses (celui des pays développés en IPv6 contre celui de l’IPv4) vu qu’ils ne communiqueront pas par le même type de langage, mais le passage de la Tunisie à l’IPv6 deviendra tôt ou tard une fatalité.

D’autant plus que Apple travaillera, certainement, sur un moyen de pression en mettant en avant et gratuitement les applications fonctionnant seulement sur l’IPv6. On s’attendra également à ce que Google suive la même démarche surtout que la firme de Mountain View a mis en ligne deux services de promotion de l’IPv6 

Contactant les opérateurs télécoms sur leur capacité à passer au tout IPv6, Tunisie Telecom, ooredoo et Orange ont tous affirmé que leur réseau est dores et déjà prêt pour l’IPv6. D’autant plus que la majorité des Smartphones supportent ce type de réseau. Mais s’il y a un problème qui se posera, ça sera plutôt du côté des connexions filaires. En effet, beaucoup des modems et routeurs déjà commercialisés sur le marché (notamment chez les entreprises) ne supportent pas l’IPv6. Pire encore avec les administrations où le matériel de connexion est vétuste.

Du côté du ministère des TIC et de l’Economie numérique, la réaction à l’annonce d’Apple était plutôt mitigée, quoi que raisonnable. En effet, d’après le ministère, il est difficile que Apple oblige les applis sur iOS à supporter uniquement l’IPv6 dans les mois à venir. «Exclure les connexions IPv4 est en effet très dangereux car il n’y a que 12% seulement des connexions dans le monde qui se font en IPv6», nous répond-t-on. «Ceci veut-il dire que nous devons croiser les bras ? Absolument pas. Il est grand temps que le ministère décide d’un plan national de transition vers l’IPv6 avant la fin de l’année».

Notons qu’il existe une commission chargée de ce plan chapeautée par le ministre des TIC Noomene Fehri. Mais ses travaux sont au ralenti depuis une année.

Gestion centralisée de points d'accès cisco -Cisco Wireless LAN controller 2504

I- Introduction

Les points d'accès peuvent être gérés de manière centralisée afin de profiter des différents services déjà décrits précédemment. Ces points d'accès intègrent alors un IOS spécifique appelé "client léger". La procédure de restauration des points d'accès en client léger et surtout la procédure inverse de restauration des points d'accès en client lourd est délicate. Aussi, afin de ne pas mettre en panne les points d'accès côtoyés pendant toutes les manipulations précédentes, vous disposez d'un point d'accès supplémentaire, configuré en client léger. Ce point d'accès est accompagné d'un contrôleur Cisco Wireless Lan Controller 2504 .Les points d'accès peuvent être gérés de manière centralisée afin de profiter des différents services déjà décrits précédemment. Ces points d'accès intègrent alors un IOS spécifique appelé "client léger". La procédure de restauration des points d'accès en client léger et surtout la procédure inverse de restauration des points d'accès en client lourd est délicate. Aussi, afin de ne pas mettre en panne les points d'accès côtoyés pendant toutes les manipulations précédentes, vous disposez d'un point d'accès supplémentaire, configuré en client léger et nommé "LAP0x". Ce point d'accès est accompagné d'un contrôleur Cisco Wireless Lan Controller 2504 

Dans le cas d'un déploiement, le ou les contrôleurs sont interconnectés à un commutateur de distribution (encore appelé cœur), qui interconnecte un ou plusieurs commutateurs de niveau 2 ou 3 (commutateurs d'accès), sur lesquelles sont connectés les points d'accès légers (Lightweight Access-Point ou LAP). Les commutateurs d'accès permettent généralement de fournir une alimentation Poe aux point d'accès.

Pour des raisons évidentes de simplification de manipulation, vous connecterez directement le LAP0x sur un port du WLC0x qui rempliront la fonction PoE (les deux ports n°3 et n°4 sur les quatre sont en effet spécifiques PoE). Les principes étudiés n'en demeurent pas moins identiques.

Note : Si vous devez vous connecter sur un AP en console, il vous est rappelé les identifiants/mot-de-passe par défaut cisco/Cisco.

II- Manipulation : Préparation au démarrage du contrôleur WiFi

Dans un premier temps, connectez le poste de travail Client n°1 au port console du boitier WLC afin d'effectuer la configuration initiale en commande en ligne. Puis connectez sur le port Ethernet n°2 du boitier WLC le même poste de travail avec un câble réseau droit afin d'y accéder par l'interface Web (Attention, le numéro du port est spécifique). Le LAP ne sera connecté qu'ultérieurement sur l'un des ports PoE. Cette étape de branchement de câbles doit être validée par l'enseignant avant tout branchement d'alimentation du boitier WLC.

III-Manipulation : Remise en configuration usine du contrôleur WLC

Bien que cette étape puisse s'effectuer par l'interface Web à l'adresse 10.4.108.1 par défaut, nous privilégions un redémarrage par ligne de commande CLI. Cette étape permet d'obtenir une configuration vierge et lancer par la suite l'utilitaire d'installation. Afin de démarrer l'utilitaire d'installation en ligne de commande, il est nécessaire de réinitialiser le contrôleur en tapant la commande « (Cisco Controller)>reset system ». Dans le cas où vous n'auriez pas la main sur la console, il faut redémarrer le contrôleur et passer à l'étape "Recover-Config". Le système redémarre alors à votre demande puis boot sur l'image active.

Au bout d'une vingtaine de secondes, une invitation apparait afin que vous puissiez renseigner le compte de première connexion "Recover-Config" (en précisant les majuscules !), ceci afin que le système redémarre à nouveau et présente l'utilitaire de première configuration. Cette procédure est peut être fastidieuse mais nécessaire pour partir sur des bases de configuration saines.

IV-Manipulation : Configuration initiale du contrôleur WLC : utilitaire d'installation

A l’aide de la session Putty existante, rester connecté sur le contrôleur WLC. Attention, l’IOS léger est limité, vous ne retrouverez pas toutes les commandes habituelles. Dans un premier temps, il faudra obligatoirement répondre aux questions de l'utilitaire d’installation. Lors du dernier redémarrage suite au « Recover-Config », le contrôleur WLC vous accueille avec le Cisco Wizard Configuration Tool.

On donnera obligatoirement admin/P@ssw0rd comme login/mot de passe (attention : c’est un zéro et non la lettre 0 majuscule). Les valeurs proposées par défaut sont écrites entre crochet en MAJUSCULES. A une question [yes][NO], la réponse par défaut est "NO" si l’on appuie directement sur la touche « entrée ». Donnez les réponses comme indiquée dans les captures d'écran ci-après.

Welcome to the Cisco Wizard Configuration Tool

Use the '-' character to backup

Would you like to terminate autoinstall? [yes]: yes

System Name [Cisco_a8:3e:40] (31 characters max):MyWLCXè où X est votre numéro de paillasse

Enter Administrative User Name (24 characters max): admin

Enter Administrative Password (24 characters max): ***** è P@ssw0rd

Re-enter Administrative Password                 : ***** è P@ssw0rd

Enable Link Aggregation (LAG) [yes][NO]: NO ènous ferons une configuration à simple attachement

Management Interface IP Address: 10.4.108.1

Management Interface Netmask: 255.255.255.0

Management Interface Default Router: 10.4.108.254

Management Interface VLAN Identifier (0 = untagged): 0

Management Interface Port Num [1 to 4]: 2 è important de le faire sur le port 2 !!!

Management Interface DHCP Server IP Address: 10.4.108.1 è on verra peut-être à le modifier plus tard...

Virtual Gateway IP Address: 1.1.1.1

Multicast IP Address: 239.1.1.1è on verra peut-être à le modifier plus tard...

Mobility/RF Group Name: MobGrpNameXè où X est votre numéro de paillasse

Network Name (SSID): mySSIDX è où X est votre numéro de paillasse

Configure DHCP Bridging Mode [YES][NO]:

Allow Static IP Addresses [YES][NO]:

Configure a RADIUS Server now? [YES][no]: no

Warning! The default WLAN security policy requires a RADIUS server.

Please see documentation for more details.

Enter Country Code list (enter 'help' for a list of countries) [US]: FR

è on fera du 802.11a/b/g

Enable 802.11b Network [YES][no]: no

Enable 802.11a Network [YES][no]: yes

Enable 802.11g Network [YES][no]: no

è le AutoRF permet de choisir automatiquement le canal le mieux adapté

Enable Auto-RF [YES][no]: yes

Configure a NTP server now? [YES][no]: noè on verra peut-être à le modifier plus tard...

Configure the system time now? [YES][no]: no

Configuration correct? If yes, system will save it and reset. [yes][NO]: yes

Cleaning up DHCP server configuration

Configuration saved!

Resetting system with new configuration...

 

La configuration initiale terminée, le contrôleur redémarre une dernière fois.

V- Manipulation : Configuration du contrôleur WLC par l'interface Web

            Une fois le contrôleur en séquence de reboot, vérifiez que poste de travail Client n°1 soit bien connecté sur le port n°2 du contrôleur WLC. Configurez les paramètres IP de la carte filaire avec l'adresse 10.4.108.123/24) et lancez le navigateur Internet Explorer (et pas un autre navigateur) à l'adresse du contrôleur WLC via le protocole sécurisé https://. Durant les différentes étapes de la manipulation,  n'oubliez pas de cliquer systématiquement sur « Save Configuration » en haut à droite après avoir modifier vos configurations.

Une fenêtre d'accueil vous demande par la touche "login" de vous identifier. Renseignez le compte "admin/P@ssw0rd" préalablement défini. Le panneau principal d'accueil du contrôleur WLC est alors disponible.

VI- Manipulation : Enregistrement d'un LAP sur le contrôleur : utilisation du DHCP !

Afin que les LAP découvrent automatiquement leur contrôleur et s’y « accrochent », il y a plusieurs possibilités détaillées dans le guide d’installation et le fichier lap-registration.pdf. La plupart des modes de découverte automatique nécessite de paramétrer l’option 43 renvoyée dans le bail DHCP ou renseigner un nom particulier (CISCO−LWAPP−CONTROLLER.localdomain) correspondant à l’adresse IP du contrôleur dans le DNS. C’est un de ces modes de fonctionnement qu’il faudra déployer en entreprise. Deux ou trois options via DHCP Server s’offrent à vous :

-   Créer un serveur DHCP sur un routeur

-   Créer un serveur DHCP sur une machine Windows2003 Server

-   Créer un serveur DHCP sur une machine Linux

… ou se connecter en mode console sur chacun des LAP afin de lui renseigner les coordonnées de son contrôleur, ce qui devient vite fastidieux. Une dernière solution possible, que nous allons adopter, est de faire gérer le DHCP servant pour les bornes par le contrôleur lui-même.

Les LAP doivent récupérer une adresse IP (et options DHCP spécifiques indiquant l’emplacement du contrôleur par exemple) pour ensuite dialoguer avec ce contrôleur. Dans la manipulation, le contrôleur lui-même sera serveur DHCP (c’est qui avait été renseigné dans le wizard précédent) ; il faut donc créer un pool d'adresses dans la définition de ce serveur pour les LAP dans un premier temps, puis un second pool d'adresses ultérieurement qui sera utile pour les clients WiFi désirant se connecter aux LAP. 

Définissez le pool d'adresses IP de .100 à .110 en sélectionnant le menu CONTROLLER et le sous-menu "Internal DHCP Server / DHCP Scope" puis en cliquant sur le bouton "New..."

N'oubliez pas validez votre configuration en cliquant sur le bouton "Apply" (enregistrement dans la RAM du contrôleur) puis "Save Configuration" (enregistrement dans la NVRAM). Dans le menu CONTROLLER et le sous-menu "Interfaces", vérifiez pour l'interface « Management » que son adresse IP est bien 10.4.108.1 (configurée initialement) dans le chapitre "DHCP Information".

VII-Manipulation : Connexion d'un point d'accès léger au contrôleur WLC

Il existe un seul type de matériel AP1242 mais, selon la version d’IOS chargée au boot, celui-ci se comporte en mode « Autonomous » ou en mode « LightWeight ».

Seuls les AP de type LightWeight, plus communément appelés LAP, sont pris en charge par les contrôleurs centralisés.

La commande « show version » vous indiquera l’image système pour déterminer le type d’AP sur lequel vous êtes connecté :

System image file is "flash:/c1240-rcvk9w8-mx.124-25e.JAP/c1240-rcvk9w8-mx.124-25e.JA"

• w7è indique un AP en mode Autonomous (non géré par le WMC)
• w8 è indique un AP en mode LightWeight (à connecter à un WLC)

            ATTENTION ATTENTION ATTENTION : les points d'accès Cisco 1242 que vous allez manipuler proviennent d'achats réalisés dans différents pays. Pour des questions de régulation, l'éditeur différencie ces points d'accès par la présence d'un code pays dont l'objectif ests de faire correspondre l'utilisation des canaux à la règlementation en vigueur dans le pays. Selon la référence stipulée au dos du point d'accès, il est possible de connaitre sa provenance (http://www.cisco.com/c/en/us/products/collateral/wireless/aironet-1300series/product_data_sheet0900aecd80537b6a.html# wp9005314). Par exemple, les références suivantes :

- AIR-LAP1242AG-E-K9  de France mais aussi la Finlande, l'Allemagne, le Kennya, ...

- AIR-LAP1242AG-N-K9  de Nouvelle-Zélande mais aussi, l'Inde, Hong Kong, ...

Selon ce code, les LAP peuvent s’accrocher au contrôleur qui sait les gérer. Il faut donc autoriser tous ces "country code" dans le menu « WIRELESS » et le sous-menu « Country » comme ceci :

Afin de changer les codes de pays, il faudra tout d’abord désactiver les radios par le menu « WIRELESS », sous-menu « Access Points - Radios - 802.11a/n/ac - Network » puis décocher "802.11a Network Status : enabled". Mêmes éléments pour 802.11b/g/n. Il est alors possible de changer les codes pays puis remettre les radios en recochant les cases sans oublier de sauvegarder la configuration par le menu « Save configuration » tout en haut à droite de la fenêtre.

Sans l’activation de ces « country codes », les LAP ne pourront pas se connecter au contrôleur WLC et présenteront sur leur console un message comme celui-ci :

*Oct  2 02:30:39.427: %CAPWAP-3-ERRORLOG: Invalid event 10 & state 5 combination.

*Oct  2 02:30:39.427: %CAPWAP-3-ERRORLOG: CAPWAP SM handler: Failed to process message type 10 state 5.

*Oct  2 02:30:39.427: %CAPWAP-3-ERRORLOG: Failed to handle capwap control message from controller

*Oct  2 02:30:39.427: %CAPWAP-3-ERRORLOG: Failed to process encrypted capwap packet from 10.4.108.1

ATTENTION ATTENTION ATTENTION : lorsqu'un point d'accès a déjà été accroché à un contrôleur WLC, il essaiera à chaque redémarrage de le retrouver car il en garde une trace "indélébile" quelque part dans sa NVRAM. Ainsi, il essayera systématiquement de trouver l'ancien contrôleur au mépris d'en rechercher un nouveau. Cette situation est pénible pour une nouvelle configuration et une alternative, non documentée mais à garder dans son cookbook, permet d'effacer toute la configuration d'un LAP :

test capwap erase

clear capwap private-config

delete flash:private-config

delete flash:private-multiple-fs

reload

Dans le cas de notre manipulation et afin d'éviter des effacement de mémoire flash: pouvant engendrer la parte de l'IOS léger qui a été installé pour l'occasion, les LAP est les contrôleurs WLC ont tous été testés par couple, un LAP ayant été accroché par un WLC spécifique. Aussi, pensez à travailler avec les équipements étiquetés de même numéro et ainsi bien associer votre LAP0x à votre WLC0x dans la même boite de conditionnement sur la paillasse.

VIII-Manipulation : Interconnexion d'un premier point d'accès léger LAP

            Connectez un LAP sur l'un des deux ports PoE du contrôleur WLC au moyen d'un câble réseau droit et vérifiez que la led du point d'accès clignote en vert et/ou en rouge. Branchez le câble conseole du poste de travail n°1 sur le point d'accès afin de vérifier qu'il démarre bien sa séquence d'amorçage et observer les messages indiquant qu'il a bien trouvé son contrôleur, téléchargeant éventuellement une mise à jour. Par l'interface graphique du WLC, visualisez les LAP déjà connectés au contrôleur (menu « WIRELESS », sous-menu « Access Points - All APs »).

Si le point d'accès connecté n’apparait pas dans la liste des LAP, regardez via son port console s’il récupère bien une adresse IP et se connecte au contrôleur pour ultérieurement le repérer dans les points d'accès rattachés au contrôleur. Si le message d'erreur suivant s'affiche :

*Mar  1 00:03:09.270: %CAPWAP-5-DHCP_RENEW: Could not discover WLC using DHCP IP. Renewing DHCP IP.

*Mar  1 00:03:19.274: %CAPWAP-3-ERRORLOG: Not sending discovery request AP does not have an Ip !!

Il y a donc un souci avec la configuration et il faut vérifier que le LAP est bien en mode DHCP puis le redémarrer de manière matérielle (débrancher et rebrancher l’alimentation) ou logicielle par un "reload" via le port console.

Dans le cadre d’un déploiement de terrain, il suffirait de relier le port 2 du WLC non pas à un poste de travail mais à un commutateur de distribution qui propagerait ce VLAN dans tous les commutateurs d'accès de l’entreprise et sur lesquels seraient connectés les LAP : ce serait des connexions LWAPP/CAPWAP de niveau 2 car WLC et LAP sont sur le même VLAN. On peut également déployer une variante de niveau 3 : les commutateurs/routeurs relaient le trafic DHCP dans les différents VLAN où sont déposés les LAP. Leurs baux indiquent au LAP l’adresse IP du contrôleur vers lequel les LAP vont être routés et monter leur tunnel LWAPP/CAPWAP qui va se terminer dans le contrôleur.

IX-Manipulation : Autorisation du management du contrôleur par WiFi

            Cette manipulation n'est pas conseillée en production, sauf cas particulier, pour des raisons évidentes de sécurité d'accès. Cependant, afin d'obtenir plus de confort d'accès lors de la manipulation, il est possible de configurer le contrôleur depuis une connexion sans fil WiFi. Ceci s'effectue par le menu « MANAGEMENT » et sous-menu « Mgmt Via Wireless ». Il faut alors cocher « Enable Controller Management to be accessible from Wireless Clients » et ne pas oublier de valider la configuration en cliquant sur le bouton "Apply" et enregistrer la configuration.

Mise en oeuvre du portail captif

I- Manipulation : Configuration d'un réseau WiFi en mode infrastructure par le WLC

L'objectif de cette manipulation est d'autoriser les postes clients WiFi à se connecter en mode infrastructure sans authentification, ni chiffrement sur le réseau défini par défaut dans le contrôleur. Lors de l'installation du contrôleur par l'utilitaire de configuration, un SSID a été créé de nom "mySSIDx". Configurez ce SSID en mode "authentication open", sans chiffrement et sans diffusion en clair (no guest-mode) afin que se connecte uniquement les clients ayant connaissance de ce réseau hertzien. Pour ce faire, sélectionnez le menu « WLANs » et sous-menu « WLANs » puis sélectionner le SSID et les onglets :

« General »: en radio B/G/A et le trafic wifi sera ponté sur l’interface 2 (management) pour le moment.

- puis  l’onglet « Security » / « Layer 2 » pour « None » dans le champ « Layer 2 Security », correspondant à « aucune authentification ».

Les LAP ajoutés sont de facto membres du groupe d’AP nommé default-group. Par défaut, tous les WLANs IDs/SSIDs sont propagés sur tous les LAP membres de default-group. Il n’y a donc rien à faire pour propager le SSID sur le groupe de point d’accès par défaut contenant le point d’accès raccordé précédemment. Utilisez un poste client WiFi afin de s'associer à unLAP via mySSIDX et connectez-vous avec un navigateur sur le contrôleur en  https://10.4.108.1.

II- Manipulation : Mise en œuvre d'un portail captif pour Hotspot WiFi

Afin de mettre en place un HotSpot (accès plus ou moins gratuit à Internet en Wifi), vous devez pouvoir tracer qui s’est connecté sur votre réseau WLAN (surtout si vous laissez des hackers ou des cybercriminels s’y connecter). Le trafic Wifi va donc sortir par le port n°2 du WLC vers Internet. Il vous faut donc mettre en place un portail captif, qui lorsque quelqu’un se connectera à votre réseau et tentera de surfer sur Internet, devra d’abord s’authentifier sur votre page web portail avant de « sortir ».

Faites en sorte de connecter le port n°2 du contrôleur sur le réseau de la salle donnant accès à Internet et cela sans entrer en conflit avec l'adresse IP d'un autre équipement ! D'autre part, il ne faut pas oublier que ce port n°2 doit toujours être joignable pour la configuration du contrôleur par son port Ethernet.

Afin de créer ce portail, il faut déclarer un nouveau WLAN ID avec pour SSID HotSpot-PAS-Unice associé à un WLAN pour lequel vous aller mettre en place l’option de portail captif en lui associant le niveau de sécurité approprié. Puis vous définirez les utilisateurs par leurs identifiants et mots de passe respectifs. Créez le WLAN ID en passant par le menu « WLAN » et sous-menu « Create New » puis le bouton « Go ».

Cliquez enfin sur « Apply » et vérifiez dans l’écran suivant que le trafic WLAN sera bridgé sur « l’Interface/Interface Group(G) » de « management ». Dans la réalité, on ferait plutôt sortir le trafic par le port n°1 ethernet encore disponible afin de ne pas mélanger trafic opératoire et trafic d’administration. Mais pour simplifier notre manipulation, l’interface de « management » suffira.

Afin que tout le monde puisse se connecter au portail, il est nécessaire dans le menu « WLANs » et l'onglet « General », de laisser l’option « Broadcast SSID » cochée. Dans le menu « WLANs », l'onglet « Security » et le sous-menu « Level 2 », il faut positionner le niveau « Level 2 security » à « NONE » pour autoriser toute le monde à s’associer.

Pour activer le portail captif, cette configuration se passe dans l’onglet « Security » du menu « WLANs » et le sous-menu « Level3 » où on demande une authentification web par « Web Policy ». Enfin pour définir les comptes utilisateurs, sélectionnez le menu « SECURITY » et le sous-menu « AAA - Local Net Users ». Créez les comptes maintenant bien connus : "potter" et "bilbon".

Il est maintenat nécessaire de créer un profil d'authentification et pour cela sélectionner le menu « SECURITY » et le sous-menu « Local EAP - Profiles » pour créer un nouveau profil appelé « EAP_for_HotSpot-PAS-Unice » dans lequel il faudra sélectionner le mode "EAP-FAST".

Revenons dans le troisième sous-onglet « AAA » de l’onglet « Security » du menu « WLANs » car il faut activer le « Local EAP authentication ». Nous n’allons pas utiliser un serveur RADIUS externe, comme il faudrait le faire dans un cas réel, mais plutôt le serveur interne au contrôleur WLC qui peut contenir 2048 utilisateurs tout de même, dans différents profils.

Sélectionnez le profil précédemment créé pour « EAP Profile Name ».

Validez votre configuration par « Apply » et sauvegardez votre configuration. Utilisez des clients WiFi quelconques afin de tenter de vous connecter à votre réseau HotSpot-PAS-Unice. Essayez de vous connecter à http://kheops.unice.fr. Si réclamé lors de la connexion, renseignez le login et mot de passe des comptes précédemment créés. Attention, le certificat auto-signé du serveur https embarqué dans le WLC pour l’authentification par portail captif ne sera pas reconnu par votre navigateur !