strongSwan IPsec-VPN configuration examples for Alibaba Cloud VPN Gateway - VPN Gateway

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

Une instance de passerelle VPN prenant en charge le mode double tunnel
Un appareil Linux exécutant CentOS Stream 9 (64 bits) ou une distribution compatible
strongSwan 5.8.0 ou version ultérieure (requis pour les interfaces virtuelles XFRM dans les scénarios de double sortie et de routage BGP)
Un noyau Linux 4.19 ou version ultérieure avec prise en charge du module XFRM, et iproute2 5.1.0 ou version ultérieure (pour les configurations basées sur XFRM)
Une connectivité réseau sur les ports UDP 500 et 4500, et le protocole ESP (protocole IP 50) autorisé à travers tous les pare-feu intermédiaires

Exemple de scénario

La figure suivante illustre un déploiement type. Un appareil strongSwan situé sur votre réseau local établit une connexion IPsec-VPN à double tunnel avec Alibaba Cloud, permettant la communication entre le VPC et votre centre de données.

Planification des adresses IP

Côté centre de données local

Bloc CIDR privé : 172.16.0.0/16
Appareil strongSwan
- Carte réseau eth0 : 172.16.20.80, sortie publique mappée par NAT 1 : 120.XX.XX.202
- (Facultatif) Carte réseau eth1 : 172.16.21.248, sortie publique mappée par NAT 2 : 47.XX.XX.127
  
  Pour les scénarios sans NAT, consultez Comment configurer strongSwan lorsque l'interface réseau possède une adresse IP publique (sans NAT) ? . Vous pouvez établir une connexion IPsec-VPN à double tunnel avec Alibaba Cloud depuis un appareil disposant d'une seule sortie publique (sortie unique) ou de deux sorties publiques (double sortie). Cette rubrique fournit des exemples pour les deux scénarios.

Côté Alibaba Cloud

Bloc CIDR du VPC : 192.168.0.0/16
- Bloc CIDR du vSwitch 1 : 192.168.10.0/24
- Bloc CIDR du vSwitch 2 : 192.168.20.0/24
- Bloc CIDR du vSwitch 3 : 192.168.40.0/24
- Bloc CIDR du vSwitch 4 : 192.168.50.0/24
- Bloc CIDR du vSwitch 5 : 192.168.55.0/24
Passerelle VPN
- Adresse IPsec 1 : 47.XX.XX.151
- Adresse IPsec 2 : 47.XX.XX.87
  
  Après la création d'une instance de passerelle VPN, le système attribue automatiquement deux adresses IPsec à l'instance.

Adresses IP BGP

Cette rubrique couvre à la fois le routage statique et le routage dynamique Border Gateway Protocol (BGP). Ignorez cette section si vous ne prévoyez pas d'utiliser BGP. Le tableau suivant répertorie la planification des blocs CIDR BGP utilisée dans cette rubrique.

Ressource	Tunnel	Bloc CIDR du tunnel BGP	Adresse IP BGP	Numéro AS BGP
Passerelle VPN	Tunnel 1	169.254.10.0/30 Le bloc CIDR de chaque tunnel sous une instance de passerelle VPN doit être unique.	169.254.10.1	65535
Passerelle VPN	Tunnel 2	169.254.20.0/30	169.254.20.1	65535
Appareil strongSwan	Tunnel 1	169.254.10.0/30	169.254.10.2	65530
Appareil strongSwan	Tunnel 2	169.254.20.0/30	169.254.20.2	65530

Planification des paramètres VPN

Dans cet exemple, les deux tunnels utilisent les mêmes valeurs de paramètres. Pour chaque tunnel, les configurations IKE et IPsec sur l'appareil strongSwan doivent correspondre à celles du côté d'Alibaba Cloud.

Clé prépartagée : ChangeMe***

Paramètre

IKE

IPsec

Version / Mode

IKEv2 / main

-

Algorithme de chiffrement

aes128

Algorithme d'authentification

sha1

Groupe DH

group2 (modp1024)

Durée de vie SA (secondes)

86400

Les paramètres de chiffrement de cet exemple (aes128-sha1-modp1024) sont choisis pour leur large compatibilité. Pour les environnements de production, envisagez d'utiliser des algorithmes plus robustes tels que aes256-sha256-modp2048 ou aes256gcm16-sha384-ecp384.

Préparez le côté Alibaba Cloud

Effectuez la configuration Alibaba Cloud en fonction de votre nombre de sorties publiques et de votre méthode de routage. Sélectionnez l'onglet correspondant à votre scénario.

Double sortie - Routage dynamique BGP

Pour plus d'informations, consultez Connecter un VPC à un centre de données local en mode double tunnel et utiliser le routage BGP. Effectuez les étapes Create a VPN gateway, Create customer gateways, Create an IPsec-VPN connection et Enable BGP dynamic routing .

Étant donné que l'appareil strongSwan dispose de deux adresses IP de sortie publique, créez deux passerelles clientes.
Lors de la création de la connexion IPsec-VPN, associez le Tunnel 1 à la sortie publique 1 et le Tunnel 2 à la sortie publique 2. Cet exemple utilise le Destination Routing Mode.

Double sortie - Routage statique

Pour plus d'informations, consultez Connecter un VPC à un centre de données local en mode double tunnel. Effectuez les étapes Create a VPN gateway, Create a customer gateway, Create an IPsec connection et Configure VPN Gateway routes .

Étant donné que l'appareil strongSwan dispose de deux adresses IP de sortie publique, créez deux passerelles clientes.
Lors de la création de la connexion IPsec-VPN, associez le Tunnel 1 à la sortie publique 1 et le Tunnel 2 à la sortie publique 2. Cet exemple utilise le Destination Routing Mode.

