Aperçu technique à l'intention des administrateurs de réseau LIVRE BLANC

Transcription

1 Aperçu technique à l'intention des administrateurs de réseau LIVRE BLANC

2 À propos de ce document Le présent aperçu traite de certains détails fonctionnels et techniques liés au VPN mobile NetMotion Mobility XE. Il s adresse particulièrement aux administrateurs de réseaux qui requièrent une étude plus approfondie du fonctionnement de Mobility XE avant de déployer ce système dans leur environnement. NetMotion Mobility XE et sa technologie sont protégés par des brevets et droits d auteur délivrés et en instance aux États-Unis et dans d'autres pays. Aperçu de l'architecture Mobility XE Mobility XE est un VPN mobile logiciel super-scalaire. Avec ses options de haute disponibilité active/active et active/passive, il fonctionne dans une infrastructure de réseau standard, dont routeurs, commutateurs et pare-feu. Le système Mobility XE comporte deux composants principaux : le serveur Mobility et le client Mobility. La communication serveur-client, qui utilise le protocole IMP (Internet Mobility Protocol) et les appels de procédure à distance (RPC), repose sur le protocole UDP (User Datagram Protocol). Serveur Mobility Le serveur Mobility gère les connexions de réseaux sans fil pour les périphériques mobiles. Il réside sur le réseau local d'entreprise, serveur exploitant Windows Server Le serveur Mobility sert de mandataire de transport pour chaque périphérique mobile exploitant le client Mobility. En maintenant le statut de chaque client et en traitant la gestion de sessions complexe, il assure des connexions permanentes aux systèmes hébergeant les applications réseaux. Lorsqu'un périphérique mobile devient injoignable, suspend la session ou passe à un réseau différent, le serveur Mobility préserve la connexion aux applications homologues du client en accusant réception des données et des demandes de mise en file d'attente. Le serveur Mobility gère également les adresses de réseaux pour les périphériques mobiles. Chaque client Mobility reçoit une adresse IP virtuelle sur le réseau câblé, généralement obtenue à partir du protocole DHCP (Dynamic Host Configuration Protocol) ou attribuée à partir de toute une gamme d'adresses réservées à cet effet sur le serveur Mobility. Le serveur Mobility XE peut également attribuer statiquement une adresse IP virtuelle à un périphérique ou utilisateur individuel. Les serveurs multiples Mobility peuvent agir comme groupe de serveurs avec capacités de basculement et d'équilibrage de la charge. Les explications figurant dans le présent document supposent une installation avec un seul serveur Mobility. Les outils et les paramètres du serveur Mobility, destinés aux administrateurs de système, servent à configurer, gérer et dépanner les connexions à distance. Une interface en ligne permet aux administrateurs de système de configurer les paramètres du Mobility XE et de gérer le serveur à partir d'un autre PC sur le réseau. Aperçu technique à l'intention des administrateurs de système 2

3 Client Mobility Le logiciel client Mobility, installé au niveau de l interface du pilote de transport (TDI) sur les plates-formes Microsoft, gère les opérations d indirection et de redirection des appels de réseau d'applications. Lorsqu une application utilise le réseau, les appels TDI sont interceptés, puis les paramètres sont triés et l'appel est transféré pour exécution sur le serveur Mobility. Il fonctionne en transparence avec les fonctionnalités du système d'exploitation pour permettre aux sessions d'applications côté client, de rester actives lorsque le périphérique perd contact avec le réseau. Un périphérique client Mobility est un périphérique mobile standard ou un ordinateur standard fonctionnant sous Windows Vista, Windows XP, Windows XP Tablet, Windows Mobile ou Windows CE. Autre infrastructure Les installations fonctionnant sous Analytics Module requièrent un serveur rapporteur et une base de données rapporteuse. Mobility s'intègre également à des services d'authentification externes. Fonctionnement Deux protocoles : appels de procédure à distance et Internet Mobility Le protocole d'appels de procédure à distance (RPC) et le protocole IMP (Internet Mobility Protocol) Mobility XE constituent l'ossature technologique connectant le serveur Mobility à chaque périphérique mobile. Un appel de procédure à distance permet d'autoriser un processus sur réseau local à appeler une procédure sur un réseau distant. Grâce à Mobility XE, les appels de réseau du client sont envoyés au serveur pour une exécution à distance. Si Mobility fonctionnait au niveau Winsock, ces appels seraient de type Aperçu technique à l'intention des administrateurs de système 3

4 interface ouverte, association, connexion, envoi et réception. Mobility XE agissant au niveau de la TDI, l'équivalent TDI de ces appels correspond à ce qui est envoyé au serveur pour exécution à distance. L'application sur réseau local ignore que l'appel de procédure est exécuté sur un réseau distant. La force de l'approche de type RPC de Mobility XE est de permettre au périphérique mobile de passer hors portée ou de suspendre l'activité sans perdre les sessions actives dans le réseau. Le maintien des sessions ne dépendant pas de la personnalisation ou du remaniement des applications, les applications standard fonctionnent sans modifier l'environnement mobile. Le protocole RPC, encapsulé par le protocole Internet Mobility Protocol (IMP), est lui aussi encapsulé dans UDP. Le protocole IMP compense les différences entre les réseaux câblés et les réseaux moins fiables, en ajustant les tailles de trames et la synchronisation des protocoles pour diminuer le trafic réseau. Ce principe s avère crucial si la bande passante est limitée, s'il y a un délai d'attente important ou si la durée de vie de la batterie pose problème. Mobility XE renforce également la sécurité des données en encryptant tout le trafic entre le serveur Mobility et les clients, et en autorisant uniquement la connexion de périphériques authentifiés au serveur Mobility. Pour plus de renseignements sur la sécurité du Mobility XE, consulter la section Sécurité pour réseaux sans fil. Enregistrement du périphérique Lorsqu'un client Mobility se connecte pour la première fois à un serveur Mobility, le serveur enregistre le numéro d'identification permanent (PID) du périphérique mobile, numéro unique que le client utilisera pour toutes les connexions ultérieures. Cet enregistrement se produit uniquement lors de la première connexion et ne nécessite aucune intervention de la part de l'utilisateur ou de l'administrateur. Le PID est stocké dans le registre du système client ainsi que dans l'entrepôt Mobility (ayant recours au protocole LDAP - Lightweight Directory Access Protocole/Protocole allégé d'accès annuaire). Le serveur Mobility stocke les PID en fonction du nom de l'ordinateur. Tant que le nom de l'ordinateur client reste inchangé, le serveur peut restaurer le PID sur le périphérique client même en cas de perte du registre client. Une telle situation survient notamment lorsque le disque dur du périphérique client est reformaté pour réinstaller le système d'exploitation. Lorsque le client Mobility est réinstallé et connecté, le serveur cherche une correspondance sur le nom du périphérique. S'il trouve une correspondance, le serveur restaurera le même PID sur le périphérique. Connexion de périphériques Pour établir une connexion au serveur Mobility, le client Mobility demande une authentification de l'utilisateur. Si l'authentification réussit, le serveur et le client créent un tunnel VPN sécurisé, utilisable pendant toute la session. Pour authentifier le réseau, le travailleur mobile peut utiliser son justificatif d'identité de connexion Windows standard. Le serveur Mobility authentifie cet Aperçu technique à l'intention des administrateurs de système 4

