VPN Gateway:Prise en main de la liaison IPsec-VPN au routeur de transit

Planification des ressources

• Cloud : Un VPC avec le bloc CIDR 10.0.0.0/16 dans la région Chine (Hangzhou).

  • vSwitch 1 : Dans la zone de disponibilité H, avec le bloc CIDR 10.0.0.0/24.

  • vSwitch 2 : Dans la zone de disponibilité J, avec le bloc CIDR 10.0.2.0/24.

  • Instance ECS : Adresse IP 10.0.0.1, utilisée pour tester la connectivité.

  • Instance CEN : Héberge le routeur de transit.

  • Routeur de transit : Créé dans la région Chine Est 1 (Hangzhou). Plage d'adresses du TR : 10.10.10.0/24 (ne doit pas entrer en conflit avec les blocs CIDR du VPC, de l'IDC ou de BGP).

• Sur site : IDC avec le bloc CIDR 172.16.0.0/16.

  • Appareil strongSwan : Adresse IP privée 172.16.0.1.

  • Adresse IP publique : XX.XX.3.3.

• algorithme de chiffrement : IKEv2 / AES-128 / SHA-1 / Groupe DH 2 / Durée de vie SA 86 400 secondes. Les deux extrémités du tunnel doivent être configurées avec les mêmes paramètres de chiffrement.

• Mode de routage : Utilisez le routage dynamique BGP. La planification des blocs CIDR BGP est la suivante (le bloc CIDR du tunnel doit être un /30 dans 169.254.0.0/16, et les deux tunnels ne peuvent pas être identiques).

  Ressource	Tunnel	sous-réseau du tunnel	Adresse IP BGP	Numéro AS BGP
  Connexion IPsec (côté cloud)	Tunnel 1	169.254.10.0/30	169.254.10.1	65535
  	Tunnel 2	169.254.20.0/30	169.254.20.1	65535
  Passerelle locale (IDC)	Tunnel 1	169.254.10.0/30	169.254.10.2	65530
  	Tunnel 2	169.254.20.0/30	169.254.20.2	65530

  Le numéro de système autonome local des deux tunnels doit être identique ; il est également recommandé que le numéro AS distant (IDC) soit le même pour les deux tunnels.

Prérequis

• Le bloc CIDR du VPC, le bloc CIDR de l'IDC et le sous-réseau du tunnel BGP ne doivent pas entrer en conflit les uns avec les autres.

• Un VPC a été créé et un vSwitch a été créé dans chacune des deux zones différentes (les zones où résident les vSwitches doivent figurer dans la liste des zones prises en charge par le routeur de transit). Au moins une instance ECS existe dans le VPC pour vérifier la connectivité.

• Une instance CEN et un routeur de transit (TR) ont été créés, les conditions suivantes étant remplies :

  • Le VPC est attaché au TR.

  • La propagation des routes et la synchronisation des routes sont activées entre le VPC et le TR.

  • Un bloc CIDR est configuré pour le TR.

• Un serveur Linux a été déployé dans l'IDC local (cet article utilise CentOS Stream 9 à titre d'exemple) avec une seule sortie publique. strongSwan (pour le tunnel IPsec) et FRRouting (pour BGP) seront installés sur ce serveur en tant que passerelle locale.

1. Configurer les règles du pare-feu

Sur l'équipement strongSwan, autorisez le protocole ESP (numéro de protocole IP 50), le port UDP 500 et le port UDP 4500 afin de permettre l'accès depuis les deux adresses IPsec côté cloud.

L'exemple ci-dessous utilise iptables. Adaptez la commande à l'outil de pare-feu que vous utilisez.

iptables -I INPUT -s XX.XX.1.1,XX.XX.2.2 -p esp -j ACCEPT  
iptables -I INPUT -s XX.XX.1.1,XX.XX.2.2 -p udp --dport 500 -j ACCEPT
iptables -I INPUT -s XX.XX.1.1,XX.XX.2.2 -p udp --dport 4500 -j ACCEPT

2. Activer le transfert IP

echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sudo sysctl -p

3. Installer strongSwan

