Cet article a fait l'objet d'une traduction automatique.

La vie errante

Introduction aux VPN IPsec sur les téléphones mobiles

Ramon Arjona

Cette après-midi, alors que je était absent du bureau, j'obtiens un message électronique sur mon téléphone. Le message a un lien vers un document que vous était supposé lire--un document sur un site disponible uniquement via l'intranet de mon entreprise. C'était un bummer car j'ai dû attendre qu'I pourrait lancer mon ordinateur portable, placer ma carte à puce dans le lecteur de carte à puce, obtenir une connexion Wi-Fi à un café, se connecter mon ordinateur portable au réseau VPN d'entreprise et session avant vous Impossible de lire le document.

Durée de vie serait beaucoup plus facile si Suffirait d'utiliser le téléphone pour accéder au site SharePoint. Bien sûr, mon téléphone aurait besoin de certains façon magique de connexion sécurisée au réseau d'entreprise et de m'authentifier. En d'autres termes, tels que mon ordinateur portable, mon téléphone serait devez la possibilité de démarrer une connexion VPN au réseau. De nombreux modèles de téléphone professionnelle, notamment les téléphones Windows, sont livrés avec un client VPN intégré. Mais il existe défauts dans les clients VPN plus largement disponibles car ils sont basés sur la version 1 d'une spécification appelée Internet Key Exchange (IKEv1). IKEv1 est une partie stable de l'infrastructure IPsec et est idéal pour les périphériques câblés ou des périphériques, tels que des ordinateurs portables, relativement importante piles ne déplacent pas autour de trop. Toutefois, il n'est pas idéal pour les téléphones mobiles.

Bien sûr, j'utilise une connexion sans fil sur mon ordinateur portable pour atteindre une salle de conférence de mon bureau et inversement. J'ai peut passer d'une connexion sans fil à un réseau câblé et n'attendent aucune perte de connectivité. Mais nous ne déplacer autour de presque autant avec un ordinateur portable comme nous avec un téléphone. Un téléphone accompagne le trafic et en et hors de bâtiments, transition d'et vers l'état itinérant. Sauf si vous utilisez un modem cellulaire, lorsque a été la dernière fois que votre ordinateur portable vous dit qu'il a été itinérants ? En règle générale, un téléphone change son point de pièce jointe réseau avec une fréquence et la complexité un ordinateur portable n'a jamais à vous soucier. L'histoire qui pensé à la spécification IKEv1 n'a pas avoir à soucier de scénarios de téléphone portable, car n'ont pas les années 1990 au plus tard, lorsque la spécification RFC 2409 a été écrite, téléphones intelligents juste été répandus sur le marché. Depuis, l'utilisation des téléphones mobiles a explosion et l'importance du téléphone mobile a commencé à aborder l'importance des autres, plus grandes périphériques informatiques, telles que la station de travail ou l'ordinateur portable.

IKEv1 n'est pas adapté à un style très mobile de l'informatique, car IKEv1 n'a pas une bonne façon faire face à un ordinateur hôte susceptibles de changer son point de pièce jointe réseau several times dans a few secondes. État de brouillon, lorsque l'état de brouillon, IKEv2 a été vous, un ensemble d'extensions appelé protocole de mobilité et l'hébergement multiple (MOBIKE) a été également vous en fonction du scénario de téléphone portable. À l'aide de ces extensions, téléphone mobile 2009a VPN devient beaucoup plus pratique. Plusieurs produits sur le marché prennent en charge IKEv2 et MOBIKE, y compris Microsoft Systems Center Mobile Device Manager (SCMDM).

