Multi-CIDR block communication - VPN Gateway: Central de Documentação do Alibaba Cloud

Este tópico descreve as recomendações de configuração para implementar a comunicação entre múltiplos blocos CIDR usando uma conexão IPsec-VPN e resume as perguntas frequentes sobre esse tipo de comunicação.

Recomendações de configuração para múltiplos blocos CIDR

Recomendamos o uso do IKEv2 para a conexão IPsec-VPN e seu dispositivo de gateway par.

Nota
Caso o dispositivo de gateway par não suporte IKEv2, a conexão IPsec-VPN e o dispositivo podem utilizar IKEv1. Em cenários onde a conexão IPsec-VPN usa IKEv1, cada conexão suporta apenas um bloco CIDR local e um bloco CIDR par. Consulte {{XREF_0}} para obter detalhes sobre a configuração necessária para estabelecer a comunicação entre múltiplos blocos CIDR.
Se o par da conexão IPsec-VPN utilizar um equipamento de fornecedores tradicionais como Cisco, H3C , siga as recomendações de configuração abaixo:
- No lado da Alibaba Cloud da conexão IPsec-VPN, os campos Encryption Algorithm, Authentication Algorithm e DH Group (Perfect Forward Secrecy) nas seções IKE Configurations e IPsec Configurations aceitam apenas um único valor. Portanto, ao adicionar configurações de VPN no dispositivo de gateway par, defina também um valor único para Encryption Algorithm, Authentication Algorithm e DH Group (Perfect Forward Secrecy) (PFS) em IKE Configurations e IPsec Configurations. Esse valor deve ser idêntico ao configurado na conexão IPsec-VPN.
- Quando a detecção de par inativo (DPD) estiver ativada na conexão IPsec-VPN, o dispositivo de gateway par deverá usar o recurso DPD padrão.
- O tempo de vida da SA (Security Association) configurado na conexão IPsec-VPN e no dispositivo de gateway par deve ser idêntico.
  
  Se o dispositivo de gateway par permitir especificar um tempo de vida de SA baseado em tráfego, defina esse valor como o máximo permitido. Alguns fabricantes permitem configurar 0 bytes como valor máximo.

Soluções de configuração recomendadas para múltiplos blocos CIDR

Ao conectar um data center on-premises a uma VPC (Virtual Private Cloud) via conexão IPsec-VPN para habilitar a comunicação entre múltiplos blocos CIDR, recomendamos a seguinte solução de configuração.

Solução	Versão IKE aplicável	Descrição da solução	Benefícios ou limitações	Exemplo de configuração
Solução 1 (recomendada)	IKEv1 IKEv2	Utilize uma única conexão IPsec-VPN para ligar o data center on-premises à VPC. Configure o modo de roteamento da conexão como Destination routing e defina no dispositivo de gateway par um fluxo de dados protegido com bloco CIDR de origem `0.0.0.0/0` e bloco CIDR de destino `0.0.0.0/0`. Em seguida, controle o encaminhamento de tráfego configurando rotas dinâmicas BGP ou rotas estáticas no gateway de VPN e no data center on-premises.	Benefícios da solução: Para adicionar ou remover blocos CIDR de comunicação posteriormente, basta ajustar a configuração de rotas, sem alterar a conexão IPsec-VPN. A adição ou exclusão de blocos CIDR não interrompe a conexão IPsec-VPN nem afeta o tráfego das demais rotas.	{{XREF_1}}
Solução 2 (segunda opção)	IKEv1 IKEv2	Use uma única conexão IPsec-VPN para conectar o data center on-premises à VPC. Agrege os blocos CIDR que precisam se comunicar tanto no lado do data center quanto no da VPC em um único bloco CIDR cada e configure esses blocos agregados na conexão IPsec-VPN e no dispositivo de gateway par.	Limitações da solução: Se houver adição ou remoção de blocos CIDR no futuro, talvez seja necessário especificar novamente o bloco agregado e reconfigurar a conexão IPsec-VPN e o gateway par. Essa operação força uma renegociação da conexão, causando uma breve interrupção no tráfego.	{{XREF_2}}
Solução 3	IKEv1 IKEv2	Estabeleça várias conexões IPsec-VPN entre o data center on-premises e a VPC, dedicando uma conexão para cada bloco CIDR que precisa se comunicar. As múltiplas conexões devem atender aos seguintes requisitos: Todas as conexões IPsec-VPN devem estar associadas ao mesmo gateway de VPN e ao mesmo customer gateway. A Local Network e todos os parâmetros da fase de Remote Network (incluindo Pre-Shared Key, IKE Configurations, Version, Negotiation Mode, Encryption Algorithm e Authentication Algorithm) devem ser idênticos em todas as conexões. O DH Group (Perfect Forward Secrecy) de cada conexão IPsec-VPN deve corresponder ao SA Life Cycle (seconds) do dispositivo de gateway par; da mesma forma, o LocalId de cada conexão deve ser igual ao RemoteId do gateway par. Nota Quando existem múltiplas conexões IPsec-VPN sob uma instância de gateway de VPN, associadas ao mesmo customer gateway e com a mesma versão IKE, elas compartilham a Fase 1. No cenário de compartilhamento da Fase 1, a RemoteId e todos os parâmetros de LocalId (incluindo Pre-Shared Key, IKE Configurations, Version, Negotiation Mode, Encryption Algorithm e Authentication Algorithm) devem ser iguais em todas as conexões. Isso garante que a configuração da fase de DH Group (Perfect Forward Secrecy) de qualquer conexão possa ser compartilhada durante a negociação do protocolo IPsec.	Limitações da solução: Caso precise modificar os blocos CIDR de comunicação posteriormente, será necessário alterar as configurações da conexão IPsec-VPN e do dispositivo de gateway par. Essa alteração provoca uma renegociação da conexão e resulta em uma breve interrupção do tráfego.	{{XREF_3}}