sudo dnf install epel-release -y
sudo dnf install strongswan -y

4. Créer les interfaces XFRM et un script updown

Dans un scénario à double tunnel, il est nécessaire de distinguer le trafic de chaque tunnel. Vous devez donc créer des interfaces virtuelles XFRM pour éviter les conflits de politiques de routage au niveau du noyau. En mode de routage dynamique BGP, configurez également les adresses de tunnel BGP sur ces interfaces XFRM.

# Create XFRM tunnel interfaces (corresponding to tunnel 1 and tunnel 2 respectively; with a single public egress, the underlying interface for both is eth0)
sudo ip link add ipsec0 type xfrm dev eth0 if_id 42
sudo ip link add ipsec1 type xfrm dev eth0 if_id 43
sudo ip link set ipsec0 up
sudo ip link set ipsec1 up

# Configure the local BGP tunnel addresses on the XFRM interfaces
sudo ip address add 169.254.10.2/30 dev ipsec0
sudo ip address add 169.254.20.2/30 dev ipsec1

5. Configurer strongSwan

1. Sauvegardez le fichier de configuration d'origine :

   mv /etc/strongswan/swanctl/swanctl.conf /etc/strongswan/swanctl/swanctl.conf.bak

2. Créez un nouveau fichier de configuration :

   vi /etc/strongswan/swanctl/swanctl.conf

