VPN Site-to-Site¶

Le VPN Site-to-Site (S2S) Scaleway relie le VPC applicatif à deux sites du réseau ADEME — Angers et Paris — par des tunnels IPsec avec routage dynamique BGP. Il permet aux workloads Kubernetes de joindre des ressources internes de l'ADEME (et inversement) sans transiter par Internet en clair. Les deux environnements applicatifs, hors-prod et prod, ont chacun leurs propres gateways et tunnels vers les mêmes FortiGate ADEME.

Généralités — le VPN Site-to-Site chez Scaleway¶

Le service est entièrement managé par Scaleway : aucune VM ni appliance à maintenir. Il s'articule autour de quatre objets, tous créés dans le projet Scaleway de l'environnement et rattachés à la région fr-par.

Comment ça fonctionne¶

• IPsec / IKEv2 — le tunnel est chiffré de bout en bout. La clé pré-partagée (PSK) est générée par Scaleway à la création de la connexion et stockée dans Secret Manager ; elle est à transmettre hors bande à l'administrateur du site distant.
• BGP — pas de routes statiques : chaque connexion établit une session BGP sur un lien point-à-point en 169.254.x.x/30 (private_ip côté Scaleway, peer_private_ip côté client). Le site distant annonce ses réseaux, Scaleway annonce les siens, chacun filtré par la routing policy.
• Propagation de routes — avec enable_route_propagation = true, les préfixes appris par BGP sont injectés dans la table de routage du VPC. Le VPC doit avoir enable_routing et enable_custom_routes_propagation activés : c'est ce qui rend les réseaux ADEME joignables depuis les autres Private Networks du VPC (dont celui du cluster Kubernetes), sans configuration sur les nœuds.
• Politique d'initiation — vpn_gateway (Scaleway initie), customer_gateway (le site distant initie) ou non défini. Chez nous, c'est Scaleway qui initie.

Haute disponibilité¶

Une VPN Gateway étant zonale, la HA consiste à créer une gateway par zone (fr-par-1 et fr-par-2) et, pour chaque site distant, deux connexions — une par gateway — avec des liens BGP distincts. Le site distant voit donc deux tunnels et deux sessions BGP vers les mêmes préfixes ; la perte d'une zone fait basculer le trafic sur l'autre via BGP.

Filtrage : deux niveaux¶

Les ACL VPC sont stateless : une règle aller ne suffit pas, le trafic retour doit être autorisé explicitement (voir Modifier les règles ACL).

Mise en œuvre¶

Topologie¶

Dans chaque environnement, le VPN est raccordé à un Private Network dédié (vpn-s2s) plutôt qu'au PN du cluster : la gateway y prend son IP privée, et la propagation de routes se charge de rendre les préfixes ADEME visibles depuis app-k8s-internal.

Sites distants¶

