Secours par NAS

Un NAS c’est quoi ?

Le NAS (Network Access Server) est une sorte de PoP (Point Of Presence ou Point d’accès) un peu spécifique. Il a pour fonction première de fournir des méthodes d’accès les plus variées possibles sur un réseau.

Ainsi un NAS peut proposer des accès téléphoniques classiques (dits RTC), des accès de type RNIS (pour notre cas c’est obligatoire !), des accès en mode synchrone ou asynchrone, et voir des accès de type GSM ou UMTS pourquoi pas !

Plus le NAS permettra des accès variés et en nombre plus il sera cher ! Mais ce n’est ici pas notre problème ! En effet, je n’ai pas l’intention de vous inviter à installer un NAS « personnel » sur votre réseau, c’est totalement désuet de nos jours (dans ma longue carrière je ne l’ai vu qu’une seule fois !), c’est cher et finalement guère moins compliqué (sur les aspects dimensionnements) que ce que nous avons vu précédemment.

Nous allons donc plutôt nous orienter vers l’utilisation des NAS que proposent la majorité des opérateurs dans le cadre de leurs offres de réseaux.

Les avantages du NAS opérateur

Les NAS fournis par les opérateurs ont vraiment de gros avantages :

Ils sont placés en cœur de réseau : ceci implique que tout équipement qui établi une connexion sur le NAS est de ce fait directement connecté au backbone. Dans le cas d’un secours RNIS, le site en mode secours sera donc abouté au réseau de la même façon que lorsqu’il est connecté en mode nominal sauf qu’au lieu d’être à l’extrémité d’une liaison permanente il est connecté sur une liaison commutée (RNIS). Ceci supprime les soucis de transfert de trafic identifiés dans le cas d’un secours bout en bout (le site accueillant la connexion de secours devant assurer le renvoi du trafic du site secouru dans le réseau via son propre raccordement nominal).

Le dimensionnement des accès n’est plus de votre ressort : vous n’avez plus à définir un potentiel d’usage en mode secours pour dimensionner le nombre d’accès RNIS à mettre en place. C’est à l’opérateur de surveiller les taux d’utilisation et de mettre en œuvre les upgrades nécessaires. D’ailleurs si l’opérateur est sérieux il aura plus d’un NAS ! Il pourra donc s’arranger pour répartir la charge ! Pour votre cas, vous devez donc juste estimer le débit de secours nécessaire pour votre site (ou pour chaque site de votre réseau).

Ils sont généralement secourus : comme indiqué précédemment, tout opérateur sérieux aura plus d’un NAS sur son réseau backbone. Il pourra donc s’assurer d’un re-routage des demandes de connexion si le NAS appelé ne répond pas (hors service ou surcharge). Pour cela il utilisera les fonctionnalités du Réseau Intelligent (RI). Essayons d’expliquer simplement ce qu’est le RI !

Le RI est en fait un ensemble de services évolués construits sur la base des fonctionnalités offertes par le réseau de signalisation RNIS. Ce réseau de signalisation est distinct du réseau de commutation lui-même, on l’appelle le réseau « sémaphore », il utilise la normalisation CCITT N° 7 (pour les curieux ou érudits : on parle aussi bien de réseau « sémaphore » que de réseau « CCITT N° 7 » ! C’est la même chose !). En fait, les canaux B d’un accès RNIS sont connectés au réseau de commutation, et les canaux D sont connectés au réseau « sémaphore ». C’est le réseau sémaphore qui véhicule toute la signalisation nécessaire à l’établissement, la gestion et la libération d’une communication sur canaux B. Avant chaque établissement de connexion il y a donc au préalable des échanges de signalisation sur canal D entre les deux partenaires. Ces échanges de signalisation ne sont pas directs, ils sont relayés par le réseau sémaphore. Lorsque A (site à secourir) souhaite établir une communication vers B (NAS de secours), il transmet sur canal D la demande de connexion en indiquant le débit souhaité (défini le nombre de canaux B à établir), le type de service (il est possible en RNIS d’indiquer le type de service que l’on souhaite véhiculer sur les canaux B. Il existe les services Voix ou Data), le numéro appelé et une foule d’autres petites informations pas forcément captivantes pour nous ici ! Le réseau sémaphore va relayer ses informations vers B. Si l’équipement connecté à B n’est pas disponible (hors service ou surchargé), le point d’accès sémaphore de raccordement le saura. Le titulaire du raccordement pourra avoir souscrit à des différentes options comme « Re-routage sur indisponibilités ». L’opérateur RNIS aura dans ce cas programmé dans un le réseau sémaphore une redirection de l’appel vers un autre numéro en cas d’indisponibilité de B. L’appel de A sera donc envoyé ainsi vers un autre NAS ! Le secours est ainsi assuré de manière totalement transparente pour A !