3. Ajoutez la configuration suivante. Remplacez les adresses IP et les clés de l'exemple par vos valeurs réelles.

   # strongSwan dual-tunnel IPsec-VPN configuration
   # Applicable to: Alibaba Cloud Transit Router-bound IPsec connection + local single public egress + BGP dynamic routing
   #
   #
   # Use XFRM interfaces (if_id) to distinguish the traffic of the two tunnels; routes are learned dynamically by BGP.
   
   connections {
   
      # === Tunnel 1 ===
      tunnel1 {
         version = 2
         dpd_delay = 10s
         rekey_time = 86400s
         proposals = aes-sha1-modp1024
         encap = yes
   
         local_addrs  = 172.16.0.1               # IP address of the strongSwan local NIC (modify as needed: in a NAT environment, use the private IP; if the NIC directly binds a public IP, use the public IP)
         local {
            auth = psk
            id = XX.XX.3.3                         # Local public egress IP (modify as needed)
         }
   
         remote_addrs = XX.XX.1.1                  # Public IP of tunnel 1 on the Alibaba Cloud side (modify as needed)
         remote {
            auth = psk
            id = XX.XX.1.1                         # Public IP of tunnel 1 on the Alibaba Cloud side, same as remote_addrs above (modify as needed)
         }
   
         children {
            tunnel1-child {
               local_ts  = 0.0.0.0/0
               remote_ts = 0.0.0.0/0
               mode = tunnel
               esp_proposals = aes-sha1-modp1024
               dpd_action = restart
               start_action = start
               close_action = start
               if_id_in = 42                       # Corresponds to the ipsec0 interface
               if_id_out = 42
            }
         }
   
         if_id_in = 42
         if_id_out = 42
      }
   
      # === Tunnel 2 ===
      tunnel2 {
         version = 2
         dpd_delay = 10s
         rekey_time = 86400s
         proposals = aes-sha1-modp1024
         encap = yes
   
         local_addrs  = 172.16.0.1               # IP address of the strongSwan local NIC, same as tunnel 1 (modify as needed)
         local {
            auth = psk
            id = XX.XX.3.3                         # Local public egress IP, same as tunnel 1 (modify as needed)
         }
   
         remote_addrs = XX.XX.2.2                  # Public IP of tunnel 2 on the Alibaba Cloud side (modify as needed)
         remote {
            auth = psk
            id = XX.XX.2.2                         # Public IP of tunnel 2 on the Alibaba Cloud side, same as remote_addrs above (modify as needed)
         }
   
         children {
            tunnel2-child {
               local_ts  = 0.0.0.0/0
               remote_ts = 0.0.0.0/0
               mode = tunnel
               esp_proposals = aes-sha1-modp1024
               dpd_action = restart
               start_action = start
               close_action = start
               if_id_in = 43                       # Corresponds to the ipsec1 interface
               if_id_out = 43
            }
         }
   
         if_id_in = 43
         if_id_out = 43
      }
   }
   
   secrets {
      ike-tunnel1 {
      ike-tunnel1 {
         id-1 = XX.XX.3.3                          # (Modify) The on-premises public IP address.
         id-2 = XX.XX.1.1                          # (Modify) The public IP address of Tunnel 1 on Alibaba Cloud.
      }
      ike-tunnel2 {
      ike-tunnel2 {
         id-1 = XX.XX.3.3                          # (Modify) The on-premises public IP address.
         id-2 = XX.XX.2.2                          # (Modify) The public IP address of Tunnel 2 on Alibaba Cloud.
      }
   }

   Important

   • Les paramètres if_id_in et if_id_out associent chaque tunnel à l'interface XFRM correspondante (ipsec0 / ipsec1), garantissant ainsi que le trafic des deux tunnels ne s'interfère pas.

   • Les paramètres local_ts et remote_ts sont définis sur 0.0.0.0/0 ; les routes apprises par BGP déterminent quel trafic emprunte le tunnel. En mode de route de destination, le sélecteur de trafic côté cloud est également 0.0.0.0/0.

6. Démarrer strongSwan et vérifier l'état des tunnels

sudo systemctl enable strongswan
sudo systemctl restart strongswan
sudo swanctl --load-all
sudo swanctl --list-sas

Si les deux tunnels affichent l'état ESTABLISHED et que CHILD_SA indique INSTALLED, la connexion IPsec est établie avec succès.

# Example of expected output (abbreviated)
tunnel1: #1, ESTABLISHED, IKEv2
  tunnel1-child: #1, reqid 1, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-128/HMAC_SHA1_96
tunnel2: #2, ESTABLISHED, IKEv2
  tunnel2-child: #2, reqid 2, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-128/HMAC_SHA1_96

7. Configurer le routage dynamique BGP (FRRouting)

Une fois le tunnel IPsec établi, les réseaux ne peuvent toujours pas communiquer. Vous devez configurer BGP sur l'équipement passerelle local pour établir des voisins BGP avec Alibaba Cloud, annoncer automatiquement les blocs CIDR locaux et apprendre les blocs CIDR côté cloud.

Remarque : Après le redémarrage de l'équipement strongSwan/FRR, vous devez recréer les interfaces XFRM, les adresses de tunnel BGP et la configuration BGP.

1. Installez FRRouting :

   sudo dnf install frr -y

2. Activez le démon bgpd :

   Modifiez le fichier /etc/frr/daemons en remplaçant bgpd=no par bgpd=yes, enregistrez les modifications, puis démarrez FRR :

   sudo sed -i 's/^bgpd=no/bgpd=yes/' /etc/frr/daemons
   sudo systemctl enable frr
   sudo systemctl restart frr

3. Ajoutez la configuration BGP :

   Accédez à l'interface de configuration vtysh et ajoutez la configuration suivante. Lors de l'exécution, remplacez les adresses par vos valeurs réelles :

   • 169.254.10.1 et 169.254.20.1 : Remplacez par les adresses BGP locales des deux tunnels côté Alibaba Cloud (c'est-à-dire les voisins BGP distants de l'équipement local).

   • 65535 : Remplacez par le numéro de système autonome local de la connexion IPsec Alibaba Cloud.

   • 65530 : Remplacez par le numéro AS BGP du centre de données local (IDC).

   • 172.16.0.0/24 : Remplacez par le bloc CIDR de l'IDC local que vous souhaitez annoncer au cloud.

   sudo vtysh

   configure terminal
   route-map allow-all permit 1
   exit
   
   router bgp 65530
    bgp router-id 169.254.10.2
    neighbor 169.254.10.1 remote-as 65535
    neighbor 169.254.10.1 timers 10 30
    neighbor 169.254.20.1 remote-as 65535
    neighbor 169.254.20.1 timers 10 30
   
    address-family ipv4 unicast
     network 172.16.0.0/24
     neighbor 169.254.10.1 soft-reconfiguration inbound
     neighbor 169.254.10.1 route-map allow-all in
     neighbor 169.254.10.1 route-map allow-all out
     neighbor 169.254.20.1 soft-reconfiguration inbound
     neighbor 169.254.20.1 route-map allow-all in
     neighbor 169.254.20.1 route-map allow-all out
     maximum-paths 32
    exit-address-family
   exit
   exit
   write memory

4. Vérifiez les voisins et les routes BGP :

   show ip bgp summary
   show ip bgp

   • Le champ State/PfxRcd des deux voisins (169.254.10.1 et 169.254.20.1) dans la sortie de show ip bgp summary doit afficher le nombre de préfixes reçus (plutôt que Active/Idle), ce qui indique que les voisins BGP sont établis.

   • Dans la sortie de show ip bgp, vous devriez voir les blocs CIDR VPC côté cloud appris via BGP (tels que 10.0.0.0/24 et 10.0.2.0/24). Chaque bloc CIDR doit présenter deux chemins équivalents (via le tunnel 1 et le tunnel 2 respectivement), formant ainsi une configuration ECMP.

   # show ip bgp summary expected output example (some content omitted)
   Neighbor        V         AS   ... State/PfxRcd
   169.254.10.1    4      65535   ...            2
   169.254.20.1    4      65535   ...            2
   
   # show ip bgp expected output example
   *> 10.0.0.0/24      169.254.10.1   ... 65535 i
   *=                  169.254.20.1   ... 65535 i
   *> 10.0.2.0/24      169.254.10.1   ... 65535 i
   *=                  169.254.20.1   ... 65535 i

5. Confirmez que les routes ECMP ont été installées dans le noyau :

   ip route show 10.0.0.0/24
   # Expected: one route with two nexthops, via ipsec0 and ipsec1 respectively

Tester la connectivité

1. Assurez-vous d'abord que les règles du groupe de sécurité ECS autorisent le protocole ICMP, puis effectuez un ping vers l'ECS côté cloud depuis un client situé dans l'IDC local :

   ping 10.0.0.1

   Une réponse confirme la connectivité entre le VPC et l'IDC sur site.

   Remarque : Lorsque vous effectuez un ping depuis l'équipement strongSwan lui-même, spécifiez l'adresse IP interne de l'IDC comme adresse source (par exemple, ping -I 172.16.0.1 10.0.0.1 ) pour empêcher le noyau de sélectionner l'adresse de tunnel BGP (169 254.x.x) comme adresse source, ce qui entraînerait un échec du chemin de retour.

2. Vérifiez que l'équipement strongSwan ou un autre serveur sur site autorise le trafic ICMP. Connectez-vous à l'instance ECS (10.0.0.1) dans le VPC et effectuez un ping vers l'équipement strongSwan :

   ping 172.16.0.1

   Une réponse confirme la connectivité bidirectionnelle.

Tester la haute disponibilité

Par défaut, une connexion IPsec liée à un Transit Router et utilisant BGP emploie simultanément les deux tunnels en mode ECMP (Equal-Cost Multi-Path), avec une répartition de charge du trafic entre les deux tunnels. En cas de défaillance d'un tunnel, BGP retire automatiquement la route associée et le trafic converge vers l'autre tunnel sans intervention manuelle.

1. Maintenez un ping continu de l'ECS vers le serveur de l'IDC :

   ping 172.16.0.1 -c 10000

2. Interrompez l'un des tunnels : Dans la console Alibaba Cloud, modifiez la clé prépartagée du tunnel 1 de la connexion IPsec (de sorte que les clés aux deux extrémités ne correspondent plus). Le tunnel sera interrompu et son voisin BGP sera déconnecté en conséquence.

3. Observez le résultat du ping : Après une brève interruption, la communication reprend, indiquant que le trafic a automatiquement convergé vers le tunnel 2.

4. Rétablissez le tunnel : Remettez la clé prépartagée du tunnel 1 à sa valeur correcte. Une fois le tunnel et le voisin BGP restaurés, le trafic sera à nouveau réparti entre les deux tunnels.