VPN Gateway:Vinculación a un transit router

Planificación de recursos

• Nube: Una VPC con bloque CIDR 10.0.0.0/16 en la región China (Hangzhou).

  • vSwitch 1: Ubicado en la zona de disponibilidad H, con el bloque CIDR 10.0.0.0/24.

  • vSwitch 2: Ubicado en la zona de disponibilidad J, con el bloque CIDR 10.0.2.0/24.

  • Instancia ECS: Dirección IP 10.0.0.1, utilizada para pruebas de conectividad.

  • Instancia CEN: Aloja el Transit Router.

  • Transit Router: Creado en la región East China 1 (Hangzhou). Rango de direcciones del TR: 10.10.10.0/24 (no debe entrar en conflicto con los bloques CIDR de la VPC, el IDC ni BGP).

• Local: IDC con bloque CIDR 172.16.0.0/16.

  • Dispositivo strongSwan: Dirección IP privada 172.16.0.1.

  • Dirección IP pública: XX.XX.3.3.

• Algoritmo de cifrado: IKEv2 / AES-128 / SHA-1 / Grupo DH 2 / Tiempo de vida de SA 86,400 segundos. Ambos extremos del túnel deben configurarse con los mismos parámetros de cifrado.

• Modo de enrutamiento: Utilice enrutamiento dinámico BGP. La planificación de bloques CIDR para BGP es la siguiente (el bloque CIDR del túnel debe ser un /30 dentro de 169.254.0.0/16, y los dos túneles no pueden usar el mismo bloque).

  Recurso	Túnel	Subred del túnel	Dirección IP BGP	Número AS BGP
  Conexión IPsec (lado de la nube)	Túnel 1	169.254.10.0/30	169.254.10.1	65,535
  	Túnel 2	169.254.20.0/30	169.254.20.1	65,535
  Dispositivo de gateway local (IDC)	Túnel 1	169.254.10.0/30	169.254.10.2	65,530
  	Túnel 2	169.254.20.0/30	169.254.20.2	65,530

  El número de sistema autónomo local de ambos túneles debe ser idéntico; también se recomienda que el número AS remoto (del IDC) sea el mismo para los dos túneles.

Requisitos previos

• El bloque CIDR de la VPC, el bloque CIDR del IDC y la subred del túnel BGP no deben entrar en conflicto entre sí.

• Se ha creado una VPC y se ha creado un vSwitch en cada una de dos zonas distintas (las zonas donde residen los vSwitches deben estar incluidas en List of zones supported by the Transit Router). Debe existir como mínimo una instancia ECS en la VPC para verificar la conectividad.

• Se han creado una instancia CEN y un Transit Router (TR) que cumplen las siguientes condiciones:

  • The VPC is attached to the TR.

  • Route propagation y Route synchronization están habilitados entre la VPC y el TR.

  • Se ha configurado una CIDR block para el TR.

• Se ha desplegado un servidor Linux en el IDC local (este artículo utiliza CentOS Stream 9 como ejemplo) con una única salida pública. En este servidor se instalarán strongSwan (para el túnel IPsec) y FRRouting (para BGP), funcionando como gateway local.

1. Configurar reglas de firewall

En el dispositivo strongSwan, permita el protocolo ESP (número de protocolo IP 50), el puerto UDP 500 y el puerto UDP 4500 para permitir el acceso desde las dos direcciones IPsec del lado de la nube.

El siguiente ejemplo utiliza iptables. Ajústelo según su herramienta de firewall.

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. Habilitar el reenvío de IP

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

3. Instalar strongSwan

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

4. Crear interfaces XFRM y un script updown

Dado que el escenario de túnel doble requiere distinguir el tráfico de cada túnel, debe crear interfaces virtuales XFRM para evitar conflictos en las directivas de enrutamiento del kernel. En el modo de enrutamiento dinámico BGP, también necesita configurar las direcciones del túnel BGP en las 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. Configurar strongSwan

1. Realice una copia de seguridad del archivo de configuración original:

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

2. Cree un nuevo archivo de configuración:

   vi /etc/strongswan/swanctl/swanctl.conf

3. Agregue la siguiente configuración. Reemplace las direcciones IP y claves de ejemplo con sus valores reales.

   # 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.
      }
   }

   Importante

   • if_id_in y if_id_out vinculan cada túnel a la interfaz XFRM correspondiente (ipsec0 / ipsec1), garantizando que el tráfico de ambos túneles no interfiera entre sí.

   • local_ts y remote_ts están establecidos en 0.0.0.0/0; las rutas aprendidas mediante BGP determinan qué tráfico ingresa al túnel. En el modo de ruta de destino, el selector de tráfico del lado de la nube también es 0.0.0.0/0.

