Schéma VPN site-to-site : tunnels IPsec, routage BGP et redondance

Votre datacenter atteint ses charges de travail AWS par un VPN site-to-site qui tourne sans bruit depuis un an. Une nuit, AWS remplace un point de terminaison de tunnel lors d'une maintenance de routine, et toutes les connexions vers le VPC tombent. Seul le tunnel 1 avait été configuré sur le pare-feu. Le tunnel 2 affichait DOWN depuis le jour de sa création.

Sur la plupart des schémas, un VPN site-to-site tient en une ligne. En pratique, ce sont deux tunnels IPsec, deux sessions BGP et un budget de MTU, et les pannes viennent des éléments que cette ligne cache. Cet article couvre les briques d'IPsec, un exemple AWS, le routage statique face à BGP, la redondance, la MTU et le MSS, la supervision, et les cas où une liaison dédiée convient mieux.

VPN site-to-site ou VPN d'accès à distance

Un VPN site-to-site relie deux réseaux : les passerelles à chaque extrémité portent les tunnels, et les hôtes derrière elles n'ont besoin d'aucun logiciel VPN. Un VPN d'accès à distance relie un seul appareil, avec un client sur chaque portable et un utilisateur qui se connecte. Si le vrai besoin est que des personnes accèdent à des applications internes, un proxy sensible à l'identité dans une architecture zero trust convient souvent mieux que l'un ou l'autre.

Les briques d'IPsec

IKEv2 (RFC 7296) authentifie les pairs et négocie les clés. ESP (RFC 4303) chiffre le trafic.

IKEv2 établit normalement l'IKE SA et la première Child SA en quatre messages (IKE_SA_INIT et IKE_AUTH). IKEv1 a été déclaré obsolète en 2023 par la RFC 9395. Pour les algorithmes, la RFC 8247 rend le groupe DH 14 obligatoire à l'implémentation et recommande le groupe 19 ; les groupes 2, 5, 23 et 24 ne devraient pas être utilisés, et le groupe 22 ne doit pas l'être.

Deux tunnels par connexion : un exemple AWS

Un AWS Site-to-Site VPN relie votre équipement customer gateway à une passerelle côté AWS. Selon la documentation AWS sur les options de tunnel, chaque connexion a deux tunnels, chacun avec sa propre IP publique, qui se terminent dans des Availability Zones différentes.

AWS remplace les points de terminaison de tunnel pour des correctifs et le retrait de matériel, un tunnel à la fois, si bien qu'un équipement qui n'utilise qu'un tunnel peut perdre la connectivité à chaque remplacement de ce point de terminaison. AWS Health envoie un avis mensuel lorsqu'un tunnel est indisponible plus d'une heure par jour.

Chaque tunnel a un /30 interne pris dans 169.254.0.0/16. AWS prend la première adresse utilisable, votre équipement la seconde, et BGP s'établit entre elles. Votre équipement initie IKE, sauf si vous réglez l'action de démarrage sur start (IKEv2 uniquement). AWS évalue les propositions à partir de la valeur la plus basse de sa liste autorisée, quel que soit l'ordre dans lequel votre équipement les envoie ; retirez donc IKEv1, SHA-1 et les groupes DH 2, 5 et 22 à 24 des deux côtés.

Définissez les tunnels dans le code pour qu'ils restent identiques. Dans Terraform, le tunnel 1 :

resource "aws_vpn_connection" "dc" {
  vpn_gateway_id      = aws_vpn_gateway.main.id
  customer_gateway_id = aws_customer_gateway.dc.id
  type                = "ipsec.1"
  static_routes_only  = false

  tunnel1_inside_cidr                  = "169.254.10.0/30"
  tunnel1_ike_versions                 = ["ikev2"]
  tunnel1_phase1_encryption_algorithms = ["AES256-GCM-16"]
  tunnel1_phase1_integrity_algorithms  = ["SHA2-384"]
  tunnel1_phase1_dh_group_numbers      = [20]
  tunnel1_phase2_encryption_algorithms = ["AES256-GCM-16"]
  tunnel1_phase2_dh_group_numbers      = [20]
  tunnel1_dpd_timeout_seconds          = 30
  tunnel1_dpd_timeout_action           = "restart"
  tunnel1_startup_action               = "start"
  # tunnel2_*: the same values with 169.254.10.4/30
}