Ils sont répartis géographiquement : si le backbone opérateur est étendu (dimension nationale ou internationale) il est probable que les NAS soient répartis sur l’ensemble du territoire couvert. Ceci permet :

• d’éviter que tous les NAS soient HS en même temps par exemple en cas de coupure d’électricité prolongée sur une zone géographique,
• d’équilibrer les charges d’entrées dans le backbone en évitant des raccordements « hauts débits » sur un nombre restreint de point d’accès au backbone. En effet, si le PoP de raccordement des NAS est hors service ceci impacte fortement les capacités d’accès au backbone.
• de diminuer les distances de communication entre les sites appelants et les NAS. Plus le NAS est prêt moins la communication est chère ! Ainsi si votre site est à New Yrok il est préférable qu’il appelle un NAS à Washington plutôt qu’à Paris ! De la même manière, le site de Marseille appellera plutôt le NAS de Marseille (s’il y en a un) plutôt que celui de Paris !

Petite remarque : Bien souvent l’opérateur n’aura qu’un seul et même numéro d’appel pour ses différents NAS d’un même pays. Donc tous les routeurs RNIS français (par exemple) de votre réseau auront le même numéro d’appel vers le NAS, que le site soit à Marseille ou à Paris. C’est encore une fois le RI qui assurera le reroutage vers le NAS le plus proche du site appelant. On appelle cela le routage géographique ! Ha ! Il est fameux ce RI !

La tarification est plus attractive : au final, une solution de secours par NAS présentera une tarification beaucoup plus attractive qu’un secours bout en bout personnalisé. Ceci en raison des principaux points suivants :

• mutualisation : les NAS opérateurs sont mutualisés pour tous les clients de l’opérateur. Le coût d’exploitation est donc divisé. De plus bien souvent ces NAS ne sont absolument pas dédiés à la fonctionnalités de secours RNIS. Les mêmes équipements permettront d’assurer la connexion de nomades (utilisateur avec son PC portable qui se promène dans la nature et veut quand même consulter ses mails !) par exemple ! Ceci renforce le partage du coût de possession.
• localisation : nous l’avons vu précédemment, plus l’opérateur a de NAS plus les distances de communication sont courtes et donc le coût de la communication est bas.
• forfaitisation : et tous ces éléments concourent au nirvana du DAF ! La forfaitisation ! En effet, l’opérateur en regard de ses implantations nombreuses et de la mutualisation de ses infrastructures pourra vous proposer un forfait mensuel pour le secours. Ce forfait incluera généralement : l’abonnement RNIS local du site à secourir, l’équipement du routeur avec une carte RNIS, les coûts de communication éventuels avec le NAS si le site passe en secours et l’accès au réseau par le NAS (ressources nécessaires sur le NAS). Le prix sera souvent variable en fonction du débit de secours souhaité (64 Kbps à 512 Kbps par exemple).

