Articles dans cette section

Cloud Connect (IPsec et Transit Gateway) : FAQ et guides

Avatar
Jorge Merino
  • Mise à jour
S’abonner

Sommaire

  1. Guides d’intégration
  2. Documentation technique
  3. Pourquoi mes tunnels IPsec sont-ils inactifs, alors que la configuration était correcte et que je n’y ai pas touché ?
  4. Les données envoyées par mes appareils connectés n’arrivent pas jusqu’à mon serveur
  5. J’ai un message d’erreur : “CIDR non valide. X.X.X.X n’est pas disponible.”
  6. Je souhaite mettre à jour ma configuration Cloud Connect. Comment faire ?
  7. Est-il possible de mettre en place une Transit Gateway / un IPsec pour certaines IP uniquement ?
  8. Quelle est la différence entre OpenVPN et IPsec ?
  9. Explications sur le fonctionnement d’IPsec
  10. Quels algorithmes sont supportés ?
  11. Les protocoles IKEv1 et IKEv21

1. Guides d’intégration

Pour consulter les guides suivants, rendez-vous sur notre banque de ressources pour les développeurs :

2. Documentation technique

Pour plus d’informations sur les VPN AWS et obtenir une documentation technique, vous pouvez vous référer aux ressources AWS suivantes : Documentation AWS Virtual Private Network, Exemples de fichiers de configuration.

3. Pourquoi mes tunnels IPsec sont-ils inactifs, alors que la configuration était correcte et que je n’y ai pas touché ?

  • Aucun trafic

Si aucun trafic ne traverse l’IPsec, les tunnels peuvent devenir inactifs. Ils seront de nouveau actifs dès lors que votre application transmettra des données. D’après la documentation AWS : “Par défaut, le tunnel VPN est activé lorsque le trafic est généré et que la négociation IKE est lancée depuis votre côté de la connexion VPN.”

Afin de maintenir le tunnel actif, nous vous recommandons de mettre en place une action permettant de relancer l’IPsec (par exemple une tâche cron, ou un ping depuis votre serveur vers un appareil connecté EMnify). Cela permet d’éviter que l’association de sécurité de l’IPsec ne soit complètement supprimée à la suite d’essais infructueux de relance (en cas de panne du réseau AWS par exemple).

  • Délai d’inactivité dépassé (idle timeout)

Si vous rencontrez des déconnexions dues à des périodes d’inactivité prolongées (idle timeout) sur un tunnel VPN :

    • Assurez-vous qu’il y a en permanence du trafic dans les deux sens entre votre application et Cloud Connect. Si besoin, créez un hôte qui envoie des requêtes ICMP à une instance de votre VPC toutes les 5 secondes.
    • Vérifiez le réglage du délai d’inactivité sur votre passerelle VPN auprès du fournisseur. Lorsqu’aucun trafic ne traverse un VPN pendant un temps (dépendant du fournisseur), la session IPsec s’achève. Référez-vous aux recommandations de configuration spécifiques de votre fournisseur.

  • Panne du réseau

Pour relancer un tunnel VPN après une panne réseau (dont la durée dépasse généralement le délai DPD), nous vous recommandons de prévoir une action en plus, à partir d’une tâche cron ou d’un ping depuis votre serveur vers un appareil connecté EMnify. Cela permet d’éviter que l’association de sécurité de l’IPsec ne soit complètement supprimée à la suite d’essais infructueux de relance. AWS n’initie pas les connexions IPsec, son fonctionnement est passif.

 

4. Les données envoyées par mes appareils connectés n’arrivent pas jusqu’à mon serveur

  • Vérifiez la destination des données émises par vos appareils connectés. Si vous utilisez un nom d’hôte pour vos serveurs applicatifs, assurez-vous qu’il renvoie vers une IP privée accessible à travers Cloud Connect.
  • Assurez-vous que le trafic entrant depuis les IP de vos appareils est autorisé.
    • 10.192.0.0/12
    • 100.64.0.0/10
    • 10.112.0.0/12
    • 10.176.0.0/12
    • Si possible, autorisez le trafic provenant de toutes les plages ci-dessous :

Dans ce cas, vous vous assurez que le trafic provenant de tous vos appareils est bien autorisé.

  • En cas de règles contradictoires, vous pouvez aussi n’autoriser que les plages d’IP reliées à votre compte. Dans ce cas, vous devrez mettre à jour la configuration lorsqu’une nouvelle plage est utilisée par votre compte.

5. J’ai un message d’erreur : “CIDR non valide. X.X.X.X n’est pas disponible.”

Vous pouvez utiliser jusqu’à 3 CIDR dans votre VPC. Si un CIDR est déjà attribué de notre côté, un message d’alerte apparaîtra au moment de valider la Transit Gateway, car la TGW d’AWS n’accepte pas les adresses IP redondantes. Dans ce cas, vous devez utiliser un autre CIDR.

6. Je souhaite mettre à jour ma configuration Cloud Connect. Comment faire ?