5 utilisateur par rapport au domaine de l'entreprise à l'aide de NTLMv2 pour une authentification naturelle Microsoft, une authentification RADIUS ou une authentification RSA SecurID. Dans une configuration prévoyant une authentification RADIUS, Mobility XE a recours à un protocole RADIUS PEAP ou EAP-TLS. Ceci permet la prise en charge d'une authentification robuste de l'utilisateur par rapport à une infrastructure à clés publiques (PKI) à l'aide de cartes à puce et / ou de certificats d'utilisateur. (Se reporter à la rubrique Authentification avancée plus bas). Pour un déploiement Microsoft, une liaison à trois voies se produit entre le client et le serveur Mobility : Le client envoie une liste de types d'authentification. Ce paquet comprend le paquet NTLMv2 HELLO. Le serveur répond par une demande d'accès NTLMv2. Le client complète l'authentification en répondant à la demande d'accès. Suite à l'authentification, le serveur et le client échangent des clés publiques ECC (cryptographie à courbe elliptique) et des documents cryptographiques connexes pour échanger les clés Diffie-Hellman. Les clés symétriques, dérivées des clés publiques, ne sont pas transmises. Un tel procédé s'applique à toutes les méthodes d'authentification prises en charge. Adresses IP virtuelles Chaque client Mobility possède une adresse IP virtuelle sur le réseau câblé, obtenue à partir du protocole DHCP ou attribuée à partir d une gamme d'adresses réservées à cet effet sur le serveur Mobility. Des adresses IP virtuelles statiques peuvent de plus être attribuées à des périphériques ou utilisateurs spécifiques. Pour chaque client actif, le serveur Mobility relaie les données dirigées vers l'adresse virtuelle du client à son adresse réelle et actuelle (adresse point de présence POP). Alors que l'adresse POP d'un client Mobility peut changer lorsque le périphérique se déplace d'une zone de couverture à une autre, l'adresse virtuelle demeure constante pendant toute la durée de la session utilisateur. Persistance de session Contrairement aux réseaux VPN IPsec ou VPN SSL, Mobility XE VPN n exige pas d'adresse locale fixe. Le tunnel est maintenu entre le serveur Mobility, possédant une adresse fixe, et le client Mobility, qui peut avoir une adresse POP constamment modifiée. D'un commun accord, le client et le serveur maintiennent le tunnel sécurisé jusqu'à ce qu une extrémité émette un signal de déconnexion. Un tel signal survient notamment lorsque l'utilisateur se déconnecte, lorsque l'administrateur met le périphérique en quarantaine ou en raison de l expiration d'un délai d inactivité du lien configurable. Le tunnel reste disponible et les sessions d'application persistent dans un certain nombre de cas : Suspension d'activité sur le périphérique et reprise ultérieure Changement d'emplacement sur le réseau Aperçu technique à l'intention des administrateurs de système 5

6 Connexion d'un périphérique mobile sur des réseaux lents, à bande passante limitée ou temps d'attente important Brouillages du fait de micro-ondes, cages d'escalier, gaines d'ascenseur tout facteur brouillant les signaux radio Changement d'interfaces de réseaux (par ex. passage d une carte WLAN à une carte WWAN) Traversée de zones de non-couverture Le délai d expiration (timeout) configurable assure que les ressources sur le serveur Mobility consommées par les sessions inactives ne soient pas consommées indéfiniment. Toutefois, dans les scénarios de test, lorsque les périphériques ont été suspendus au milieu d'une transaction d'application, puis réactivés une semaine plus tard, la transaction a repris exactement là où elle s'était arrêtée. Persistance des applications L écriture des applications réseaux sert à utiliser des interfaces de contenu, telles que Winsock (API interfaces Windows). Un simple appel à une application API peut générer plusieurs paquets de données entrantes ou sortantes au niveau transport (IP). Dans les réseaux mobiles existants, si l'un de ces paquets se perd, l état de la connexion risque d être instable et la session interrompue. Le protocole IMP (Internet Mobility Protocol) surmonte ces difficultés. Le protocole adopte un comportement câblé et livre des données en toute fiabilité, tout en traitant diverses situations, dont perte de connexions au milieu d'une transmission et d itinérance. La session logique demeure maintenue et active, même si le périphérique est injoignable ou en suspens. Du point de vue de l'application sur le périphérique mobile, l'application attend l obtention d'une réponse à moins qu elle ne fasse jouer son propre délai d expiration (timeout). Mobility XE accomplit cette fonction dès que le serveur est injoignable en assignant à l'opération un statut en attente.. L'interface Winsock renvoie ensuite la réponse à l'application, qu elle utilise le blocage d appels, les appels asynchrones ou le recouvrement E/S. L'application reçoit les mêmes réponses et comportements que si elle était sur un réseau câblé. Gestion de l'état de connexion Mobility XE ne «teste pas» pour déterminer si un périphérique est accessible avant l'envoi. Mobility envoie tout simplement les données nécessaires et attend en retour un accusé de réception. Si l'accusé de réception retour n'est pas reçu, il tentera un certain nombre d'essais, puis s'arrêtera, conclura à l impossibilité de joindre du périphérique et réessayera plus tard. Le système de tenue du statut du protocole IMP suit l'envoi des paquets ceux avec accusé de réception et ceux qui doivent être renvoyés tout en préservant l'intégrité de toute la session. Pour déterminer si un périphérique mobile inactif est joignable, le système Mobility XE utilise des trames d'entretien : le client Mobility envoie périodiquement des trames au serveur Mobility. La fréquence de ces trames d'entretien, configurable par l'utilisateur, peut être affaiblie pour réduire le trafic sur les réseaux à bande passante limitée. Si le serveur Mobility ne parvient pas à recevoir ces trames pendant le délai configuré, il indique que le périphérique est Aperçu technique à l'intention des administrateurs de système 6

