

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# AWS Site-to-Site VPN options de routage
<a name="VPNRoutingTypes"></a>

AWS recommande de faire de la publicité pour des itinéraires BGP spécifiques afin d'influencer les décisions de routage dans la passerelle privée virtuelle. Consultez la documentation de votre fournisseur pour connaître les commandes spécifiques à votre appareil.

Lorsque vous créez plusieurs connexions VPN, la passerelle réseau privé virtuel envoie le trafic réseau vers la connexion VPN appropriée à l'aide de routes affectées statiquement ou d'annonces de routes BGP. Le choix de la route dépend de la façon dont la connexion VPN a été configurée. Les routes affectées statiquement sont préférées aux routes annoncées par BGP lorsque des routes identiques existent dans la passerelle réseau privé virtuel. Si vous sélectionnez l'option d'utiliser une annonce BGP, vous ne pouvez pas spécifier de routes statiques.

Pour plus d’informations sur la priorité de route, consultez [Tables de routage et priorité des itinéraires](vpn-route-priority.md).

Lorsque vous créez une connexion Site-to-Site VPN, vous devez effectuer les opérations suivantes :
+ Spécifiez le type de routage que vous prévoyez d'utiliser (statique ou dynamique)
+ Mettez à jour la [table de routage](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) de votre sous-réseau

Le nombre de routes que vous pouvez ajouter à une table de routage est limité. Pour plus d'informations, consultez la section Tables de routage dans [Quotas Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html) dans le *Guide de l'utilisateur Amazon VPC*.

**Topics**
+ [Routage statique et dynamique](vpn-static-dynamic.md)
+ [Tables de routage et priorité des itinéraires](vpn-route-priority.md)
+ [Routage pendant les mises à jour des points de terminaison du tunnel VPN](routing-vpn-tunnel-updates.md)
+ [IPv4 et IPv6 trafic](ipv4-ipv6.md)

# Routage statique et dynamique dans AWS Site-to-Site VPN
<a name="vpn-static-dynamic"></a>

Le type de routage que vous sélectionnez peut dépendre de la marque et du modèle de votre périphériques de passerelle client. Si votre dispositif de passerelle client prend en charge le protocole BGP (Border Gateway Protocol), spécifiez le routage dynamique lorsque vous configurez votre connexion Site-to-Site VPN. Si votre périphérique de passerelle client ne prend pas en charge le BGP, spécifiez un routage statique.

**Note**  
Site-to-Site Les concentrateurs VPN ne prennent en charge que le routage BGP. Le routage statique n'est pas pris en charge pour les connexions VPN qui utilisent un concentrateur Site-to-Site VPN.

Si vous utilisez un appareil qui prend en charge la publicité BGP, vous ne spécifiez pas de routes statiques vers la connexion Site-to-Site VPN, car l'appareil utilise le protocole BGP pour annoncer ses itinéraires vers la passerelle privée virtuelle. Si vous utilisez un périphérique qui ne prend pas en charge les annonces BGP, vous devez sélectionner un routage statique et entrer les routes (préfixes IP) pour votre réseau qui doivent être communiquées à la passerelle réseau privé virtuel. 

Nous vous recommandons d'utiliser des périphériques compatibles avec BGP, quand c'est possible, puisque le protocole BGP offre de solides contrôles de détection du caractère vivant qui peuvent assister le failover vers le second tunnel VPN si le premier tunnel s'arrête. Les périphériques qui ne prennent pas en charge BGP peuvent également exécuter des vérifications de l'état pour assister le failover vers le second tunnel lorsque c'est nécessaire.

Vous devez configurer votre dispositif de passerelle client pour acheminer le trafic de votre réseau local vers la connexion Site-to-Site VPN. La configuration dépend de la marque et du modèle de votre périphérique. Pour de plus amples informations, veuillez consulter [AWS Site-to-Site VPN dispositifs de passerelle client](your-cgw.md).

# Tables de routage et priorité des AWS Site-to-Site VPN itinéraires
<a name="vpn-route-priority"></a>