Sortie unique - Routage dynamique BGP

Pour plus d'informations, consultez Connecter un VPC à un centre de données local en mode double tunnel et utiliser le routage BGP. Effectuez les étapes Create a VPN gateway, Create customer gateways, Create an IPsec-VPN connection et Enable BGP dynamic routing .

L'appareil strongSwan dispose d'une seule adresse IP de sortie publique. Créez une passerelle cliente.
Lors de la création de la connexion IPsec-VPN, associez les deux tunnels à la même passerelle cliente. Cet exemple utilise le Destination Routing Mode.

Sortie unique - Routage statique

Pour plus d'informations, consultez Connecter un VPC à un centre de données local en mode double tunnel. Effectuez les étapes Create a VPN gateway, Create a customer gateway, Create an IPsec connection et Configure VPN Gateway routes . Notez les points suivants :

L'appareil strongSwan dispose d'une seule adresse IP de sortie publique. Créez une passerelle cliente.
Lors de la création de la connexion IPsec-VPN, sélectionnez le mode Protected Data Flows et associez les deux tunnels à la même passerelle cliente. Configurez les paramètres suivants :
- Définissez Local Network sur le bloc CIDR du VPC côté Alibaba Cloud, soit 192.168.0.0/16.
- Définissez Remote Network sur le bloc CIDR privé du centre de données local, soit 172.16.0.0/16.

Si une connexion IPsec-VPN est associée à un Transit Router, utilisez le routage dynamique BGP. Le routage statique n'est pas recommandé pour ce scénario.

Configurez l'appareil strongSwan

Les étapes suivantes utilisent CentOS Stream 9 (64 bits) comme exemple. Pour les autres distributions, consultez la documentation officielle de strongSwan .

1. Configurez les politiques de pare-feu

Autorisez le protocole ESP (protocole IP 50), le port UDP 500 et le port UDP 4500 sur l'appareil strongSwan.

iptables -I INPUT -p 50 -j ACCEPT
iptables -I INPUT -p udp --dport 500 -j ACCEPT 
iptables -I INPUT -p udp --dport 4500 -j ACCEPT

Ces règles iptables ne persistent pas après un redémarrage. Pour les rendre permanentes, utilisez iptables-save , firewall-cmd --permanent ou l'outil de gestion de pare-feu préféré de votre distribution.

2. Activez le transfert de trafic

Activez le transfert IP afin que l'appareil strongSwan puisse router le trafic entre le réseau local et le VPC. La commande suivante prend effet immédiatement et persiste après les redémarrages.

Ajoutez la configuration de transfert au fichier /etc/sysctl.conf.
```
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
```
Appliquez la configuration.
```
sudo sysctl -p
```
Vérifiez que le transfert IP est activé.
```
cat /proc/sys/net/ipv4/ip_forward
```
La sortie doit être 1.

3. Installez strongSwan

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

4. Configurez les doubles tunnels

Double sortie - Routage statique et routage dynamique BGP

Important

La double sortie nécessite des interfaces réseau virtuelles XFRM. Vérifiez les éléments suivants avant de continuer : strongSwan 5.8.0 ou version ultérieure, noyau Linux 4.19 ou version ultérieure, iproute2 5.1.0 ou version ultérieure, et prise en charge du module XFRM (exécutez lsmod | grep xfrm pour vérifier). Pour plus d'informations, consultez XFRM Interfaces on Linux.

Ajoutez des routes afin que le trafic vers l'adresse IPsec 1 passe par eth0 et que le trafic vers l'adresse IPsec 2 passe par eth1.

ip route add 47.XX.XX.151 via 172.16.20.253 dev eth0  # 172.16.20.253 is the private gateway address of eth0.
ip route add 47.XX.XX.87 via 172.16.21.253 dev eth1   # 172.16.21.253 is the private gateway address of eth1.

Vérifiez la connectivité vers les deux adresses IPsec.

ping 47.XX.XX.151 
ping 47.XX.XX.87

Créez deux interfaces réseau virtuelles pour établir les tunnels IPsec-VPN.

ip link add ipsec0 type xfrm dev eth0 if_id 42 # Create an XFRM virtual network interface for Tunnel 1. The interface ID is 42 and the underlying interface is the public interface eth0.
ip link add ipsec1 type xfrm dev eth1 if_id 43 # Create an XFRM virtual network interface for Tunnel 2. The interface ID is 43 and the underlying interface is the public interface eth1.
ip link set ipsec0 up # Start the XFRM virtual network interface for Tunnel 1.
ip link set ipsec1 up # Start the XFRM virtual network interface for Tunnel 2.

Important

Les interfaces XFRM ne persistent pas après un redémarrage. Vous devez configurer le script de démarrage suivant afin que les interfaces soient automatiquement recréées et que strongSwan soit rechargé à chaque démarrage.

Cliquez pour afficher le script de démarrage.

Créez un fichier de script.
```
vi xfrm.sh
```

Ajoutez le contenu suivant et enregistrez le fichier.

sudo ip link add ipsec0 type xfrm dev eth0 if_id 42 # Create an XFRM virtual network interface for Tunnel 1. The interface ID is 42 and the underlying interface is the public interface eth0.
sudo ip link add ipsec1 type xfrm dev eth1 if_id 43 # Create an XFRM virtual network interface for Tunnel 2. The interface ID is 43 and the underlying interface is the public interface eth1.
sudo ip link set ipsec0 up # Start the XFRM virtual network interface for Tunnel 1.
sudo ip link set ipsec1 up # Start the XFRM virtual network interface for Tunnel 2.