Le secours par NAS (opérateur) permet donc de s’affranchir de la majorité des points d’imperfections soulevés dans l’option de secours bout en bout. Seul reste le problème d’un débit de secours assez limité lié à la technologie RNIS. A noter de plus que dans la théorie avec un secours bout en bout vous pourriez atteindre un débit de 1920 Kbps (30 canaux B cumulés) ce qu’aucun opérateur ne vous proposera sur technologie NAS. Généralement le débit maximum de secours proposé sur NAS opérateur est de 512 Kbps.

Architecture technique du secours par NAS

L’approche est franchement similaire à celle du secours bout en bout. En effet, après tout un secours par NAS c’est un secours RNIS bout en bout avec à une extrémité un routeur et à l’autre un NAS ! Les notions de détection d’indisponibilité, d’établissement de communication et de libération de la connexion sont les mêmes. Toutefois, en regard du caractère « mutualisé » du NAS il sera nécessaire de mettre en œuvre quelques artifices de sécurisation supplémentaires.

L’identification de l’utilisateur

Nous avons vu précédemment que l’identification d’un appelant pouvait se faire sur deux niveaux :

• identification du numéro appelant
• transmission d’une couple identifiant / mot de passe lors de l’établissement de la connexion PPP

Pour ce deuxième point il faut donc que le NAS qui accueille la connexion ait une table des identifiants / Mot de passe de chaque utilisateur (si nomade) ou routeur (si secours RNIS) pour vérifier ces identifications.

On pourrait envisager une table locale mémorisée dans le NAS lui-même. Charge à l’opérateur de mettre à jour cette table à chaque création de user. Mais nous avons vu que le RI permettait de rerouter l’appelant vers d’autres NAS si celui le plus proche est indisponible ou surchargé. On ne peut donc pas anticiper le NAS de connexion ! Ceci implique qu’il faudrait entrer les identifications dans tous les NAS !

L’opérateur est plutôt pragmatique … Il va donc préférer utiliser une base centralisée qui sera consultée par chaque NAS à chaque demande de connexion. La solution d’identification la plus connue dans ce type d’usage est la base RADIUS (Remote Authentication Dial In User Service). Cette technologie permet de mettre en œuvre des fonctionnalités d’identification très évoluée avec des volumétries pharamineuses, mais ce n’est pas l’objet de notre cours. Retenons simplement que ces bases sont implémentées sur des serveurs dédiés que l’on appelle couramment : Serveur Radius.

Par contre, si ce serveur (ou ces serveurs lorsqu’on pense à installer des serveurs de secours) doit être contacté par n’importe quel NAS, il faut que chacun d’entre-eux puisse le joindre à travers un réseau. Il faut donc installer les NAS en réseau avec le serveur Radius.

L’identification du service

Les NAS sont des équipements coûteux qu’il est indiqué d’optimiser. Un opérateur envisagera très certainement d’utiliser ces équipements pour divers types d’utilisation. Nous avons évoqué tout à l’heure la possibilité de connecter des nomades en plus de l’utilisation pour les backup RNIS. Mais l’opérateur pourra éventuellement les utiliser pour des accès à Internet comme pour des accès à un réseau privé type VPN. Pour certains (les plus gros) ils peuvent même « revendre » de la capacité d’accès à d’autres opérateurs plus petits pour leur permettre d’offrir des accès à leur propre réseau.

On pourra alors être confronté à la mise en relation des NAS avec plusieurs bases Radius, chacune gérant l’identification des accès pour un service donné. On pourra dans ce cas utiliser un serveur dit « Proxy Radius » qui procédera à une analyse partielle de l’identifiant afin de relayer la demande d’accès vers le bon Radius.

Le schéma ci-dessus illustre le cas de l’utilisation d’un même NAS pour deux services différents :

• en rouge le cheminement d’une identification pour l’accès d’un routeur à un service de backup RNIS
• en vert le cheminement d’une identification pour l’accès d’un nomade à Internet.
  Les deux connexions empruntent le même NAS. Celui-ci relaie les identifiants reçus par la connexion PPP (rappelez-vous … PAP/CHAP) vers le proxy-radius.

