Problemas conhecidos para gateways de VPN

Problemas conhecidos são bugs identificados ou comportamentos inesperados que não foram corrigidos antes do lançamento, mas não eram críticos o suficiente para atrasá-lo. Esses problemas são comunicados a você, geralmente com soluções alternativas, e são priorizados para resolução em curto prazo pela equipe de desenvolvimento.

Os problemas conhecidos dos gateways de VPN site a site são os seguintes:

• Um gateway de VPN para VPC aceita somente pacotes VPN com encapsulamento UDP de pacotes IPsec ESP. Os pacotes Encapsulating Security Payload(ESP) não são aceitos. Certifique-se de que o recurso NAT-T esteja ativado em seu dispositivo VPN no local. Além disso, certifique-se de que as portas UDP 500 e 4500 sejam permitidas para IBM VPC NACL e redes pares.

  O NAT-T permite que o tráfego VPN passe pelos dispositivos NAT encapsulando os pacotes IPsec em UDP. Sem o NAT-T, os pacotes IPsec podem ser descartados pelos dispositivos NAT porque eles não conseguem lidar adequadamente com o tráfego ESP. Para obter uma conectividade VPN confiável entre dispositivos NAT, o NAT-T deve estar ativado em seu dispositivo local.

• Quando várias redes, sub-redes ou ambas estiverem associadas a um gateway VPN da IBM Cloud ou um dispositivo no local, evite combinar VPNs baseadas em política e baseadas em rotas. As VPNs baseadas em política criam um túnel para cada intervalo de rede de destino. No entanto, as VPNs baseadas em rota roteiam tudo para um dispositivo de peer por meio de um único túnel. Portanto, quando vários intervalos de rede são configurados, somente um único túnel associado a um único intervalo de rede pode ser estabelecido. A combinação de sub-redes contíguas em um único superconjunto CIDR é uma solução válida.

• As sub-redes de mesmo nível de uma conexão de gateway VPN não podem se sobrepor.

• Transit Gateway no momento, a filtragem de prefixo não é compatível com gateways de VPN.

• Quando você conectar uma VPN baseada em política com um par baseado em rota (ou uma VPN estática baseada em rota com um par baseado em política), use apenas um único intervalo de rede para ambos os lados. Uma VPN baseada em política usa um túnel para cada rede associada, enquanto uma VPN baseada em rota requer apenas um único túnel. As conexões entre diferentes tipos de VPNs associadas a vários intervalos de rede em ambos os lados podem funcionar apenas para um intervalo de rede.

  

  Se possível, combine sub-redes contíguas em um único intervalo de rede em uma configuração de VPN. Por exemplo, as sub-redes 192.168.0.0/24 e 192.168.1.0/24 podem ser definidas como 192.168.0.0/23 em uma configuração de VPN ou de roteamento.

• Um gateway VPN baseado em política da IBM Cloud reside na zona que está associada à sub-rede que você seleciona durante o fornecimento. O gateway de VPN atende somente às instâncias de servidor virtual na mesma zona da VPC. Portanto, as instâncias em outras zonas não podem usar o gateway VPN para se comunicar com uma rede privada local. Para a tolerância a falhas da zona, implemente um gateway VPN por zona.

• Um gateway VPN baseado em rota da IBM Cloud reside na zona que está associada à sub-rede que você seleciona durante o fornecimento. Recomenda-se que um gateway VPN atenda instâncias de servidor virtual apenas na mesma zona da VPC. Ao adicionar rotas de saída personalizadas à tabela de roteamento para direcionar o tráfego, as instâncias em outras zonas podem usar o gateway de VPN baseado em rota para se comunicar com uma rede privada no local; no entanto, essa configuração não é recomendada. Para a tolerância a falhas da zona, implemente um gateway VPN por zona.

• Ao configurar e otimizar conexões VPN IPsec de site para site, você pode encontrar problemas de desempenho de rede, um dos quais está relacionado à fixação de Unidade de Transmissão Máxima (MTU) e Tamanho Máximo de Segmento (MSS). Para obter mais informações, consulte IBM fixação de unidade máxima de transmissão de VPN(MTU)de site para site.

• Quando uma rota usa uma conexão de gateway de VPN como seu próximo salto, ela deve estar presente em uma tabela de roteamento de saída associada a sub-redes VPC. Além disso, quando o gateway de VPN encaminha o tráfego para o túnel de VPN, ele verifica se o IP de origem desse tráfego está dentro da sub-rede que está anexada a essa tabela de roteamento. Se o IP de origem estiver fora dessa sub-rede, o tráfego não será criptografado nem enviado pelo túnel VPN para o gateway de par. Por exemplo, se o gateway de VPN receber tráfego que é roteado por meio da tabela de roteamento de entrada, o tráfego não será encaminhado para o túnel de VPN porque o IP de origem está fora da sub-rede anexada à tabela de roteamento.

  Não há suporte para a criação de uma rota em uma tabela de roteamento de entrada com uma conexão de gateway de VPN como o próximo salto.

• A configuração das identidades IKE local e de par (endereço, FQDN ou nome de host) é opcional quando você cria um gateway de VPN. No entanto, a atualização posterior do endereço do par ou do FQDN pode afetar a conectividade da VPN:

  • Se você não especificar as identidades IKE local e de par, o gateway usará automaticamente os valores padrão: o IP público do gateway de VPN é usado como a identidade IKE local e o IP público do gateway de par é usado como a identidade IKE de par. Essa configuração padrão ajuda a manter uma conexão VPN estável, mesmo que o endereço do par seja alterado.
  • Se você definir explicitamente as identidades IKE locais e de pares, estará fixando valores específicos. Nesse caso, a atualização do endereço do par ou do FQDN exige que você exclua e recrie a conexão VPN para evitar a interrupção da conectividade.