Trouvez le chemin absolu du script.
```
sudo find / -name xfrm.sh
```
Ajoutez le chemin du script à /etc/rc.d/rc.local afin qu'il s'exécute au démarrage. Remplacez /path/to/xfrm.sh par le chemin réel renvoyé par la commande find précédente.
```
echo '/path/to/xfrm.sh' | sudo tee -a /etc/rc.d/rc.local
```
Accordez des permissions d'exécution au fichier rc.local et au script xfrm.sh.
```
sudo chmod +x /etc/rc.d/rc.local
sudo chmod +x /path/to/xfrm.sh
```

Modifiez le fichier de configuration de strongSwan.

Sauvegardez le fichier de configuration original de strongSwan.

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

Créez un nouveau fichier de configuration strongSwan.
```
vi /etc/strongswan/swanctl/swanctl.conf
```

Ajoutez la configuration suivante. Chaque valeur de paramètre doit correspondre à la configuration du tunnel Alibaba Cloud correspondante.

Important

Pour le routage statique, décommentez les lignes updown = /root/connect_1.sh et updown = /root/connect_2.sh dans la configuration.

connections {
   vco1 {                            # Add the VPN configuration for IPsec-VPN Tunnel 1.
      version = 2                    # Specify the IKE version. It must be the same as the IKE version of Tunnel 1 on the Alibaba Cloud side. 2 indicates IKEv2.
      local_addrs  = 172.16.20.80       # The IP address of the first on-premises network interface card.
      remote_addrs = 47.XX.XX.151       # Specify the peer IP address of Tunnel 1 as the gateway IP address of Tunnel 1 on the Alibaba Cloud side, which is IPsec address 1.
      dpd_delay = 10
      rekey_time = 84600             # Specify the SA lifetime for Tunnel 1. It must be the same as the SA lifetime in the IKE configurations of Tunnel 1 on the Alibaba Cloud side.
      over_time = 1800               
      proposals = aes128-sha1-modp1024  # Specify the encryption algorithm, authentication algorithm, and DH group for Tunnel 1. They must be the same as those in the IKE configurations of Tunnel 1 on the Alibaba Cloud side. group2 corresponds to modp1024.
      encap = yes

      local {
         auth = psk                  # Set the authentication method for the on-premises side to PSK, which is the pre-shared key method.
         id = 120.XX.XX.202             # The first on-premises public egress IP address. It must be the same as the RemoteId of Tunnel 1 on the Alibaba Cloud side.
      }
      remote {
         auth = psk                  # Set the authentication method for the peer to PSK. This means Alibaba Cloud uses the pre-shared key method.
         id = 47.XX.XX.151             # IPsec address 1 on the Alibaba Cloud side. It must be the same as the LocalId of Tunnel 1 on the Alibaba Cloud side.
      }
      children {
         vco_child1 {
            local_ts  = 0.0.0.0/0    # The policy-based traffic selector for the destination-based routing mode on Alibaba Cloud is 0.0.0.0/0.
            remote_ts = 0.0.0.0/0    # The policy-based traffic selector for the destination-based routing mode on Alibaba Cloud is 0.0.0.0/0.
            mode = tunnel
            rekey_time = 85500
            life_time = 86400        # Specify the SA lifetime for Tunnel 1. It must be the same as the SA lifetime in the IPsec configurations of Tunnel 1 on the Alibaba Cloud side.
            dpd_action = restart
            start_action = start
            close_action = start
            esp_proposals = aes128-sha1-modp1024   # Specify the encryption algorithm, authentication algorithm, and DH group for Tunnel 1. They must be the same as those in the IPsec configurations of Tunnel 1 on the Alibaba Cloud side. group2 corresponds to modp1024.

            if_id_out = 42           # Specify the egress and ingress interfaces for Tunnel 1 as the XFRM virtual network interface of Tunnel 1.
            if_id_in = 42
            #updown = /root/connect_1.sh         # Execute the /root/connect_1.sh script to configure routes based on the UP and DOWN status of Tunnel 1. This parameter is required only when you use static routing.
         }
      }
   }
  vco2 {                             # Add the VPN configuration for IPsec-VPN Tunnel 2.
      version = 2                    # Specify the IKE version. It must be the same as the IKE version of Tunnel 2 on the Alibaba Cloud side. 2 indicates IKEv2.
      local_addrs  = 172.16.21.248        # The IP address of the second on-premises network interface card.
      remote_addrs = 47.XX.XX.87       # IPsec address 2 on the Alibaba Cloud side.
      dpd_delay = 10
      rekey_time = 84600             # SA lifetime. Must match Tunnel 2 IKE configurations.
      over_time = 1800
      proposals = aes128-sha1-modp1024  # group2 = modp1024. Must match Tunnel 2 IKE configurations.
      encap = yes

      local {
         auth = psk                  # Pre-shared key authentication.
         id = 47.XX.XX.127              # Second on-premises public egress IP. Must match RemoteId of Tunnel 2.
      }
      remote {
         auth = psk                  # Set the authentication method for the peer to PSK. This means Alibaba Cloud uses the pre-shared key method.
         id = 47.XX.XX.87             # IPsec address 2 on the Alibaba Cloud side. It must be the same as the LocalId of Tunnel 2 on the Alibaba Cloud side.
      }
      children {
         vco_child2 {
            local_ts  = 0.0.0.0/0    # The policy-based traffic selector for the destination-based routing mode on Alibaba Cloud is 0.0.0.0/0.
            remote_ts = 0.0.0.0/0    # The policy-based traffic selector for the destination-based routing mode on Alibaba Cloud is 0.0.0.0/0.
            mode = tunnel 
            rekey_time = 85500
            life_time = 86400        # Specify the SA lifetime for Tunnel 2. It must be the same as the SA lifetime in the IPsec configurations of Tunnel 2 on the Alibaba Cloud side.
            dpd_action = restart
            start_action = start
            close_action = start
            esp_proposals = aes128-sha1-modp1024     # Specify the encryption algorithm, authentication algorithm, and DH group for Tunnel 2. They must be the same as those in the IPsec configurations of Tunnel 2 on the Alibaba Cloud side. group2 corresponds to modp1024.
            if_id_out = 43           # Specify the egress and ingress interfaces for Tunnel 2 as the XFRM virtual network interface of Tunnel 2.
            if_id_in = 43
            #updown = /root/connect_2.sh           # Execute the /root/connect_2.sh script to configure routes based on the UP and DOWN status of Tunnel 2. This parameter is required only when you use static routing.
         }
      }
   }
}