Le proxy-radius analyse l’identifiant transmis pour identifier la base Radius à interroger. Ceci imposera généralement de s’accorder sur un format bien connu pour l’identifiant. Ici nous donnons un exemple d’identifiant structuré en user@service_ID. La partie service_ID permet au proxy Radius d’identifier le Radius vers qui relayer la requête (base de correspondance dans le proxy-radius). Mais ce n’est qu’un exemple … très … réel !

L’accès au service

Nous supposons maintenant que l’autorisation d’accès à chaque service a été donné au nomade ou au routeur par les Radius concernés. L’autorisation a été relayée par le proxy-radius, chaque NAS la reçoit. Que font-ils ?

Le cas simple mais irréel : chaque NAS est connecté à un PoP qui donne accès au service considéré. Le NAS envoie donc tous les paquets IP en provenance de la connexion PPP vers le PoP d’accès au service (réseau privé pour le routeur, Internet pour le nomade). Mais comme nous avons vu que nous ne pouvons pas prédire sur quel NAS se présentera la connexion (routage du RI), ceci suppose que chaque NAS devra être connecté à tous les PoP des différents services ! Ceci complexifie grandement l’architecture et en augmente le coût !

Comme l’indique le schéma ci-dessus, il faudra autant de ports d’entrée sur les PoP qu’il y a de NAS potentiels. Sur les NAS il faudra autant de ports de sortie qu’il y a de PoP de service à atteindre ! Sans compter le coût des liaisons car les PoP ne seront pas forcément co-localisés aux NAS !

La solution apparemment plus simple : intégrer les PoP dans le réseau IP de connexion des NAS, celui-ci supportant déjà les Radius.

Les NAS ont déjà une connexion au réseau de collecte pour l’accès aux Radius (via un PoP généralement co-localisé). Il suffit de connecter les PoP d’accès aux différents services sur ce même réseau et les NAS pourront envoyer les paquets IP dans ce réseau pour qu’ils atteignent les PoP et donc les services souhaités …

Chaîne d’authentification et de connexion

Nous avons précédemment exposé le principe des serveurs Radius et Proxy Radius pour la gestion des authentifications et avons indiqué que le protocole L2TP gére une double authentification.

Pour terminer en beautée sur le secours par NAS, le schéma ci-contre présente le chronogramme d’établissement d’une communication RNIS via NAS.

Un peu plus sur le Radius et sur les LAC/LNS

Le protocole Radius permet d’embarquer la fourniture de nombreux attributs divers. Lorsque le serveur est sollicité par un NAS ou un LNS afin d’authentifier une identification il pourra retourner dans sa réponse des paramètres complémentaires comme :

• L’adresse du serveur DNS (résolution des noms de domaine) que l’utilisateur doit contacter
• L’adresse d’un serveur DHCP (serveur fournissant une adresse IP sur demande)
• L’adresse IP (et le masque !) à affecter au poste demandant la connexion. Ceci permet de gérer en centralisé les adresses à affecter. Il y a deux manières de procéder :
  • Affectation dynamique : le Radius puise dans un pool d’adresse mis à disposition pour les connexions nomades
  • Affectation statique : le Radius a une correspondance précise entre une identification et une adresse IP. Chaque connecté aura donc toujours la même adresse IP. Ceci est pratique pour repèrer les nomades dans un réseau et leur appliquer des limitations d’accès par filtrage IP par exemple.

Un des soucis majeurs de l’opérateur est de pouvoir contrôler le taux d’utilisation du service et le cas échéant facturer l’usage (ceci dépend du type de service souscrit). Le LAC,  le LNS ou le Radius (selon le cas) pourront être interfacé avec un serveur de « ticketting ». A chaque établissement de connexion ils envoient un START et à chaque déconnexion ils émettent un STOP pour un userID donné. Le serveur enregistre ainsi les nombres et durées de communication qui peuvent ensuite être mises en rapport avec une base de facturation. Celle-ci comportera les informations d’abonnement au service relatives au user (type de forfait ou facturation à l’usage, type de communication dans ou hors forfait, etc …). Il sera alors facile de générer une facturation automatique.