Routage statique ou BGP

Le routage statique liste vos préfixes sur la connexion et laisse le basculement aux contrôles de santé de votre équipement. Avec BGP, chaque tunnel porte une session eBGP, et les routes d'un tunnel mort sont retirées dès que sa session tombe. AWS recommande BGP partout où l'équipement le gère, et ECMP l'exige. Quatre règles :

1. Utilisez des ASN privés distincts. Le côté AWS prend 64512 par défaut. Donnez à votre site son propre ASN privé : 64512 à 65534, ou 4200000000 à 4294967294 (RFC 6996).
2. Annoncez des résumés. Une virtual private gateway accepte au plus 100 routes de votre équipement, une limite fixe.
3. Ne faites jamais se chevaucher les CIDR. La route locale du VPC l'emporte sur toute route VPN, même plus spécifique. Planifiez l'espace d'adressage entre les sites, ou faites du NAT d'un côté.
4. Connaissez les critères de départage. Pour un même préfixe, une virtual private gateway préfère Direct Connect, puis les routes VPN statiques, puis les routes BGP ; ensuite le chemin AS le plus court, puis le MED le plus bas.

Sans ECMP, AWS renvoie le trafic par un seul tunnel à la fois, signalé par le MED. La recommandation AWS sur la priorité des routes est d'autoriser le routage asymétrique et de garder des chemins AS égaux. Si votre pare-feu à états ne le supporte pas, allongez le chemin AS par prepending sur le tunnel 2 et abaissez sa local preference ; un changement du chemin de sortie AWS peut alors interrompre des flux. L'exemple de configuration AWS utilise un keepalive de 10 secondes et un hold time de 30 secondes, et non les 90 secondes que suggère la RFC 4271.

Conceptions de redondance

Deux tunnels couvrent les pannes côté AWS. Ils partagent encore votre équipement, votre FAI et votre site.

Avec deux équipements, chacun a sa propre connexion VPN et tous deux annoncent les mêmes préfixes. ECMP répartit chaque flux sur un tunnel par hachage ; quatre tunnels donnent donc environ 5 Gbps au total, mais une seule connexion TCP plafonne toujours à 1,25 Gbps, et un pare-feu à états peut exiger du source NAT pour la symétrie. Avec de nombreux sites, la transit gateway devient le hub d'un réseau hub-and-spoke.

MTU et MSS clamping

Chaque paquet tunnelisé porte un nouvel en-tête IP plus la surcharge ESP. AWS prend en charge au plus une MTU de 1 446 octets et un MSS TCP de 1 406 octets, sans Path MTU Discovery ni jumbo frames. Les valeurs exactes dépendent de vos algorithmes, selon les bonnes pratiques AWS pour les customer gateways :

Réglez la MTU du tunnel et bridez (clamp) le MSS des paquets TCP SYN dans les deux sens, car chaque côté annonce le sien. Sur une passerelle Linux :

ip link set dev vti1 mtu 1446
iptables -t mangle -A FORWARD -o vti1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1406
iptables -t mangle -A FORWARD -i vti1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1406

Le symptôme classique d'une mauvaise valeur : le ping et SSH fonctionnent, mais les copies de fichiers se bloquent. La page AWS sur les exigences des équipements suggère 1 399 octets, ce qui fonctionne aussi mais gaspille quelques octets.

Superviser les tunnels

• État des tunnels. CloudWatch publie TunnelState par tunnel ; pour les connexions BGP, 1 signifie que la session est établie. Déclenchez une alarme dès que l'un des tunnels passe sous 1. TunnelDataIn et TunnelDataOut montrent quel tunnel porte le trafic.
• Journaux. Les journaux Site-to-Site VPN enregistrent les états IKE, les événements DPD, l'état BGP et les changements de routes.
• Votre côté. Surveillez l'état BGP et les préfixes reçus par tunnel. Une session établie avec zéro préfixe reste une panne.

Quand un tunnel ne monte pas, vérifiez couche par couche : IKE SA, IPsec SA, un ping vers l'adresse interne AWS, puis BGP.

Quand passer à Direct Connect