secrets {
   ike-vco1 {
      id = 47.XX.XX.151               # The public IP address of Tunnel 1 of the VPN gateway on the Alibaba Cloud side.
      secret = ChangeMe***            # Specify the pre-shared key for Tunnel 1. The key must be the same as the pre-shared key of Tunnel 1 on the Alibaba Cloud side.
   }
   ike-vco2 {
      id = 47.XX.XX.87                # The public IP address of Tunnel 2 of the VPN gateway on the Alibaba Cloud side.
      secret = ChangeMe***            # Specify the pre-shared key for Tunnel 2. The key must be the same as the pre-shared key of Tunnel 2 on the Alibaba Cloud side.
   }
}

Redémarrez le processus strongSwan, rechargez la configuration strongSwan et vérifiez l'état du tunnel.
```
sudo systemctl restart strongswan
swanctl --load-all
watch swanctl --list-sas
```
La sortie suivante confirme que la connexion IPsec-VPN est établie. Cependant, la connectivité réseau nécessite une configuration des routes à l'étape suivante.
Configurez les routes.

Reportez-vous à la section correspondant à la méthode de routage que vous prévoyez d'utiliser.
Routage dynamique BGP

Les adresses IP BGP attribuées aux interfaces XFRM ( ip address add ) ne persistent pas après un redémarrage. Ajoutez ces commandes au script de démarrage XFRM décrit précédemment. La configuration FRR BGP persiste automatiquement après avoir exécuté write memory dans vtysh (voir la dernière étape ci-dessous).
1. Configurez les adresses IP BGP sur les interfaces XFRM.
  ip address add 169.254.10.2/30 dev ipsec0 ip address add 169.254.20.2/30 dev ipsec1
2. Installez FRR (Free Range Routing) pour la prise en charge de BGP.
  yum install -y frr
3. Modifiez vi /etc/frr/daemons et définissez le paramètre bgpd sur yes pour activer BGP.
  
  Modifiez le fichier, effectuez la modification et enregistrez.
4. Activez et démarrez FRR.
  systemctl enable frr systemctl restart frr
5. Ajoutez la configuration BGP. Remplacez les adresses IP et les numéros AS par vos valeurs réelles.
  1. Accédez à l'interface de configuration FRR.
    
    vtysh
  2. Passez en mode configuration.
    
    config terminal
  3. Ajoutez la configuration BGP avec les commandes suivantes.
    
    Remplacez les valeurs suivantes par vos adresses réelles :
    
    Remplacez « 169.254.10.1 » et « 169.254.20.1 » par les adresses IP BGP réelles des tunnels côté Alibaba Cloud.
    
    Remplacez « 65535 » par le numéro AS BGP réel de la passerelle VPN.
    
    Remplacez « 172.16.20.0/24 » et « 172.16.21.0/24 » par les blocs CIDR réels de votre centre de données local.
    
    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.20.0/24 network 172.16.21.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
6. Exécutez exit pour quitter le mode de configuration, puis exécutez show ip bgp pour afficher les routes BGP.
  
  La sortie confirme que l'appareil strongSwan a appris les routes du VPC. Le centre de données local et le VPC peuvent désormais communiquer.
7. Enregistrez la configuration BGP afin qu'elle persiste lors des redémarrages de FRR.
  write memory
Routage statique

Créez deux scripts appelés par strongSwan pour configurer les routes et contrôler le flux du trafic.
1. Créez et modifiez le script /root/connect_1.sh.
  vi /root/connect_1.sh
2. Ajoutez et enregistrez le contenu suivant.
  #!/usr/bin/env bash if [ x"$PLUTO_VERB" == "xup-client" ]; then echo "ip route add 192.168.0.0/16 dev ipsec0" >> /root/vpn_route.log;ip route add 192.168.0.0/16 dev ipsec0 metric 100 elif [ x"$PLUTO_VERB" == "xdown-client" ]; then echo "ip route del 192.168.0.0/16 dev ipsec0" >> /root/vpn_route.log;ip route del 192.168.0.0/16 dev ipsec0 metric 100 fi
  Ce script ajoute une route pour le trafic allant du centre de données local vers le VPC Alibaba Cloud (192.168.0.0/16) via l'interface réseau virtuelle XFRM du tunnel 1 lorsque celui-ci est actif. La valeur de métrique de cette route est définie sur 100, ce qui lui confère une priorité plus élevée que la route du tunnel 2. Si le tunnel 1 est inactif, le script révoque la route.
3. Créez et modifiez le script /root/connect_2.sh.
  vi /root/connect_2.sh
4. Ajoutez et enregistrez le contenu suivant.
  #!/usr/bin/env bash if [ x"$PLUTO_VERB" == "xup-client" ]; then echo "ip route add 192.168.0.0/16 dev ipsec1" >> /root/vpn_route.log;ip route add 192.168.0.0/16 dev ipsec1 metric 101 elif [ x"$PLUTO_VERB" == "xdown-client" ]; then echo "ip route del 192.168.0.0/16 dev ipsec1" >> /root/vpn_route.log;ip route del 192.168.0.0/16 dev ipsec1 metric 101 fi
  Ce script ajoute une route pour le trafic allant du centre de données local vers le VPC Alibaba Cloud (192.168.0.0/16) via l'interface réseau virtuelle XFRM du tunnel 2 lorsque celui-ci est actif. La valeur de métrique de cette route est définie sur 101, ce qui lui confère une priorité inférieure à celle de la route du tunnel 1. Si le tunnel 2 est inactif, le script révoque la route.