Ces bases d’authentification Radius et de « ticketting » pourront être mises à disposition du client via des frontaux http (par exemple) afin de leur offrir un Web d’administration proposant :

• Une interface de création / modification de user (commande d’un nouveau user, modification du mot de passe, gel de l’accès, etc …).
• Une interface de suivi des consommations
• Différents relevés statistiques (consommation d’une flotte par exemple), etc.

On voit donc tous les avantages que l’on peut tirer de ce type d’architecture. Mais bien sûr ceci n’est rentable que dans le cadre d’une volumétrie importante, donc assez peu adaptée à des flottes « personnelles ».

Nous avons tout de même un peu dérivé du sujet initial « Backup par NAS » car beaucoup de ces fonctions ne sont en fait utiles que pour des usages en nomade et non pas en mode routeur de secours.

Exemple de paramètrage d’un routeur

Pour illustrer ce long discours sur les éléments à prendre en compte dans une solution de secours RNIS par NAS, voici en exemple un extrait partiel de paramètrage d’un routeur Cisco. Merci à Laurent (qui se reconnaîtra !) pour cet extrait de configuration !

interface ATM0/0.1 point-to-point<?xml:namespace prefix = o ns = « urn:schemas-microsoft-com:office:office » /> description — EQ_VPN_TDSL LDEF001 vers PE TLS14 ATM2/0/1.51 — bandwidth 1280 ip address 171.20.3.230 255.255.255.252 no snmp trap link-status pvc 8/35 vbr-nrt 1272 1272 1 tx-ring-limit 3 oam-pvc manage 5 oam retry 3 5 1 encapsulation aal5mux ip service-policy input COUNT-IN service-policy output COS-OUT	Ici une interface routeur de type SDSL implémentant ATM en protocole de niveau 2 Les lignes oam définissent la fréquence à laquelle le routeur vérifie l’état « up » de la ligne. => Détection d’indisponibilité du lien
interface BRI1/0 description *** Sec RNIS **SPN PE-LNS** no ip address encapsulation ppp no ip route-cache cef no ip route-cache no ip mroute-cache dialer pool-member 1 isdn switch-type basic-net3 isdn point-to-point-setup no fair-queue no cdp enable ppp multilink   interface BRI1/0 description *** Sec RNIS **SPN PE-LNS** no ip address encapsulation ppp no ip route-cache cef no ip route-cache no ip mroute-cache dialer pool-member 1 isdn switch-type basic-net3 isdn point-to-point-setup no fair-queue no cdp enable ppp multilink	Paramètrage de deux interfaces RNIS pour le secours. Chez Cisco on défini un minimum de paramètrage sur les interfaces « dial » directement. La commande « dialer pool-member » permet de regrouper plusieurs interfaces physiques en un même « pool » d’interfaces. Ceci permet donc d’obtenir une interface virtuelle composée de plusieurs interfaces physiques. Le débit total possible de l’interface virtuelle est donc ici de 256 Kbps (2 accès RNIS soit 4 canaux B).     On notera la commande « ppp multilink » permettant d’implémenter un cumul des connexions PPP pour ne présenter sur les 4 canaux B qu’une seule et même connexion de niveau 2
interface Dialer1 description *-*-*-* Sec RNIS ** SPN PE-LNS – ip unnumbered FastEthernet0/0 encapsulation ppp no logging event link-status dialer pool 1 dialer idle-timeout 108 dialer enable-timeout 5 dialer wait-for-carrier-time 15 dialer string [numéro de NAS à appeler] dialer hold-queue 5 dialer load-threshold 1 either dialer-group 1 no cdp enable ppp chap hostname [userID@clientID] ppp chap password 7 1210171B17181C0A ppp multilink	C’est ici que l’on paramètre réellement la connexion RNIS. La commande « ip unnumbered FastEthernet0/0” indique que l’interface RNIS lorsqu’elle sera active prendra l’adresse IP de l’interface Eth0. C’est une spécificité Cisco qui permet d’éviter d’affecter des IP à des interfaces Dial. Le routeur transfère tout le trafic vers l’Ethernet. Les « dialer enable-timeout, wait for carrier, idle-timeout » définissent les timers d’attente avant connexion, avant déconnexion ou attente de porteuse. On note les paramètrages PPP (encapsulation, multilink, identifiant et mot de passe CHAP). La commande « load-treshold » défini comment et combien de canaux B doivent être ouverts en fonction de la charge. La commande « dialer-group » renvoie aux commandes « dialer pool-member » des interfaces BRI permettant ainsi de définir quelles interfaces BRI sont groupées sous l’interface « dialer 1 ».
access-list 101 remark **** Conditions montee RNIS et maintien de connexion **** access-list 101 deny   udp any eq netbios-ns any access-list 101 deny   udp any eq ntp any eq ntp access-list 101 deny   udp any eq rip any eq rip access-list 101 permit ip any any dialer-list 1 protocol ip list 101	On défini ici la nature du trafic à scanner susceptible d’activer la connexion RNIS. Ici tout trafic IP peut activer l’interface sauf le trafic netbios, ntp et rip. La commande « dialer-list » indique qu’on applique la liste de filtres 101 à l’interface « dialer 1 ».
ip route 0.0.0.0 0.0.0.0 ATM0/0.1     ip route 0.0.0.0 0.0.0.0 Dialer1 250	Ici un extrait de la configuration du routage (en statique ici). On voit que le trafic pour n’importe quelle destination (0.0.0.0 0.0.0.0) est routé sur l’interface nominale ATM0. Sans coût indiqué (coût nul) Par contre la deuxième ligne indique la même chose mais vers l’interface « dialer 1 » avec un coût de 250. Donc tant qu’ATM0 est active Dialer 1 n’est pas utilisée.