Les [tables de routage](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) déterminent où le trafic réseau de votre VPC est dirigé. Dans votre table de routage VPC, vous devez ajouter une route pour votre réseau distant et spécifier la passerelle réseau privé virtuel comme cible. Cela permet au trafic de votre VPC destiné à votre réseau distant de s'acheminer via la passerelle réseau privé virtuel et sur l'un des tunnels VPN. Vous pouvez autoriser la propagation du routage pour votre table de routage pour automatiquement propager vos routes réseau vers la table pour vous. 

Nous utilisons la route la plus spécifique de votre table de routage qui correspond au trafic afin de déterminer comment router le trafic (correspondance de préfixe le plus long). Si votre table de routage comporte des routes qui se chevauchent ou correspondent, les règles suivantes s'appliquent :
+ Si les routes propagées à partir d'une connexion Site-to-Site VPN ou d'une Direct Connect connexion se chevauchent avec la route locale de votre VPC, la route locale est préférable, même si les routes propagées sont plus spécifiques. 
+ Si les routes propagées à partir d'une connexion ou d'une Direct Connect connexion Site-to-Site VPN ont le même bloc d'adresse CIDR de destination que les autres routes statiques existantes (la correspondance de préfixe la plus longue ne peut pas être appliquée), nous donnons la priorité aux routes statiques dont les cibles sont une passerelle Internet, une passerelle privée virtuelle, une interface réseau, un identifiant d'instance, une connexion d'appairage VPC, une passerelle NAT, une passerelle de transit ou un point de terminaison VPC de passerelle.

Par exemple, la table de routage suivante a une route statique vers une passerelle Internet et une route propagée vers une passerelle réseau privé virtuel. Les deux routes ont pour destination : `172.31.0.0/24`. Dans ce cas, tout le trafic destiné à l'adresse `172.31.0.0/24` est routé vers la passerelle Internet. Il s'agit d'une route statique qui a donc priorité sur la route propagée.


| Destination | Cible | 
| --- | --- | 
| 10.0.0.0/16 | Locale | 
| 172.31.0.0/24 | vgw-11223344556677889 (propagée) | 
| 172.31.0.0/24 | igw-12345678901234567 (statique) | 

Seuls les préfixes IP connus de la passerelle réseau privé virtuel, que ce soit par une annonce BGP ou une entrée de routage statique, peuvent recevoir du trafic sortant de votre VPC. La passerelle réseau privé virtuel n'achemine pas d'autre trafic destiné en dehors des annonces BGP reçues, des saisies de routage statique ou du CIDR de VPC attaché. Les passerelles privées virtuelles ne prennent pas en charge le IPv6 trafic.

Quand une passerelle réseau privé virtuel reçoit des informations de routage, elle utilise la sélection des chemins pour déterminer comment acheminer le trafic. La correspondance de préfixe la plus longue s'applique si tous les points de terminaison sont sains. L'état du point de terminaison d'un tunnel est prioritaire par rapport aux autres attributs de routage. Cette priorité s'applique aux VPNs passerelles privées virtuelles et aux passerelles de transit. Si les préfixes sont les mêmes, la passerelle réseau privé virtuel donne la priorité suivante aux routes, de la route la plus préférée à la route la moins préférée : 
+ Routes propagées par BGP à partir d'une connexion Direct Connect 

  Les routes Blackhole ne sont pas propagées vers une passerelle client Site-to-Site VPN via BGP. 