Il n’est pas encore possible de modifier votre configuration Cloud Connect. À la place, supprimez l’attachement, et créez-en un nouveau.

En ce qui concerne les Transit Gateways, assurez-vous de les supprimer depuis l’interface EMnify. Si vous le faites depuis l’interface AWS, nous ne recevrons pas l’information, et le CIDR utilisé ne sera pas disponible automatiquement.

NB : lorsque vous supprimez un attachement et que vous en créez un autre dans la foulée, les deux sont facturés pour le mois courant.

NB 2 : si vous ne supprimez un attachement que depuis l’interface AWS, nous continuerons à vous facturer. Assurez-vous de bien supprimer l’attachement sur le portail EMnify.

7. Est-il possible de mettre en place une Transit Gateway / un IPsec pour certaines IP uniquement ?

Cloud Connect donne accès à l’ensemble de vos appareils. Cependant, libre à vous de créer des règles de votre côté pour restreindre l’accès à seulement certaines adresses IP.

8. Quelle est la différence entre OpenVPN et IPsec ?

EMnify propose plusieurs types de VPN :

  • OpenVPN sert à accéder à distance à vos appareils équipés d’une SIM EMnify depuis n’importe quel ordinateur. Pour plus d’informations, référez-vous à notre FAQ OpenVPN.
  • IPsec permet de créer une connexion directe entre un serveur applicatif et des appareils connectés à internet via une SIM EMnify. Si vous optez pour un IPsec, tout le trafic (dans les deux sens) entre vos appareils et votre serveur applicatif passera par un tunnel, et il sera crypté et sécurisé sans passer par l’internet public. Cela permet aux appareils d’accéder directement à l’application au sein d’un même réseau. Le Cloud Connect EMnify permet une configuration rapide d’un IPsec. Pour les clients AWS, il est possible d’utiliser la fonctionnalité Transit Gateway et ainsi de garder tout le trafic au sein d’AWS.

9. Explications sur le fonctionnement d’IPsec

La technologie IPSec fait intervenir de nombreux composants et méthodes de cryptage. On peut cependant séquencer le fonctionnement d'IPSec en cinq étapes principales :

  1. Un « trafic intéressant » initie le processus IPSec. Le trafic est jugé intéressant lorsque la stratégie de sécurité IPsec configurée dans les homologues IPsec lance le processus IKE.
  2. Phase 1 du protocole IKE. IKE authentifie les homologues IPsec et négocie les SA IKE au cours de cette phase, en mettant en place un canal sécurisé pour négocier les SA IPsec au cours de la phase 2.
  3. Phase 2 du protocole IKE. IKE négocie les paramètres de SA IPsec et configure les SA IPsec correspondantes chez les homologues.
  4. Transfert de données. Les données sont transférées entre homologues IPsec en fonction des paramètres et des clés IPsec stockées dans la base de données SA.
  5. Terminaison du tunnel IPSec. Les SA IPsec se terminent par suppression ou expiration du délai.

1. Définition du “trafic intéressant”

Déterminer quel trafic est considéré comme “intéressant” fait partie de l’élaboration de la politique de sécurité d’un VPN. Cette politique est ensuite implémentée dans l’interface de configuration de chaque homologue IPsec. Quand du trafic intéressant est généré par un client IPsec, celui-ci déclenche la prochaine étape du processus, la négociation d’une phase 1 IKE.

2. Phase 1 du protocole IKE

Le but de la phase 1 du protocole IKE est d’authentifier les homologues IPsec et de créer un canal sécurisé entre eux pour permettre des échanges IKE. Voici les fonctions de la phase 1 :

  • Authentifier et protéger l’identité des homologues IPsec
  • Négocier une politique de IKE SA commune aux homologues pour protéger l’échange IKE
  • Réaliser un échange de clés Diffie-Hellman authentifié afin de partager les mêmes clés secrètes
  • Mettre en place un tunnel sécurisé pour négocier les paramètres de la phase 2 du protocole IKE

La phase 1 peut se dérouler selon deux modes : le mode principal et le mode agressif.

    • Mode Principal

Le mode principal engendre trois allers-retours d’informations entre l’initiateur et le destinataire.

      • Premier échange : les algorithmes et hachages de sécurisation des communications IKE sont validés par des SA correspondantes chez chaque homologue.
      • Deuxième échange : un échange de Diffie-Hellman est réalisé pour générer un matériel de clé partagé, permettant lui-même de créer des clés secrètes partagées et de transmettre des nonces, c’est-à-dire des nombres aléatoires envoyés à l’autre homologue, puis signés et renvoyés pour prouver son identité.
      • Troisième échange : vérification de l’identité de l’autre partie. La valeur de l’identité correspond à l’adresse IP de l’homologue IPsec, sous sa forme cryptée. Le principal résultat du mode principal est l’élaboration d’une SA IKE commune aux homologues, permettant d’avoir un canal protégé pour les échanges ISAKMP ultérieurs. La SA précise les caractéristiques de l’échange IKE : la méthode d’authentification, le cryptage et l’algorithme de hachage, le groupe de Diffie-Hellman, sa durée de vie en secondes ou kilooctets, et les valeurs de la clé secrète partagée pour les algorithmes de cryptage. La SA IKE de chaque homologue est bi-directionnelle.

    • Mode aggressif