Dans cet article, j'aborderai parmi les notions de base de la technologie IKEv2 et MOBIKE. Je supposent une connaissance de IPv4 et mise en réseau, familiarisé avec les téléphones mobiles et une connaissance élémentaire de cryptographie. Cet article ne va pas couvrir IPsec en détail et ne va pas pour discuter des autres types de technologies VPN, tels que les connexions VPN basées sur SSL. Vous ne parlez également IPv6. IPsec et IKE sont extensions pour IPv4, mais ils sont intégrées dans IPv6, par conséquent, parmi les choses que nous allons Evoquez ici seront toujours applicables sur un réseau IPv6. Toutefois, IPv6 présente suffisamment complexité et la nouvelle terminologie qu'il n'est pas possible de traiter de manière suffisamment détaillée.

Dites ‘ AH ’

Trois protocoles constituent le cœur d'IPsec : Le protocole AH (Authentication Header), ESP (Encapsulating Security Payload) et IKE. Pour répondre à IKE, vous devez d'abord discuter AH et ESP.

En bref, AH garantit que les paquets de que nous envoyer ne sont pas falsifiés. Elle protège l'intégrité des paquets de notre. AH garantit également que les paquets sont envoyés de la personne qui prétend avoir envoyé les. Elle garantit l'authenticité de notre paquets. AH ne fournit pas, cependant, toute mesure de confidentialité ou de cryptage. Un attaquant accède au réseau peut intercepter toujours les paquets qui sont protégées par AH et extraire leur contenu. Il ne, cependant, peut pas usurper l'identité parmi les parties authentifiées ni à pouvoir modifier notre paquets en transit. AH est défini dans RFC 4302.

Par exemple, Alice et Bob ont établi une connexion VPN entre eux et avez choisi protéger leurs paquets avec AH. Charlie lui-même insère sur le réseau et commence une interception des paquets. Charles est capable de reconstruire conversation Alice et Bob car il peut afficher le contenu de leurs paquets et discerner le passage de quel type de trafic entre les. Toutefois, il ne peut falsifier un message d'Alice à Bob sans obtenir interceptée et il ne peut pas modifier les messages de Bob à Alice, soit. Ces deux opérations sont évitées en AH.

AH peut être utilisé en mode de transport ou mode tunnel. En mode de transport, la charge utile d'un paquet est protégée et les paquets sont acheminés directement un ordinateur hôte à un autre. En mode de tunnel, l'ensemble du paquet est protégé par AH et les paquets sont routés de l'extrémité d'un «tunnel» IPsecà l'autre. Tunneling s'effectue via l'encapsulation du paquet d'origine. Aux extrémités du tunnel est une passerelle de sécurité. La passerelle qui envoie un paquet est responsable de l'encapsulation paquet en ajoutant un «externe»En-tête IP et adresse. Cette adresse externe achemine le paquet vers la passerelle de sécurité à l'autre extrémité du tunnel. La passerelle qui reçoit le paquet est chargée de traiter le mode AH pour déterminer le paquet provient d'un expéditeur valide et n'a pas été falsifié et qu'il achemine ensuite le paquet vers sa destination finale.

En mode de transport, un AH obtient ajouté au paquet juste après l'en-tête IP. Le protocole AH vient avant le protocole de couche suivant dans le paquet (tel que UDP ou TCP) et aussi avant les autres en-têtes IPsec dans le paquet, tels que l'en-tête ESP. L'en-tête IP qui précède le protocole AH doit avoir la valeur 51, qui est le nombre magique assigné par l'IANA pour AH qui indique l'application de traitement des paquets que la chose suivante qu'il s'affiche est un AH. La figure 1 présente la forme d'un paquet après avoir un AH ajouté.