5. Accordez des permissions d'exécution aux deux scripts.
  sudo chmod +x /root/connect_1.sh sudo chmod +x /root/connect_2.sh
6. Redémarrez le processus strongSwan.
  sudo systemctl restart strongswan
7. Vérifiez les routes.
  route -n

Routage dynamique BGP à sortie unique

Important

Le routage dynamique BGP nécessite des interfaces réseau virtuelles XFRM. Vérifiez les éléments suivants : strongSwan 5.8.0 ou version ultérieure, noyau Linux 4.19 ou version ultérieure, iproute2 5.1.0 ou version ultérieure, et prise en charge du module XFRM (exécutez lsmod | grep xfrm pour vérifier). Pour plus d'informations, consultez XFRM Interfaces on Linux.

Créez deux interfaces réseau virtuelles pour établir les tunnels IPsec-VPN.

ip link add ipsec0 type xfrm dev eth0 if_id 42 # Create an XFRM virtual network interface for Tunnel 1. The interface ID is 42 and the underlying interface is the public interface eth0.
ip link add ipsec1 type xfrm dev eth0 if_id 43 # Create an XFRM virtual network interface for Tunnel 2. The interface ID is 43 and the underlying interface is the public interface eth0.
ip link set ipsec0 up # Start the XFRM virtual network interface for Tunnel 1.
ip link set ipsec1 up # Start the XFRM virtual network interface for Tunnel 2.

Important

Les interfaces XFRM ne persistent pas après un redémarrage. Vous devez configurer le script de démarrage suivant afin que les interfaces soient automatiquement recréées et que strongSwan soit rechargé à chaque démarrage.

Cliquez pour afficher le script de démarrage.

Créez un fichier de script.
```
vi xfrm.sh
```

Ajoutez et enregistrez la configuration suivante.

sudo ip link add ipsec0 type xfrm dev eth0 if_id 42 # Create an XFRM virtual network interface for Tunnel 1. The interface ID is 42 and the underlying interface is the public interface eth0.
sudo ip link add ipsec1 type xfrm dev eth0 if_id 43 # Create an XFRM virtual network interface for Tunnel 2. The interface ID is 43 and the underlying interface is the public interface eth0.
sudo ip link set ipsec0 up # Start the XFRM virtual network interface for Tunnel 1.
sudo ip link set ipsec1 up # Start the XFRM virtual network interface for Tunnel 2.

Recherchez le chemin absolu du script.
```
sudo find / -name xfrm.sh
```
Ajoutez le chemin du script à /etc/rc.d/rc.local pour qu'il s'exécute au démarrage. Remplacez /path/to/xfrm.sh par le chemin réel renvoyé par la commande find précédente.
```
echo '/path/to/xfrm.sh' | sudo tee -a /etc/rc.d/rc.local
```
Accordez des permissions d'exécution au fichier rc.local et au script xfrm.sh.
```
sudo chmod +x /etc/rc.d/rc.local
sudo chmod +x /path/to/xfrm.sh
```

Modifiez le fichier de configuration strongSwan.

Sauvegardez le fichier de configuration strongSwan d'origine.

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

Créez un nouveau fichier de configuration strongSwan.
```
vi /etc/strongswan/swanctl/swanctl.conf
```

La configuration suivante est similaire à l'exemple à double sortie. Seules les différences sont annotées. Ajoutez et enregistrez la configuration suivante.

connections {
   vco1 {
      version = 2
      local_addrs  = 172.16.20.80    # Both tunnels use the same eth0 interface (single egress).
      remote_addrs = 47.XX.XX.151
      dpd_delay = 10
      rekey_time = 84600
      over_time = 1800
      proposals = aes128-sha1-modp1024
      encap = yes

      local {
         auth = psk
         id = 120.XX.XX.202
      }
      remote {
         auth = psk
         id = 47.XX.XX.151
      }
      children {
         vco_child1 {
            local_ts  = 0.0.0.0/0
            remote_ts = 0.0.0.0/0
            mode = tunnel
            rekey_time = 85500
            life_time = 86400
            dpd_action = restart
            start_action = start
            close_action = start
            esp_proposals = aes128-sha1-modp1024

            if_id_out = 42
            if_id_in = 42
         }
      }
   }
  vco2 {
      version = 2
      local_addrs  = 172.16.20.80    # Same as vco1 (single egress).
      remote_addrs = 47.XX.XX.87
      dpd_delay = 10
      rekey_time = 84600
      over_time = 1800
      proposals = aes128-sha1-modp1024
      encap = yes

      local {
         auth = psk
         id = 120.XX.XX.202          # Same public egress IP as vco1 (single egress).
      }
      remote {
         auth = psk
         id = 47.XX.XX.87
      }
      children {
         vco_child2 {
            local_ts  = 0.0.0.0/0
            remote_ts = 0.0.0.0/0
            mode = tunnel
            rekey_time = 85500
            life_time = 86400
            dpd_action = restart
            start_action = start
            close_action = start
            esp_proposals = aes128-sha1-modp1024
            if_id_out = 43
            if_id_in = 43
         }
      }
   }
}

secrets {
   ike-vco1 {
      id = 47.XX.XX.151
      secret = ChangeMe***
   }
   ike-vco2 {
      id = 47.XX.XX.87
      secret = ChangeMe***
   }
}

