Recursos do VPN for VPC

O serviço IBM Cloud VPN for VPC inclui os recursos a seguir:

MD-5 e SHA-1, 2 e 5 grupos DH e o algoritmo de criptografia 3-DES foram descontinuados em 20 de setembro de 2022 e não têm mais suporte no console.

• Autenticação - O IBM Cloud VPN for VPC suporta uma chave pré-compartilhada para a autenticação de peer da Fase 1. Os algoritmos de autenticação compatíveis para ambas as fases incluem SHA-256, SHA-384 e SHA-512.

• Alta disponibilidade - O IBM Cloud VPN for VPC é construído em dois dispositivos VPN para fornecer redundância de nível de dispositivo. Uma VPN baseada em política opera no modo Ativo-Em espera com um único IP de gateway da VPN compartilhado entre os membros, enquanto uma VPN baseada em rota oferece redundância Ativa-Ativa com dois IPs de gateway de VPN.

  Uma VPN estática, baseada em rota, é implementada no modo de redundância Ativo-Ativo. Dois túneis VPN estão conectados ao gateway VPN peer; no entanto, o gateway IBM sempre usa o túnel com o pequeno IP público como caminho de egresso primário. O túnel com o grande IP público é o caminho de egresso secundário. O tráfego do IBM VPC até a rede no local passará pelo caminho de egresso primário se ambos os túneis estiverem ativos. O tráfego passará pelo caminho de egresso secundário se o caminho de egresso primário estiver desativado. O gateway VPN no local deve usar prioridade de rota para escolher o mesmo caminho preferencial. Saiba mais

• Detecção de peer inativo - Mecanismo configurável para detectar a disponibilidade de um peer de IPsec.

• Diffie-Hellman (DH) - Protocolo de troca de chave usado na Fase 1 para gerar uma chave secreta compartilhada entre os peers de VPN. Opcionalmente, os usuários podem ativar o Perfect Forward Secrecy (PFS) e um Grupo DH para negociação de IPsec da Fase 2. IBM Cloud VPN para VPC oferece suporte aos grupos DH 14-24 e 31.

• Criptografia- IBM Cloud VPN for VPC suporta AES-128, AES-192 e AES-256 para criptografia de dados durante a Fase 1 e a Fase 2 do IKE.

• Internet Key Exchange (IKE) - o IKE é uma parte do protocolo IPsec que é usado para estabelecer conexões VPN. No IKE Fase 1, os peers de VPN usam a troca de chave Diffie-Hellman (DH) para criar um canal de comunicação seguro e autenticado. No Fase 2 do IKE, os peers usam o canal seguro da Fase 1 para negociar parâmetros para os túneis do IPsec. O IBM Cloud VPN for VPC suporta ambos, IKEv1 (modo principal) e IKEv2. Consulte Sobre a negociação de política para obter as combinações suportadas.

• IPsec - Conjunto de protocolo que fornece comunicação segura entre os dispositivos. IBM Cloud VPN para VPC usa o encapsulamento UDP de pacotes IPsec Encapsulating Security Protocol (ESP) no modo túnel, que oferece autenticação e criptografia completa de pacotes.

• Modos - O IBM Cloud VPN for VPC oferece modos de VPN baseados em rota estática e baseados em política. Com uma VPN baseada em política, o tráfego que corresponde aos intervalos de CIDR passa pela VPN. Para uma VPN baseada em rota estática, são criadas interfaces de túnel virtual e qualquer tráfego que seja roteado para essas interfaces lógicas com rotas customizadas passa pela VPN. Ambas as opções de VPN fornecem os mesmos recursos.

• Perfect Forward Secrecy (PFS) - o PFS garante que chaves geradas por DH não sejam usadas novamente durante uma renegociação de IPsec. Se uma chave estiver comprometida, apenas os dados em trânsito durante o tempo de vida da associação de segurança protegida estarão acessíveis.

Introdução aos gateways VPN

Antes de criar uma VPN, deve-se primeiro criar uma VPC e uma ou mais sub-redes para a VPN e outros recursos.

Embora não seja necessário, recomenda-se dedicar uma sub-rede de pelo menos 16 IPs (prefixo 28 ou inferior) para o seu gateway VPN. Se decidir fornecer recursos extras dentro da sub-rede VPN, certifique-se de que sempre haja pelo menos quatro IPs disponíveis para tarefas de recuperação e manutenção para uso pelo gateway VPN. Além dos quatro IPs requeridos pelo gateway VPN, até cinco IPs em uma sub-rede são reservados para uso interno da rede, portanto, certifique-se de que a sub-rede seja grande o suficiente.

Para criar um gateway VPN, siga estas etapas:

1. Certifique-se de que as ACLs de rede para o fluxo de tráfego da VPN estejam em vigor.

2. Certifique-se de que seu dispositivo peer suporta NAT Traversal e que esteja ativado no dispositivo peer. Para obter mais informações, consulte Limitações de gateway VPN.

3. Revise as considerações de planejamento e crie seu gateway VPN.

4. Crie conexões VPN.

   O IBM Cloud VPN for VPC suporta apenas uma VPN baseada em rota por zona por VPC.

5. Para VPNs estáticas, baseadas em rota, selecione ou crie uma tabela de roteamento para roteamento estático e, em seguida, crie rotas usando o tipo de conexão VPN.

