Considerações de planejamento para gateways de VPN

Antes de criar um gateway de VPN, analise as considerações de planejamento aplicáveis, os requisitos de configuração e outras diretrizes.

Considerações gerais

Analise as seguintes considerações gerais antes de criar um gateway de VPN:

  • Certifique-se de que haja espaço suficiente na sub-rede para o gateway. Para assegurar que as funções de gerenciamento de VPN e de failover possam funcionar corretamente, crie o gateway de VPN em uma sub-rede sem nenhum outro recurso de VPC. Esse processo garante que haja endereços IP privados suficientes disponíveis para o gateway. Um gateway VPN precisa de quatro endereços IP privados para acomodar a alta disponibilidade e os upgrades contínuos. Como são reservados no máximo cinco endereços IP privados em uma sub-rede, o tamanho mínimo da sub-rede que pode ser usado para hospedar um gateway de VPN é /28 (16 endereços IP ou máscara de rede 255.255.255.240).
  • Por padrão, o PFS (Perfect Forward Secrecy) está desativado para IBM Cloud VPN para VPC. Alguns fornecedores requerem ativação de PFS para a Fase 2. Verifique as instruções do fornecedor e use políticas personalizadas se você precisar de PFS.
  • O gateway IBM VPN usa seu endereço IP público como a identidade local do IKE e designa o endereço IP público do peer como a identidade do peer do IKE por padrão. É possível especificar as identidades IKE local e peer para substituir esse comportamento padrão ao criar uma conexão VPN. Nos casos em que o gateway de VPN de par está localizado atrás de um firewall NAT e o endereço IP público do par não está associado à interface do gateway de VPN de par, você pode ajustar a configuração do gateway de VPN de par. Essa configuração garante que o endereço IP público do par seja usado como a identidade IKE. Também é possível especificar a identidade IKE do peer ao criar uma conexão VPN para usar a identidade IKE real do gateway VPN do peer.
  • Se o gateway VPN de par estiver atrás de um dispositivo NAT e não tiver IP público, você poderá associar um FQDN ao endereço IP NATed. Em seguida, você pode usar esse FQDN em vez de um endereço IP ao criar uma conexão VPN. Dessa forma, a identidade IKE do peer padrão é o FQDN.. Você pode especificar a identidade IKE do par para substituir esse padrão ao criar a conexão VPN se o padrão não corresponder à identidade IKE real do gateway de VPN do par.
  • Você pode selecionar um modo de estabelecimento (bidirecional ou somente par) ao criar uma conexão VPN. Lembre-se de que, se seu gateway VPN de peer não tiver nenhum endereço IP público ao criar uma conexão VPN, deve-se configurar o gateway VPN para o modo Somente peer. Nesse caso, o gateway de VPN par é responsável por restabelecer a conexão se ela cair.
  • Após o provisionamento de uma conexão VPN, não é possível alterar o tipo de endereço de gateway de par de endereço IP para FQDN ou de FQDN para endereço IP.
  • IBM Cloud VPC oferece suporte à resolução de FQDN por meio dos DNS Services. Se a VPC em que o gateway de VPN reside estiver na rede permitida de uma instância de DNS privado, os registros de DNS adicionados nesse DNS privado poderão ser resolvidos no gateway de VPN.

Considerações sobre o gateway de VPN baseado em políticas

Analise as considerações a seguir antes de criar um gateway de VPN baseado em políticas:

  • O gateway de VPN baseado em políticas é criado na zona associada à sub-rede que você selecionou. O gateway de VPN pode se conectar a instâncias de servidor virtual somente nessa zona Como resultado, as instâncias em outras zonas não podem usar esse gateway de VPN para se comunicar com a outra rede. Para a tolerância a falhas da zona, implemente um gateway VPN por zona.
  • Para gateways VPN baseados em políticas, as rotas não são descobertas automaticamente. A tabela de roteamento deve ser configurada para aceitar rotas do gateway VPN, e as rotas propagadas são limitadas aos prefixos CIDR definidos na política VPN. Veja Rotas de publicidade.

Considerações sobre o gateway VPN baseado em rota

Analise as considerações a seguir antes de criar um gateway de VPN baseado em rota:

Considerações sobre a conexão VPN baseada em rota estática