Redémarrez le processus strongSwan, rechargez la configuration strongSwan et vérifiez l'état du tunnel.
```
sudo systemctl restart strongswan
swanctl --load-all
watch swanctl --list-sas
```
La sortie suivante confirme que la connexion IPsec-VPN est établie. Configurez les routes à l'étape suivante pour activer la connectivité réseau.
Configurez le routage dynamique BGP.

Les adresses IP BGP attribuées aux interfaces XFRM ( ip address add ) ne persistent pas après un redémarrage. Ajoutez ces commandes au script de démarrage XFRM décrit précédemment. La configuration BGP FRR persiste automatiquement après avoir exécuté write memory dans vtysh (voir la dernière étape ci-dessous).
1. Configurez les adresses IP BGP sur les interfaces XFRM.
```
ip address add 169.254.10.2/30 dev ipsec0
ip address add 169.254.20.2/30 dev ipsec1
```
2. Installez FRR (Free Range Routing) pour la prise en charge de BGP.
```
yum install -y frr
```
3. Modifiez vi /etc/frr/daemons et définissez le paramètre bgpd sur yes pour activer BGP.
  
  Modifiez le fichier, effectuez la modification et enregistrez.
4. Activez et démarrez FRR.
```
systemctl enable frr
systemctl restart frr
```
5. Ajoutez la configuration BGP. Remplacez les adresses IP et les numéros AS par vos valeurs réelles.
  1. Accédez à l'interface de configuration FRR.
```
vtysh
```
  2. Passez en mode de configuration.
```
config terminal
```
  3. Ajoutez la configuration BGP avec les commandes suivantes.
    
    Remplacez les valeurs suivantes par vos adresses réelles :
    - Remplacez « 169.254.10.1 » et « 169.254.20.1 » par les adresses IP BGP réelles des tunnels côté Alibaba Cloud.
    - Remplacez « 65535 » par le numéro AS BGP réel de la passerelle VPN.
    - Remplacez « 172.16.20.0/24 » et « 172.16.21.0/24 » par les blocs CIDR réels de votre centre de données local.
```
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.20.0/24                  
  network 172.16.21.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
```
6. Exécutez exit pour quitter le mode de configuration, puis exécutez show ip bgp pour afficher les routes BGP.
  
  La sortie confirme que l'appareil strongSwan a appris les routes du VPC. Le centre de données local et le VPC peuvent désormais communiquer.
7. Enregistrez la configuration BGP afin qu'elle persiste lors des redémarrages de FRR.
```
write memory
```

Routage statique à sortie unique

Important

En mode de routage statique à sortie unique, Alibaba Cloud peut basculer proactivement le trafic vers le tunnel de secours s'il détecte une menace sur le tunnel actif. Surveillez le compteur XfrmInTmplMismatch dans /proc/net/xfrm_stat. Si cette valeur continue d'augmenter, le trafic a été basculé. Ajustez le paramètre priority pour le tunnel de secours dans /etc/strongswan/swanctl/swanctl.conf afin d'acheminer le trafic local via le tunnel de secours.

Sauvegardez le fichier de configuration strongSwan d'origine.

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

Créez un nouveau fichier de configuration strongSwan.
```
vi /etc/strongswan/swanctl/swanctl.conf
```

La configuration suivante est similaire à l'exemple à double sortie. Différences clés : sélecteurs de trafic basés sur des politiques (local_ts/remote_ts) et priority pour le basculement actif/de secours. Ajoutez et enregistrez la configuration suivante.

connections {
   vco1 {
      version = 2
      local_addrs  = 172.16.20.80
      remote_addrs = 47.XX.XX.151
      dpd_delay = 10
      rekey_time = 84600
      over_time = 1800
      proposals = aes128-sha1-modp1024
      encap = yes

      local {
         auth = psk
         id = 120.XX.XX.202
      }
      remote {
         auth = psk
         id = 47.XX.XX.151
      }
      children {
         vco_child1 {
            local_ts  = 172.16.0.0/16   # Policy-based: on-premises private CIDR block.
            remote_ts = 192.168.0.0/16  # Policy-based: VPC CIDR block.
            mode = tunnel
            rekey_time = 85500
            life_time = 86400
            dpd_action = restart
            start_action = start
            close_action = start
            esp_proposals = aes128-sha1-modp1024
            priority = 1                # Active tunnel (higher priority).
         }
      }
   }
  vco2 {
      version = 2
      local_addrs  = 172.16.20.80
      remote_addrs = 47.XX.XX.87
      dpd_delay = 10
      rekey_time = 84600
      over_time = 1800
      proposals = aes128-sha1-modp1024
      encap = yes

      local {
         auth = psk
         id = 120.XX.XX.202
      }
      remote {
         auth = psk
         id = 47.XX.XX.87
      }
      children {
         vco_child2 {
            local_ts  = 172.16.0.0/16   # Policy-based: on-premises private CIDR block.
            remote_ts = 192.168.0.0/16  # Policy-based: VPC CIDR block.
            mode = tunnel
            rekey_time = 85500
            life_time = 86400
            dpd_action = restart
            start_action = start
            close_action = start
            esp_proposals = aes128-sha1-modp1024
            priority = 2                # Standby tunnel (lower priority).
         }
      }
   }
}

secrets {
   ike-vco1 {
      id = 47.XX.XX.151
      secret = ChangeMe***
   }
   ike-vco2 {
      id = 47.XX.XX.87
      secret = ChangeMe***
   }
}

Redémarrez le processus strongSwan, rechargez la configuration strongSwan et vérifiez l'état du tunnel.
```
sudo systemctl restart strongswan
swanctl --load-all
watch swanctl --list-sas
```
La sortie suivante confirme que la connexion IPsec-VPN est établie. Le centre de données local et le VPC peuvent désormais communiquer.