Le mode agressif occasionne moins d’échanges, et moins de paquets. Lors du premier échange, presque tout est contenu dans les valeurs proposées pour la SA IKE : la clé publique Diffie-Hellman, un nonce signé par l’autre partie, et un paquet relatif à l’identité, qui peut être utilisé pour une vérification par une tierce partie. Le destinataire renvoie tout ce qui est nécessaire pour finaliser l’échange. Il reste simplement à confirmer l’échange du côté de l’initiateur. L’inconvénient du mode agressif est qu’il occasionne un échange d’information avant la mise en place d’un canal sécurisé. Par conséquent, il est possible pour un tiers de “renifler” la transmission, et de savoir qui a créé la nouvelle SA. En revanche, ce mode est plus rapide que le mode principal.

3. Phase 2 du protocole IKE

Le but de la phase 2 du protocole IKE est de négocier les paramètres de SA IPsec pour mettre en place le tunnel IPsec. Voici les fonctions de la phase 2 :

  • Négocier les paramètres de SA IPsec sous la protection d’une SA IKE existante
  • Établir les associations de sécurité
  • Régulièrement renégocier les SA pour assurer la sécurité
  • Éventuellement réaliser en plus un échange Diffie-Hellman

La phase 2 n’a qu’un mode, le mode rapide. Ce mode intervient après qu’IKE a mis en place un tunnel sécurisé lors de la phase 1. Il négocie une politique IPsec partagée, en tire un matériel de clé partagé utilisé dans les algorithmes de sécurité IPsec, et il établit les SA IPsec. Le mode rapide occasionne un échange de nonces pour se protéger contre les réexécutions. Ces nonces servent à générer un nouveau matériel de clé partagé empêchant la création de fausses SA lors d’une attaque.

Le mode rapide sert aussi à renégocier une nouvelle SA IPsec lorsque la précédente a expiré. Le mode rapide de base rafraîchit le matériel de clé utilisé pour créer la clé secrète partagée, basée sur le matériel de clé issu de l’échange Diffie-Hellman de la phase 1.

    • Perfect Forward Secrecy (Confidentialité persistante)

Si la politique IPsec contient la perfect forward secrecy (PFS), un nouvel échange Diffie-Hellman est réalisé à chaque mode rapide, afin de fournir un matériel de clé de plus grande entropie, donc plus résistant face aux attaques cryptographiques. Chaque échange Diffie-Hellman demande beaucoup de puissance de calcul, ce qui impacte la performance.

4. Tunnel IPsec crypté

À la fin de la phase 2, une fois les SA IPsec établies par le mode rapide, les informations sont échangées via un tunnel IPsec. Les paquets de données sont cryptés, puis décryptés, suivant le cryptage précisé par la SA.

5. Terminaison du tunnel 

Les SA IPsec disparaissent par suppression, ou expiration de leur durée de vie. Une SA peut expirer après un certain délai, ou une fois qu’une quantité de données prédéfinie a transité par le tunnel. Quand une SA expire, les clés correspondantes sont aussi supprimées. Par la suite, quand de nouvelles SA sont nécessaires à un transfert, IKE déclenche une nouvelle phase 2, et une nouvelle négociation de phase 1 si nécessaire. Une fois la négociation menée à terme, de nouvelles SA et de nouvelles clés sont disponibles. Il est possible d’établir de nouvelles SA avant l’expiration des précédentes, pour assurer la continuité des échanges.

10. Algorithmes pris en charge

mceclip0.png

10. IKEv1 et IKEv2

  • IKEv1

    • VPN sur demande, c’est-à-dire que le tunnel se désactive quand il n’est pas utilisé. Il est donc nécessaire de maintenir un trafic constant dans le tunnel.
    • Le tunnel ne peut pas être initié depuis le côté EMnify, c’est donc le client qui doit relancer l’IPsec pour remettre le tunnel en place.

  • IKEv2

    • Le tunnel reste actif même si aucun trafic ne le traverse.
    • L’IPsec peut être remis en place interruption du tunnel, en utilisant les paramètres suivants côté client :
      • DPD timeout action (RESTART)
      • Startup action (start)

NB :

  • Une fois ces paramètres configurés de votre côté, ils seront automatiquement pris en compte par EMnify, car ils sont déjà acceptés par défaut.
  • Une limite persiste : la négociation doit toujours être initiée côté client.

Par conséquent, si le tunnel IPsec est interrompu côté client à cause d’une absence d’activité, alors il ne sera pas réactivé par un trafic entrant depuis un appareil connecté.

  • Actuellement, les paramètres liés aux actions DPD timeout et Startup ne peuvent pas être modifiés côté EMnify

Articles associés

Commentaires

0 commentaire

Vous devez vous connecter pour laisser un commentaire.