Exemplos de soluções de configuração para múltiplos blocos CIDR

Exemplo de configuração da Solução 1

Considere o seguinte cenário: múltiplos blocos CIDR na VPC (10.1.1.0/24 e 10.1.2.0/24) precisam se comunicar com múltiplos blocos no data center on-premises (192.168.1.0/24 e 192.168.2.0/24). As configurações recomendadas são:

Ao configurar a conexão IPsec-VPN no lado da Alibaba Cloud, defina o SA Life Cycle (seconds) como IKE Configurations. Para mais informações, consulte {{XREF_4}}.
Ao adicionar configurações de rota para a instância do gateway de VPN, prefira usar uma rota baseada em política e adicione as configurações correspondentes. Para mais detalhes, veja {{XREF_5}}.
Adicione um fluxo de dados protegido no dispositivo de gateway on-premises com bloco CIDR de origem 0.0.0.0/0 e bloco CIDR de destino 0.0.0.0/0. Para os comandos específicos, consulte o fabricante do dispositivo de gateway on-premises.

Example of Solution 1 for multi-CIDR block communication..png

Exemplo de configuração da Solução 2

Exemplo 1

Tome como base o seguinte cenário: vários blocos CIDR na VPC (10.1.1.0/24 e 10.1.2.0/24) necessitam de comunicação com blocos no data center on-premises (192.168.1.0/24 e 192.168.2.0/24). Siga estas recomendações:

Na configuração da conexão IPsec-VPN na Alibaba Cloud, selecione Routing Mode no campo Destination routing mode. Defina a Routing Mode como o bloco agregado da VPC 10.1.0.0/16 e a Protected data flows mode como o bloco agregado do data center 192.168.0.0/16. Consulte {{XREF_6}} para mais informações.
Quando o Local Network estiver definido como Remote Network, o sistema adiciona automaticamente uma rota baseada em política à Routing Mode da instância do gateway de VPN. Nessa rota, o Protected data flows mode corresponde à Policy-based Route Table da conexão, o Source CIDR Block equivale à Local Network e o próximo salto aponta para a conexão IPsec-VPN. Por padrão, essa rota não é anunciada para a VPC.

Para utilizar a rota baseada em política padrão, anuncie-a para a VPC. Caso prefira uma rota personalizada, exclua a entrada criada automaticamente pelo sistema e reconfigure conforme necessário. Veja {{XREF_7}} para detalhes.

Multi-CIDR block Solution 2 example 1..png

Exemplo 2

No cenário ilustrado na figura abaixo, múltiplos blocos CIDR na VPC (10.1.1.0/24 e 10.1.2.0/24) precisam se comunicar com blocos distintos no data center on-premises (192.168.1.0/24 e 172.16.1.0/24). A configuração recomendada é:

Configure a conexão IPsec-VPN na Alibaba Cloud definindo o Destination CIDR Block como Remote Network. Especifique a Routing Mode como o bloco agregado da VPC 10.1.0.0/16 e a Protected data flows mode como 0.0.0.0/0. Para mais detalhes, consulte {{XREF_8}}.