En résumé

Nous voici arrivé au terme de ce long chapitre sur le secours RNIS par NAS. Vous aurez remarqué que même sur un sujet aussi simple, on peut en dire long. J’ai souhaité être précis car c’était l’occasion idéale de mettre en lumière la technologie RNIS, les problématiques d’authentification et de sécurité ainsi que certains principes de routage et de dimensionnement.

Mais il est toujours bien de ne retenir que l’essentiel, et je vous propose les ponts suivants :

• le secours RNIS bout en bout ne peut être considéré que comme une solution de repli quand le secours par NAS n’est pas proposable. Il pose des problémes de dimensionnement à grande échelle et accessoirement de maîtrise des coûts.
• le backup par NAS est une solution avant tout « opérateur » et n’a pas beaucoup de sens dans un réseau totalement privé (au sens sans backbone opérateur). Dans le contexte opérateur elle garanti un niveau optimum de disponibilité, de sécurité et une tarification plus attractative (bien qu’ici tout soit relatif !).
• Une solution de secours RNIS nécessite d’implémenter des fonctions :
  • De détection d’indisponibilités des liens nominaux
  • D’authentification des extrémités mises en relation
  • D’optimisation (sélection) du trafic à secourir
  • De gestion du routage (route nominale et secours)
  • De retour à la situation nominale lorsque la route initiale est rétablie.

Le secours RNIS reste tout de même une technologie offrant un débit relativement limité dans une technologie assez couteuse. Nous verrons dans le chapitre suivant que l’avènement de l’ADSL a complétement changé l’approche du secours. Reste à s’affranchir des problèmes d’éligiblités !

Il vous faudra toutefois patienter un peu, car ce chapitre n’est pas encore écrit à ce jour (Juin 2009) !

Page Précédente | Sommaire