7 injoignable dans la console de gestion du serveur. Les trames d'entretien ne sont envoyées qu'en l'absence d'application ou d'autre trafic. Périphérique injoignable L'emploi du RPC de Mobility XE préserve l'état des transferts de données interrompus et conserve les données en attente dans la file d'attente. Mobility XE préserve tunnel, application et données VPN même lorsque le client nʹest pas joignable Lorsque le serveur d'application transmet des données au client Mobility et que ce client est injoignable en raison d'une perturbation du réseau ou d une suspension du périphérique, les algorithmes de contrôle de flux Mobility XE avisent le RPC du serveur Mobility de cesser d accepter les données en provenance du serveur d'application. En raison du remplissage des tampons TCP dans le serveur Mobility, la taille de la fenêtre TCP se remet à zéro (0), avisant à son tour le serveur d application d interrompre la transmission de données jusqu à ce que le client puisse recevoir les données. Dans une telle situation, le serveur Mobility et le serveur d application échangent les accusés de réception TCP pour conserver une connexion active indéfiniment ou pendant une durée préconfigurée par un administrateur. Une fois le client de nouveau joignable, le contrôle de flux informe le RPC que le transfert de données peut reprendre. Le RPC recommence alors à acquérir des données en provenance de la pile TCP, ce qui permet aux tampons de réception de la connexion TCP de se vider. Lorsque la mémoire tampon devient disponible, la pile TCP assigne une valeur non nulle à la fenêtre de réception de connexion, informant la pile TCP du serveur d application qu elle est de nouveau prête à recevoir des données. Itinérance du périphérique Mobility XE utilise le protocole DHCP pour détecter et faciliter l'itinérance, lorsque les périphériques mobiles se déplacent dans une frontière sous-réseau ou vers un réseau différent. L'utilisateur n'a pas besoin de redémarrer le système ou d éteindre les connexions réseaux existantes pour obtenir une nouvelle adresse. Itinérance sous-réseaux Mobility XE permet aux périphériques mobiles de traverser des frontières sousréseaux sans perdre leurs connexions réseaux ou leurs sessions d'application. Pour y parvenir, le client Mobility doit pouvoir détecter que le périphérique s'est déplacé vers un nouveau sous-réseau et doit obtenir une nouvelle adresse point de présence à partir d'un serveur DHCP. Aperçu technique à l'intention des administrateurs de système 7

8 Pour détecter qu'il s'est déplacé vers un nouveau sous-réseau, le client Mobility utilise deux méthodes. Une première méthode privilégiée s appuie sur l'information provenant du pilote de carte de réseau. L'autre se fonde sur le signal d'alarme DHCP et implique de fréquents échanges découvertes/offres DHCP. Ces deux méthodes d'itinérance sous-réseaux utilisent les services DHCP, au moins en partie, pour assurer l'itinérance. Le client Mobility utilise les services DHCP pour acquérir son adresse IP et d autres paramètres de configuration facultatifs pour le nouveau réseau ou sous-réseau. Détection d'itinérance dans les WAN sans fil Dans un réseau WWAN, l'infrastructure réseau prend en charge l'itinérance sans recourir à un signal d'alarme. Le signal d'alarme est automatiquement désactivé si l'un des points suivants est validé : Le client Mobility se connecte à un adaptateur de réseau commuté (DUN) ou adaptateur PPP (Protocole Point à Point) L'adaptateur de réseau du client Mobility, en obtenant une adresse IP statique, n'a pas besoin de changer son adresse IP en itinérance WAN sans fil (par ex. itinérance activée dans l'infrastructure sous-jacente WWAN). Détection d'itinérance sur un réseau SuperNet Mobility XE propose une configuration qui modifie la détection d'itinérance, fondée sur signal d'alarme dans un réseau SuperNet. Dans ce réseau, deux conditions interviennent : Un seul réseau physique prend en charge deux ou plusieurs réseaux logiques, et Les serveurs DHCP attribuent des adresses IP aux clients Mobility sur plus d'un réseau logique. Si ces deux conditions s'appliquent et que l'environnement réseaux ne peut être facilement modifié pour simplifier l'attribution d'adresses IP aux clients Mobility, en activant l'itinérance SuperNet sur le serveur Mobility la performance de l'itinérance fondée sur signal d'alarme sera améliorée par la prévention de fréquentes tentatives d'itinérance lorsque cela n'est pas nécessaire. Itinérance InterNetwork Roaming Un client Mobility préserve sa connexion et ses sessions d'applications même lorsqu il se déplace entre différents réseaux média. Si les cartes d'interface réseau pour différents types de connexions réseaux ont été installées et correctement configurées sur le périphérique mobile, Mobility XE assure une persistance d'applications lorsque le client se déplace entre des réseaux LAN, LAN et WAN sans fil, ou autre type de réseau IP. Aucune autre configuration n'est nécessaire sur le client ou serveur Mobility. Le système d'exploitation et le matériel réseau sur le périphérique mobile déterminent le degré d'intervention de l utilisateur requis pour assurer une itinérance InterNetwork Roaming. Un client Mobility disposant de plusieurs interfaces réseaux activées est capable de passer automatiquement d'une Aperçu technique à l'intention des administrateurs de système 8

