VPN Gateway:Getting started with binding IPsec-VPN to Transit Router

Planejamento de recursos

• cloud: Uma VPC com bloco CIDR 10.0.0.0/16 na região China (Hangzhou).

  • vSwitch 1: Na zona de disponibilidade H, com o bloco CIDR 10.0.0.0/24.

  • vSwitch 2: Na zona de disponibilidade J, com o bloco CIDR 10.0.2.0/24.

  • Instância ECS: Endereço IP 10.0.0.1, usada para testes de conectividade.

  • Instância CEN: Hospeda o Transit Router.

  • Transit Router: Criado na região East China 1 (Hangzhou). Faixa de endereços do TR: 10.10.10.0/24 (não deve entrar em conflito com os blocos CIDR da VPC, do IDC ou do BGP).

• On-premises: IDC com bloco CIDR 172.16.0.0/16.

  • Dispositivo strongSwan: Endereço IP privado 172.16.0.1.

  • Endereço IP público: XX.XX.3.3.

• Algoritmo de criptografia: IKEv2 / AES-128 / SHA-1 / Grupo DH 2 / Tempo de vida da SA de 86400 segundos. Configure ambas as extremidades do túnel com os mesmos parâmetros de criptografia.

• Modo de roteamento: Use roteamento dinâmico BGP. O planejamento dos blocos CIDR do BGP é o seguinte (o bloco CIDR do túnel deve ser um /30 dentro de 169.254.0.0/16, e os dois túneis não podem ter o mesmo bloco).

  Recurso	Túnel	Sub-rede do túnel	Endereço IP BGP	Número AS BGP
  Conexão IPsec (lado da cloud)	Túnel 1	169.254.10.0/30	169.254.10.1	65535
  	Túnel 2	169.254.20.0/30	169.254.20.1	65535
  Dispositivo de gateway local (IDC)	Túnel 1	169.254.10.0/30	169.254.10.2	65530
  	Túnel 2	169.254.20.0/30	169.254.20.2	65530

  O número do sistema autônomo local de ambos os túneis deve ser o mesmo. Recomenda-se também que o número AS remoto (IDC) seja igual para os dois túneis.

Pré-requisitos

• Os blocos CIDR da VPC, do IDC e a sub-rede do túnel BGP não devem entrar em conflito entre si.

• Crie uma VPC e um vSwitch em cada uma das duas zonas diferentes (as zonas onde residem os vSwitches devem estar incluídas na List of zones supported by the Transit Router). A VPC deve ter pelo menos uma instância ECS para verificação de conectividade.

• Crie uma instância CEN e um Transit Router (TR) que atendam às seguintes condições:

  • The VPC is attached to the TR.

  • A Route propagation e a Route synchronization estão habilitadas entre a VPC e o TR.

  • Um CIDR block está configurado para o TR.

• Implante um servidor Linux no IDC local (este artigo usa CentOS Stream 9 como exemplo) com uma única saída pública. Instale o strongSwan (para o túnel IPsec) e o FRRouting (para BGP) neste servidor para atuar como gateway local.

1. Configurar regras de firewall

No dispositivo strongSwan, permita o protocolo ESP (número de protocolo IP 50), a porta UDP 500 e a porta UDP 4500 para permitir o acesso a partir dos dois endereços IPsec do lado da cloud.

O exemplo a seguir utiliza iptables. Ajuste conforme sua ferramenta 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 o encaminhamento de IP

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

3. Instalar o strongSwan

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

4. Criar interfaces XFRM e um script updown

Como o cenário de túnel duplo precisa distinguir o tráfego de cada túnel, crie interfaces virtuais XFRM para evitar conflitos nas políticas de roteamento do kernel. No modo de roteamento dinâmico BGP, também configure os endereços do túnel BGP nas 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 o strongSwan

1. Faça backup do arquivo de configuração original:

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

2. Crie um novo arquivo de configuração:

   vi /etc/strongswan/swanctl/swanctl.conf

3. Adicione a seguinte configuração. Substitua os endereços IP e chaves de exemplo pelos seus valores reais.

   # 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

   • Os parâmetros if_id_in e if_id_out vinculam cada túnel à interface XFRM correspondente (ipsec0 / ipsec1), garantindo que o tráfego dos dois túneis não interfira entre si.

   • Os parâmetros local_ts e remote_ts estão definidos como 0.0.0.0/0; as rotas aprendidas via BGP determinam qual tráfego entra no túnel. No modo de rota de destino, o seletor de tráfego do lado da cloud também é 0.0.0.0/0.

