Conjunto de endereços IPv4 do cliente

Ao criar um servidor VPN, um conjunto de endereços IPv4 do cliente (faixa de CIDR) é solicitado. Um endereço IP é designado ao cliente para sua sessão deste conjunto de endereços. Tenha em mente que a propriedade do conjunto de IPs do cliente não deve sobrepor-se aos prefixos de endereço da VPC. O serviço VPN valida o endereço IP do cliente se o conjunto de IPs do cliente se sobrepõe a um prefixo de endereço existente.

Revise os requisitos a seguir:

• Cada cliente VPN ativo recebe um endereço IP por meio de um conjunto de IPs configurável. Deve-se selecionar o intervalo CIDR do IP cuidadosamente para certificar-se de que ele não se sobrepõe ao prefixo da VPC e ao CIDR local do dispositivo pessoal.
• Dependendo do caso de uso, o conjunto de IPs do cliente não pode sobrepor-se ao endereço IP do dispositivo local do cliente. O conjunto de IPs do cliente também não pode se sobrepor à rede de destino; por exemplo, se o servidor VPN for usado para acessar a rede clássica IBM Cloud, o IP do cliente não poderá sobrepor-se à rede clássica IBM Cloud.
• Deve-se garantir que o tamanho do bloco seja pelo menos /22 (1024 endereços IP livres). Recomenda-se usar um bloco CIDR que contenha duas vezes o número de endereços IP que são necessários para permitir o número máximo de conexões simultâneas.

Sub-redes: alta disponibilidade versus modo independente

Ao criar um servidor VPN, é possível especificar o modo de alta disponibilidade ou independente.

• Se você selecionar o modo de alta disponibilidade, deverá implementar o servidor VPN nas duas sub-redes em diferentes zonas. Use este modo para implementações de produção. É melhor para implementações em várias zonas e soluções nas quais o acesso à VPN do cliente é essencial.
• Se você selecionar o modo independente, implemente o servidor VPN em uma sub-rede e zona únicas. Use este modo para uma implementação piloto de não produção onde a resiliência multizona não é necessária.

Autenticação de servidor VPN

Deve-se especificar um certificado de servidor VPN durante o fornecimento. Você pode criar um certificado usando o site IBM Cloud Secrets Manager ou usar um de sua preferência.

Se estiver usando a CLI ou a API, especifique o CRN do certificado. Para obter o CRN do certificado, consulte Localizando o CRN do certificado.

Se o servidor VPN estiver usando autenticação de ID e senha de usuário apenas, será necessário especificar o certificado do servidor VPN, que inclui a chave pública/privada e a autoridade de certificação. O serviço VPN recebe as chaves públicas e privadas da instância do certificado e as armazena no servidor VPN. Este certificado da autoridade de certificação também é copiado no perfil do cliente para que o cliente possa utilizar o certificado da autoridade de certificação para verificar o servidor VPN.

Se a autenticação de certificado estiver ativada, você deverá especificar o certificado da autoridade de certificação do cliente. A chave pública e a chave privada não são necessárias. O serviço VPN obtém o certificado CA do cliente em Secrets Manager. Por sua vez, o cliente apresenta a sua chave pública quando se conecta ao servidor VPN, e o servidor VPN utiliza o certificado de autoridade de certificação para verificar a chave pública.

Se o certificado do servidor cliente e VPN forem assinados pela mesma autoridade de certificação, então o administrador poderá utilizar a mesma instância de certificado quando provisionar o servidor VPN.

Para obter mais informações, consulte Configurando a autenticação de cliente para servidor.

Autenticação de cliente VPN

Como o administrador do servidor VPN, você deve escolher pelo menos um método de autenticação e configurá-lo durante o fornecimento do servidor VPN. É possível escolher um certificado de cliente, segurança adicional com um ID de usuário e código de acesso ou ambos os tipos de autenticação de cliente.

Vários clientes VPN podem compartilhar um certificado de cliente.

Se você planeja utilizar o certificado de cliente, o usuário deverá editar o perfil do cliente fornecido pelo administrador do servidor e incluir o certificado do cliente (também chamado de chave pública) e a chave privada. Observe que a modificação do perfil do cliente não é necessária se estiver usando apenas a autenticação de cliente "ID de usuário e código de acesso".