9 interface à l autre. Ainsi, si un périphérique client dispose de deux cartes WLAN et WWAN, et passe hors de portée de tout point d'accès LAN sans fil, les communications peuvent automatiquement passer au support WWAN. Sur un périphérique client combinant plusieurs cartes interfaces de réseaux activées simultanément, Mobility XE utilise la même interface que le système d'exploitation. La sélection d'interface du système d'exploitation peut dépendre de l'ordre dans lequel les interfaces deviennent actives sans aboutir nécessairement à utiliser la «meilleure» interface. Le serveur Mobility modifie les paramètres d'un itinéraire défini dans le système d'exploitation du client en fonction de la vitesse de l'interface réseau, assurant ainsi que le périphérique mobile utilise l'interface disponible avec la plus grande bande passante. Si l'option Interface Roaming Use Fastest est désactivée, l'utilisateur mobile devra peut-être arrêter et démarrer manuellement les cartes interface en fonction du système d'exploitation. Parfois, les connexions réseaux sont disponibles via deux interfaces, mais le serveur Mobility peut être seulement joignable via l'un de ces réseaux. Le basculement du réseau client de Mobility XE permet au client de se connecter lorsque l'interface privilégiée est disponible, sans pourtant se connecter à un serveur Mobility. Pour plus de renseignements sur la détection et le comportement d'itinérance, consulter le Guide de l'administrateur du Système Mobility XE. NAT Traduction des adresses réseau Étant donné qu'il a recours au protocole UDP, Mobility n'est pas susceptible d'être exposé aux problèmes communs aux VPN IPSec et NAT. Les VPN IPSec sont tenus d appliquer la NAT-T (NAT Traversée voir RFC 3947) qui encapsule les paquets IPSec ESP dans le protocole UDP pour traverser des pare-feu ou routeurs non compatibles à la NAT. Comme Mobility XE est, de par sa conception, adapté à la NAT, il ne requiert pas le niveau supplémentaire d'encapsulation et de temps système nécessaires pour traverser les nœuds intermédiaires entre client et serveur Mobility. Authentification avancée Mobility XE prend en charge différentes méthodes d'authentification à deux facteurs. Outre un nom d'utilisateur, mot de passe ou PIN (quelque chose que l'utilisateur connaît), une authentification à deux facteurs exige également quelque chose dont l'utilisateur dispose (certificat, porte-clé, etc.). Méthodes prises en charge : Jetons de sécurité (porte-clé RSA SecurID, par exemple) Cartes à puce (lues par un lecteur de carte), notamment celles ayant recours à un scanneur biométrique pour lire l'empreinte digitale de l'utilisateur au lieu d'un numéro d'identification personnelle ou d'un mot de passe Certificats d'utilisateur stockés sur le disque dur du périphérique Aperçu technique à l'intention des administrateurs de système 9

10 RSA SecurID RSA SecurID permet d'authentifier les utilisateurs en fonction de leur capacité à saisir une chaîne de chiffres et de lettres fréquemment modifiée et générée par générateur de jetons, après qu'ils aient saisi leur numéro d'identification personnelle (PIN). Le générateur de jetons peut être un générateur matériel porte-clé ou jeton USB affichant un code temporel que l'utilisateur saisit manuellement. Ou il peut s'agir d'une application logicielle fonctionnant sur le périphérique qui génère la chaîne. Dans une installation RSA SecurID, le logiciel agent d'authentification RSA fonctionne sur le serveur Mobility. Il crypte les identifiants fournis avec un hachage à sens unique, puis les transmet au gestionnaire d'authentification RSA qui fonctionne sur un serveur distinct. Le gestionnaire d'authentification RSA prend en charge la vérification des justificatifs et la retransmission de l'état d'authentification au serveur Mobility. Mobility XE prend également en charge le rétablissement périodique d'un nouveau PIN SecurID (mode New PIN) pour la fourniture de nouveaux jetons, ainsi que la saisie de codes de jetons successifs (mode Next Token). Le produit Mobility XE a reçu la certification RSA Secured Partner Program pour le produit RSA SecurID. Cette certification signifie qu'un partenariat technique a été établi pour rehausser la sécurité des clients communs qui utilisent les deux produits. Infrastructure de clés publiques/radius Mobility XE prend en charge des solutions d'authentification à deux facteurs fondées sur des normes mettant en œuvre des certificats numériques, en conjonction avec une infrastructure de clés publiques (PKI) pour la validation de ces certificats et une authentification RADIUS EAP (Extensible Authentication Protocol). L utilisation par Mobility XE de RADIUS EAP est une représentation couramment employée de la norme de sécurité 802.1x. La technologie PKI est intégrée aux systèmes d'exploitation Microsoft, ainsi qu'à de nombreuses autres solutions de fournisseurs indépendants, et elle prend en charge la norme internationale X.509v3 de certification numérique. Authentification robuste employée en conjonction avec des certificats validés RADIUS et PKI Pour répondre aux exigences d'une authentification basée sur PKI, des certificats doivent être installés sur les clients Mobility et les serveurs RADIUS pour Aperçu technique à l'intention des administrateurs de système 10

11 permettre une authentification mutuelle. Les certificats suivants sont installés et configurés sur le serveur RADIUS : Certificat numérique et clé privée X.509v3 Certificat pour l'organisme de certification (CA) de confiance ayant signé les certificats sur les périphériques clients Les certificats suivants sont installés et configurés sur les clients Mobility : Certificat pour l'organisme de certification de confiance ayant signé le certificat du serveur RADIUS Certificat X.509v3 installé et configuré ou carte à puce pourvue d'un certificat valide déployé par l'intermédiaire de l'organisme de certification de l'entreprise Pour les cartes à puce, un lecteur qui prend en charge le fournisseur de services cryptographiques (CSP) Microsoft. Le serveur Mobility fait fonction de serveur d'accès au réseau (NAS) dans le système de sécurité RADIUS. Le serveur RADIUS transmet le protocole d'authentification EAP-TLS entre le client et le serveur d'authentification. Si le client emploie des certificats protégés par mot de passe stockés sur le disque dur, l'utilisateur doit saisir le mot de passe du certificat pour les déverrouiller. Si le certificat est stocké sur une carte à puce, l'utilisateur doit saisir le PIN qui lui est associé. Le serveur Mobility et le client Mobility créent alors un tunnel sécurisé mutuellement authentifié et protégé par les certificats x.509. Le serveur Mobility transmet les justificatifs de l'utilisateur au serveur RADIUS. Le RADIUS achève l'authentification en validant le certificat auprès de l'organisme de certification. Si le serveur RADIUS valide les justificatifs d authentification, il informe le serveur Mobility d autoriser l'utilisateur à accéder aux services Mobility XE. Si le serveur RADIUS ne parvient pas à authentifier le certificat, il rejette la demande d'authentification et le serveur Mobility met fin à la tentative de connexion. La méthode d'authentification à deux facteurs prend en charge des systèmes biométriques, lecteur d'empreintes digitales par exemple, quand ces systèmes sont employés au lieu d'un mot de passe pour déverrouiller l'accès à des certificats stockés. Des directives précises pour la configuration de certains des serveurs RADIUS les plus couramment disponibles figurent dans le Guide de l'administrateur du système Mobility XE. Optimisations de liens Une multiplicité de comportements du protocole TCP/IP réduisent son efficacité dans un environnement mobile. Pour en tenir compte, Mobility XE est conçu pour assurer une performance optimale dans des liens de réseaux intermittents et à bande passante limitée. Son architecture comporte des améliorations qui permettent au trafic du réseau sur IP de mieux prendre en charge une perte momentanée de connectivité depuis un périphérique mobile, qu'elle soit due à une indisponibilité de couverture ou à des facteurs externes, gestion d'énergie ou intervention de l'utilisateur par exemple. Elle emploie au mieux la bande Aperçu technique à l'intention des administrateurs de système 11

12 passante donnée et met en jeu de nombreuses fonctions évoluées pour réduire le «bavardage» des protocoles de transport : Accusés de réception sélectifs Groupage des données et accusés de réception Amalgame de messages Réduction et synchronisation des retransmissions Optimisations des fragmentations Compression des données Algorithmes de réduction des erreurs Accélération Web De concert, ces fonctions avancées assurent un maximum d'efficacité dans le transfert de données. De plus, quand la fonction «Use Fastest Interface» (Utiliser l'interface la plus rapide) est activée, Mobility XE passe automatiquement sur la connexion de réseau offrant la bande passante la plus rapide quand plusieurs connexions sont actives. On trouvera ci-dessous une description du fonctionnement de ces fonctions dans un environnement mobile, notamment en zone étendue. Algorithme d'accusé de réception sélectif Quand des données sont transmises sur une connexion sans fil en zone étendue, la perte de paquets peut grandement affecter la performance. Quand un train de paquets est transmis d'un côté ou de l'autre, il est fort possible que certaines de ces trames «disparaissent» et ne parviennent jamais à leur destination finale. Mobility XE tient compte de la perte de paquets lors de la transmission et de la réception de données. Mobility emploie des numéros de séquence pour détecter si une trame n'a pas été reçue dans le bon ordre. S'il reçoit une trame dont le numéro de séquence est supérieur à celui qui est prévu, il alerte l'homologue transmetteur pour l'informer qu'il manque une ou plusieurs trames dans la séquence de réception. L'homologue transmetteur retransmet alors les trames manquantes. En revanche, des systèmes sans accusé de réception sélectif non seulement retransmettent les trames manquantes, mais retransmettent également les trames qui ont été correctement reçues par l'homologue. Ces retransmissions superflues gaspillent de la largeur de bande et des ressources de traitement. Amalgame de messages, groupage données et accusés de réception La plupart des implantations de protocole de réseau utilisent des trames d'accusé de réception pour rétro-informer l'émetteur que l'homologue a bien reçu les paquets envoyés. Cette rétro-information est continue : une trame sur deux (au maximum) fait l'objet d'un accusé de réception et crée un flux de petites trames de service dans la direction inverse. Ces trames supplémentaires, bien qu'elles soient petites, peuvent se traduire par un important temps système. Aperçu technique à l'intention des administrateurs de système 12