6. Iniciar o strongSwan e verificar o status do túnel

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

Se ambos os túneis exibirem o status ESTABLISHED e o CHILD_SA mostrar INSTALLED, a conexão IPsec foi estabelecida com sucesso.

# 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 roteamento dinâmico BGP (FRRouting)

Após o estabelecimento do túnel IPsec, as redes ainda não conseguem se comunicar. Configure o BGP no dispositivo de gateway local para estabelecer vizinhos BGP com o lado da Alibaba Cloud, anunciar automaticamente os blocos CIDR locais e aprender os blocos CIDR da cloud.

Nota : Após reiniciar o dispositivo strongSwan/FRR, readicione as interfaces XFRM, os endereços do túnel BGP e a configuração BGP.

1. Instale o FRRouting:

   sudo dnf install frr -y

2. Habilite o daemon bgpd:

   Edite o arquivo /etc/frr/daemons, altere bgpd=no para bgpd=yes, salve e inicie o FRR:

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

3. Adicione a configuração BGP:

   Entre na interface de configuração vtysh e adicione a seguinte configuração. Durante a execução, substitua os endereços pelos seus valores reais:

   • 169.254.10.1 e 169.254.20.1: Substitua pelos endereços BGP locais dos dois túneis no lado da Alibaba Cloud (ou seja, os vizinhos BGP remotos do dispositivo local).

   • 65535: Substitua pelo número do sistema autônomo local da conexão IPsec da Alibaba Cloud.

   • 65530: Substitua pelo número AS BGP do IDC local.

   • 172.16.0.0/24: Substitua pelo bloco CIDR do IDC local que você precisa anunciar para o lado da 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. Confirme os vizinhos e as rotas BGP:

   show ip bgp summary
   show ip bgp

   • O campo State/PfxRcd dos dois vizinhos (169.254.10.1 e 169.254.20.1) na saída do comando show ip bgp summary deve exibir o número de prefixos recebidos (em vez de Active/Idle), indicando que os vizinhos BGP foram estabelecidos.

   • Na saída do comando show ip bgp, você deverá ver os blocos CIDR da VPC do lado da cloud aprendidos via BGP (como 10.0.0.0/24 e 10.0.2.0/24). Cada bloco CIDR terá dois caminhos equivalentes (via túnel 1 e 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 se as rotas ECMP foram instaladas no kernel:

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

Testar conectividade

1. Primeiro, garanta que as regras do grupo de segurança da ECS permitiram o protocolo ICMP e execute ping na ECS do lado da cloud a partir de um cliente no IDC local:

   ping 10.0.0.1

   Uma resposta confirma a conectividade entre a VPC e o IDC on-premises.

   Nota : Ao executar ping a partir do próprio dispositivo strongSwan, especifique o IP interno do IDC como endereço de source (por exemplo, ping -I 172.16.0.1 10.0.0.1 ) para evitar que o kernel selecione o endereço do túnel BGP (169.254.x.x) como endereço de source, o que causaria falha no caminho de retorno.

2. Garanta que o dispositivo strongSwan ou outro servidor on-premises permita tráfego ICMP. Faça login na instância ECS (10.0.0.1) na VPC e execute ping no dispositivo strongSwan:

   ping 172.16.0.1

   Uma resposta confirma a conectividade bidirecional.

Testar alta disponibilidade

Uma conexão IPsec associada a um Transit Router e utilizando BGP usa ambos os túneis simultaneamente no modo ECMP (Equal-Cost Multi-Path) por padrão, com o tráfego balanceado entre os dois túneis. Quando um túnel falha, o BGP retira automaticamente a rota desse túnel, e o tráfego converge para o outro túnel sem necessidade de failover manual.

1. Mantenha a ECS executando ping continuamente no servidor do IDC:

   ping 172.16.0.1 -c 10000

2. Interrompa um dos túneis: No console da Alibaba Cloud, modifique a chave pré-compartilhada do túnel 1 da conexão IPsec (para que as chaves em ambas as extremidades fiquem inconsistentes). O túnel será interrompido e seu vizinho BGP será desconectado consequentemente.

3. Observe o resultado do ping: Após uma breve interrupção, a comunicação é retomada, indicando que o tráfego convergiu automaticamente para o túnel 2.

4. Restaure o túnel: Altere a chave pré-compartilhada do túnel 1 de volta para o valor correto. Após a restauração do túnel e do vizinho BGP, o tráfego voltará a ser balanceado entre os dois túneis.