VPN Gateway:Configure routes for a VPN gateway

Routes statiques par rapport aux routes BGP

Routes statiques : basées sur la destination ou sur des politiques

Choisissez entre les routes basées sur la destination et celles basées sur des politiques.

Priorité des routes

La passerelle VPN fait correspondre le trafic aux routes selon l'ordre suivant :

1. La passerelle vérifie d'abord la Policy-based Route Table, en faisant correspondre les routes par priorité de politique, et non par la règle du préfixe le plus long.

2. La passerelle vérifie ensuite la Destination-based Route Table, en faisant correspondre les routes selon la règle du préfixe le plus long.

3. Enfin, la passerelle vérifie la BGP Route Table.

Aperçu de bout en bout

La connexion d'un VPC à un centre de données via une passerelle VPN implique trois tables de routage :

Configuration des routes basées sur la destination

Une route basée sur la destination achemine le trafic en fonction de l'adresse IP de destination.

Règles de correspondance :

• Correspondance du préfixe le plus long : le trafic correspond à la route dont le masque de sous-réseau est le plus long. Par exemple, si les routes 10.0.0.0/8 et 10.10.0.0/16 existent toutes les deux, le trafic destiné à 10.10.10.1 correspondra à la route 10.10.0.0/16.

• Routes actif/passif (uniquement pour les anciennes passerelles VPN à tunnel unique) : seules les routes actives correspondent ; les routes de secours sont ignorées. Configuration des routes actif/passif.

Configuration des routes basées sur une politique

Une route basée sur une politique fait correspondre le trafic en fonction de l'adresse IP source et de l'adresse IP de destination. Elle est prioritaire par rapport aux routes basées sur la destination et aux routes BGP.

Ordre de correspondance :

1. Priorité de la politique : les routes ayant la valeur de priorité la plus faible sont mises en correspondance en premier.

2. Routes de même priorité : elles sont traitées séquentiellement selon leur date de création. La première correspondance trouvée est utilisée.

Annoncer vers une table de routage VPC

Après la création des routes basées sur une politique et des routes basées sur la destination, elles sont par défaut à l'état Non publié dans la table de routage VPC. Vous pouvez publier directement les routes ajoutées manuellement dans la table de routage système du VPC sans avoir à les ajouter manuellement dans la table de routage du VPC.

• Les routes sont annoncées uniquement dans la table de routage système du VPC, et non dans les tables de routage personnalisées. Pour ajouter une route à une table de routage personnalisée, utilisez la procédure Ajouter et supprimer des entrées de routage.

• Si des routes ayant le même bloc CIDR de destination existent à la fois dans les tables de routage basées sur une politique et basées sur la destination, le retrait de la route d'une table entraîne également son retrait de l'autre.