13 D'une trame sur deux, Mobility XE peut réduire le flux inverse d'information à une sur quatre ou moins. Pour ce faire, il met en œuvre sa politique d'accusé de réception sélectif et ajuste ses paramètres pour déterminer la latence du réseau. Cela permet la transmission d'un volume plus important de données associées à l'application au lieu d'utiliser la bande passante pour des informations de contrôle supplémentaires. Pour réduire encore plus la consommation de largeur de bande, Mobility XE a recours à une technique de regroupement (multiplexage) de messages. Cet algorithme permet de faire passer dans la même trame des données de contrôle et des données d'application provenant de plusieurs flux de messages distincts. Sans cette fonctionnalité, l'information est encapsulée dans sa propre trame quand l'application transmet les données. Au fur et à mesure que des connexions supplémentaires sont établies, un temps système plus important est nécessaire au niveau du protocole. En regroupant ces flux, Mobility permet le transfert d'un plus grand volume de données d'application dans le même espace, ce qui se traduit par d'importantes économies de largeur de bande. Un autre avantage de cette technique est qu'elle permet à chaque trame d'acheminer un maximum de données utiles. Dans cet exemple, deux applications transmettent et reçoivent comme suit des données dans une implantation ordinaire : l'application A transmet 100 octets de données à son homologue et l'application B transmet 150 octets au sien. Ce qui est représenté comme suit sur un VPN IPSec (les VPN SSL ont des problèmes similaires) : Les VPN traditionnels génèrent des trames distinctes avec un temps système de protocole pour chaque application Cela génère normalement deux trame distinctes, une avec 100 octets de données (plus le temps système de protocole) et une avec 150 octets (plus les besoins de protocole). Chaque trame nécessite alors un accusé de réception distinct de la part de l'homologue récepteur, si bien que quatre trames en tout sont nécessaires pour déplacer les 250 octets de données sur le lien sans fil. Même exemple, mais avec Mobility XE : Les données provenant de l'application A (100 octets) et de l'application B (150 octets) traversent le lien en un paquet de 250 octets (plus le temps système de protocole). Un seul accusé de réception est généré, si bien que seules deux trames suffisent à déplacer les mêmes 250 octets de données. Mobility devient encore plus efficace quand des applications supplémentaires transmettent des données. Aperçu technique à l'intention des administrateurs de système 13