Quando um certificado privado é usado para autenticação de cliente, o administrador não precisa modificar o perfil do cliente.. Em vez disso, o administrador pode fazer download do perfil do cliente com o certificado privado mesclado e a chave para todos os certificados ou selecionar certificados privados e fazer download do perfil do cliente com o certificado privado mesclado e a chave para os certificados selecionados. Para obter mais informações, consulte Configurando um ambiente VPN do cliente e conectando a um servidor VPN.

Os usuários da VPN não usam sua senha diretamente para se conectar ao servidor VPN. Eles recebem a senha do IBM Access Manager (IAM) via navegador e, se o MFA estiver ativado, a aplicação do MFA será sempre feita via navegador. O usuário deve configurar o MFA adequadamente para ter certeza de que a aplicação do MFA pode ser feita no navegador. Depois que um usuário obtém a senha, ele insere a senha no cliente OpenVPN e inicia a conexão.

O servidor VPN recebe o nome de usuário e senha do cliente VPN e faz uma chamada de IAM para verificar a senha e a permissão com a política do IAM.

• O código de acesso é uma senha de uso único. O usuário DEVE gerar novamente a senha para reconectar, mesmo que a reconexão seja iniciada pelo servidor VPN.
• O SoftLayer MFA não é suportado porque a aplicação do SoftLayer MFA não é feita via navegador.

Se você usar a autenticação de ID/senha do usuário, as atividades de manutenção forçarão os usuários a autenticar novamente por meio da busca e reinserção do código. A conexão será restaurada somente depois que o novo código for inserido. Isto é aplicável usando o modo independente ou HA.

Listas de revogação de certificado de cliente

Opcionalmente, é possível importar uma lista de revogação de certificado (CRL), que é uma lista de certificados com registro de data e hora que foram revogados por uma autoridade de certificação (CA). Um certificado em uma lista de revogação de certificado (CRL) pode não estar expirado, mas não é mais confiável pela autoridade de certificação que emitiu o certificado. O cliente VPN usa esta lista para validar certificados digitais.

Depois de importar uma CRL, o cliente VPN usa esta lista para validar certificados digitais. A CRL é salva como uma sequência de caracteres (não um arquivo) no sistema. Se for necessário fazer download do CRL no futuro, ele será renomeado como <vpn_server_name>.pem.

Para obter mais informações, consulte Configurando a autenticação de cliente para servidor.

Protocolo de transporte

A camada de transporte supervisa a entrega de dados de um processo em um dispositivo a um processo em outro dispositivo. Os protocolos da camada de transporte atuam como ligações entre os protocolos da camada de aplicativo e os serviços que são fornecidos pela rede. VPN cliente para VPC suporta os protocolos a seguir:

O UDP é recomendado para o desempenho ideal; TCP para confiabilidade.

• Protocolo de Datagrama do Usuário (UDP)

  O Protocolo de Datagrama do Usuário (UDP) é um protocolo simples e leve com sobrecabeça mínima. Se um processo quer enviar uma mensagem pequena e não se preocupa com a confiabilidade, ele pode usar o UDP. Enviar uma mensagem usando UDP leva bem menos tempo do que usando TCP. Ele executa pouca verificação de erros e não acrescenta nenhuma vantagem aos serviços IP, exceto para fornecer comunicação de processo para processo em vez de comunicação de host para host.

• Protocolo de Controle de Transmissões (TCP)

  Protocolo de Controle de Transmissões (TCP) é um protocolo de camada de transporte confiável, mas complexo. O TCP inclui recursos orientados a conexão e confiabilidade aos serviços IP.

  O TCP é um serviço de entrega de fluxo que garante a entrega de fluxos de dados enviados de um host para outro sem duplicação ou perda de dados. Como a transferência de pacotes não é confiável, uma técnica conhecida como reconhecimento positivo com retransmissão é usada para garantir a confiabilidade das transferências de pacotes. Essa técnica fundamental requer que o receptor responda com uma mensagem de confirmação conforme ele recebe os dados.

  O remetente mantém um registro de cada pacote que envia, e aguarda por confirmação antes de enviar o próximo pacote. O emissor também mantém um cronômetro de quando o pacote foi enviado e retransmite um pacote se o cronômetro expira. Esse cronômetro é necessário para o caso de um pacote se perder ou ser corrompido.

Modo full versus split-túnel