+ Routes statiques ajoutées manuellement pour une connexion Site-to-Site VPN
+ Routes propagées par BGP à partir d'une connexion VPN Site-to-Site
+ Pour les préfixes correspondants lorsque chaque connexion Site-to-Site VPN utilise BGP, le PATH AS est comparé et le préfixe avec le plus court AS PATH est préféré.
**Note**  
AWS recommande vivement d'utiliser des dispositifs de passerelle client qui prennent en charge le routage asymétrique.  
Pour les périphériques de passerelle client qui prennent en charge l'acheminement asymétrique, nous *déconseillons* d'utiliser le préfixe AS PATH, afin de garantir que les deux tunnels ont le même AS PATH. Cela permet de s'assurer que la valeur multi-exit discriminator (MED) que nous avons définie sur un tunnel lors des [mises à jour du point de terminaison du tunnel VPN](routing-vpn-tunnel-updates.md) est utilisée pour déterminer la priorité du tunnel.  
Pour les périphériques de passerelle client qui ne prennent pas en charge l'acheminement asymétrique, vous pouvez utiliser AS PATH prepending et Local Preference pour préférer un tunnel à l'autre. Toutefois, lorsque le chemin de sortie change, cela peut entraîner une baisse du trafic.
+ Lorsque les AS PATHs ont la même longueur et si le premier AS de l'AS\$1SEQUENCE est le même sur plusieurs chemins, multi-exit discriminators (MEDs) sont comparés. Le chemin avec la valeur MED la plus faible est préféré.

La priorité de route est affectée lors des [mises à jour des points de terminaison du tunnel VPN](routing-vpn-tunnel-updates.md).

Sur une connexion Site-to-Site VPN, AWS sélectionne l'un des deux tunnels redondants comme chemin de sortie principal. Cette sélection peut parfois changer, et nous vous recommandons fortement de configurer les deux tunnels pour une haute disponibilité, et permet un routage asymétrique. L'état du point de terminaison d'un tunnel est prioritaire par rapport aux autres attributs de routage. Cette priorité s'applique aux VPNs passerelles privées virtuelles et aux passerelles de transit.

Pour une passerelle privée virtuelle, un tunnel pour toutes les connexions Site-to-Site VPN de la passerelle sera sélectionné. Pour utiliser plusieurs tunnels, nous vous recommandons d'utiliser le protocole ECMP (Equal Cost Multipath), qui est pris en charge pour les connexions Site-to-Site VPN sur une passerelle de transit. Pour plus d'informations, consultez [Passerelles de transit](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html) dans *Passerelles de transit Amazon VPC*. L'ECMP n'est pas pris en charge pour les connexions Site-to-Site VPN sur une passerelle privée virtuelle.

Pour les connexions Site-to-Site VPN qui utilisent le protocole BGP, le tunnel principal peut être identifié par la valeur multi-exit discriminator (MED). Nous vous recommandons de publier des itinéraires BGP plus spécifiques pour influencer les décisions de routage. 

Pour les connexions Site-to-Site VPN qui utilisent le routage statique, le tunnel principal peut être identifié par des statistiques ou des métriques de trafic. 

# Routage pendant les mises à jour des points de terminaison du tunnel VPN
<a name="routing-vpn-tunnel-updates"></a>

Une connexion Site-to-Site VPN consiste en deux tunnels VPN entre un dispositif de passerelle client et une passerelle privée virtuelle ou une passerelle de transit. Nous vous recommandons de configurer les deux tunnels pour la redondance. De temps en temps, effectue AWS également une maintenance de routine sur votre connexion VPN, ce qui peut désactiver brièvement l'un des deux tunnels de votre connexion VPN. Pour de plus amples informations, veuillez consulter [Notifications de remplacement des points de terminaison du tunnel](monitoring-vpn-health-events.md#tunnel-replacement-notifications).

Lorsque nous effectuons des mises à jour sur un tunnel VPN, nous définissons une valeur MED (multi-exit discriminator) inférieure sur l'autre tunnel. Si vous avez configuré votre périphérique de passerelle client afin qu'il utilise les deux tunnels, votre connexion VPN utilise l'autre tunnel (en amont) pendant le processus de mise à jour du point de terminaison du tunnel.

**Note**  
 Pour vous assurer que le tunnel en amont avec la valeur MED inférieure est préféré, assurez-vous que votre périphérique de passerelle client utilise les mêmes valeurs de poids et de préférence locale pour les deux tunnels (les valeurs de poids et de préférence locale ont une priorité plus élevée que la valeur MED).

# IPv4 et IPv6 trafic entrant AWS Site-to-Site VPN
<a name="ipv4-ipv6"></a>