Analise as considerações a seguir antes de criar uma conexão VPN baseada em rota estática:

  • Se você planeja definir uma rota padrão (0.0.0.0/0) em uma tabela de roteamento de VPC para permitir que o tráfego de saída dos recursos da VPC passe por um gateway de VPN, crie o gateway de VPN em uma sub-rede diferente da associada à tabela de roteamento. Caso contrário, essa rota padrão causa um conflito de roteamento para o gateway da VPN e pode derrubar a conexão VPN.
  • O IBM Cloud VPN for VPC suporta apenas uma VPN baseada em rota por zona por VPC.

Considerações sobre a conexão VPN baseada em rota dinâmica

Analise as considerações a seguir antes de criar uma conexão VPN dinâmica baseada em rota:

  • Para ativar o roteamento dinâmico entre o gateway VPN e os dispositivos locais, você deve criar um gateway de trânsito e anexá-lo ao gateway VPN. Nessa configuração, o gateway de trânsito gerencia e distribui automaticamente o tráfego entre seus dispositivos. Consulte Considerações sobre a conexão do gateway VPN com Transit Gateway. Lembre-se de que o roteamento estático não é compatível com esse tipo de anexo.
  • Você pode criar conexões VPN dinâmicas a qualquer momento, mesmo antes de o gateway VPN ser conectado ao gateway de trânsito. No entanto, o tráfego flui somente quando o gateway VPN está conectado ao gateway de trânsito.
  • Um valor ASN local e de par é necessário para a VPN dinâmica baseada em rota. O ASN local identifica sua rede local para peering BGP, enquanto o ASN de peer identifica a rede de peer remota com a qual a VPN troca rotas. Se você não especificar o valor ASN local, o gateway VPN será criado com o ASN padrão de 64520.
  • Certos valores de ASN são restritos quando você cria um gateway de VPN e não podem ser usados como ASNs locais ou de pares, incluindo 0, 13884, 36351, 64512, 64513, 65100, 65200–‍65234, 65402‍–‍65433, 65500 ou 4201065000‍–‍4201065999. Esses valores são reservados ou fazem parte de intervalos ASN privados e podem causar conflitos de roteamento.
  • Quando você conecta um gateway de trânsito a uma VPN, não é possível alterar o valor do ASN até que você remova a conexão de serviço.
  • Vários gateways de VPN podem se conectar ao mesmo gateway de trânsito, mas cada gateway de VPN pode se conectar a apenas um gateway de trânsito.
  • Se você planeja usar um CIDR não RFC 1918 para a conexão do gateway de trânsito que não esteja dentro dos intervalos de IP privados padrão (10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16), é necessário adicionar uma rota delegate-VPC na tabela de roteamento de saída da VPC. Essa rota deve apontar para o CIDR que você escolheu e deve estar associada à sub-rede VPN na mesma zona. Consulte Considerações sobre a conexão do gateway VPN para o gateway de trânsito.
  • Cada IBM VPN suporta um máximo de 120 rotas para cada par de VPN em uma configuração de roteamento dinâmico. Se esse limite for excedido, a sessão BGP para esse par será automaticamente encerrada. Para restaurar a sessão, reduza o número de rotas anunciadas da rede local para 120 ou menos e, em seguida, alterne a conexão no site IBM Cloud para restabelecer a sessão BGP. Para obter mais informações, consulte Quantas rotas o site VPN for VPC suporta por par de VPN para uma conexão dinâmica e baseada em rota?

IBM Power Virtual Servers automatize a implementação de seu espaço de trabalho

Um projeto de automação de VPN de site para site está disponível que fornece um módulo do Terraform para criar um gateway VPN de site para site. Ele também permite uma conexão segura pela Internet a partir de sua rede local no local para recursos privados em um espaço de trabalho Power Virtual Server. Esse módulo do Terraform Infrastructure as Code ( IaC ) cria um gateway de VPN baseado em políticas e uma conexão com políticas locais e de pares. Um espaço de trabalho Transit Gateway e IBM Power Virtual Server são criados por padrão, mas você pode substituir o padrão especificando os existentes.

O repositório GitHub para esse projeto de automação está localizado em IBM / power-vpn-gateway GitHub repositório. O arquivo README do projeto cria um gateway de VPN e o anexa a um espaço de trabalho novo ou existente do Power Virtual Server, fornecendo acesso seguro à infraestrutura do IBM Cloud Power.