6. Conecte-se a uma rede no local por meio de um túnel VPN.

7. Verifique se sua conexão VPN está disponível enviando ping ou tráfego de dados em todo o túnel para dispositivos que estão na rede de peer.

Arquitetura

Este diagrama ilustra uma configuração de VPN de exemplo com várias redes no local. A VPN é configurada em uma sub-rede dentro de uma VPC do usuário, mas pode ser compartilhada por instâncias em todas as sub-redes dentro da zona. As políticas IKE e IPsec também podem ser usadas por uma ou mais conexões VPN.

Sobre a negociação de política

Para ambas as fases de negociação do IKE, os peers IPsec devem trocar propostas de parâmetros de segurança que cada um está configurado para suportar e concordar com um conjunto de configurações. As políticas customizadas de IKE e IPsec permitem que os usuários do IBM Cloud VPN for VPC configurem esses parâmetros de segurança usados durante esta negociação.

O uso de políticas IKE e IPsec para configurar uma conexão de VPN é opcional. Quando uma política não é selecionada, as propostas padrão são escolhidas automaticamente por meio de um processo conhecido como negociação automática.

Os principais parâmetros de segurança que estão envolvidos nesse processo de negociação são os seguintes:

• Fase do IKE
• Algoritmo de criptografia
• Algoritmo de autenticação
• Grupo Diffie-Hellman (protocolo de troca de chave de criptografia)

Como a negociação automática da IBM Cloud usa IKEv2, o dispositivo no local também deve usar IKEv2. Use uma política IKE customizada se o dispositivo local não suportar IKEv2.

Casos de uso do VPN for VPC

Caso de uso 1: conexão VPN com dispositivo peer remoto único do mesmo tipo que está associado a uma ou mais redes de peer

As VPNs baseadas em rotas e baseadas em política permitem que os usuários se conectem a um único dispositivo de peer remoto associado a uma ou mais redes.

Esse caso de uso não se aplica a conexões entre uma VPN baseada em política e uma VPN baseada em rota. Para obter mais informações, consulte Limitações conhecidas.

Caso de uso 2: conexões VPN com vários dispositivos de peer remoto

As VPNs baseadas em política e baseadas em rota permitem que os usuários se conectem a vários dispositivos peer remotos associados a diferentes VPCs/ambientes usando várias conexões VPN

..

Caso de uso 3: configuração avançada de VPN usando um FQDN

O caso de uso a seguir ilustra um cliente que tem uma VPC no IBM Cloud e deseja conectar seu site no local com um único gateway VPN. O gateway VPN do site no local está atrás de um dispositivo NAT e não tem endereço IP público. A identidade IKE local do gateway VPN no local é o endereço IP privado que ele possui. Um FQDN está associado ao endereço IP público do dispositivo NAT.

Caso de uso 4: distribuição de tráfego para uma VPN baseada em rota

Uma VPN baseada em rota tem 2 túneis ativos no backend. Quando os dois túneis VPN estão ativos, apenas um túnel é usado para rotear o tráfego VPN pelo túnel.

A VPN usa o túnel com o IP público pequeno como o caminho de saída principal. Quando o caminho de saída primário é desativado, o tráfego flui pelo caminho secundário. O motivo de usar apenas um túnel para rotear o tráfego é evitar o problema de roteamento assimétrico. O diagrama a seguir mostra a configuração padrão. Quando você cria uma rota com destino 10.1.0.0/24 e o próximo salto é a conexão VPN, se ambos tunnel 1 e tunnel 2 estiverem ativos, o IP privado 10.254.0.2 do dispositivo VPN é retornado para a criação da rota.

A filtragem do estado do protocolo em uma interface de rede virtual oferece opções para resolver o problema de roteamento assimétrico. Para obter mais informações, consulte Modo de filtragem do estado do protocolo.

Ao criar conexões para uma VPN baseada em rota, agora você pode ativar a distribuição do tráfego entre os Up túneis da conexão do gateway de VPN quando o próximo salto de uma rota VPC for a conexão VPN. Para realizar esse modo de redundância ativo/ativo, você deve ativar o recurso "distribuir tráfego" ao criar ou adicionar conexões a um gateway de VPN.

Conforme mostrado no diagrama a seguir, o tráfego de saída é roteado para os dois túneis dinamicamente. Quando os túneis são Up, os endereços IP privados 10.254.0.2 e 10.254.0.3 são retornados e o serviço de rede VPC cria duas rotas. Como essas rotas têm a mesma prioridade, o tráfego flui para tunnel 1 e tunnel 2 dinamicamente.

Para usar esse recurso, o dispositivo local deve oferecer suporte ao roteamento assimétrico para obter maior desempenho da rede. Além disso, lembre-se de que nem todos os gateways de VPN no local são compatíveis com esse caso de uso. Por exemplo, se a saída e a entrada do tráfego VPN forem de túneis diferentes, o tráfego poderá ser bloqueado por dispositivos VPN locais ou firewalls.

Links relacionados

Esses links fornecem informações adicionais sobre o IBM Cloud VPN for VPC:

• Referência de CLI da VPN
• Referência de API da VPN
• Referência de Terraforme VPN
• Gerenciando o acesso ao IAM para serviços de infraestrutura VPC
• Eventos do Activity Tracker
• Perguntas mais frequentes para gateways VPN
• Resolução de problemas de gateways VPN
• Cotas de gateway VPN