En mode de tunnel, le protocole AH est ajouté après le nouvel en-tête IP. L'en-tête IP encapsulé est traité comme une partie de la charge utile, ainsi que tout le reste. Cela est illustré dans la figure 2. Les 8 premiers bits d'un paquet protégé par AH spécifier l'ID protocole de la charge utile qui vient après le protocole AH. Ceci indique le récepteur à quoi s'attendre après la charge utile AH. Par exemple, si le protocole de couche suivant est TCP, l'ID du protocole sera définie à 6. Ce champ est appelé l'en-tête suivant. (Vous demandez peut-être pourquoi il n'est pas appelé protocole de manière cohérente avec d'autres en-têtes dans IPv4. La raison est la cohérence et la compatibilité avec IPv6. Heureusement, vous ne souhaitez vraiment pas savoir sur IPv6 pour comprendre comment AH fonctionne sur votre réseau IPv4, mais si vous ont été vous demandez pourquoi il est appelé en-tête suivant, c'est pourquoi.)

Ensuite vient la longueur de 7 bits de la charge utile AH. Puisqu'il est seulement 7 bits, taille de la charge utile est limitée à 128 octets. Puis vient une longue chaîne de zéros--2 octets, en fait. Ces 2 octets sont réservés futurs conformément à la demande, par conséquent, tant que future utilisation est définie, nous avons 2 octets vides qui sont simplement le long de la conduite.

Ces 2 octets est l'index SPI (Security Parameter Index). Ceci est un nombre 32 bits qui est utilisé pour déterminer quelle association de sécurité IPsec (SA) le protocole AH est associé. Je vais décrire en détail les sa lorsque aborder IKEv2. Ce numéro est suivi par un numéro de séquence 32 bits, ce qui est incrémenté avec chaque paquet envoyé et est utilisé pour empêcher les attaques de relecture.

Après la séquence de nombre est Integrity Check Value (ICV). La valeur ICV est calculée à l'expéditeur en appliquant une fonction de hachage, telle que SHA-2, à l'en-tête IP, le protocole AH et la charge utile. Le destinataire vérifie que le paquet n'a pas été falsifié en appliquant la même fonction de hachage et confirmer que le même hachage est généré.

Mes avoirs ESP

Comme AH, ESP (Encapsulating Security PAYLOAD) peuvent fournir l'intégrité et authentification. Contrairement à AH, ESP offre toutefois l'authentification et l'intégrité uniquement pour la charge utile du paquet, pas pour l'en-tête du paquet. ESP peut également être utilisé pour assurer la confidentialité en cryptant la charge utile de paquet. En théorie, les fonctionnalités de ESP peuvent être activées indépendamment, il est possible de chiffrement sans authentification et l'intégrité ou intégrité et l'authentification sans cryptage. Dans la pratique, toutefois, effectuant l'une sans l'autre n'est pas apporter beaucoup de sens. Par exemple, sachant qu'un message a été envoyé à moi confidentielle ne me n'importe quelle bonne si je ne peut pas être également totalement sûr qui l'a envoyé. ESP est défini dans RFC 4303.

ESP, comme AH, peut être activé en mode de tunnel ou en mode transport. L'en-tête ESP doit être inséré après le protocole AH. En mode de transport, ESP crypte la charge utile du paquet IP. En mode de tunnel ESP traite tout le paquet encapsulé en tant que la charge utile et crypte. Ceci est illustré dans la figure 3.

L'algorithme de cryptage est choisi par un processus de négociation entre les homologues configurer la SA IPsec. Avancées Encryption Standard (AES) est un choix courant d'algorithme de cryptage pour les implémentations modernes. Bien entendu, pour utiliser AES, tout d'abord avoir un secret partagé pour que les deux hôtes allez démarrer une communication sécurisée. Donnant manuellement la clé partagée pour l'ordinateur hôte d'est une approche peu pratique, car il n'est pas évoluer, mais vous pouvez utiliser échange de clés Diffie-Hellman (DH) pour configurer le secret.

Groupes Diffie-Hellman

Diffie-HELLMAN est un protocole qui permet à deux parties partager un secret sur un canal non sécurisé et qu'il fait partie intégrante de la négociation a lieu dans IKE. Le secret partagé qui est communiqué via Diffie-HELLMAN peut être utilisé pour créer un canal de communication est crypté en toute sécurité. Les calculs qui sont placées dans Diffie-HELLMAN sont complexe et je ne pas aller dans il en détail ici. Si vous souhaitez en savoir plus sur elle, vérifiez les ressources couvrant modulaires groupes (MODP) exponentielles et leur application Diffie-HELLMAN. Pour nos besoins, il suffit de dire qu'un groupe Diffie-HELLMAN est une collection spécifique de nombres avec une relation mathématique et un code de groupe unique.

Lorsqu'une connexion sécurisée est en cours définie avec IPsec, lors de la négociation IKE d'un groupe Diffie-HELLMAN est spécifié. Dans cette négociation, les deux homologues tente d'établir une connexion sécurisée devra rechercher un groupe Diffie-HELLMAN qui prennent tous deux en charge. Groupes Diffie-HELLMAN avec ID supérieurs avoir puissance de cryptage plus élevée. Par exemple, les groupes Diffie-HELLMAN premier qui sont appelés dans la spécification IKE d'origine avait sur la même puissance de chiffrement comme une clé symétrique, avec entre 70 et 80 bits. Avec l'avènement des algorithmes de cryptage plus forts comme AES, plus de puissance était nécessaire de groupes Diffie-HELLMAN pour empêcher les groupes Diffie-HELLMAN de devenir un maillon faible dans la chaîne cryptographique. Par conséquent, plus récentes groupes Diffie-HELLMAN spécifiés dans RFC 3526 fournir estimé puissance entre 90 et 190 bits.

L'inconvénient de ces groupes Diffie-HELLMAN plus récentes est que leur niveau supérieur a un coût : avec les groupes plus puissants, plus le temps de traitement est requis. C'est une des raisons pourquoi homologues doivent négocier un groupe Diffie-HELLMAN acceptable mutuellement. Par exemple, mon téléphone n'est peut-être pas suffisamment puissant pour traiter les groupe Diffie-HELLMAN 15, afin qu'il souhaite prendre en charge uniquement le groupe Diffie-HELLMAN 2. En essayant d'établir une connexion IPsec avec un serveur, mon téléphone proposer Diffie-HELLMAN groupe 2 et si le serveur prend en charge groupe Diffie-HELLMAN 2, ce groupe sera utilisé--même si le serveur peut potentiellement avoir utilisé un groupe Diffie-HELLMAN plus puissant. Bien entendu, si les deux homologues ne peut pas s'accordent sur un groupe Diffie-HELLMAN communs, ils sera en mesure de communiquer.

C'est assez arrière-plan. Parlons IKE.

Je comme IKE (et si vous devez)

IKE est utilisé pour établir une connexion entre homologues IPsec. Cette connexion est appelée une association de sécurité (SA). Il existe deux types de sa et le IKE_SA le CHILD_SA. Le IKE_SA définir premier. Il s'agit dans lequel le secret partagé est négocié sur Diffie-HELLMAN et où cryptage et algorithmes de hachage sont également négociés. Le CHILD_SA est où le trafic réseau est envoyé, protégé par AH, ESP ou les deux.

Chaque demande dans IKE requiert une réponse, ce qui facilite le penser en termes de paires de messages. Le premier message paire est appelée IKE_SA_INIT et est utilisée pour déterminer quel algorithme de chiffrement et Diffie-HELLMAN groupe les homologues doit utiliser. La cryptographie est toujours en cours déterminée pendant cet échange, cette paire de messages n'est pas cryptée. La paire de messages suivante est appelée IKE_SA_AUTH. Cet échange authentifie les messages envoyés au cours de IKE_SA_INT et prouve l'identité de l'initiateur et le répondeur. Cette étape est nécessaire car le premier message a été envoyé en clair--avoir établi un canal sécurisé, les homologues maintenant doivent prouver à eux qu'ils sont vraiment ceux qu'ils prétendent qu'être et que leur vraiment conçues pour démarrer cette conversation. L'échange de messages IKE_SA_AUTH définit également le premier CHILD_SA, qui est fréquemment CHILD_SA uniquement créé entre les homologues.

Un CHILD_SA est une connexion simplex--ou à sens unique, afin que CHILD_SAs sont toujours configurer par paires. Si une association de sécurité dans une paire est supprimée, l'autre doit également être supprimé. Ceci est géré dans IKE via les messages d'information. Par RFC 4306, un message d'information contient zéro ou plusieurs des messages de notification, de supprimer ou de configuration. Supposons que nous avons un initiateur qui est un ordinateur et un répondeur est un serveur. L'ordinateur décide de fermer la connexion CHILD_SA et terminer la connexion VPN. Il envoie un message d'information avec une charge utile de supprimer le serveur, qui identifie la SA pour supprimer par son index SPI. Le serveur puis supprime cette association de sécurité entrante et envoie une réponse à l'ordinateur pour supprimer sa moitié de l'association de sécurité. L'ordinateur reçoit ce message et supprime sa moitié de l'association de sécurité, et tout est parfait.

Bien sûr, choses ne fonctionnent pas toujours de cette manière. Un répondeur ou un initiateur peut retrouver avec une association de sécurité dans un «moitié fermé»état, où un membre de la paire de SA est fermé mais l'autre est toujours ouverte. La demande spécifie qu'il s'agit une condition anormale mais ne permet pas d'un homologue fermer ces connexions semi-ouvertes par lui-même. Au lieu de cela, l'homologue est censé pour supprimer les IKE_SA si l'état de connexion devient instable suffisamment--mais suppression le IKE_SA supprime alf CHILD_SAs qui ont été créés sous celui-ci. Tous les cas serait pénible sur un téléphone ouvert le CHILD_SA serait consommant des ressources système est insuffisante, comme avoir à les détruire et recréer la IKE_SA.

En outre, il est possible pour un hôte à la fin d'une SA pour disparaît complètement, sans indiquant le système de l'autre côté de l'association de sécurité qu'il est judicieux de. Ceci est un cas est particulièrement susceptible de se produire avec les téléphones mobiles. Par exemple, imaginez un scénario dans lequel un utilisateur de portable a établi une connexion VPN IPsec avec un serveur. L'utilisateur de téléphone portable passe en un sous-sol et perd son signal radio. Le serveur n'a aucun moyen de savoir que le téléphone a disparu dans un trou noir et il continue à envoyer des messages sur le CHILD_A, mais ne reçoit aucune réponse. Il est possible de la même façon pour le téléphone commencer l'envoi de messages dans un trou noir en raison de routage problèmes sur le réseau cellulaire. Tout ce qui peut provoquer un homologue de perdre la trace d'un autre peut entraîner cette situation, mais le coût figurant sur le téléphone est supérieur au coût sur le serveur, car les ressources sur le téléphone sont plus rares.

Pourquoi est-ce mauvais pour détruire et recréer l'association de sécurité ?

Est la réponse courte supprimer et reconstruire la clé de session utilise ressources onéreuses que le téléphone can’t vous permettre de perdre. Plus précisément, l'UC est utilisée pour effectuer des calculs cryptographiques et pendant que la radio est en utilisez envoyer et recevoir des grandes quantités de données, les deux la durée de vie de la batterie de coût. La grande quantité de données transférées également consomme la bande passante, qui coûte money, notamment dans les endroits où données envisage de frais par les kilo-octets.

Envoyer un message sur le radio les coûts de puissance et l'alimentation sur le téléphone est limitée, le téléphone doit détecter ces situations de trou noir et traiter avec eux pour conserver les ressources système. Cette opération est généralement gérée par un processus appelé inactive type détection (DPD), dans lequel un homologue soupçonne qu'il peut être parler à un trou noir envoie un message demandant la preuve de liveness. Si la cible de cette demande ne répond pas dans un laps de temps approprié, l'expéditeur peut prendre action appropriée pour supprimer le IKE_SA et récupérer des ressources en cours consacrés. En général, il est préférable d'envoyer des messages DPD uniquement lorsqu'il n'y a aucun trafic circulant via l'association de sécurité et l'homologue a raison de suspecter que son partenaire sur l'association de sécurité n'est plus il. Bien qu'il aucune exigence d'implémenter DPD de cette façon, il peu significatif pour confirmer la liveness d'un homologue est actuellement vous envoyer d'autres types de trafic réseau.

Une autre situation peut provoquer des problèmes sur une connexion VPN est un ordinateur hôte modifier son adresse IP. L'adresse d'un ordinateur hôte est utilisée avec cet index 32 bits pour identifier un ordinateur hôte particulier et associer à une association de sécurité. Lorsqu'un ordinateur hôte perd son adresse IP, cette association est également perdue et l'association de sécurité doit être détruit et recréé avec la nouvelle adresse IP.

Comme nous avons dit avant, il s'agit pas d'un problème de bureau ou portables. Un ordinateur peut perdre un bail DHCP et obtenir une nouvelle adresse IP, mais la plupart des implémentations de DHCP est très probable que la même adresse IP qu'il avait avant va être attribuée à l'ordinateur. En d'autres termes, ordinateurs de bureau ne modifiez souvent adresses IP. Les ordinateurs portables, car ils sont mobiles, modifier leur point de pièce jointe de réseau et donc obtenir une nouvelle adresse IP, forcer toute SA ils ont ouvert pour être détruit et recréé. Toutefois, le taux auquel les ordinateurs portables basculer adresses est encore relativement rare lorsqu'elle est comparée avec le taux auquel un téléphone. Par exemple, un téléphone qui a la possibilité de transmettre des données via Wi-Fi et canaux cellulaire peut basculer des réseaux chaque fois qu'un utilisateur parcourt ou arrière dans son bâtiment comme le téléphone passe d'un Wi-Fi à une connexion GPRS et une sauvegarde à nouveau. Contrairement à un ordinateur portable déplacement bureaux, qui peut rester sur la même liaison de réseau et par conséquent continuent à avoir une adresse réseau topologically correct sans modification, le téléphone a basculé entre deux réseaux fondamentalement différents, donc il est pratiquement garanti pour modifier les adresses IP. Il en résulte une connexion interrompue sur le téléphone chaque fois qu'un transfert entre les réseaux se produit. La même chose peut se produire alors que le téléphone se trouve sur le réseau cellulaire uniquement. Le téléphone peut mode itinérant et passer de son réseau domestique à un réseau externe appartenant à un opérateur mobile différent. Le téléphone peut déplacer d'une zone de couverture à un autre et devienne lié à une partie totalement différente du réseau de l'opérateur mobile.

Il existe un certain nombre d'autres raisons contrôlé par l'opérateur mobile qui peut provoquer une connexion interrompue. Cette fréquence supprimer et la reconstruction de l'association de sécurité rendrait le VPN mobile complexes n'étaient pas pour les extensions à IKEv2 appelé MOBIKE.

MOBIKE

Le protocole IKEv2 MOBIKE est défini dans RFC 4555. Il permet de pairs dans un réseau privé virtuel IPsec pour annoncer qu'ils ont plusieurs adresses IP. Une de ces adresses est associée à la SA de cet homologue. Si l'homologue est forcée pour passer son adresse IP raison d'une modification en pièce jointe de réseau, une des adresses IP précédemment identifiés ou une adresse qui vient d'être affectée, peut être transférée dans sans avoir à détruire et recréer l'association de sécurité.

Pour indiquer la possibilité d'utiliser MOBIKE, un homologue inclut une notification MOBIKE_SUPPORTED dans l'échange IKE_SA_AUTH. L'échange IKE_AUTH inclut également les adresses supplémentaires pour l'initiateur et le répondeur. L'initiateur est le périphérique qui démarré l'installation de la connexion VPN par l'envoi du premier message IKE et est responsable des décisions sur lequel les adresses IP à utiliser parmi ceux qu'il dispose et celles proposées à celui-ci par le répondeur.

Comme la demande fait remarquer, l'initiateur est généralement le périphérique mobile car le périphérique mobile possède plus conscience de son emplacement sur le réseau et par conséquent il est mieux adapté à prendre des décisions concernant les adresses à utiliser. Toutefois, la demande ne spécifie pas comment ces décisions doivent être prises. En règle générale, une extrémité de la connexion VPN IPsec sera un périphérique mobile et l'autre extrémité sera un serveur de passerelle de sécurité fixe. La spécification ne nécessite pas cette implémentation et autorise les deux extrémités de la passerelle à déplacer, mais il ne fournit pas un moyen pour les deux extrémités de la passerelle eux retrouver s'ils se déplacent en même temps. Autrement dit, si un homologue met à jour son adresse et l'autre homologue ne la même chose en même temps, il n'est aucune possibilité de communiquer cette modification à l'homologue et la connexion VPN seront perdue.

L'initiateur utilise liste d'adresses du répondeur pour déterminer la meilleure paire d'adresses à utiliser pour l'association de sécurité. Le répondeur n'utilise pas adresses de l'initiateur, à l'exception comme moyen de communication à l'initiateur qu'adresse du répondeur a été modifié.

Par exemple, lorsque l'initiateur voit que son adresse a été modifié, il informe le répondeur de ce fait avec un message d'information qui contient une notification UPDATE_SA_ADDRESSES. Ce message utilise la nouvelle adresse, qui démarre également utilisé dans les messages ESP de l'homologue. Le récepteur de la notification de mise à jour enregistre la nouvelle adresse et éventuellement vérifie retour routability être sûr que l'adresse appartient à l'autre nœud mobile comme est revendiqué. Après cela, le répondeur démarre en utilisant la nouvelle adresse pour son trafic ESP sortant.

Bien entendu l'initiateur ou le répondeur peut ignoriez toutes les adresses qu'il aura jamais pendant la durée de vie de l'association de sécurité. Un homologue peut annoncer une modification dans la liste des adresses qu'il prend en charge avec un message d'information. Si l'homologue ne possède qu'une seule adresse, cette adresse est présente dans l'en-tête et le message contient la notification NO_ADDITIONAL_ADDRESSES. Dans le cas contraire, si l'homologue a plusieurs adresses, une de ces adresses est placée dans l'en-tête du message d'information et les autres sont inclus dans une notification ADDITIONAL_IP4_ADDRESSES.

Cette liste n'est pas une mise à jour ; il est la liste entière des adresses de l'hôte souhaite publier à ce moment. En d'autres termes, la liste entière est envoyée chaque fois, mais ce coût est toujours inférieur au coût de supprimer et régénérer l'association de sécurité chaque fois que le téléphone change son point de pièce jointe de réseau.

Conclusion

Vous devez maintenant avoir une idée de base du fonctionnement un VPN IPsec avec MOBIKE sur un téléphone cellulaire.

L'importance croissante de téléphones intelligents dans l'accueil et espace de travail va rendre ces solutions plus important que les utilisateurs commencent à demander une expérience qui correspond à sur plusieurs périphériques informatiques riches en ressources. Pour l'instant, les gens sont prêt à accepter les téléphones qui ne peut pas se connectent au réseau d'entreprise, qui ont uniquement un jour de la durée de vie de la batterie et qui souffrent d'autres défauts du téléphone intelligent que nous connaissent tous les. Ce n'est pas le dernier. Concurrence et l'émergence de meilleur matériel entraînera l'adoption de solutions plus complètes, fin à fin qui permettent des expériences pour le téléphone qui sont de pair avec au bureau et portables.

Et puis I, ainsi que tout le monde, sera en mesure de parcourir les sites SharePoint d'entreprise tout en cliquant sur un lien sur mon téléphone.

Remerciements particuliers à Melissa Johnson pour ses suggestions et étude technique de cet article.

Ramon Arjona est un responsable SDET chez Microsoft.