• Si une entrée de route avec le même bloc CIDR de destination que la route à publier, mais avec un prochain saut différent, existe déjà dans la table de routage VPC (par exemple, pointant vers une connexion d'appairage ou une passerelle NAT), le système signalera un conflit de routage (route en double) lors de la publication. Après avoir évalué vos besoins métier, supprimez la route conflictuelle ou ajustez le plan d'adressage CIDR, puis effectuez à nouveau l'opération de publication une fois le conflit résolu. Pour plus d'informations, consultez la section Gérer les erreurs de routes en double.

Limites

Ces limites s'appliquent aux routes basées sur la destination et aux routes basées sur une politique :

• Vous ne pouvez pas ajouter de route avec le bloc CIDR de destination 0.0.0.0/0.

• N'ajoutez pas de route vers 100.64.0.0/10 (y compris les sous-réseaux et les super-réseaux). Cela entraînerait des échecs de connexion ou de négociation IPsec.

• Si le système signale un conflit de routage, consultez la section Gérer les erreurs de routes en double.

Vue d'ensemble de bout en bout

Principes d'annonce des routes BGP

• Trafic entrant vers le cloud : les routes annoncées par le centre de données via BGP sont propagées vers la passerelle VPN, puis automatiquement vers la table de routage système du VPC (la propagation des routes doit être activée).

• Trafic sortant depuis le cloud : les entrées de route système de la table de routage système du VPC sont automatiquement apprises par la passerelle VPN (la propagation des routes doit être activée), puis propagées vers le centre de données via BGP.

Procédure

Avant de commencer, assurez-vous que :

• La passerelle VPN prend en charge le protocole BGP. Vérifier si une passerelle VPN prend en charge BGP.

• L'équipement de passerelle de votre centre de données prend en charge le protocole BGP.

Limites

• Chaque table de routage BGP de passerelle VPN prend en charge jusqu'à 50 routes (extensible à 200 ; contactez votre gestionnaire de compte).

• La passerelle VPN n'accepte pas les routes BGP dont le bloc CIDR de destination est 0.0.0.0/0.

• Lorsque le protocole BGP est activé pour plusieurs connexions IPsec-VPN sur la même passerelle VPN, le paramètre Local ASN doit être identique pour toutes les connexions.

• N'échangez pas de routes entre différentes connexions IPsec-VPN.

• Lorsqu'un VPC est associé à plusieurs passerelles VPN, celles-ci ne prennent pas en charge l'établissement d'une relation de peering BGP entre elles. N'échangez pas de routes entre différentes passerelles VPN.

• Si un VPC est associé à plusieurs passerelles VPN utilisant toutes le protocole BGP et connectées à la même passerelle client, le paramètre Local ASN des connexions IPsec-VPN sur chaque passerelle VPN doit être identique afin d'éviter les boucles de routage.

• Si plusieurs connexions IPsec-VPN à double tunnel utilisent simultanément le protocole BGP, les blocs CIDR de destination des routes apprises par chaque connexion ne doivent pas se chevaucher.

• Lors de l'utilisation d'un circuit Express Connect et d'une passerelle VPN pour un accès actif/passif à un VPC, l'ASN local configuré sur le routeur border (VBR) et sur la passerelle VPN doit être identique.

• Si le VPC de la passerelle VPN appartient à un Cloud Enterprise Network (CEN), activez le chevauchement des routes. Cette option est activée par défaut pour les instances CEN créées après mars 2019.

• Si plusieurs VPC au sein d'un même CEN se connectent au même centre de données via BGP, les routes dynamiques peuvent se propager via le CEN vers d'autres VPC, provoquant une instabilité des routes (flapping). Utilisez plutôt des routes statiques.

• Passerelle VPN en mode simple tunnel : ne propagez pas les routes pour 100.64.0.0/10 (y compris ses sous-réseaux et super-réseaux). Vous pouvez éviter ce problème en Mettant à niveau une connexion IPsec-VPN vers le mode double tunnel.

Recommandations de configuration des routes

• Utilisez la même méthode de routage pour toutes les connexions IPsec-VPN sur une passerelle VPN. Ne mélangez pas les routes basées sur la destination, les routes basées sur des politiques et les routes BGP.

• Lors de la configuration des routes BGP, définissez le paramètre Routing Mode de la connexion IPsec-VPN sur Destination Routing Mode.

Vérifier si une passerelle VPN prend en charge le protocole BGP

• Les passerelles VPN nouvellement créées qui prennent en charge les connexions IPsec-VPN à double tunnel prennent en charge le protocole BGP par défaut.

• Pour les passerelles VPN existantes : appelez l'opération DescribeVpnGateway et vérifiez que le champ Tag contient le tag VpnEnableBgp avec la valeur true.

• Options de mise à niveau pour les passerelles non prises en charge :

  - Passerelle VPN en mode double tunnel : Mettre à niveau une passerelle VPN (type standard uniquement)

  - Passerelle VPN en mode simple tunnel : Passer au mode double tunnel

Configuration des routes actif/passif

• Pour configurer le mode actif/passif sur une ancienne passerelle VPN en mode simple tunnel, mettez à niveau une connexion IPsec-VPN vers le mode double tunnel. Les connexions à double tunnel offrent un mode actif/passif par défaut sans nécessiter de configuration de poids.

• Si vous devez toujours configurer un lien actif/passif en mode simple tunnel, suivez ces étapes :

  1. La route principale a un poids de 100 et la route de secours a un poids de 0. Les blocs CIDR de destination doivent être identiques, mais les sauts suivants doivent être différents. Pour les routes basées sur des politiques, les blocs CIDR source doivent également être identiques.

  2. Configurez une vérification de l'état pour la connexion IPsec-VPN afin d'activer le basculement automatique. Vous trouverez cette option dans les paramètres de configuration du tunnel de la connexion IPsec-VPN.

  3. Pour modifier le poids d'une route, supprimez d'abord la route de secours, modifiez le poids de la route active, puis recréez la route de secours. La même procédure s'applique lors de la modification du poids de la route de secours.

  Pour les instances de passerelle VPN qui n'ont pas été mises à niveau depuis le 12 octobre 2023, si vous devez configurer des routes basées sur des politiques en mode actif/passif, assurez-vous qu'un lien actif/passif est spécifié pour chaque bloc CIDR. Si un seul lien est configuré pour un bloc CIDR, le basculement pour les autres blocs CIDR peut échouer. Vous pouvez éviter ce problème en mettant à niveau la passerelle VPN ou en mettant à niveau une connexion IPsec-VPN vers le mode double tunnel . Ce problème n'affecte pas les instances de passerelle VPN créées ou mises à niveau après le 12 octobre 2023.

• Après la configuration, la route prend effet selon les règles suivantes :

  |
  **Connexion IPsec-VPN pour la route active**
  |
  **Connexion IPsec-VPN pour la route de secours**
  |
  **Route effective**
  | | --- | --- | --- | |
  Up (négociation réussie et vérification de l'état normale)
  |
  Tout état
  |
  Route active
  | |
  Down
  |
  Up
  |
  Route de secours
  | |
  Down
  |
  Down
  |
  Route active (par défaut)
  |
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

FAQ

Q : Lorsqu'une instance ECS accède à des ressources locales via une passerelle VPN, comment le trafic correspond-il à la table de routage ?

Lorsqu'une instance ECS communique avec des ressources locales via un VPN, le trafic est transféré selon l'ordre de correspondance suivant :

1. Table de routage VPC : le système interroge d'abord la table de routage VPC. Si une entrée de route correspondant à l'adresse IP de destination existe (avec la passerelle VPN comme saut suivant), le trafic est transféré vers la passerelle VPN.

2. Table de routage de la passerelle VPN : la passerelle VPN détermine ensuite, sur la base de sa propre table de routage (routage basé sur la destination ou routage basé sur des politiques), vers quelle connexion IPsec le trafic est transféré.

Q : Que faire si le centre de données local ne parvient pas à pinguer une instance ECS cloud ou si la connexion SSH échoue ?

Effectuez le dépannage dans l'ordre suivant :

1. Confirmez que la configuration de la route VPN est correcte (la table de routage VPC contient une entrée de route pointant vers la passerelle VPN, et la table de routage de la passerelle VPN dispose de la route de destination ou de la route basée sur des politiques correspondante).

2. Vérifiez les règles du groupe de sécurité de l'instance ECS cloud :

   • Test Ping (ICMP) : confirmez que la direction entrante du groupe de sécurité autorise le protocole ICMP depuis le bloc CIDR du centre de données local.

   • Connexion SSH (port TCP 22) : confirmez que la direction entrante du groupe de sécurité autorise le port TCP 22 depuis le bloc CIDR du centre de données local.

Si la configuration de la route est normale mais que la connectivité échoue toujours, le blocage par le groupe de sécurité est une cause fréquente et doit être vérifié en premier lieu pour éviter de diagnostiquer à tort un problème de routage.

Q : Lorsqu'une passerelle NAT VPC est utilisée conjointement avec IPsec-VPN, comment configurer les routes de l'instance ECS ?

Dans un scénario combinant une passerelle NAT et une passerelle VPN, le trafic envoyé par une instance ECS vers des services locaux doit d'abord être traduit par la passerelle NAT, puis transmis via le tunnel VPN. Les étapes de configuration sont les suivantes :

1. Créez une table de routage personnalisée dans la console des tables de routage et associez-la au vSwitch où réside l'instance ECS.

2. Ajoutez une entrée de route à la table de routage personnalisée : définissez le bloc CIDR de destination sur l'adresse du service interne local et le saut suivant sur la passerelle NAT.

Pour plus d'informations, consultez Accès au réseau privé via les passerelles NAT et VPN.

Q : Quel est l'impact de la configuration du sélecteur de trafic sur 0.0.0.0/0 ou sur un grand bloc CIDR (tel que 10.0.0.0/8) ?

La portée du sélecteur de trafic détermine le type de trafic qui déclenche la négociation IKE, mais le trafic qui entre effectivement dans le tunnel est contrôlé par les décisions de routage :

• La configuration de 0.0.0.0/0 n'affecte pas directement la connectivité du réseau local. Toutefois, si vous pointez la route 0.0.0.0/0 vers le tunnel VPN dans la table de routage locale, tout le trafic (y compris l'accès à Internet) tentera d'entrer dans le tunnel, ce qui peut entraîner une panne de l'accès à Internet.

• Vous pouvez configurer le bloc CIDR local comme une plage étendue (telle que 10.0.0.0/8), mais assurez-vous que la liste de contrôle d'accès cryptographique (crypto ACL) sur l'appareil homologue est également modifiée pour correspondre au bloc CIDR agrégé. Si le bloc CIDR homologue ne peut pas être agrégé, vous pouvez utiliser 0.0.0.0/0 et ajouter des entrées de route spécifiques sous la connexion IPsec pour réaliser un contrôle granulaire du trafic et réduire le nombre de négociations SA.

Pour plus d'informations, consultez Recommandations et FAQ pour la configuration de l'interconnexion multi-CIDR.

Tutoriels

Consultez Configuration strongSwan.