14 Mobility XE améliore lʹefficacité Réduction et synchronisation des retransmissions La plupart des problèmes de performance sur liens WWAN peuvent être attribués à des politiques de retransmission trop agressives. La plupart des implantations IP ont été mises au point pour fonctionner dans des environnements à haut débit et à faibles pertes (infrastructures câblées, par exemple). Mais une latence variable existe dans des connexions sans fil en zone étendue, ce qui peut aisément être interprété à tort par des implantations normales comme une perte de paquet. Le protocole de transport retransmet alors incorrectement une copie d'une trame précédente. Cette retransmission affecte la performance de deux façons : Des données sont retransmises en double sur un lien à bande passante déjà limitée. Cette retransmission superflue consomme les précieuses ressources d'une bande limitée et retarde la transmission de nouvelles données et d'accusés de réception pour les données transmises. Quand un transport retransmet une trame, il suppose normalement que la congestion du réseau a entraîné la perte et emploie un algorithme de recul, réduisant ainsi le volume total de données pouvant être transmises à tout moment. Du fait de l augmentation du temps de transmission réel quand une trame est vraiment perdue, le temps de récupération peut être bien plus long, ce qui réduit sans raison la performance générale. Cela peut entraîner un effet de spirale, ce qui va réduire encore plus la transmission de données à quasiment un échange arrêt-attente. Pour déterminer la latence du réseau, Mobility XE emploie de nombreux heuristiques au-delà d'un calcul d'aller-retour standard. Ces calculs supplémentaires permettent à Mobility de s'adapter plus rapidement à une latence variable et aux autres conditions survenant sur les WWAN. Mobility réduit de façon notable la quantité de données en double qui sont envoyées pour permettre d accommoder un plus grand volume de données d'application dans la ligne de communications. La politique de retransmission synchronisée de Mobility XE est un des exemples de ces heuristiques. Quand une trame est transmise dans des implantations existantes, un délai est fixé pour le moment butoir auquel un accusé de réception doit être reçu pour la trame. Si l'accusé de réception n'a pas été reçu à l expiration de ce délai, certains transports soumettent simplement une autre copie de la trame. Mais quand Mobility décide de retransmettre une trame, il regarde si la couche sous-jacente a pris en charge la copie précédente de la trame. Si ce n'est pas le cas, il retarde la soumission d'une autre copie. Si un périphérique mobile est temporairement hors de portée, par exemple, il n'est pas Aperçu technique à l'intention des administrateurs de système 14

15 nécessaire d'envoyer une autre copie si la précédente n'a pas encore quitté le système local. Un autre exemple des fonctionnalités perfectionnées de Mobility XE est sa capacité à partager des informations sur les caractéristiques du lien sur toutes les connexions au niveau de l'application. Voici comment fonctionnent les implantations de transport actuelles : Au fur et à mesure que chaque application crée une connexion à un homologue, le mécanisme de transport détermine les caractéristiques de la liaison. Une fois ces informations recueillies, la performance s'améliore. Mais pour qu'une quantité suffisante de données d'application passent dans le lien (peut-être 64 K ou plus), cela prend du temps. Quand la connexion est terminée, toutes les informations recueillies sont perdues. Avec Mobility XE, au contraire cela se passe comme suit : Mobility XE conserve les informations recueillies ; si une application entame une autre connexion, les réglages des paramètres mis au point sont employés. Quand Mobility XE passe d'une interconnexion de réseau à une autre, les nouvelles caractéristiques sont immédiatement appliquées à toutes les connexions actives. Il n'est pas nécessaire pour chaque connexion de recalculer ces valeurs, avec le risque d'entraîner des retransmissions supplémentaires. Optimisations des fragmentations Dans le domaine du réseautage, la fragmentation des paquets IP est considérée comme un mal nécessaire qu'il faut éviter. Elle consomme des ressources de plusieurs façons, notamment : Un système intervenant (routeur, par exemple) devra peut-être procéder à un traitement supplémentaire sur les trames fragmentées au lieu de simplement les transmettre à leur destination finale. Le réassemblage d'une trame peut consommer d'importantes ressources sur le système récepteur. Si une partie de la trame fragmentée est perdue, la trame doit être retransmise dans son intégralité. Mais en itinérance d'une interconnexion de réseau à une autre (avec un changement possible dans la taille de trame maximum), une fragmentation peut s'avérer nécessaire. Voici comment Mobility XE optimise cette situation : Il existe une taille maximum de message pouvant être transféré sur un lien et Mobility XE connaît cette taille. Si l'application soumet une demande de transmission de données qui est trop grande pour un seul message, elle la fragmente avant de la transmettre à la couche de réseau sous-jacente. L'avantage est que les données traversent le réseau en trames Aperçu technique à l'intention des administrateurs de système 15