5. Vérifier la connectivité et la haute disponibilité

Vérifiez la connectivité entre le centre de données local et le VPC.

Depuis un client du centre de données local, utilisez ping vers une instance ECS dans le VPC. Les paquets de réponse confirment une connexion réussie.
```
ping <IP_address_of_an_ECS_instance_in_the_VPC>
```
Vérifiez la haute disponibilité de la connexion IPsec-VPN.
1. Pendant l'exécution de la commande ping, interrompez le tunnel actif.
  
  Une façon d'interrompre le tunnel consiste à modifier sa clé pré-partagée afin que les clés des deux extrémités ne correspondent plus.
2. Surveillez le trafic ping après avoir interrompu le tunnel actif. Une brève interruption suivie d'une récupération confirme que le trafic bascule automatiquement vers le tunnel de secours.

FAQ

Comment configurer strongSwan lorsque la connexion IPsec-VPN est associée à un Transit Router ?

La configuration de strongSwan reste identique à celle décrite dans cette rubrique. Utilisez le routage dynamique BGP pour les scénarios impliquant un Transit Router. Une fois la configuration appliquée, l’appareil strongSwan apprend les routes du VPC via BGP et les deux tunnels forment automatiquement une liaison ECMP (Equal-Cost Multi-Path). ECMP routes through Transit Router

strongSwan prend-il en charge IKEv1 ?

Oui. Définissez version = 1 dans le fichier /etc/strongswan/swanctl/swanctl.conf.

Comment spécifier les flux de données protégés (streams of interest) ?

Définissez les champs local_ts et remote_ts dans le fichier /etc/strongswan/swanctl/swanctl.conf. Assurez-vous également que le mode Protected Data Flows est configuré côté Alibaba Cloud.

Pour spécifier plusieurs blocs CIDR de part et d’autre, l’appareil strongSwan et la connexion IPsec-VPN d’Alibaba Cloud doivent tous deux utiliser IKEv2.

children {
         vco_child1 {
            local_ts  = 172.16.20.0/24,172.16.21.0/24  # The CIDR blocks of the on-premises data center.
            remote_ts = 192.168.0.0/16    # The CIDR block of the VPC on the Alibaba Cloud side.
         }
}

Comment configurer strongSwan lorsque l’interface réseau dispose d’une adresse IP publique (sans NAT) ?

Modifiez le champ local_addrs de chaque tunnel dans le fichier /etc/strongswan/swanctl/swanctl.conf pour y indiquer l’adresse IP publique. Toutes les autres configurations restent inchangées.

connections {
   vco1 {                            
      local_addrs  = 1.1.XX.XX     # Specify the public IP address that is bound to the network interface card of the strongSwan device.
   }
}

Comment résoudre les échecs de négociation de tunnel ?

Exécutez journalctl -u strongswan -f ou swanctl --log pour afficher les journaux de négociation en temps réel. Les causes courantes d’échec de négociation incluent :

Clé pré-partagée incorrecte entre l’appareil strongSwan et Alibaba Cloud
Incompatibilité des algorithmes (chiffrement, authentification ou groupe DH)
Version IKE incompatible (IKEv1 par rapport à IKEv2)
Pare-feu bloquant le port UDP 500 ou 4500, ou le protocole ESP (protocole IP 50)

Pourquoi le tunnel est-il établi mais le trafic ne circule-t-il pas ?

Si swanctl --list-sas indique que le tunnel est établi mais que le ping échoue, vérifiez les points suivants :

Vérifiez que le transfert IP est activé : cat /proc/sys/net/ipv4/ip_forward (la sortie doit être 1)
Vérifiez les politiques et états XFRM : ip xfrm policy et ip xfrm state
Vérifiez la table de routage : ip route show
Vérifiez que la chaîne FORWARD d’iptables autorise le trafic : iptables -L FORWARD -n

Comment résoudre les instabilités fréquentes du tunnel (délais DPD) ?

Les délais de détection des pairs inactifs (DPD) provoquent des instabilités du tunnel lorsque le réseau entre les points de terminaison est instable. Pour atténuer ce problème :

Augmentez la valeur de dpd_delay (par exemple, de 10 à 30) dans le fichier /etc/strongswan/swanctl/swanctl.conf afin de réduire la sensibilité aux pertes de paquets transitoires
Assurez-vous que les paramètres DPD sont compatibles des deux côtés
Vérifiez la stabilité du réseau entre les points de terminaison (perte de paquets et latence) à l’aide de mtr ou de ping -c 100

Comment configurer un tunnel unique ?

Important

Si la passerelle VPN que vous avez achetée prend uniquement en charge les connexions IPsec-VPN à tunnel unique, nous vous recommandons de mettre à niveau la connexion IPsec-VPN vers le mode à double tunnel. Une connexion IPsec-VPN en mode double tunnel prend en charge la reprise après sinistre au niveau de la zone, ce qui améliore la haute disponibilité du réseau.

Guide de configuration à tunnel unique (pour les instances de passerelle VPN héritées)

Cette section s’applique aux instances de passerelle VPN qui ne prennent en charge que les connexions IPsec-VPN à tunnel unique. Si votre instance prend en charge le mode double tunnel, utilisez la configuration décrite dans les sections principales ci-dessus.

Configuration à tunnel unique

Exemple de scénario

La figure suivante illustre un déploiement à tunnel unique où un appareil strongSwan établit une connexion IPsec-VPN avec Alibaba Cloud.

Planification des adresses IP

Côté centre de données sur site

Bloc CIDR privé : 172.16.0.0/16
Appareil strongSwan, carte réseau eth0 : 172.16.20.80, sortie publique mappée par NAT : 120.XX.XX.202