Passez-y quand le trafic est constant à l'échelle du gigabit, que la latence compte, ou que la sortie Internet coûte plus cher qu'un port. Depuis septembre 2026, les connexions dédiées de 10 et 100 Gbps peuvent bénéficier d'une tarification forfaitaire qui inclut le transfert de données sortant dans un palier. Gardez le VPN en secours : une virtual private gateway préfère les routes Direct Connect, donc le trafic n'emprunte les tunnels que si le circuit tombe. Le schéma d'architecture de reprise après sinistre couvre cette planification.

Le schéma du VPN site-to-site

Comment le lire :

• À gauche, le datacenter : 10.20.0.0/16 dans l'AS 65010. Le LAN envoie le trafic du VPC au pare-feu de bordure, l'équipement customer gateway.
• Deux tunnels atteignent deux points de terminaison de la virtual private gateway, chacun avec son /30 interne et sa session BGP. Les deux sont actifs ; AWS choisit le tunnel de retour.
• À droite, le VPC : 10.50.0.0/16, avec des sous-réseaux privés dans deux Availability Zones et une route propagée vers 10.20.0.0/16.
• Le bloc Markdown liste les paramètres qui doivent concorder sur les deux tunnels.
• Les notes du bas disent ce que couvrent deux tunnels (les remplacements de points de terminaison) et ce qu'ils ne couvrent pas (un pare-feu, un FAI).

Dessiner clairement des schémas de VPN site-to-site

• Étiquetez les deux extrémités avec le CIDR, l'ASN et l'IP publique. La plupart des tickets VPN commencent par l'un d'eux.
• Dessinez les deux tunnels avec leurs /30 internes et leurs pairs BGP, et indiquez lequel est préféré et pourquoi.
• Mettez les paramètres communs dans un seul cadre : version d'IKE, algorithmes, groupe DH, durées de vie, MTU et MSS.
• Montrez les points uniques de défaillance, comme un seul équipement ou un seul FAI.
• Omettez les clés pré-partagées, les détails internes du FAI et les listes d'hôtes.

Le schéma de topologie réseau couvre le côté bureau ; le schéma de VPC AWS couvre les sous-réseaux et les tables de routage.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez un Cadre du pack Base pour le datacenter, nommé avec son CIDR et son ASN. À l'intérieur, ajoutez un Sous-réseau avec deux nœuds Serveur et un Pare-feu, tous du pack Réseau.
3. Ajoutez un VPC du pack Réseau. À l'intérieur, ajoutez un Cadre pour la virtual private gateway avec deux nœuds Routeur, et deux Sous-réseau privés avec une Instance de calcul du pack Cloud dans chacun.
4. Tracez les tunnels du pare-feu vers les points de terminaison avec des flèches aux deux bouts, étiquetés avec le /30 interne et les pairs BGP. Ajoutez des liens du LAN au pare-feu et de la passerelle aux sous-réseaux.
5. Ajoutez un bloc Markdown du pack Base entre les tunnels pour les paramètres communs, et des notes Texte.

Si le VPN est défini dans Terraform, l'outil gratuit Terraform vers diagramme vous donne un premier brouillon ; voir aussi les diagrammes réseau.

L'exemple utilise 14 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Que doit montrer un schéma de VPN site-to-site ? Les deux réseaux avec leurs CIDR, l'IP publique et l'ASN de chaque passerelle, les adresses internes de chaque tunnel, le routage et les paramètres que les deux côtés doivent partager.

Pourquoi un AWS Site-to-Site VPN a-t-il deux tunnels ? Chaque connexion a deux tunnels vers des points de terminaison dans des Availability Zones différentes. AWS les maintient un à la fois ; avec les deux configurés, le trafic bascule au lieu de s'arrêter.

Dois-je utiliser le routage statique ou BGP sur IPsec ? BGP, dès que votre équipement le gère. Il retire automatiquement les routes d'un tunnel en panne et il est requis pour ECMP. Le routage statique est réservé aux équipements sans BGP.

Quelles MTU et MSS utiliser pour un VPN AWS ? Au plus 1 446 et 1 406 octets, avec AES-GCM et sans NAT traversal. Les chiffrements CBC et NAT-T demandent des valeurs plus petites, données dans le tableau AWS.

Quand utiliser Direct Connect plutôt qu'un VPN ? Quand le trafic est constant à l'échelle du gigabit, que la latence doit être prévisible, ou que vous avez besoin d'un SLA allant jusqu'à 99,99 %. Gardez le VPN comme secours chiffré.

Commencez gratuitement — un siège, sans carte bancaire.