16 «normales» (non fragmentées) et n'exigent pas de temps système supplémentaire au niveau des systèmes intermédiaires. L'algorithme de fragmentation des messages de Mobility XE a été optimisé pour qu'une quantité minimale de ressources, tant computationnelles qu'au niveau de la mémoire, soit consommée pour fragmenter et réassembler le message. Dans le cas d'une retransmission, la fragmentation est réévaluée. Si la taille de message maximum a augmenté, la trame peut être retransmise dans son intégralité, préservant là encore le temps système du réseau. Compression des données La compression des données peut améliorer la vitesse de traitement sur des connexions à bande passante limitée ou dans des environnements de réseau congestionnés pour permettre aux usagers de gagner du temps et de l'argent (selon les politiques de facturation du réseau). Avec Mobility XE, l'administrateur du système peut personnaliser la fonctionnalité de compression, déterminer quand elle doit être activée et si elle doit être activée globalement (pour tous les utilisateurs et tous les périphériques), pour une classe de périphérique mobile ou pour un utilisateur particulier. Mobility peut également être configuré pour activer ou désactiver automatiquement la compression en fonction de la vitesse de l'interface actuelle. Les utilisateurs peuvent passer de LAN b à grande largeur de bande à des WAN 1xEV-DO ou GPRS de moindre largeur de bande et inversement et obtenir automatiquement la meilleure performance possible. Mobility XE compresse les données qui sont transmises entre le serveur et le client Mobility. Il met en œuvre les algorithmes standard figurant dans la spécification RFC 1951 (LZ77 déflation / inflation). Seules les données d'application utiles de chaque trame sont compressées - les en-têtes de transport ne sont pas modifiées. Cela permet à Mobility d'opérer au travers de tout matériel de mise en application de politiques, pare-feu et traducteurs d'adresses réseau (NAT) par exemple. Il peut égaler opérer sur tout réseau IP. Au contraire d'autres technologies de compression qui sont associées à des applications particulières, l'implantation Mobility XE s'applique à toutes les données d'application qui traversent le tunnel Mobility. Aucune modification ou reconfiguration de l'application n'est nécessaire pour bénéficier de cette fonctionnalité. Le temps système au niveau du client et du serveur sont de moins de 16 K de mémoire par connexion Mobility à des fins de dictionnaire et autres de gestion interne. Il est difficile de prédire le degré de compression des données puisque cela dépend du type de données transmises. Comme indiqué dans la spécification RFC 1951 : «Un simple argument de comptage montre qu'aucun algorithme de compression sans perte ne peut compresser toutes les données d'entrée possibles. Un texte anglais est généralement compressé par un facteur de 2,5 à 3 ; les fichiers exécutables sont généralement un peu moins compressés ; les données graphiques, images tramées par exemple, peuvent être bien plus compressées». Autrement dit, le kilométrage peut varier. Mobility XE se conforme également à la «politique de non expansion» telle que définie dans la spécification RFC 1951 : la taille des données transmises n'augmente pas. Aperçu technique à l'intention des administrateurs de système 16