Pour les scénarios sans NAT, consultez Comment configurer strongSwan lorsque l’interface réseau dispose d’une adresse IP publique (sans NAT) ? .

Côté Alibaba Cloud

Bloc CIDR du VPC : 192.168.0.0/16
- Bloc CIDR du vSwitch 1 : 192.168.10.0/24
- Bloc CIDR du vSwitch 2 : 192.168.20.0/24
- Bloc CIDR du vSwitch 3 : 192.168.30.0/24
- Bloc CIDR du vSwitch 4 : 192.168.40.0/24
- Bloc CIDR du vSwitch 5 : 192.168.50.0/24
Passerelle VPN
- Adresse IPsec : 47.XX.XX.151
  
  Après la création d’une instance de passerelle VPN, le système attribue automatiquement une adresse IPsec à l’instance.

Planification des paramètres VPN

Les configurations IKE et IPsec de l’appareil strongSwan doivent correspondre à celles d’Alibaba Cloud.

Clé pré-partagée : ChangeMe***

Paramètre

IKE

IPsec

Version / Mode

IKEv2 / main

-

Algorithme de chiffrement

aes128

Algorithme d’authentification

sha1

Groupe DH

group2 (modp1024)

Durée de vie SA (secondes)

86400

Préparer le côté Alibaba Cloud

Avant de configurer l’appareil strongSwan, effectuez les opérations suivantes côté Alibaba Cloud : Créer une passerelle VPN, Créer une passerelle cliente, Créer une connexion IPsec-VPN et Configurer les routes de la passerelle VPN. Pour plus d’informations, consultez Connecter un VPC à un centre de données sur site en mode tunnel unique.

Lors de la création de la connexion IPsec-VPN, définissez le mode de routage sur Protected Data Flows :

Définissez Réseau local sur le bloc CIDR du VPC côté Alibaba Cloud, soit 192.168.0.0/16.
Définissez Réseau distant sur le bloc CIDR privé du centre de données sur site, soit 172.16.0.0/16.

Configurer l’appareil strongSwan

Les étapes suivantes utilisent CentOS Stream 9 (64 bits) à titre d’exemple. Pour les autres distributions, consultez la documentation officielle de strongSwan .

1. Configurer les règles de pare-feu

Autorisez le protocole ESP (protocole IP 50), le port UDP 500 et le port UDP 4500 sur l’appareil strongSwan.

iptables -I INPUT -p 50 -j ACCEPT
iptables -I INPUT -p udp --dport 500 -j ACCEPT 
iptables -I INPUT -p udp --dport 4500 -j ACCEPT

Ces règles iptables ne persistent pas après un redémarrage. Pour les rendre permanentes, utilisez iptables-save , firewall-cmd --permanent ou l’outil de gestion de pare-feu privilégié par votre distribution.

2. Activer le transfert de trafic

Activez le transfert IP afin que l’appareil strongSwan puisse acheminer le trafic entre le réseau sur site et le VPC. La commande suivante prend effet immédiatement et persiste après les redémarrages.

Ajoutez la configuration de transfert au fichier /etc/sysctl.conf.
```
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
```
Appliquez la configuration.
```
sudo sysctl -p
```
Vérifiez que le transfert IP est activé.
```
cat /proc/sys/net/ipv4/ip_forward
```
La sortie doit être 1.

3. Installer strongSwan

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

4. Configurer le tunnel

Configurez le tunnel en fonction des sélecteurs de trafic basés sur les politiques de strongSwan.

Sauvegardez le fichier de configuration strongSwan d’origine.

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

Créez un nouveau fichier de configuration strongSwan.
```
vi /etc/strongswan/swanctl/swanctl.conf
```

La configuration suivante est similaire aux exemples à double tunnel. Les différences clés sont les suivantes : connexion unique, sélecteurs de trafic basés sur les politiques et absence d’interfaces XFRM. Ajoutez et enregistrez la configuration suivante.

connections {
   vco1 {
      version = 2
      local_addrs  = 172.16.20.80      # On-premises private IP address.
      remote_addrs = 47.XX.XX.151      # IPsec address on the Alibaba Cloud side.
      dpd_delay = 10
      rekey_time = 84600
      over_time = 1800
      proposals = aes128-sha1-modp1024
      encap = yes

      local {
         auth = psk
         id = 120.XX.XX.202            # On-premises public egress IP (NAT-mapped).
      }
      remote {
         auth = psk
         id = 47.XX.XX.151
      }
      children {
         vco_child1 {
            local_ts  = 172.16.0.0/16     # Policy-based: on-premises private CIDR block.
            remote_ts = 192.168.0.0/16    # Policy-based: VPC CIDR block.
            mode = tunnel
            rekey_time = 85500
            life_time = 86400
            dpd_action = restart
            start_action = start
            close_action = start
            esp_proposals = aes128-sha1-modp1024
         }
      }
   }
}

secrets {
   ike-vco1 {
      id = 47.XX.XX.151
      secret = ChangeMe***
   }
}

Redémarrez le processus strongSwan et rechargez la configuration strongSwan.
```
systemctl restart strongswan
swanctl --load-all
```
Vérifiez l’état du tunnel.
```
watch swanctl --list-sas 
```
Comme illustré sur la figure, une connexion IPsec-VPN est correctement établie entre l’appareil strongSwan et la passerelle VPN.

5. Vérifier la connectivité

Vérifiez la connectivité entre l’appareil strongSwan et le VPC :

Depuis l’appareil strongSwan, exécutez un ping vers une instance ECS dans le VPC. La réception de paquets de réponse confirme que la connexion est réussie.

ping <IP_address_of_an_ECS_instance_in_the_VPC>