Les deux environnements se raccordent aux mêmes FortiGate ADEME, avec les mêmes ASN et les mêmes préfixes acceptés ; seul le préfixe annoncé change (le PN du cluster de l'environnement).

10.255.3.0/24 (services DRI : VIP LDAP, bases DPE…) est joignable par les deux sites.

Chaque site a donc, par environnement, deux tunnels (<vpn_name>-par1 et <vpn_name>-par2) et deux sessions BGP — soit quatre tunnels par FortiGate. Les liens BGP /30 sont uniques sur l'ensemble des connexions :

Les tunnels des deux environnements sont montés : les huit connexions sont établies (tunnel et sessions BGP up).

Suites cryptographiques¶

Identiques pour tous les tunnels, phase 1 (IKEv2) comme phase 2 (ESP) :

Schéma¶

Les deux VPC applicatifs (hors-prod et prod) et leurs gateways (une par zone), les tunnels vers les FortiGate ADEME d'Angers et de Paris, et les sessions BGP associées.

Source : VPN-SCW-ADEME.drawio, modifiable via l'icône crayon de la barre d'outils.

Gestion Terraform¶

Chaîne de configuration¶

Tout est piloté par la configuration centralisée (scw-init-config/001.config_infrastructure/terraform.tfvars), publiée dans le state config/infrastructure.tfstate puis consommée par les runs de l'environnement.

cd infrastructure/main-infra/scw-init-config/001.config_infrastructure && terraform apply
cd ../../scw-application/<env>/terraform/003.s2s_vpn && terraform apply   # <env> : horsprod ou prod
cd ../004.vpc_firewall && terraform apply

Les runs 003 et 004 s'authentifient auprès de Scaleway avec les credentials lus dans Vault (ademe/cluster-<env>/scaleway_credentials) : un VAULT_TOKEN valide est nécessaire.

Le module scaleway_s2s_vpn¶

Le module prend un préfixe de nom (le nom de l'environnement), un type de gateway, le PN cible et une liste de tunnels. Il en déduit :

• une gateway <env>-par1, toujours ;
• une gateway <env>-par2, uniquement si au moins un tunnel demande high_availability = true ;
• par tunnel : une customer gateway et une routing policy nommées <vpn_name>, une connexion <vpn_name>-par1, et une connexion <vpn_name>-par2 si HA.

Les ressources sont indexées par vpn_name (for_each) : ajouter ou retirer un site ne recrée pas les autres.

Référence d'un tunnel¶

Chaque entrée de s2s_vpn_definition.<env>.tunnels :

Ajouter un site distant¶

1. Dans 001.config_infrastructure/terraform.tfvars, ajouter une entrée à s2s_vpn_definition.<env>.tunnels en choisissant des /30 BGP non encore utilisés (voir le tableau des liens BGP ci-dessus).
2. Si le site expose de nouveaux réseaux, les ajouter à prefix_filter_in et prévoir les règles vpc_firewall correspondantes.
3. Appliquer 001.config_infrastructure, puis 003.s2s_vpn, puis 004.vpc_firewall.
4. Transmettre à l'administrateur du site : l'IP publique de chaque gateway, l'ASN Scaleway (12876), les IP BGP, les suites cryptographiques et la PSK (voir ci-dessous).

Récupérer les informations à transmettre au site distant¶

IP publique des gateways — elle n'est pas directement dans l'output : vpn_gateway_config_par1.public_config contient l'ID de l'IP IPAM, à résoudre via l'API :

cd scw-application/<env>/terraform/003.s2s_vpn
terraform output -json vpn_gateway_config_par1 | jq '.public_config'   # idem avec vpn_gateway_config_par2
curl -s -H "X-Auth-Token: $SCW_SECRET_KEY" \
  "https://api.scaleway.com/ipam/v1/regions/fr-par/ips/<ipam_ipv4_id>" | jq '.address'

PSK — générée par Scaleway et stockée dans Secret Manager. L'ID du secret est dans l'output des connexions :

terraform output -json vpn_connections_par1 | jq '."prod-angers" | {secret_id, secret_version}'   # idem pour chaque site, par1 et par2
scw secret version access-by-path secret-id=<secret_id> revision=<secret_version>

Elle est aussi consultable dans la console Scaleway, sur la page de la connexion.

État des tunnels — status, tunnel_status et bgp_status_ipv4 sont exposés sur chaque connexion :

terraform apply -refresh-only   # les outputs reflètent le state : le rafraîchir pour avoir l'état courant
terraform output -json vpn_connections_par1 | jq 'map_values({status, tunnel_status, bgp_status_ipv4})'
terraform output -json vpn_connections_par2 | jq 'map_values({status, tunnel_status, bgp_status_ipv4})'

Modifier les règles ACL (firewall VPC)¶

Où sont les règles¶

Dans scw-init-config/001.config_infrastructure/terraform.tfvars, variable vpc_firewall, une liste par environnement :

vpc_firewall = {
  horsprod = [
    { source = "172.16.0.0/22", dest = "10.1.12.108/32", proto = "TCP", port = "3306", comment = "SRV-ANG-BDD108" },
    { source = "172.16.0.0/22", dest = "10.255.3.1/32",  proto = "TCP", port = "636",  comment = "VIP Load balancing CDMs" },
    # ...
  ]
  prod = [
    { source = "172.16.16.0/22", dest = "10.255.3.1/32", proto = "TCP", port = "636", comment = "VIP Load balancing CDMs" },
    # ...
  ]
}

Pour un flux sortant, la source est le Private Network du cluster de l'environnement (172.16.0.0/22 en hors-prod, 172.16.16.0/22 en prod) ; la destination, une machine ou un service précis du réseau ADEME, de préférence en /32 et sur le seul port utile.

Ce que génère le run 004.vpc_firewall¶

Le run traduit chaque règle en règle scaleway_vpc_acl (action accept) et génère automatiquement la règle retour : les ACL VPC étant stateless, la réponse dest → source doit être autorisée elle aussi. Pour une règle A → B sur le port P, on obtient :

La règle retour reprend la description de la règle aller, préfixée de return:. Il n'y a donc pas à écrire les règles retour dans le tfvars. Une seule ACL IPv4 est créée par VPC, avec toutes les règles ; si la liste est vide, aucune ACL n'est créée.

Procédure¶

1. Éditer vpc_firewall.<env> dans 001.config_infrastructure/terraform.tfvars.
2. Vérifier que les réseaux distants visés sont bien dans prefix_filter_in du tunnel concerné — une règle ACL vers un réseau non routé est inutile.
3. Appliquer :

cd infrastructure/main-infra/scw-init-config/001.config_infrastructure && terraform apply
cd ../../scw-application/<env>/terraform/004.vpc_firewall && terraform plan   # relire les règles aller + retour
terraform apply

L'output vpc_acl.rules du run liste les règles effectivement poussées, retour compris.