Quando uma conexão VPN é configurada, um túnel criptografado é criado por meio da Internet para o servidor VPN. A conexão VPN aparece como uma interface de rede virtual para o computador, além da interface LAN existente. Agora é possível utilizar ambas as interfaces simultaneamente, enviando o tráfego privado destinado ao VPC dentro do túnel VPN e o tráfego público (tráfego de Internet) sobre a outra interface (fora do túnel VPN). Quando o tráfego é dividido entre a interface VPN e outras interfaces, o tunelamento dividido é considerado em uso. Quando o tunelamento dividido não está em uso, todo o tráfego usa a interface VPN, resultando no envio do tráfego de Internet para o túnel VPN, que é túnel completo.

Outras considerações:

• Use o modo full-tunnel (padrão) se você tiver uma preocupação de segurança quando o cliente acessar a Internet sem um túnel VPN. Full-tunnel geralmente é necessário para conformidade com os padrões regulatórios; no entanto, essa abordagem pode ser custosa e também aumentar a carga do servidor VPN.
• No modo split-tunnel, as rotas são enviadas por push para o cliente VPN pelo servidor VPN. Desta forma, o cliente OpenVPN sabe qual tráfego deve ser enviado para o túnel VPN. Tenha cuidado ao incluir rotas e evitar loops de roteamento. Por exemplo, se o endereço IP público do servidor VPN for 3.3.3.3, não será possível incluir uma rota 3.3.3.0/24 porque esta rota enviaria tráfego para 3.3.3.3 que não deve passar pelo túnel VPN. Idealmente, é necessário configurar a sub-rede privada apenas como um destino de rota, como uma sub-rede VPC, uma sub-rede CSE, uma sub-rede privada no local e assim por diante.
• A rota VPN é enviada por push para seu cliente VPN. Se o seu cliente VPN já tem uma rota com o mesmo destino, o "push" da rota falha e o tráfego não pode chegar ao seu servidor VPN. Deve-se abordar o conflito de rotas e, em seguida, reconectar o cliente VPN. Um problema comum é se você incluir uma rota VPN com destino 0.0.0.0/0 em um servidor VPN em modo split tunnel e esta rota precisar ser empurrada para seu cliente VPN. Geralmente, o cliente VPN já possui uma rota com destino 0.0.0.0/0; portanto, esta rota VPN irá entrar em conflito com a rota de seu cliente VPN. Para evitar conflitos, use um servidor VPN em modo full tunnel ou remova a rota 0.0.0.0/0 em seu host.

Independentemente do modo de túnel escolhido, deve-se usar a API /vpn_servers/{id}/routes para definir como o servidor VPN encaminha o tráfego do cliente VPN. Por exemplo, se você deseja que o tráfego da Internet do cliente passe pelo túnel VPN, uma rota 0.0.0.0/0 deve ser configurada usando a API de rotas de serviço VPN.

Software de cliente VPN suportado

Deve-se fornecer software de cliente VPN para seus usuários. As versões de software cliente a seguir são verificadas para uso:

• Para macOS Catalina e posterior: OpenVPN Conectar v3, OpenVPN Conectar v2, e Tunnelblick 3.8.4
• Windows 8 e posterior: OpenVPN Connect v3, OpenVPN Connect v2
• RHEL 7.x e posterior: OpenVPN Connect v3, OpenVPN Connect v2 e cliente de linha de comando OpenVPN (versão 2.4.4 e posterior)
• Ubuntu 18.04 e posteriores: OpenVPN Connect v3, OpenVPN Connect v2, e OpenVPN cliente de linha de comando (versão 2.4.10 e posterior)

Os usuários clientes do VPN podem escolher outros softwares clientes compatíveis com OpenVPN-2.4. No entanto, softwares não listados não têm garantia de funcionar.

IBM Power Virtual Servers: Automatize a implementação de sua área de trabalho

Está disponível um projeto de automação de VPN cliente-a-site que fornece um módulo do Terraform para criar um servidor VPN cliente-a-site, permitindo que os usuários se conectem com segurança de um dispositivo no local ou remoto a uma área de trabalho do Power Virtual Server. O repositório do Github para esse projeto de automação está localizado no IBM / repositório do Github power-vpn-server. Este projeto Arquivo Leia-me cria um servidor VPN e o anexa a uma área de trabalho nova ou existente do Power Virtual Server, fornecendo acesso seguro à infraestrutura do Power do IBM Cloud