6. Iniciar strongSwan y verificar el estado del túnel

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

Si ambos túneles muestran el estado ESTABLISHED y CHILD_SA muestra INSTALLED, la conexión IPsec se ha establecido correctamente.

# 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. Configurar enrutamiento dinámico BGP (FRRouting)

Una vez establecido el túnel IPsec, las redes aún no pueden comunicarse. Es necesario configurar BGP en el dispositivo de gateway local para establecer vecinos BGP con el lado de Alibaba Cloud, anunciar automáticamente los bloques CIDR locales y aprender los bloques CIDR del lado de la nube.

Nota : Después de reiniciar el dispositivo strongSwan/FRR, debe volver a agregar las interfaces XFRM, las direcciones del túnel BGP y la configuración BGP.

1. Instale FRRouting:

   sudo dnf install frr -y

2. Habilite el daemon bgpd:

   Edite /etc/frr/daemons, cambie bgpd=no por bgpd=yes, guarde los cambios y luego inicie FRR:

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

3. Agregue la configuración BGP:

   Ingrese a la interfaz de configuración vtysh y agregue la siguiente configuración. Al ejecutarla, reemplace las direcciones con sus valores reales:

   • 169.254.10.1 y 169.254.20.1: Reemplácelos con las direcciones BGP locales de los dos túneles del lado de Alibaba Cloud (es decir, los vecinos BGP remotos del dispositivo local).

   • 65535: Reemplácelo con el número de sistema autónomo local de la conexión IPsec de Alibaba Cloud.

   • 65530: Reemplácelo con el número AS BGP del IDC local.

   • 172.16.0.0/24: Reemplácelo con el bloque CIDR del IDC local que necesita anunciar al lado de la nube.

   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. Confirme los vecinos y las rutas BGP:

   show ip bgp summary
   show ip bgp

   • El campo State/PfxRcd de los dos vecinos (169.254.10.1 y 169.254.20.1) en show ip bgp summary debe mostrar el número de prefijos recibidos (en lugar de Active/Idle), lo cual indica que los vecinos BGP se han establecido.

   • En show ip bgp, debería poder ver los bloques CIDR de la VPC del lado de la nube aprendidos mediante BGP (como 10.0.0.0/24 y 10.0.2.0/24); cada bloque CIDR tendrá dos rutas equivalentes (a través del túnel 1 y del túnel 2 respectivamente), formando 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. Confirme que las rutas ECMP se han instalado en el kernel:

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

Probar la conectividad

1. Primero asegúrese de que las reglas del security group de la ECS hayan permitido el protocolo ICMP; luego, haga ping a la ECS del lado de la nube desde un cliente en el IDC local:

   ping 10.0.0.1

   Una respuesta confirma la conectividad entre la VPC y el IDC local.

   Nota : Al hacer ping desde el propio dispositivo strongSwan, especifique la IP interna del IDC como dirección de origen (por ejemplo, ping -I 172.16.0.1 10.0.0.1 ) para evitar que el kernel seleccione la dirección del túnel BGP (169.254.x.x) como dirección de origen, lo cual provocaría un fallo en la ruta de retorno.

2. Asegúrese de que el dispositivo strongSwan u otro servidor local permita tráfico ICMP. Inicie sesión en la instancia ECS (10.0.0.1) de la VPC y haga ping al dispositivo strongSwan:

   ping 172.16.0.1

   Una respuesta confirma la conectividad bidireccional.

Probar la alta disponibilidad

Una conexión IPsec vinculada a un Transit Router que utiliza BGP emplea ambos túneles simultáneamente en modo ECMP (Equal-Cost Multi-Path) de forma predeterminada, con el tráfico balanceado entre los dos túneles. Cuando uno de los túneles falla, BGP retira automáticamente la ruta de ese túnel y el tráfico converge hacia el otro sin necesidad de un cambio manual.

1. Mantenga la ECS haciendo ping continuamente al servidor del IDC:

   ping 172.16.0.1 -c 10000

2. Interrumpa uno de los túneles: En la consola de Alibaba Cloud, modifique la clave precompartida del túnel 1 de la conexión IPsec (de modo que las claves en ambos extremos sean inconsistentes). El túnel se interrumpirá y su vecino BGP se desconectará en consecuencia.

3. Observe el resultado del ping: Tras una breve interrupción, la comunicación se reanudará, lo que indica que el tráfico ha convergido automáticamente hacia el túnel 2.

4. Restaure el túnel: Cambie la clave precompartida del túnel 1 a su valor correcto. Una vez restaurados el túnel y el vecino BGP, el tráfico volverá a balancearse entre ambos túneles.