Votre connexion Site-to-Site VPN sur une passerelle de transit peut prendre en charge le IPv4 trafic ou le IPv6 trafic à l'intérieur des tunnels VPN. Par défaut, une connexion Site-to-Site VPN prend en charge le IPv4 trafic à l'intérieur des tunnels VPN. Vous pouvez configurer une nouvelle connexion Site-to-Site VPN pour prendre en charge le IPv6 trafic à l'intérieur des tunnels VPN. Ensuite, si votre VPC et votre réseau local sont configurés pour l' IPv6 adressage, vous pouvez envoyer IPv6 du trafic via la connexion VPN.

Si vous activez IPv6 les tunnels VPN pour votre connexion Site-to-Site VPN, chaque tunnel possède deux blocs CIDR. L'un est un bloc d'adresse IPv4 CIDR de taille /30 et l'autre est un bloc d'adresse CIDR de taille /126 IPv6 .

## IPv4 et IPv6 support
<a name="ipv6-tunnel-options"></a>

Site-to-Site Les connexions VPN prennent en charge les configurations IP suivantes :
+ **IPv4 tunnel extérieur avec paquets IPv4 internes** : fonctionnalité IPv4 VPN de base prise en charge sur les passerelles privées virtuelles, les passerelles de transit et le Cloud WAN.
+ **IPv4 tunnel extérieur avec paquets IPv6 internes - Autorise les** IPv6 applications/le transport dans le tunnel VPN. Pris en charge sur les passerelles de transit et le Cloud WAN. Cela n'est pas pris en charge pour les passerelles privées virtuelles.
+ **IPv6 tunnel extérieur avec paquets IPv6 internes** - Permet une IPv6 migration complète avec des IPv6 adresses à la fois pour le tunnel externe IPs et pour le paquet interne IPs. Pris en charge à la fois pour les passerelles de transit et le Cloud WAN.
+ **IPv6 tunnel extérieur avec paquets IPv4 internes** - Permet l'adressage du tunnel IPv6 externe tout en prenant en charge IPv4 les applications existantes au sein du tunnel. Pris en charge à la fois pour les passerelles de transit et le Cloud WAN.

Les règles suivantes s’appliquent :
+ IPv6 les adresses du tunnel extérieur ne IPs sont prises en charge que sur les connexions Site-to-Site VPN terminées sur une passerelle de transit ou sur le Cloud WAN. Site-to-Site Les connexions VPN sur une passerelle privée virtuelle ne prennent pas en charge IPv6 le tunnel IPs extérieur.
+ Lorsque vous utilisez IPv6 un tunnel externe IPs, vous devez attribuer IPv6 des adresses à la fois du AWS côté de la connexion VPN et de la passerelle client pour les deux tunnels VPN.
+ Vous ne pouvez pas activer le IPv6 support pour une connexion Site-to-Site VPN existante. Vous devez supprimer la connexion existante et en créer une nouvelle.
+ Une connexion Site-to-Site VPN ne peut pas prendre en charge à la fois IPv6 le trafic IPv4 et le trafic. Les paquets encapsulés internes peuvent être l'un IPv6 ou l'autre IPv4, mais pas les deux. Vous avez besoin de connexions Site-to-Site VPN distinctes pour le transport IPv4 et IPv6 les paquets.
+ Les adresses IP privées VPNs ne prennent pas en charge IPv6 les adresses pour le tunnel extérieur IPs. Ils utilisent des adresses RFC 1918 ou CGNAT. Pour plus d'informations sur la RFC 1918, consultez la [RFC 1918 - Allocation d'adresses pour les réseaux Internet privés](https://datatracker.ietf.org/doc/html/rfc1918).
+ IPv6 VPNs supportent les mêmes limites de débit (Gbit/s et PPS), de MTU et de route que. IPv4 VPNs
+ Le IPSec chiffrement et l'échange de clés fonctionnent de la même manière pour les deux IPv4 et IPv6 VPNs.

Pour plus d'informations sur la création d'une connexion VPN avec IPv6 assistance, voir [Création d'une connexion VPN](SetUpVPNConnections.md#vpn-create-vpn-connection) dans Commencer avec un Site-to-Site VPN.