Nota
Como os dois blocos CIDR do data center on-premises não são adjacentes, não é possível agregá-los eficientemente. Nesse caso, recomendamos definir a Local Network da conexão IPsec-VPN como 0.0.0.0/0.
Com o Remote Network ajustado para Remote Network, o sistema insere automaticamente uma rota baseada em política na Routing Mode do gateway de VPN. O Protected data flows mode dessa rota reflete a Policy-based Route Table da conexão, enquanto o Source CIDR Block espelha a Local Network, tendo a conexão IPsec-VPN como próximo salto. Essa rota não é propagada para a VPC por padrão.

Evite configurar uma rota para o bloco 0.0.0.0/0 na Destination CIDR Block. Recomendamos excluir a rota gerada automaticamente e criar uma rota baseada em política mais específica. Consulte {{XREF_9}} para orientações.

Multiple CIDR blocks Solution 2 example 2..png

Exemplo de configuração da Solução 3

O cenário abaixo serve como exemplo. Vários blocos CIDR (10.1.1.0/24 e 10.1.2.0/24) em uma VPC devem se comunicar com blocos distintos (192.168.1.0/24 e 172.16.1.0/24) em um data center on-premises. Siga esta configuração:

Crie múltiplas conexões IPsec-VPN no lado da Alibaba Cloud. Defina o Destination CIDR Block das conexões como Remote Network e configure uma Routing Mode e uma Protected data flows mode específicas para cada conexão. Consulte {{XREF_12}} para mais informações.
Com o Local Network da conexão IPsec-VPN definido como Remote Network, o sistema cria automaticamente uma rota baseada em política na Routing Mode do gateway de VPN. Nela, o Protected data flows mode é a Policy-based Route Table da conexão e o Source CIDR Block é a Local Network. O próximo salto aponta para a conexão IPsec-VPN. Essa rota não é publicada na VPC por padrão.

Publique as quatro rotas baseadas em política geradas automaticamente pelo sistema na VPC. Para mais detalhes, consulte {{XREF_13}}.

Example of Solution 3 for multiple CIDR blocks..png

Perguntas frequentes

Por que o status da conexão IPsec-VPN mostra "Phase 2 negotiation succeeded", mas em cenários com múltiplos blocos CIDR apenas alguns conseguem se comunicar?

Causa

Em cenários onde uma conexão IPsec-VPN liga um data center on-premises a uma VPC, se o gateway de VPN estiver conectado a dispositivos de fornecedores tradicionais como Cisco, H3C , e a conexão utilizar o modo de roteamento Destination CIDR Block com múltiplos blocos CIDR configurados, apenas um bloco conseguirá estabelecer comunicação, enquanto os demais falharão.

Esse comportamento ocorre devido à incompatibilidade dos protocolos IPsec nas duas pontas quando um gateway de VPN da Alibaba Cloud se conecta a equipamentos de fabricantes tradicionais como Cisco, H3C . Quando múltiplos blocos CIDR estão configurados na conexão IPsec-VPN, o gateway da Alibaba Cloud utiliza uma única SA para negociar com o dispositivo par, enquanto o gateway par tenta usar múltiplas SAs para negociar com o gateway da Alibaba Cloud nesse cenário.

Solução

Para resolver esse problema, consulte {{XREF_14}} neste tópico.

Como implementar a comunicação entre múltiplos blocos CIDR se o dispositivo de gateway on-premises não suportar IKEv2?

Utilize o protocolo IKEv1. Para mais detalhes, consulte {{XREF_15}} neste tópico.

Por que o log da conexão IPsec-VPN exibe "can't find sa for proto ESP" ou por que o túnel falha ao ser estabelecido após receber uma mensagem DELETE?

Causa

Em cenários envolvendo múltiplos blocos CIDR (ou seja, quando vários fluxos de dados protegidos estão configurados em uma conexão IPsec-VPN), as duas pontas negociam esses fluxos de maneira inconsistente, ocorrendo negociações cruzadas entre fluxos de diferentes blocos CIDR. Isso faz com que a negociação da Fase 2 da conexão IPsec-VPN atinja o tempo limite. Após o timeout, as SAs estabelecidas são excluídas ou o gateway de VPN da Alibaba Cloud envia uma mensagem DELETE ao par. Como resultado, a mensagem can't find sa for proto ESP aparece nos logs do dispositivo par ou o túnel não consegue ser estabelecido.

Solução

Para corrigir essa situação, consulte {{XREF_16}} neste tópico.