Esta seção descreve as várias decisões de configuração que você deve tomar antes de configurar uma VPN e explica as opções disponíveis para cada decisão. Em alguns casos, são fornecidos exemplos para explicar as opções. Esta seção descreve os seguintes tipos de opções:
Esta seção fornece exemplos das seguintes opções de configuração site-a-site:
Neste exemplo, a empresa possui escritórios em dois sites remotos: San José e Atenas, como é mostrado na Figura 6-1. Os escritórios corporativos e o financeiro estão em San José e o escritório de contabilidade está em Atenas. Os dois escritórios devem compartilhar dados sem permitir que outros usuários acessem esses dados de dentro da empresa ou através da Internet. Nos dois sites, o servidor VPN está conectado diretamente com a Internet e está sendo usado como servidor de fronteira.
Se comparada com as outras duas opções de configuração site-a-site, essa opção possui a vantagem de precisar de apenas uma máquina por site para fornecer a conectividade de uma VPN e a proteção de um firewall. Além disso, quando o firewall e a VPN estão na mesma máquina, é mais fácil administrá-los. Quando o firewall e a VPN estão em máquinas e sistemas operacionais diferentes, talvez seja necessário mais de um administrador para gerenciar essas duas máquinas.
A desvantagem dessa configuração, no entanto, é que ela possui um único ponto de falha. Essa configuração também afeta a performance dos usuários que desejam enviar dados não criptografados para outras redes sem usarem a VPN.
Para essa configuração, você deve implementar a filtragem básica usando filtros RIP TCP/IP e filtros de reencaminhamento de pacotes TCP/IP. A filtragem básica será configurada automaticamente durante a instalação se você selecionar a opção Setup BorderManager for Secure Access to the Public Interface (Configurar o BorderManager para Obter Acesso Seguro à Interface Pública) durante a instalação. Para configurar filtros manualmente, consulte o guia Configuração e Gerenciamento do Filtro de Pacotes.
Figura 6-1.
Sites Remotos Vinculados por Servidores VPN Conectados Diretamente com a Internet 
Neste exemplo, o servidor VPN master do escritório financeiro em San José está por trás de um servidor de firewall conectado com a Internet, como é mostrado na Figura 6-2. Os dois escritórios estão compartilhando dados que precisam ser criptografados e enviados através de um túnel da VPN.
O endereço IP público e a máscara de sub-rede do servidor VPN fazem parte de uma rede local. O firewall possui o endereço IP 200.20.176.12 para a conexão com a Internet. O servidor VPN master possui o endereço IP público 220.150.17.65. A rede local está usando a máscara de sub-rede FF.FF.FF.C0. O servidor slave em Atenas está conectado através de um ISP. O endereço IP público e a máscara de sub-rede são 135.145.188.25 e FF.FF.FC.0, respectivamente.
Se comparada com as outras duas opções de configuração site-a-site, essa opção apresenta a vantagem de o nó da VPN estar melhor protegido contra ataques externos. Você também pode escolher qual máquina deseja usar como firewall, proporcionando a melhor proteção e o melhor controle dos recursos da rede. A instalação da VPN em uma máquina de alta velocidade separada do firewall também aprimora a performance das atividades de firewall e a criptografia e a descriptografia do fluxo de tráfego.
A desvantagem dessa configuração é que torna-se necessário usar duas máquinas, o que é mais difícil de administrar. Com o firewall e a VPN em máquinas e sistemas operacionais diferentes, talvez seja necessário mais de um administrador para gerenciar as duas máquinas.
Figura 6-2.
Sites Remotos Conectados por Servidores VPN atrás de um Firewall 
Neste exemplo, os servidores de finanças e contabilidade em San José estão em uma intranet corporativa ou rede privada, como é mostrado na Figura 6-3. Os dois departamentos estão compartilhando dados que devem ser criptografados e enviados através de um túnel da VPN.
Neste cenário, o acesso à Internet e ao ISP não é necessário, apenas a conectividade IP entre os servidores master e slave. O servidor master tem o endereço IP público 135.27.180.1. A rede local está usando a máscara de sub-rede FF.FF.FC.0. Neste exemplo, os servidores master e slave devem usar endereços de sub-rede diferentes porque estão em segmentos de LAN diferentes. O servidor slave tem o endereço IP 135.27.184.1 e a máscara de sub-rede FF.FF.FC.0.
Embora não seja mostrado neste exemplo, os nós da VPN também poderiam ser unidos usando uma conexão ponto-a-ponto e teriam o mesmo endereço de rede.
Se comparada com as outras duas opções de configuração site-a-site, essa opção possui a vantagem de permitir que os grupos de trabalho protejam a privacidade de seus dados de outros usuários dentro de uma intranet de LAN ou WAN corporativa. Como 80% de todas as tentativas que comprometem a segurança da rede originam-se dentro das intranets, essa vantagem é importante.
A desvantagem desta configuração é que os grupos de trabalho protegidos devem estar por trás de uma máquina que esteja executando o BorderManager. Por isso, talvez seja necessária uma máquina adicional e a performance provavelmente será afetada.
Figura 6-3.
Sites Remotos em uma Intranet Conectados por Servidores VPN 
Existem dois métodos disponíveis para determinar quais redes privadas estão protegidas por uma VPN:
Observe a seguir essas opções e suas vantagens e desvantagens:
Esta opção elimina o tráfego de roteamento no túnel da VPN, colocando mais banda passante disponível para a transferência de dados. A configuração estática também elimina os loops de roteamento e permite que o administrador controle melhor quais redes têm acesso à rede criptografada. A utilização de uma lista estática garante que o acesso à VPN seja limitado a redes especificadas e que os dados no túnel fiquem sempre criptografados. No entanto, uma lista estática deve ser digitada manualmente e é necessário maior overhead administrativo.
Esta opção não requer um overhead administrativo para configurar atualizações quando ocorrem mudanças na topologia da rede. No entanto, esta opção exige que seja configurado um filtro RIP para bloquear rotas indesejadas. Mais importante, se o túnel criptografado for desativado, talvez os dados sejam enviados sem estarem criptografados.
São necessárias rotas estáticas entre os servidores VPN nas seguintes situações:
A versão do software de VPN usada determina quais métodos de criptografia e autenticação estão disponíveis. Como o software de criptografia está sujeito a restrições de exportação, as leis de exportação norte-americanas determinam qual versão pode ser adquirida em determinado país. Estas três versões estão disponíveis:
Os esquemas de criptografia incluídos em cada versão do software da VPN estão listados na Tabela 6-1 por ordem de prioridade, da maior para a menor. Os esquemas de autenticação incluídos em cada versão do software da VPN estão listados na Tabela 6-2 por ordem de prioridade, da maior para a menor. A prioridade dos esquemas configurados para as duas extremidades da conexão da VPN é um dos fatores usados para determinar qual esquema é utilizado nas comunicações site-a-site e de cliente para site.
|
|
Domestic+ |
Domestic |
Export |
|---|---|---|---|
|
Triplo DES |
De 192 bits |
Não disponível |
Não disponível |
|
DES |
De 64 bits |
De 64 bits |
Não disponível |
|
RC2 |
De 128 ou 40 bits |
De 128 ou 40 bits |
40 bits |
|
RC5 |
De 128 ou 40 bits |
De 128 ou 40 bits |
40 bits |
|
|
Domestic+ |
Domestic |
Export |
|---|---|---|---|
|
SHA1 HMAC |
De 160 bits |
De 160 bits |
De 160 bits |
|
SHA1 KEYED |
De 160 bits |
De 160 bits |
De 160 bits |
|
MD5 HMAC |
De 128 bits |
De 128 bits |
De 128 bits |
|
MD5 KEYED |
De 128 bits |
De 128 bits |
De 128 bits |
Os fatores a seguir são usados na negociação que determina quais esquemas de criptografia e autenticação são implantados para cada conexão da VPN:
Por padrão, os servidores e clientes VPN têm RC5 e MD5 KEYED configurados como esquemas de segurança preferenciais. Para os servidores VPN, os esquemas de segurança preferenciais podem ser mudados para qualquer esquema suportado pelo software da VPN do servidor, mas os clientes VPN não podem reconfigurar seus esquemas de segurança preferenciais.
Durante a negociação dos esquemas de segurança, o esquema preferencial configurado para cada membro VPN é verificado para determinar se o esquema é suportado pelos dois membros VPN. Se o esquema de segurança com a maior prioridade for suportado pelos dois membros VPN, esse esquema será usado para comunicações VPN entre os dois membros VPN. Se apenas um dos esquemas preferenciais for suportado pelos dois membros VPN, esse esquema, o de menor prioridade, será usado.
Se um dos membros VPN for um cliente e o servidor tiver sido configurado para restringir um cliente VPN a seu esquema preferencial, o cliente será verificado para determinar se ele suporta o esquema de segurança preferencial do servidor. Se o cliente não puder suportar o esquema de segurança preferencial do servidor, a conexão será rejeitada.
São mostradas várias combinações de negociação na Tabela 6-3. Por exemplo, um servidor que esteja executando a versão Domestic+ com a segurança preferencial configurada como Triplo DES e SHA1 HMAC, conectando-se com um servidor executando a versão Domestic+ com a segurança preferencial definida como RC5 e MD5 KEYED, usaria as opções com maior prioridade: Triplo DES e SHA1 HMAC. Uma conexão com um cliente que esteja executando a versão Domestic+ usaria as mesmas opções.
O oposto acontece para um servidor que esteja executando a versão Domestic+ com a segurança preferencial configurada como Triplo DES e SHA1 HMAC, conectando-se com um servidor executando a versão Export com a segurança preferencial configurada como RC5 e MD5 KEYED. Eles usariam as opções com a menor prioridade: RC5 e MD5 KEYED. Se o servidor estiver configurado para restringir um cliente ao uso da segurança preferencial do servidor, uma conexão com um cliente que esteja executando a versão Export seria rejeitada.
|
|
Servidor VPN executando a versão Domestic+ com Triplo DES e SHA1 HMAC |
Servidor VPN executando a versão Domestic com DES e SHA1 KEYED |
Servidor VPN executando a versão Export com RC5 e MD5 KEYED |
|---|---|---|---|
|
Servidor VPN executando a versão Domestic+ com RC5 e MD5 KEYED |
Triplo DES |
DES |
RC5 de 40 bits |
|
Cliente VPN executando a versão Domestic+ |
Triplo DES |
DES |
RC5 de 40 bits |
|
Cliente VPN executando a versão Domestic |
Conexão |
DES |
RC5 de 40 bits |
|
Cliente VPN executando a versão Export |
Conexão |
Conexão |
RC5 de 40 bits |
Você pode configurar a VPN para suportar conectividade de rede em malha completa, em estrela e em anel entre membros VPN. A topologia que você selecionar determinará os tipos e o número de conexões que são estabelecidas, o fluxo de dados e o fluxo de tráfego de roteamento. As conexões em qualquer uma dessas topologias podem ser unilaterais (sempre iniciadas por um servidor) ou bilaterais (iniciadas pelos dois servidores). As topologias são descritas da seguinte maneira:
Esta é a topologia padrão. Todos os servidores estão interconectados para formar uma teia, ou rede em malha, com apenas um salto para qualquer membro VPN. A comunicação pode ocorrer entre todos os membros da VPN, se necessário ou não.
Esta topologia é a mais tolerante a falhas. Se um membro VPN for desativado, somente a conexão com a rede protegida desse membro será perdida. Além disso, após as chaves criptográficas serem definidas, o servidor master não será mais necessário. No entanto, esta topologia tem mais tráfego de roteamento porque cada membro VPN deve enviar atualizações para todos os demais membros. Além disso, os loops de roteamento em uma topologia de rede em malha podem demorar algum tempo para serem solucionados.
O servidor master é o hub central desta topologia, com todas as comunicações propagando-se para fora para outros servidores e retornando ao servidor master.
Em termos de tráfego de roteamento, esta é a topologia com menos tráfego, mas o servidor master é o ponto único de falha. Se o servidor master for desativado, um túnel criptografado não poderá ser estabelecido para qualquer servidor slave e a capacidade de enviar dados criptografados para todas as redes protegidas será perdida.
Nesta topologia, cada membro se comunica com seus vizinhos imediatos. O anel faz um loop do servidor master para os servidores slave subseqüentes e de volta para o servidor master.
Esta topologia possui menos tráfego através do túnel do que a rede em malha. Além disso, é mais confiável do que a rede em estrela. No entanto, uma desvantagem desta topologia é que os loops de roteamento exigem algum tempo para serem solucionados. Além disso, as outras redes podem estar a uma distância de mais de um salto.
As conexões podem ser iniciadas de uma extremidade ou das duas. Observe a seguir as vantagens e desvantagens de cada opção:
Esta opção proporciona controle administrativo porque somente o servidor VPN master pode iniciar uma conexão. As conexões serão estabelecidas somente se o escritório central precisar de uma. No entanto, uma desvantagem é que se um membro VPN passivo for reinicializado, ele deverá esperar até que a outra extremidade inicie a chamada para você poder enviar o tráfego criptografado.
Esta opção permite que as duas extremidades iniciem uma conexão automaticamente sem precisar esperar pela outra extremidade. No entanto, se uma conexão com determinado membro VPN não for necessária, você não poderá desativá-la porque a outra extremidade sempre iniciará automaticamente uma chamada que sai.
A sincronização dos servidores master-slave é ajustada usando os parâmetros a seguir:
O valor de Tempo de Espera de Conexão corresponde ao tempo que o servidor master pode esperar tentando estabelecer uma conexão com um servidor slave. O valor de Tempo de Espera de Resposta corresponde ao tempo que o servidor master pode esperar para receber uma resposta às informações de configuração que envia a um servidor slave. O servidor slave também tem um valor de Tempo de Espera de Resposta. Por último, o valor de Intervalo de Atualização corresponde ao tempo que o servidor master deve esperar antes de tentar contatar novamente os servidores slave que não puderam ser atualizados com as informações de configuração atuais durante a última tentativa.
Determinar os valores desses parâmetros representa um equilíbrio entre uma convergência rápida da VPN e o overhead de tráfego e da CPU.
Se os seus servidores e conexões ISP estiverem operando corretamente, os valores de tempo de espera padrão serão adequados para permitir que a VPN seja sincronizada no menor período de tempo possível.
Durante a sincronização, use o registro de auditoria para determinar se não foi possível entrar em contato com algum servidor slave. Se isso ocorrer devido à latência no caminho de conexão, o aumento do valor de Tempo de Espera de Conexão talvez permita estabelecer uma conexão. Se um servidor não puder ser contatado porque a conexão com o servidor ou com o ISP estava desativada, o aumento nos valores dos tempos de espera não fará com que a VPN convirja mais rapidamente. Para que a VPN seja sincronizada mais rapidamente, verifique se todos os servidores slave estão operando e se suas conexões ISP possuem uma latência mínima. Para saber qual servidor slave não pode ser contatado, use a janela Atividade da VPN, conforme descrito no manual Configuração e Gerenciamento da VPN. Em uma VPN grande com muitos servidores desativados, a diminuição temporária do valor do parâmetro Tempo de Espera de Conexão para cerca de 10 segundos permite que todos os servidores funcionais convirjam mais rapidamente e que você determine quais servidores slave estão desativados.
Além dos efeitos na sincronização do servidor, o aumento no valor do parâmetro Tempo de Espera de Resposta pode ajudar você a manter a conectividade entre dois servidores se o link entre eles for lento.
O software da VPN do BorderManager permite que os clientes de discagem remota acessem um ou mais servidores VPN usando uma conexão PPP. Quando os clientes VPN estabelecem uma conexão PPP, eles usam o TCP/IP para se comunicarem com o Gateway de Autenticação da VPN e se autenticarem. Esse gateway passa informações de configuração para o cliente de modo que ele possa gerar suas chaves e estabelecer um túnel criptografado com o servidor VPN. Depois disso, todo tráfego IPX e IP destinado ao cliente e proveniente dele será criptografado. Para configurar o controle de acesso para conexões de cliente para site, consulte o manual Configuração e Gerenciamento do Controle de Acesso.
O cliente pode se conectar com o servidor VPN usando uma destas opções:
Com esta opção, o cliente usa o protocolo PPP para estabelecer uma conexão com um ISP e, em seguida, se conecta com o servidor VPN através da Internet, como é mostrado na Figura 6-4. Embora a utilização de uma conexão ISP não proporcione uma banda passante garantida e possa ser mais lenta do que uma conexão por discagem direta, esta opção tem a vantagem de oferecer um custo menos elevado do que uma conexão por discagem direta. Além do custo da linha telefônica, a discagem direta requer que você mantenha um servidor de discagem, modems e outros equipamentos afins.
Se o seu ISP suportar o protocolo PPTP (Point-to-Point Tunneling Protocol), o cliente VPN poderá usá-lo para acessar o servidor VPN através de uma conexão ISP.
Embora a Figura 6-4 não mostre que o servidor VPN é um membro de uma VPN site-a-site, os servidores VPN podem suportar conexões de cliente para site e site-a-site. Se o servidor VPN fizer parte de uma VPN site-a-site, o cliente também poderá acessar todos os outros membros da VPN site-a-site e as redes que eles protegem. Além disso, as conexões site-a-site podem ser conexões com a Internet ou com a intranet.
Figura 6-4.
Conexão ISP com o Servidor VPN através da Internet 
Com esta opção, o cliente usa o protocolo PPP (Point-to-Point Protocol) para discar diretamente para o servidor VPN, como é mostrado na Figura 6-5. Embora uma conexão PPP direta tenha banda passante garantida, seu custo é mais elevado e talvez ela não seja mais rápida do que uma conexão ISP.
Para alguns clientes remotos, uma conexão por discagem direta talvez seja a única opção disponível.
Embora a Figura 6-5 não mostre que o servidor VPN é um membro de uma VPN site-a-site, os servidores VPN podem suportar conexões de cliente para site e site-a-site. Se o servidor VPN fizer parte de uma VPN site-a-site, o cliente também poderá acessar todos os outros membros da VPN site-a-site e as redes que eles protegem. Além disso, as conexões site-a-site podem ser conexões com a Internet ou com a intranet.
Figura 6-5.
Conexão por Discagem Direta com o Servidor VPN 