A página VPN > Configurações fornece os recursos Dell SonicWALL para configurar as políticas de VPN. É possível configurar políticas de VPN site a site e políticas de GroupVPN nessa página.
Uma VPN (redes virtuais privadas) fornece uma conexão segura entre dois ou mais computadores ou redes protegidas pela Internet pública. Ela fornece a autenticação para garantir que as informações estejam indo de/para as partes corretas. Ela fornece segurança para proteger as informações de exibição ou de adulterações na rota.
Antes da invenção de IPsec (Internet Protocol Security) e de SSL (Secure Socket Layer), as conexões seguras entre redes ou computadores remotos precisavam de uma linha dedicada ou de um link por satélite. Isso era ambos inflexíveis e caros.
Uma VPN cria uma conexão com a confiabilidade e segurança semelhantes, estabelecendo um túnel seguro através da Internet. Como este túnel não é uma conexão física, é mais flexível - é possível alterá-la a qualquer momento para adicionar mais nós, alterar os nós ou removê-lo completamente. Ela é também muito menos dispendiosa, porque utiliza a infraestrutura existente da Internet.
Há dois tipos principais de VPN em uso popular hoje:
• VPN IPsec: O IPsec é um conjunto de protocolos de segurança na camada de processamento de pacotes de comunicação de rede. Uma vantagem do IPsec é que arranjos de segurança podem ser tratados sem exigir alterações nos computadores de usuários individuais. O SonicOS oferece suporte a criação e o gerenciamento de VPNs IPsec.
• O IPsec oferece duas opções de serviço de segurança: O cabeçalho de autenticação (AH), que permite essencialmente a autenticação do remetente de dados, e o ESP (Encapsulating Security Payload), que oferece suporte a autenticação do remetente e a criptografia de dados também. As informações específicas associadas a cada um desses serviços são inseridas no pacote em um cabeçalho que segue o cabeçalho do pacote IP.
• SSL VPN: O SSL (Secure Socket Layer) é um protocolo para gerenciar a segurança de uma transmissão de mensagem na Internet, geralmente, por HTTPS. O SSL usa uma camada de programa localizada entre as camadas HTTP (protocolo de transferência de hipertexto) e o TCP (protocolo de controle de transporte) da Internet. O SSL usa o sistema de criptografia de chave pública e privada de RSA, que também inclui o uso de um certificado digital. Uma SSL VPN usa SSL para proteger o túnel de VPN.
• Uma vantagem da SSL VPN é que o SSL foi criado na maioria dos navegadores da Web. Nenhum hardware ou software de cliente de VPN especial é necessário.
Note A Dell SonicWALL faz os dispositivos SSL VPN com os quais é possível usar em conjunto ou independentemente de um dispositivo de segurança de rede da Dell SonicWALL ao executar o SonicOS. Para obter informações sobre os dispositivos da Dell SonicWALL SSL VPN, consulte o site da Dell SonicWALL:
http://www.SonicWALL.com/us/products/Secure_Remote_Access.html
Tráfego de VPN IPsec é protegido em dois estágios:
• Autenticação: A primeira fase estabelece a autenticidade do remetente e do destinatário do tráfego usando uma troca da parte de chave pública de um par de chaves pública-privada. Esta fase deverá ser bem-sucedida antes do túnel de VPN poder ser estabelecido.
• Criptografia: O tráfego no túnel de VPN é criptografado, usando um algoritmo de criptografia, como AES ou 3DES.
A menos que você usar uma chave manual (que deve ser digitada de forma idêntica em cada nó na VPN), a troca de informações para autenticar os membros da VPN e criptografar/descriptografar os dados usa o protocolo IKE (Internet Key Exchange) para trocar informações de autenticação (chaves) e estabelecer o túnel de VPN. O SonicOS Enhanced suporta duas versões de IKE:
• IKEv2
O IKE versão 1 usa um processo de duas fases para proteger o túnel de VPN.
• IKE fase 1 é a fase de autenticação. Os nós ou gateways no final do túnel autenticam-se uns aos outros, trocam chaves de criptografia/descriptografia e estabelecem o túnel seguro.
• IKE fase 2 é a fase de negociação. Uma vez autenticado, a dois nós ou gateways negociam os métodos de criptografia e verificação de dados (usando uma função de hash) para ser usado em dados transmitidos através da VPN e negociam o número de SAs (associações seguras) no túnel e seu tempo de vida antes de solicitar a renegociação das chaves de criptografia/descriptografia.
IKE fase 1
Em IKE v1, há dois modos de troca de informações de autenticação: Modo principal e Modo agressivo.
Modo principal: O nó ou o gateway que inicia a VPN consulta o nó ou o gateway na extremidade de recepção e eles trocam métodos de autenticação, chaves públicas e informações de identidade. Isso geralmente requer seis mensagens para frente e para trás. A ordem das mensagens de autenticação em Modo principal é:
1. O iniciador envia uma lista de algoritmos criptográficos em que o iniciador oferece suporte.
2. O respondente responde com uma lista de algoritmos criptográficos suportados.
3. O iniciador envia uma chave pública (parte de um par de chaves pública/privada Diffie-Hellman) para o primeiro algoritmo criptográfico com suporte mútuo.
4. O respondente responde com a chave pública para o mesmo algoritmo criptográfico.
5. O iniciador envia informações de identidade (geralmente um certificado).
6. O respondente responde com informações de identidade.
Modo agressivo: Para reduzir o número de mensagens trocadas durante a autenticação pela metade, a negociação de qual algoritmo criptográfico usar é eliminada. O iniciador propõe um algoritmo e o respondente responde se ele oferece suporte a esse algoritmo:
1. O iniciador propõe um algoritmo criptográfico para usar e enviar sua chave pública.
2. O respondente responde com uma chave pública e uma prova de identidade.
3. O iniciador envia uma prova de identificação. Após a autenticação, o túnel de VPN é estabelecido com duas SAs, uma de cada nó para o outro.
IKE fase 2
Em IKE fase 2, as duas partes negociam o tipo de segurança a ser usado, quais métodos de criptografia usar para o tráfego através do túnel (se necessário) e negociam a vida útil do túnel antes que recriação de chave seja necessária.
Os dois tipos de segurança para pacotes individuais são:
• ESP (Encryption Secured Payload), no qual a parte de dados de cada pacote é criptografada usando um protocolo negociado entre as partes.
• AH (Cabeçalho de autenticação), no qual o cabeçalho de cada pacote contém informações de autenticação para garantir que as informações sejam autenticadas e que não tenham sido violadas. Nenhuma criptografia é usada para os dados com o AH.
O SonicOS oferece suporte para os seguintes métodos de criptografia para tráfego através da VPN.
• DES
• 3DES
• AES-128
• AES-192
• AES-256
É possível encontrar mais informações sobre o IKE v1 nas três especificações que definem inicialmente IKE, RFC 2407, RFC 2408 e RFC 2409, disponível na Web em:
• http://www.FAQs.org/RFCs/rfc2407.HTML
• http://www.FAQs.org/RFCs/rfc2408.HTML
• http://www.FAQs.org/RFCs/rfc2409.HTML
O IKE versão 2 é um protocolo novo para negociar e estabelecer associações de segurança. Recursos de IKEv2 aprimorados de segurança, uma arquitetura simplificada e suporte aprimorado para usuários remotos. Além disso, o IKEv2 oferece suporte a alocação de endereço IP e EAP para habilitar diferentes métodos de autenticação e cenários de acesso remoto. Usar o IKEv2 reduz consideravelmente o número de trocas de mensagens necessárias para estabelecer um Modo principal SA sobre IKE v1, enquanto estiver sendo mais seguro e flexível que Modo agressivo IKE v1. Isso reduz os atrasos durante a recriação de chave. Visto que as VPNS aumentam para incluir mais e mais túneis entre vários nós ou gateways, o IKEv2 reduz o número de SAs necessários por túnel, reduzindo, assim, a largura de banda necessária e as despesas de manutenção do sistema.
O IKEv2 não é compatível com o IKE v1. Se usar o IKEv2, todos os nós na VPN deverão usar o IKEv2 para estabelecer os túneis.
As SAs em IKEv2 são chamadas de SAs filhas e podem ser criadas, modificadas e excluídas independentemente a qualquer momento durante a vida do túnel de VPN.
Inicialização e autenticação no IKEv2
O IKEv2 inicializa um túnel de VPN com um par de trocas de mensagens (dois pares de mensagem/resposta).
• Inicializar a comunicação: O primeiro par de mensagens (IKE_SA_INIT) negocia algoritmos de criptografia, valores de uso único de troca (valores aleatórios gerados e enviados para proteção contra mensagens repetidas) e executa uma troca de chave pública.
– O iniciador envia uma lista de algoritmos de criptografia com suporte, chaves públicas e um valor de uso único.
– O respondente envia o algoritmo de criptografia selecionado, a chave pública, um número de uso único e uma solicitação de autenticação.
• Autenticar: O segundo par de mensagens (IKE_AUTH) autentica as mensagens anteriores, as identidades de troca e os certificados e estabelece a primeira CHILD_SA. As partes dessas mensagens são criptografadas e a integridade protegida com chaves estabelecidas por meio de troca IKE_SA_INIT, portanto, as identidades são ocultas contra bisbilhoteiros e todos os campos em todas as mensagens são autenticados.
– O iniciador envia a prova de identidade, como um segredo compartilhado ou um certificado e uma solicitação para estabelecer uma SA filha.
– O respondente envia a prova de identidade correspondente e conclui a negociação de uma SA filha.
Negociando SAs em IKEv2
Essa troca consiste em um único par de solicitação/resposta e era conhecida como uma troca de fase 2 no IKE v1. Pode ser iniciada pelas extremidades da SA após a conclusão das as trocas iniciais.
Todas as mensagens após a troca inicial são protegidas criptograficamente usando as chaves negociadas e os algoritmos criptográficos nas duas primeiras mensagens da troca IKE.
O ponto de extremidade pode iniciar uma troca CREATE_CHILD_SA, portanto, nesta seção o termo "iniciador" refere-se ao ponto de extremidade que inicia essa troca.
1. O iniciador envia uma oferta SA filha e, se os dados deverem ser criptografados, o método de criptografia e a chave pública.
2. O respondente envia a oferta SA filha aceita e, se as informações de criptografia tiverem sido incluídas, uma chave pública.
Carga de configuração
A carga de configuração (CP) do IKEv2 permite ao servidor VPN atribuir dinamicamente endereços IP a clientes remotos. O cliente e servidor trocam informações, semelhante a uma negociação DHCP como se o cliente fosse diretamente conectado a uma LAN.
Quando o IKEv2 é selecionado como o método de troca para a proposta de fase 1 de IKE, o administrador pode escolher atribuir ao cliente um endereço IP a partir do pool de endereços IP IKEv2.
As cargas de configuração IKEv2 destinam-se a implantações de escala relativamente pequena.
Cliente Windows 7 IKEv2
Quando usado com dispositivos Dell SonicWALL, o cliente Windows 7 IKEv2 deve usar certificados de terceiros como o método de autenticação. Os certificados instalados no servidor de acesso remoto devem ter os seguintes valores:
• Nome comum (CN): Este campo deve conter o nome DNS totalmente qualificado ou o endereço IP do servidor de acesso remoto. Se o servidor estiver localizado atrás de um roteador de conversão de endereço de rede (NAT), o certificado deve conter o nome DNS totalmente qualificado ou o endereço IP da conexão externa do roteador NAT (o endereço que o computador do cliente vê como o endereço do servidor).
• EKU: Este campo deve incluir a Autenticação do servidor. Se existir mais de um certificado de autenticação de servidor, inclua também o EKU intermediário do IKE de segurança do IP. Somente um certificado deve ter ambas as opções de EKU, caso contrário o IPsec não consegue determinar que certificado usar e pode não escolher o certificado que você pretendia. Para obter mais informações, consulte:
http://technet.microsoft.com/en-us/library/dd941612(WS.10).aspx
Note É possível encontrar mais informações sobre o IKEv2 na especificação, RFC 4306, disponível na Web em: http://www.ietf.org/RFC/rfc4306.txt