17 Le processus de compression consommant beaucoup de temps machine, un compromis doit être fait pour apporter à l'utilisateur un maximum d'avantages. Empiriquement, avec des débits de données bout en bout supérieurs à un mégabit à la seconde, une compression peut ne pas représenter d'importantes économies. Mobility XE en tient compte et emploie d'autres algorithmes avancés qui détectent la latence du réseau et les taux de compression. En fonction de la latence du réseau et du pourcentage d'économies réalisées en transmettant la trame compressée au lieu de l'original, Mobility peut décider de transmettre une trame sous son format non compressé. Cela réduit les cycles requis au niveau du processeur pour décompresser la trame à la réception et apporte à l'utilisateur un maximum d'avantages. Comme toujours, Mobility consomme aussi efficacement que possible les ressources informatiques et réseautiques. Accélération Web Pour accélérer la navigation Web sur les réseaux lents, Mobility XE présente une option de compression des images. Le niveau de compression est configurable et co-existe avec la sécurité VPN mobile de Mobility XE (tandis que les solutions d'accélération Web proposées par la plupart des fournisseurs de services mobiles ne peuvent pas être employées en conjonction avec un VPN). Les images JPEG sont compressées à l'aide de la mesure de qualité JPEG (le paramètre le plus rapide produit une taille de fichier d'environ 28 pour cent par rapport à la taille originale). Dans les images GIF, le nombre de bits par pixel est réduit, ce qui réduit le nombre de couleurs. L'image est également «aplatie» : les images GIF animées sont réduites à une image et les commentaires textuels sont éliminés. L'accélération Web est disponible à deux endroits différents : Module de gestion des politiques : en jouant sur les politiques, l'administrateur peut sélectivement activer et désactiver l'accélération Web, modifier le niveau de compression ou changer les ports HTTP en fonction des caractéristiques actuelles du réseau, d'une application particulière ou d'autres conditions du moment. Consignes client : l'accélération Web est disponible dans le produit de base sans besoin de licence supplémentaire. Le niveau de compression peut être configuré ; si elle est activée, les images de tout le trafic HTTP aux ports désignés seront compressées au niveau établi. Tailles de paquets Les tailles de paquets TCP/IP ne sont pas toujours optimales pour une transmission sans fil. Dans un environnement mobile, les taux d'erreur augmentent au fur et à mesure que la puissance de transmission baisse, ce qui rend les erreurs plus fréquentes dans les zones de couverture marginale. Quand des paquets volumineux sont transmis dans ce genre de situation, il y a davantage de chances qu'un paquet entier soit rejeté et renvoyé. Des paquets plus petits peuvent améliorer l'efficacité générale en réduisant le nombre de renvois. Nombreux sont les administrateurs de réseau qui ne se rendent pas Aperçu technique à l'intention des administrateurs de système 17

18 compte que même les WLAN peuvent faire état d'un grand nombre de paquets interrompus et d'erreurs de paquets. Le protocole UDP est bien mieux adapté à des réseaux sans fil. Il permet d'éviter le temps système et les inefficacités du protocole TCP, qui n'a pas été conçu à l'intention des réseaux sans fil. De son côté, le protocole IMP (Internet Mobility Protocol) fonctionne par-dessus du protocole UDP et met en application ses propres méthodes pour ajuster, de manière dynamique, tant les tailles des paquets que les paramètres de temporisation en fonction des conditions du réseau. Le protocole IMP, en conjonction avec le protocole UDP, prend en charge les vitesses de transmission et les conditions de connexion bien plus variées d'un réseautage sans fil. Cette démarche permet également au protocole IMP d'appliquer ses propres optimisations de compression et de liens, ce qui peut multiplier par deux la vitesse de traitement sur des réseaux à bande passante limitée. Fiabilité Étant donné que le protocole UDP est sans connexion, le protocole IMP de Mobility garantit la fiabilité de transmission des données. Il met en œuvre ses propres algorithmes pour, de manière sélective, accuser réception des paquets, prendre en charge la gestion des délais, détecter et retransmettre les paquets rejetés. C'est un protocole bien plus perfectionné que TCP/IP et il se doit de l'être. Il doit non seulement vérifier la livraison parmi les instabilités d'un environnement mobile, mais aussi le faire avec un temps système minimal et avec aussi peu de retransmissions de trames que possible sans absorber trop de la bande passante limitée. Modélisation du trafic Qualité de service et DSCP Mobility XE implémente la gestion avancée de la Qualité de Service (QoS) par l'intermédiaire du module de gestion de politiques (voir plus bas) pour établir les paramètres qui vont prioriser et modéliser le trafic du réseau. La QoS est cruciale au maintien de la productivité lorsque les travailleurs passent des réseaux à haute vitesse et à large bande passante à des réseaux à capacité plus faible et à longs délais d'attente. Par exemple, pendant la connexion au réseau LAN via Ethernet, la performance peut convenir parfaitement à une application indispensable à l activité de l entreprise ou à un appel vocal sur IP (VoIP), fonctionnant parallèlement au courrier électronique, à la navigation Web et à d'autres applications. Mais sur réseau WWAN, les administrateurs veulent définir des priorités d utilisation d une bande passante plus étroite et s'assurer qu'un navigateur Web et un client de messagerie n'utilisent pas la capacité nécessaire pour l'application indispensable à l entreprise ou l'application VoIP. La QoS joue un rôle vital, la demande de trafic vocal et vidéo exigeant davantage des ressources de réseau. Ces applications à large bande passante reposent sur de bonnes conditions de livraison de paquets (rapidité, fiabilité). Les politiques QoS permettent aux administrateurs d'accorder à ces applications la priorité dont elles ont besoin pour fonctionner correctement. Aperçu technique à l'intention des administrateurs de système 18

19 Sans QoS : Accès indifférencié au tunnel et au réseau Mobility XE prédéfinit cinq classes principales pour la priorité du trafic : Haute priorité, Voix, Vidéo, Au mieux et Arrière-plan. Chaque classe comporte une configuration prédéterminée pour les divers paramètres QoS, qui assurent un contrôle précis de la modélisation du trafic, du comportement en file d'attente des paquets, du phasage, du taggage DSCP (Differential Service Code Point) et d'autres mécanismes associés. Par exemple, on peut affecter à un trafic VoIP d importance cruciale la priorité Voix pour une modélisation optimale du trafic ou la priorité Au mieux ou Arrière-plan s'il ne s'agit pas d'une utilisation essentielle du réseau. Mobility XE prévoit différents paramètres en fonction d'applications ou d'adresses IP particulières. Ce degré de contrôle d'utilisation du réseau est ce qui distingue le VPN mobile de Mobility XE. Les VPN conventionnels peuvent ne permettre aux administrateurs que de désactiver certaines applications non essentielles. En revanche, avec Mobility XE, les applications peuvent continuer à fonctionner mais à un niveau réduit («goutte à goutte»). Et quand les applications ayant priorité sur toutes les autres achèvent la transmission de données, le plein accès au tunnel de réseau est automatiquement restauré pour les applications restantes. Avec QoS : Priorités de tunnel et de réseau établies par l'administrateur Si elles sont activées, les règles QoS affectent tout le trafic qui passe dans le tunnel Mobility XE. Du côté privé / interne du serveur Mobility, Mobility XE prend en charge le taggage DSCP, norme Internet qui utilise des bits TOS (type de service) dans l'en-tête du paquet TCP/IP pour l'acheminement priorisé par des composants de l'infrastructure du réseau, routeurs et pare-feu par exemple. Aperçu technique à l'intention des administrateurs de système 19

20 Récupération de perte de paquets (PLR) La récupération de perte de paquets fait partie du mécanisme QoS de Mobility XE et est particulièrement bénéfique pour les flux de média, trafic vocal et vidéo par exemple. Ceux-ci reposent sur une livraison de paquets continue, séquentielle et en temps opportun. Puisque la retransmission d'un paquet prend trop longtemps, surtout sur des réseaux sans fil à bande plus étroite présentant plus de latence et de gigue, les paquets perdus ou interrompus entraînent souvent une perte momentanée d'image ou une coupure de conversation. La technique PLR appliquée par les politiques QoS de Mobility XE a recours à un modèle mathématique perfectionné qui ajoute un peu de temps système à chaque paquet. Quand les paquets sont perdus, le mécanisme PRL les reconstruit à l'aide des informations extraites des paquets qui ont été reçus. Le réglage des paramètres du niveau de récupération de perte de paquets permet à l'administrateur d'équilibrer la nécessité d'une récupération par rapport aux conditions du réseau et à la quantité de charge supplémentaire ajoutée à chaque paquet. Un réglage bas du paramètre PLR ajoute moins de données et suffit généralement dans des situations où les pertes de paquets sont mineures. Un réglage élevé du paramètre PLR améliore l'efficacité de récupération, mais augmente également la charge de chaque paquet. La fonction PLR est activée au niveau des paramètres de gestion des politiques QoS et est appliquée par défaut au trafic classé Voix ou Vidéo. La récupération de perte de paquets est réglée par défaut sur «moyen». Gestion Gestion des politiques Le serveur Mobility maintient les politiques d'utilisateur et les oriente vers les clients Mobility dans le champ où elles sont mises en application.. Les documents de politiques sont stockés dans l'entrepôt Mobility. Tous les serveurs Mobility, dans un groupe de serveurs, se partagent un ensemble de politiques communes. Les politiques Mobility sont envoyées vers le périphérique mobile quand celui-ci se connecte. Ces politiques peuvent être définies comme étant propres au périphérique ou propres à l'utilisateur. Les mises à jour ou modifications des politiques sont appliquées en temps réel une fois que l'administrateur les publie en vue de leur diffusion. Pour stocker, extraire et valider les règles entre client et serveur, Mobility utilise un langage de règles XML. Un document de politique contient une définition XML de la politique, liste numérotée de règles, faisant référence à des documents réglementaires (règle ou ensemble de règles contrôlant le comportement du réseau client). Le serveur Mobility fractionne le prolixe langage XML du côté serveur en objets code utilisables et valide les règles par rapport à un fichier XSD (définition de schéma XML) lors de la sauvegarde ou de l'ouverture du document généré. Lorsque des règles sont créées et sauvegardées, le serveur effectue une conversion XSL à partir d un XML prolixe du côté serveur au format client, créant ainsi un document de politique économe en ressources ne contenant que les informations requises par chaque client. Aperçu technique à l'intention des administrateurs de système 20