Adoção do novo sistema operacional da Microsoft deve crescer no mercado corporativo a partir da segunda metade de 2010.Os grupos Doux e Pif Paf Alimentos são donos de marcas reconhecidas na indústria alimentícia. O primeiro, de origem francesa, emprega mais de 14 mil pessoas em todo o mundo e comercializa produtos no mercado nacional sob as marcas LeBon e Frangosul. Já o mineiro Pif Paf, por sua vez, contabiliza 4 mil funcionários e vende, mensalmente, 12 mil toneladas de carne suína e de frango, além de produtos industrializados, para aproximadamente 50 mil clientes no País e no exterior.Mas além do porte e da área de atuação, os dois grupos têm algo mais em comum. Fazem parte de 97% das empresas, no Brasil, que utilizam a plataforma Windows como sistema operacional de seus computadores, segundo dados da Fundação Getúlio Vargas (FGV).Mais que isso, tanto o gerente de tecnologia da informação da Pif Paf, Augusto Carelli, quanto o Chief Executive Officer (CIO) do grupo Doux, Rafael Nicolela, não pretendem migrar, no curto prazo, para a nova geração do sistema operacional da Microsoft, o Windows 7, que chega ao mercado em 22 de outubro.Uma pesquisa realizada por Computerworld em agosto, com 130 CIOs, indica que a decisão de Nicolela e Carelli está em linha com o restante do mercado. Embora 59,56% dos executivos tenham respondido que pretendem transformar o Windows 7 no sistema operacional padrão de suas empresas, 33,09% deles devem fazê-lo no prazo entre um ano e dois anos e outros 52,94% ainda não definiram uma estimativa.O cálculo da consultoria Gartner é que o Windows 7 comece a ganhar a adesão do mercado corporativo a partir da segunda metade de 2010 e do primeiro semestre de 2011. Este é o tempo médio considerado por analistas como plausível para que uma empresa avalie a substituição do sistema operacional usado em seus computadores.De acordo com o Gartner, as companhias necessitam deste período para ter a garantia de que todas as suas aplicações e hardware serão suportados pelo Windows 7 e para colocar em prática testes-piloto com o novo sistema operacional. “É prática aguardar que saiam as primeiras correções do sistema operacional, para termos uma resposta do mercado e que os principais problemas que normalmente vêm com o sistema operacional sejam resolvidos”, diz Rodrigo Suzuki, gerente de TI da PromonLogicalis.Qual é o benefício?A decisão de fazer a substituição de sistema operacional deve ser baseada, em primeiro lugar, na análise da relação custo-benefício que o novo produto e o próprio processo de migração trarão para o negócio.É difícil estabelecer quanto uma empresa gasta para fazer a migração de sistema operacional. Especialistas ouvidos pela Computerworld afirmam que é delicado fazer essa estimativa porque o valor varia em função de diversos aspectos, como número de máquinas envolvidas e complexidade do ambiente computacional, entre outros fatores. “Não é barato, porque o sistema operacional é o coração do negócio”, observa o responsável pela área de tecnologia da consultoria Everis no Brasil, Felipe Dáguila.Por isso mesmo, é necessário identificar, claramente, quais ganhos a corporação terá ao fazer a substituição, seja em aumento no nível de segurança, novas funcionalidades do novo sistema operacional ou por exigência das necessidades do negócio. É preciso fazer a conta fechar. “Migrar por migrar não faz sentido”, ressalta o diretor da área de tecnologia da informação da consultoria Accenture, Ricardo Chisman.No grupo Doux, cerca de 900 dos 1,2 mil computadores utilizam o Windows XP como sistema operacional padrão. As outras 300 máquinas ainda usam o Windows 2000, porque foram licenciadas com ele e não tinham requisitos de hardware suficientes para rodar o XP. A empresa optou por não aumentar essa capacidade. A decisão foi mantida quando a Microsoft apresentou o Vista, que não conquistou espaço na empresa do ramo alimentício. “Não ficou claro o benefício da migração para o novo sistema operacional”, conta Nicolela.
Cinco das atualizações disponibilizadas pela empresa são críticas.
A Microsoft anunciou no final da semana passada que pretende publicar um total de nove boletins de segurança nesta terça-feira (11). Cinco deles são críticos. Windows, Office, Visual Studio, ISA Server e até mesmo Client for Mac, que permite interação do Mac com sistemas Windows, receberão atualizações de segurança. Também na coluna de hoje: sites de deputados norte-americanos são pichados, conferências de segurança trazem pesquisas inovadoras sobre rootkits para computadores Macintosh e insegurança de atualizações automáticas. O pacote mensal de correções de segurança da Microsoft sai nesta terça-feira (11). Segundo informações divulgadas pela empresa, nove boletins de segurança serão lançados. Serão eliminadas brechas no Windows, no Office, no “Client for Mac”, no ISA Server e no Visual Studio .NET 2003. As informações preliminares da Microsoft não indicam quantas vulnerabilidades serão corrigidas. Um mesmo boletim pode conter correções para diversas e diferentes falhas. Em junho, 10 boletins eliminaram 31 brechas, sendo o pacote da Microsoft recordista em número de brechas eliminadas. Pelo menos cinco dos nove boletins serão considerados “críticos”. Entre os que afetam Windows, haverá correções para todas as versões com suporte, incluindo Windows Vista e Windows 2008. O único boletim relacionado a problemas do Microsoft Office e do ISA Server – este último usado apenas em empresas – também é um dos considerados críticos. É recomendada a utilização do recurso de Atualizações Automáticas, disponível no Painel de Controle. Se estiver configurado, você deverá receber um aviso de que as atualizações estão sendo baixadas ou um pedido de confirmação para baixá-las e/ou instalá-las. A instalação das atualizações é importante para impedir que criminosos possam se aproveitar de erros nos programas para infectar seu PC.
Dê cara nova ao seu XP com Seven Remix XP, um tema de simples instalação que em apenas alguns segundos transformará a aparência do seu sistema, deixando-o praticamente idêntico ao tão comentado Windows Seven, imitando os efeitos e estilos de janelas e barras de tarefas, mas sem pesar na memória!
Vi esse post em um dos blogs que costumo acompanhar e se realmente o CD faz tudo que promete, como o autor do CD mesmo decreve: "Realmente, uma mão na roda".
Nós que gerenciamos um Departamento de TI, uma vez ou outra nos deparamos com situações onde as estações de trabalho ficam lentas, outras vezes o Windows XP não inicia por ter motivo de arquivo corrompido, para esse tipo de problema uma reparação do sistemas as vezes resolve, e quando o chkdsk não consegue resolver a parada? Lá vai ter aquele trabalhão em tirar o HD, colocar em outra máquina, salvar os arquivos, e depois disso formatar e reinstalar tudo novamente.
Achei interessante esse CD, vou baixar ele e começar a adotar em minhas rotinas para ver se me traz uma economia de trabalho e tempo, volto com o feedback no post em forma de comentário para vocês, Até a próxima!!!
"Quem administra redes acaba topando, uma hora ou outra, com um PC em que o Windows está tão baleado que não quer nem iniciar. Nesses casos, uma solução é copiar os arquivos do usuário para a rede e, assim, formatar o HD e reinstalar o sistema, sem correr riscos. Para isso, é claro, é preciso que o micro funcione. Pensando nisso, eu desenvolvi o Live XP, um Live CD baseado no Windows XP Professional. Com ele é possível fazer backup dos dados e rodar utilitários para diagnóstico e manutenção no micro com problemas. Realmente, uma mão na roda!"
Desenvolvedor do CD
» Configuração Mínima CPU de 400Mhz 64MB de RAM LiveXP Professional v1.0 Idioma: Ingles
Muitas vezes nos contentamos com os padrões que o Windows nos fornece, mesmo quando esses padrões são os grandes culpados pela ineficiência do sistema, especialmente no Vista que costuma ter muitas ferramentas desnecessárias.
Para aqueles que gostam de deixar o software, digamos, com sua cara, saiba que é possível modificar a forma como o Windows exibe suas pastas. Isso porque quando abrimos uma pasta, a disposição que vemos nossos arquivos ali dentro é escolhida pelo próprio Windows, mas saiba que você pode mudar isso.
No Windows XP Se você tem o Windows XP instalado e deseja alterar o modo de exibição para uma pasta em particular, selecione a pasta em questão e, ao abri-la, clique no botão drop-down da opção Modo de exibição e selecione o mode de exibição desejado (Película, Miniatura, Lado a lado, Lista, Ícones e Detalhes).
Para deixar esse modo como padrão em todas as pastas, na mesma janela da pasta aberta selecione Ferramentas, Opções de Pasta. Clique na aba Modo de Exibição e clique no botão Aplicar em Todas as Pastas.
Windows Vista Se você estiver usando o Vista, saiba que também é possível realizar essa alteração. Siga o mesmo procedimento e abra uma pasta qualquer, selecione Modo de Exibição e então escolha o modo que você prefere (detalhes, ícones, entre outros).
Para padronizar no modo de exibição escolhido por você, selecione Organizar e então clique em Opções de Pasta e Pesquisa. Selecione a aba Modo de Exibição e pressione o botão Aplicar às Pastas.
De acordo com o TechARP, a Microsoft está planejando lançar a versão final do Internet Explorer 8 nas próximas semanas. O browser deverá ser lançado em Março de 2009, provavelmente nas últimas duas semanas.
Quando a versão final do IE8 for lançada, ela será oferecida para os OEMs como um suplemento opcional para todos os Sistemas Operacionais Windows XP e Windows Vista licenciados pelos OEMs. Ou seja, os OEMs poderão integrar o Internet Explorer 8 aos seus produtos com Windows Vista e Windows XP.
Internet Explorer 8 RC1
O lançamento ocorrerá em duas "ondas". A primeira, que será lançada em Março, incluirá versões em inglês, português brasileiro e outros. Já a segunda ainda não tem uma data definida.
A versão mais recente do IE8 disponível para o público é a RC1, que pode ser baixada aqui.
Muitos dos aplicativos tipicamente usados no Linux, como o Pidgin, OpenOffice, Firefox, Gimp e muitos outros possuem também versões nativas para Windows. O uso deles, abre diversas portas, já que você pode rodar os mesmos aplicativos nos PCs com Linux e nos com o Windows, compatibilizando as duas plataformas.
Eles são também uma excelente alternativa para criar um sistema suave de migração, já que, uma vez que você consegue migrar os aplicativos, dar o passo final e migrar o sistema operacional acaba sendo muito mais fácil. Vamos então a uma pequena lista das opções disponíveis:
OpenOffice: Embora a história seja pouco conhecida hoje em dia, o OpenOffice teve suas origens no StarOffice, que era originalmente uma suíte de escritório para Windows, desenvolvida pela StarDivision. Por ter sido desenvolvido em C++, o StarOffice era bastante portável, o que levou à criação da versão Linux. Esta suíte de escritório multiplataforma atraiu a atenção da Sun, que decidiu comprar a StarDivision em 1999, abrindo o código da suíte e dando origem ao OpenOffice que conhecemos.
Apesar das mudanças, o OpenOffice continua disponível em versão Windows, que oferece o mesmo conjunto de recursos e o mesmo look and feel. Não é preciso dizer que com as melhorias no suporte a documentos, suporte nativo a PDFs, corretor ortográfico atualizado e assim por diante, ele é uma excelente alternativa ao MS Office. Você pode escolher entre baixar o OpenOffice da Sun, disponível no http://download.openoffice.org ou o BrOffice, disponível no http://broffice.org/download.
Firefox: O Firefox é a jóia da coroa entre os aplicativos open-source. Com o crescimento no uso de wep-apps e no acesso à web de forma geral, o navegador se torna um componente cada vez mais importante e mais estratégico.
Há quem preveja que em um futuro próximo quase todos os aplicativos rodarão dentro do navegador e que o próprio sistema operacional se tornará algo secundário. Se as previsões virem a se realizar, o Firefox tem tudo para assumir uma posição de ainda mais destaque. Você pode baixar a versão em Português do Brasil diretamente no: http://pt-br.www.mozilla.com/
Para os poucos sites que ainda são compatíveis apenas com o IE, existe a opção de usar o IE Tab (http://ietab.mozdev.org/), uma extensão que permite abrir uma aba com o Internet Explorer, deixando que ele lide com o site problemático. Naturalmente, essa extensão é apenas para Windows, já que ela simplesmente utiliza a instalação do IE disponível nele.
Entre os projetos da fundação Mozilla estão também o Sunbird, que é um aplicativo de calendário e organizador pessoal, e o Thunderbird, que atende a quem prefere um cliente de e-mail local.
Filezilla: Além de ser um excelente cliente de FTP, o Filezilla é um dos poucos clientes Windows que oferece suporte à transferência de arquivos via SFTP, o que o torna uma ferramenta indispensável em redes mistas e também para quem administra servidores Linux. Além do cliente (que possui também versão para Linux) está disponível também uma versão servidor. Faça o download no: http://filezilla-project.org/
VLC: O mesmo VLC usado no Linux ao lado do Gmplayer, Totem, Xine e Kaffeine, possui também uma versão Windows, que oferece a mesma interface e o mesmo conjunto de codecs que está disponível no Linux. Ele é uma excelente opção de player de vídeo para instalações "virgens" do Windows, poupando-o de precisar instalar players e codecs manualmente: o VLC sozinho resolve o problema. Ele está disponível no: http://www.videolan.org/vlc/
PuTTY: O PuTTY é mais conhecido que o Elvis, mas mesmo assim não poderia deixar de citá-lo, já que ele resolve o problema da falta de um cliente SSH no Windows: http://www.chiark.greenend.org.uk/~sgtatham/putty/
Na página está disponível também o PSFTP, que é um cliente SFTP de linha de comando, mas o Filezilla é bem mais prático de usar. Outra opção de cliente SFTP open-source é o WinSCP, disponível no: http://winscp.net/
Pidgin: O Pidgin possui uma versão portada para Windows desde a época do Gaim. Ele é uma excelente opção de mensageiro multiprotocolo, que pode se conectar simultaneamente a praticamente todas as redes conhecidas. Ele é também bem mais leve que a maioria dos outros aplicativos similares para Windows e, naturalmente, livre de pragas e propagandas. Ele está disponível no: http://www.pidgin.im/download/
Ekiga: Apesar de ser um projeto relativamente novo, o Ekiga já possui uma versão Windows, disponível através do http://wiki.ekiga.org/index.php/Windows_Users. Ele é uma boa opção de cliente SIP, que pode ser configurado para trabalhar em conjunto com diversos serviços de VoIP.
Audacity: Apesar da interface simples, o Audacity é um editor de áudio bastante poderoso, que se sai bem mesmo quando comparado a muitos aplicativos comerciais. Uma das grandes vantagens de aprender a trabalhar com ele é justamente o fato de possuir versões para Linux e Windows, em vez de rodar sobre apenas uma das duas plataformas: http://audacity.sourceforge.net/download/
Gimp: O Gimp é outro veterano entre os aplicativos multiplataforma. O desenvolvimento do Gimp para Windows deu origem à versão Windows da biblioteca GTK, que é atualmente usada por um grande número de aplicativos open-source para a plataforma.
Como o Gimp for Windows é mantido por uma equipe muito menor, ele fica muitas vezes uma ou duas versões atrás e alguns poucos recursos não está disponíveis, mas apesar disso ele é bem mais poderoso que outros editores de imagem gratuitos. A página oficial (que oferece apenas os pacotes para desenvolvedores) é a http://www.gimp.org/windows/ e a versão instalável está disponível para download no http://gimp-win.sourceforge.net/.
Para usar os scripts em Python, é preciso instalar também o interpretador Python, que você pode baixar no http://www.python.org/download/.
Inkscape: Embora não ofereça todos os recursos encontrados em aplicativos especializados, como o Corel ou o Illustrator, o Inkscape possui a seu favor o uso de uma interface simples e de uma excelente documentação: http://www.inkscape.org/download/
Scribus: Completando o time, temos também a versão Windows do Scribus, que serve como uma boa opção de aplicativo de desktop publishing. Ele é um aplicativo que vem evoluindo em um ritmo bastante acelerado. http://www.scribus.net/?q=downloads
Migrando as configurações: Na maioria dos casos, é possível migrar as configurações dos aplicativos em um PC com Windows para uma instalação do Linux, uma vez que a estrutura de arquivos de configuração usada pelos aplicativos é a mesma nas duas plataformas. Para isso, localize a pasta com as configurações do aplicativo no "C:\Documents and Settings\nome\Dados de aplicativos" no Windows e copie o conteúdo para dentro da pasta de configurações correspondente dentro do home, no Linux.
Essa dica, simples, rápida e fácil, não desabilita os ícones da bandeja; ela apenas os oculta. Isso significa que, embora os programas continuem rodando em background, seus ícones não serão exibidos ali embaixo.
A bandeja? É aquela parte da barra de tarefas onde ficam o relógio e ícones de programas residentes na memória. Essa, ó:
O procedimento para conseguir o milagre do desaparecimento é o seguinte:
Abra o registro - no Executar…, digite “regedit.exe” (sem aspas), e dê Enter;
Navegue até a seguinte pasta: HKEY_CURRENT_USER \ Software \ Microsoft \ Windows \ CurrentVersion \ Policies \ Explorer;
Clique com o botão direito na pasta Explorer, aponte para Novo, e clique em Valor DWORD;
Dê à nova chave o nome NoTrayItemsDisplay;
Após criá-la, dê um clique duplo, e substitua o valor 0 (zero) por 1.
Pronto! Agora, faça logoff, e entre novamente em sua conta: a bandeja estará limpa, como a minha:
Para voltar a exibir ícones ali, volte à pasta Explorer, no registro, e ou atribua valor 0 (zero) à chave NoTrayItemsDisplay, ou então simplesmente a apague.
Usar chaves estáticas permite criar VPNs rapidamente, interligando duas máquinas. A facilidade de configuração faz com que esta modalidade seja a mais utilizada, embora as limitações sejam claras. Nesta segunda parte do tutorial, estudaremos a configuração avançada do OpenVPN, utilizando certificados X509, opções adicionais de configuração e a criação de bridges, que permite efetivamente unir as duas redes, incluindo até mesmo tráfego de broadcast.
Usar chaves estáticas permite criar VPNs rapidamente, interligando duas máquinas. A facilidade de configuração faz com que esta modalidade seja a mais utilizada, embora as limitações sejam claras.
Vamos agora criar uma configuração mais elaborada, utilizando certificados X509. Este método é chamado de PKI (Public Key Infraestructure) e permite criar VPNs mais complexas, envolvendo vários servidores e vários clientes, além de oferecer uma maior segurança.
Para isso, criaremos uma "entidade certificadora", que será usada para gerar os certificados usados pelo servidor e pelos clientes. Falar em uma "entidade certificadora" dá a impressão de que precisaremos contratar uma empresa especializada para gerar os certificados, mas, na verdade, tudo é feito internamente, usando scripts fornecidos junto com o OpenVPN.
Durante o processo, é gerado um certificado mestre (um arquivo, que pode ser tanto armazenado pelo próprio servidor quanto por outra máquina da rede) que é usado para gerar os certificados usados pelas máquinas. O uso dos certificados permite que o servidor verifique a identidade dos clientes e também que os clientes verifiquem a identidade do servidor, evitando a possibilidade do uso de ataques "man-in-the-middle", onde alguém substitui o servidor por outra máquina, configurada para capturar as credenciais dos clientes quando eles tentam estabelecer a conexão.
Os certificados podem ser criados rapidamente, conforme for necessário conectar mais máquinas à VPN. Quando é necessário bloquear o acesso a uma determinada máquina (um funcionários que se desligou da empresa, por exemplo), basta revogar o certificado para que o servidor deixe de aceitar a conexão.
CRIANDO CERTIFICADOS
Para criar os certificados, utilizaremos o easy-rsa, um conjunto de scripts incluídos no pacote do OpenVPN. Na maioria das distribuições, os scripts estão disponíveis dentro da pasta "/usr/share/doc/openvpn/examples/easy-rsa". Se a pasta não existir na sua instalação, use os comandos abaixo para localizar a pasta:
# updatedb # locate easy-rsa
Duas localizações comuns são as pastas "/usr/share/doc/packages/openvpn/easy-rsa" e "/usr/share/doc/openvpn-2.0/easy-rsa". No Fedora, especificamente, é usada a pasta "/usr/share/openvpn/easyrsa" e no CentOS é usada a pasta "/usr/share/doc/openvpn-2.0.9/easy-rsa/" (onde o 2.0.9 é a versão do pacote).
O primeiro passo é copiar todo o diretório para dentro da pasta "/etc/openvpn" (você pode usar outro diretório se preferir). Isso evita que nossa configuração seja apagada ao atualizar o pacote do OpenVPN no futuro. No Debian o comando seria:
# cp -a /usr/share/doc/openvpn/examples/easy-rsa /etc/openvpn/
No Fedora, onde a localização da pasta é diferente, o comando seria:
# cp -a /usr/share/openvpn/easyrsa /etc/openvpn/
Isso criará o diretório "/etc/openvpn/easy-rsa", contendo os seguintes arquivos:
Em outras distribuições basta verificar qual é a pasta onde estão os exemplos e ajustar o comando de acordo.
A partir daí, toda a configuração será feita dentro do novo diretório:
# cd /etc/openvpn/easy-rsa
Comece editando o arquivo "vars" usando seu editor de textos preferido:
# joe vars
No final do arquivo, você encontra um conjunto de parâmetros usados para gerar as chaves (país, estado, cidade, empresa, etc.), que devem ser editados, como em:
Em seguida, usamos o comando "source" para carregar as variáveis contidas dentro do arquivo "vars" e em seguida executamos os scripts "clean-all" e "build-ca". O primeiro script limpa qualquer sobra de configuração anterior, enquanto o segundo gera o certificado raiz, usando o openssl. Como os scrips estão dentro do diretório atual, usamos o "./" ao executá-los:
# source vars # ./clean-all # ./build-ca
Generating a 1024 bit RSA private key ...................++++++ .....................++++++ writing new private key to 'ca.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [BR]: State or Province Name (full name) [SP]: Locality Name (eg, city) [Guarulhos]: Organization Name (eg, company) [GDH]: Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []: Email Address [morimoto@guiadohardware.net]:
Isso criará a pasta "/etc/openvpn/easy-rsa/keys", contendo os seguintes arquivos:
ca.crt ca.key index.txt serial
O arquivo "ca.crt" contém o certificado raiz. Ele jamais deve sair do servidor, já que qualquer um que tenha acesso a ele poderá gerar certificados adicionais que, essencialmente, permitirão que qualquer um se conecte à VPN. A necessidade de manter esse arquivo secreto faz com que alguns administradores prefiram gerar as chaves em uma máquina desconectada da rede (apenas com acesso local) e copiar manualmente os certificados gerados para o servidor e as demais máquinas.
Depois de criar o certificado raiz, podemos passar para o para o passo seguinte, que é gerar os certificados para o servidor e para os clientes.
Para gerar o certificado do servidor, usamos o script "build-key-server", especificando como parâmetro o nome do arquivo que será gerado ("servidor" no exemplo). O nome é apenas para identificação dos hosts, você pode usar os nomes que preferir:
# cd /etc/openvpn/easy-rsa/ # ./build-key-server servidor
Ele começa confirmando as informações que serão incluídas no certificado (país, cidade, empresa, etc.), da mesma forma que ao rodar o build-ca. Em um certo ponto, ele perguntará pelo atributo "Common Name", onde você deve fornecer o nome do servidor, como em:
Common Name (eg, your name or your server's hostname) []:Etch
Em seguida, ele oferece a opção de incluir um "challenge password", uma senha que será solicitada cada vez que o certificado for usado. Ela aumenta a segurança, mas em compensação reduz bastante a praticidade, já que você precisará digitar a senha cada vez que o certificado for utilizado, o que pode se tornar incrivelmente inconveniente em um servidor administrado remotamente. Se quiser manter as coisas simples, deixe o campo em branco:
A challenge password []:
Antes de terminar, ele confirma se você deseja assinar o certificado e pede mais uma confirmação antes de aplicar a alteração. Responda "y" em ambas, caso contrário a geração do certificado é abortada:
Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y
Em seguida, geramos as chaves que serão usadas pelos clientes, usando o script "build-key". Você pode gerar chaves para vários clientes em sequência, especificando nomes diferentes, como em:
# ./build-key cliente1 # ./build-key cliente2
Cada vez que o comando é executado, o script mostra a saída do comando do openssl usado para gerar a chave e confirma os parâmetros do certificado, como ao rodar o "build-key-server":
Generating a 1024 bit RSA private key .++++++ .......................++++++ writing new private key to 'cliente1.key'
Se ele simplesmente for executado instantaneamente, sem exibir o indicador ou qualquer mensagem de erro, é sinal de que alguma coisa está errada, provavelmente com a atribuição das variáveis usada pelo script. Nesse caso, experimente rodar novamente o comando "source vars" e executar o script novamente, como em:
# source vars # ./build-key cliente1
Não se esqueça de preencher a opção "commonName" com o nome da máquina (ou outro nome definido por você, diferente em cada chave). Deixando o campo em branco a chave não é gerada. No final não esqueça de responder as perguntas "Sign the certificate?" e "1 out of 1 certificate requests certified, commit?" com o valor "y".
Common Name (eg, your name or your server's hostname) []:cliente1 ... Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y
Diferente do "build-key-server", ele não oferece a opção de proteger a chave usando uma senha. Se você quiser que os usuários precisem digitar uma senha antes de poderem efetuar a conexão usando o certificado, gere as chaves usando o script "build-key-pass" em vez do "build-key". Ele confirma todos os parâmetros (assim como o build-key-server) e oferece a opção incluir a senha:
# ./build-key-pass cliente2
Em seguida, usamos o script "build-dh" (sem parâmetros). Ele gera os parâmetros Diffie Hellman, que reforçam a segurança, permitindo que o servidor e os clientes troquem as chaves (de forma segura) no momento da conexão, confirmando suas identidades:
# ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2 This is going to take a long time ....................................+...........+...............
O comando demora quase um minuto para gerar os parâmetros, mostrando um indicador de progresso durante o processo. Em caso de problemas, certifique-se de que está rodando os comandos a partir do diretório "/etc/openvpn/easy-rsa", rode o comando "source vars" para carregar as variáveis e tente novamente.
O processo de geração das chaves gera um conjunto de arquivos ".csr". Estes arquivos correspondem às requisições para a assinatura das chaves, que é feita durante o processo de criação. Eles podem ser removidos no final do processo:
# rm *.csr
Você ficará então com um conjunto de arquivos similar a esse dentro do diretório "/etc/openvpn/easy-rsa/keys":
Caso esteja curioso, estes scripts nada mais fazem do que executar os comandos correspondentes do OpenSSL, usando os parâmetros definidos no arquivo "vars". O script "build-key", por exemplo, executa os comandos:
Note que é usado o parâmetro "-days 3650", que faz com que as chaves tenham validade de 10 anos. Se a sua VPN ainda estiver em uso até lá, não se esqueça de trocar as chaves antes do 3650° dia, caso contrário sua VPN parará de funcionar após completar o décimo aniversário. :)
Falta agora fazer a instalação das chaves, tanto no servidor quanto nos clientes. Para o servidor, crie o diretório "/etc/openvpn/keys" e copie para ele os arquivos "ca.crt", "servidor.crt" e "servidor.key", como em:
# cd /etc/openvpn/easy-rsa/keys # mkdir /etc/openvpn/keys # cp -a ca.crt servidor.crt servidor.key /etc/openvpn/keys/
Copie também o arquivo "dh1024.pem" (o número 1024 corresponde ao comprimento da chave e pode mudar de acordo com a configuração), ele contém os parâmetros Diffie Hellman, e é gerado ao rodar o script "build-dh":
# cp -a dh1024.pem /etc/openvpn/keys/
O passo final é fazer a cópia dos certificados para os clientes, usando o SFTP ou outra ferramenta de transferência de arquivos.
Todos os clientes devem possuir o arquivo "ca.crt", o arquivo "dh1024.pem" e os arquivos .crt e .key correspondentes a ele. O cliente1 receberia os arquivos "ca.crt", "dh1024.pem", "cliente1.crt" e "cliente1.key"; o cliente2 receberia os arquivos "ca.crt", "dh1024.pem", "cliente2.crt" e "cliente2.key", e assim por diante.
Nos clientes Linux, crie o diretório "/etc/openvpn/keys", e copie os três arquivos para ele. Se eles estiverem com o servidor SSH ativo (e você tiver a senha de root, pode fazer a cópia a partir do próprio servidor, usando o SFTP, como em:
# sftp root@192.168.1.21
Password:
sftp> mkdir /etc/openvpn/keys sftp> cd /etc/openvpn/keys sftp> put ca.crt sftp> put dh1024.pem sftp> put cliente1.crt sftp> put cliente1.key
No caso dos clientes Windows, os quatro arquivos devem ser copiados para o diretório "keys", dentro do diretório de instalação do OpenVPN, como em "C:\Arquivos de programas\OpenVPN\config\keys". Assim como no caso dos clientes Linux, é necessário criar o diretório manualmente:
O uso de chaves torna necessário que os relógios das máquinas estejam sincronizados. No Linux, você pode acertar o relógio da máquina via web usando o comando:
# ntpdate -u pool.ntp.org
No Windows, marque a opção "Sincronizar automaticamente com um servidor de horário na Internet", disponível no Painel de Controle > Data e hora > Horário na Internet".
Ajustando a configuração
A parte mais complicada em usar certificados é a configuração inicial, que acabamos de fazer. Uma vez que os certificados já estão criados e instalados nos clientes, tudo fica mais simples.
Vamos começar com uma configuração básica, similar à VPN que criamos inicialmente utilizando chaves estáticas. Nesse exemplo, estou utilizando o sistema TAP (em vez do TUN, como no exemplo anterior) e estou utilizando os certificados anteriormente criados. A diferença entre o TUN e o TAP é que no TUN o tráfego da rede é roteado (o que elimina os pacotes de broadcast), enquanto no TAP tudo é transmitido, incluindo pacotes de broadcast e pacotes de outros protocolos de rede (como o IPX/SPX).
O arquivo "/etc/openvpn/server.conf" no servidor ficaria:
dev tap ifconfig 10.0.0.1 255.255.255.0 tls-server dh /etc/openvpn/keys/dh1024.pem ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/servidor.crt key /etc/openvpn/keys/servidor.key
Veja que agora usamos a linha "tls-server" e especificamos a localização dos 4 arquivos com os certificados que instalamos nos passos anteriores. A linha "ifconfig" especifica o endereço IP que será usado pelo servidor, juntamente com a máscara de subrede.
A configuração no arquivo "/etc/openvpn/client.conf" nos clientes ficaria:
remote guiadohardware.no-ip.org dev tap tls-client ifconfig 10.0.0.2 255.255.255.0 dh /etc/openvpn/keys/dh1024.pem ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/cliente1.crt key /etc/openvpn/keys/cliente1.key
Criados os arquivos de configuração no servidor e no cliente, reinicie o serviço em ambas as máquinas, para que o daemon leia a nova configuração e estabeleça a conexão:
# /etc/init.d/openvpn restart
Se a VPN não funcionar, ou se você receber um "Starting virtual private network daemon: client(FAILED)" ao reiniciar o serviço, experimente ativar o OpenVPN manualmente (no cliente), usando o comando:
# openvpn --config client.conf
Isso faz com que ele exiba as mensagens geradas pelo programa durante a inicialização, o que pode ajudá-lo a identificar o problema. Pode ser que ele não esteja conseguindo contactar o servidor no endereço especificado (ou o firewall pode estar bloqueando a porta especificada na configuração), pode existir algum erro na configuração, ou pode ter havido algum problema durante a geração ou a cópia das chaves, por exemplo.
Nos clientes Windows, a configuração é quase idêntica, mudando apenas as linhas com a localização das chaves. Se você as colocou dentro da pasta "keys", no diretório de configuração, o arquivo "client.ovpn" ficaria como no screenshot abaixo:
Para permitir que vários clientes se conectem simultaneamente à VPN, é necessário fazer algumas mudanças na configuração. A principal delas é que em vez de especificar manualmente o endereço IP usado pelo servidor e pelo cliente usando o comando "ifconfig" como em "ifconfig 10.0.0.2 10.0.0.1", passamos a especificar uma faixa de endereços IP para a VPN e deixamos que o servidor atribua endereços para os clientes conforme eles se conectam.
Isso é mais simples do que parece. Na configuração do servidor utilizaremos a linha "server" (deixando de usar a linha do ifconfig), especificando a faixa de endereços e a máscara, como em:
server 10.0.0.0 255.255.255.0
É importante enfatizar que a faixa de endereços utilizada na VPN deve ser diferente da faixa de endereços utilizada na rede local à qual o servidor está ligado, que, por sua vez, também deve ser diferente da faixa de endereços de rede local utilizada pelo cliente.
Originalmente o cliente tem acesso apenas ao próprio servidor. Para permitir que ele possa acessar os demais hosts da rede local, adicionamos uma linha adicional, que faz com que o servidor inclua uma regra de roteamento na configuração do cliente, no momento da conexão. Ela especifica a faixa de endereços e a máscara usada na rede local:
push "route 192.168.1.0 255.255.255.0"
Com a regra, o cliente passará a usar o endereço IP do servidor na VPN como roteador para os pacotes destinados à faixa de endereços especificada. Essa linha substitui o comando "route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.0.0.1 dev tun0" (executado no cliente) que usamos no tópico sobre VPNs com chaves estáticas.
Na configuração do cliente, adicionamos a linha "pull" (push = empurrar, pull = puxar), para que ele aceite as configurações fornecidas pelo servidor. Com isso, o cliente recebe automaticamente um endereço aleatório dentro da faixa "10.0.0.x", sem que você precise especificar a configuração de cada um manualmente:
pull
Aqui temos um exemplo de configuração completa do servidor, utilizando a interface tun, especificando uma porta UDP alternativa e utilizando as novas opções:
proto udp port 22222 dev tun server 10.0.0.0 255.255.255.0 push "route 192.168.1.0 255.255.255.0" tls-server dh /etc/openvpn/keys/dh1024.pem ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/servidor.crt key /etc/openvpn/keys/servidor.key
A configuração correspondente para o cliente seria:
remote guiadohardware.no-ip.org proto udp port 22222 client pull dev tun tls-client dh /etc/openvpn/keys/dh1024.pem ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/cliente1.crt key /etc/openvpn/keys/cliente1.key
Com essa configuração, o servidor passa a ser capaz de receber conexões a partir de vários clientes simultaneamente. O OpenVPN é capaz de gerenciar todas as conexões utilizando a mesma porta.
Para adicionar um novo cliente à VPN, você precisaria apenas gerar um novo certificado, usando o comando "./build-key" e copiar os quatro arquivos para dentro da pasta "/etc/openvpn/keys" (além de instalar o OpenVPN, naturalmente). Em resumo, os comandos para gerar um novo certificado são:
# cd /etc/openvpn/easy-rsa/ # source vars # ./build-key novocliente
A configuração é a mesma que foi usada para o primeiro cliente, mudando apenas os arquivos dos certificados. Com isso, cada cliente recebe um endereço diferente dentro da faixa "10.0.0.x" e pode acessar o servidor através do endereço "10.0.0.1".
É necessário também ativar, no servidor, a regra de firewall que roteia os pacotes provenientes dos clientes da VPN para a interface de rede local. Como agora estamos utilizando endereços atribuídos automaticamente e não mais endereços estáticos, especificamos a faixa de endereços, em vez de especificar diretamente o endereço usado pelo cliente:
Estes dois comandos precisam ser executados pelo servidor a cada boot. Você pode incluí-los no seu script de firewall, ou em algum dos scripts de inicialização do sistema.
Uma opção útil ao usar vários clientes é a opção "ifconfig-pool-persist". Ela faz com que o OpenVPN passe a armazenar uma lista cos os endereços IP usados por cada clientes da VPN e faça o possível para atribuir sempre os mesmos endereços em futuras conexões dos clientes. Isso não impede que os endereços mudem, mas torna as mudanças muito menos freqüentes. Esta opção é incluída apenas na configuração do servidor, especificando um arquivo de texto onde a lista será salva, como em:
ifconfig-pool-persist /etc/openvpn/ipp.txt
O arquivo é criado e atualizado automaticamente pelo OpenVPN, a única exigência é que ele deve ser criado dentro do diretório "/etc/openvpn" ou outra pasta à qual o usuário "openvpn", usado pelo daemon tenha acesso.
Uma opção que aumenta a segurança dos clientes é a "remote-cert-tls server" que faz com que os clientes verifiquem o certificado do servidor no momento da conexão. Ela é mais uma opção destinada a proteger os clientes contra ataques man-in-the-middle. Esta opção é adicionada apenas na configuração dos clientes:
remote-cert-tls server
Uma observação importante é que esta opção é suportada apenas pelo OpenVPN versão 2.1 (final) em diante. Se o cliente usar uma versão anterior (como o OpenVPN 2.1_rc4, usado no Debian Etch), a opção muda para "ns-cert-type server":
ns-cert-type server
Você pode verificar qual é a versão do OpenVPN usada e assim descobrir qual das duas opções deve ser utilizada usando o comando:
# openvpn --version
Usar a opção "remote-cert-tls server" em um cliente com uma versão antiga do OpenVPN faz com que o serviço simplesmente deixe de funcionar até que você a substitua pela "ns-cert-type server".
Outro problema comum é com relação ao uso da banda pelos usuários da VPN. Se uma única conexão web é dividida entre o uso da VPN e o acesso à web, você vai provavelmente querer restringir o uso de banda da VPN, para evitar que cópias de grandes arquivos e outras atividades que envolvam grande uso de banda saturem a conexão.
Isso é feito usando a opção "shaper", que limita o banda total de saída usada pela VPN a um determinado volume de tráfego. Se você usa um link ADSL com 512 kbits (ou seja, 64 kbytes) de upload, você poderia restringir o uso de banda pela VPN a 50 kbytes, por exemplo, de forma a deixar pelo menos uma pequena porção da banda reservada para outros usos.
A opção "shaper" pode ser incluída na configuração do servidor (para que seja aplicada ao tráfego de saída somado de todos os clientes conectados a ele), na configuração dos clientes (limitando assim o tráfego de saída permitido por cada um) ou em ambos. Basta especificar o limite desejado, em bytes, como em:
shaper 51200
Você pode também limitar o número de clientes simultâneos que será aceitos pelo servidor usando a opção "max-clients", especificando o número de clientes desejados, como em:
max-clients 10
Uma última opção, que pode ser usada para proteger sua VPN contra ataques DoS e oferecer uma camada adicional de segurança é a opção "tls-auth".
Com ela, uma chave compartilhada é usada para criar uma segunda camada de encriptação, sobre os pacotes já encriptados usando os certificados. O servidor só aceita pedidos de conexão encriptados com a chave compartilhada, o que faz com que pedidos de conexão de pessoas não autorizadas (que não terão a chave) sequer sejam processados pelo servidor.
Para utilizar a opção, é necessário criar uma chave estática, usando o comando "openvpn --genkey --secret", o mesmo que utilizamos no inicio para gerar a chave estática usada na nossa VPN inicial. Este arquivo pode ser armazenado no diretório "/etc/openvpn/keys", junto com os arquivos dos certificados:
# cd /etc/openvpn/keys # openvpn --genkey --secret chave.key
O arquivo gerado deve ser então copiado para todos os clientes. O próximo passo é adicionar a opção, tanto na configuração do servidor quanto na dos clientes, especificando a localização do arquivo, como em:
tls-auth /etc/openvpn/keys/chave.key
Note que, nesse caso, a chave não permite acessar a VPN. Ela é apenas um pré-requisito para poder enviar requisições de conexão para o servidor. Além dela, é necessário ter os 4 arquivos com o certificado e as chaves, como nos exemplos anteriores.
Aqui temos um exemplo final de configuração para o servidor, utilizando todas as opções que vimos até aqui:
# /etc/openvpn/server.conf proto udp port 22222 dev tun server 10.0.0.0 255.255.255.0 push "route 192.168.1.0 255.255.255.0" comp-lzo keepalive 10 120 persistkey persisttun float ifconfig-pool-persist /etc/openvpn/ipp.txt max-clients 10 shaper 51200 tls-server dh /etc/openvpn/keys/dh1024.pem ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/servidor.crt key /etc/openvpn/keys/servidor.key tls-auth /etc/openvpn/static.key
Aqui vai o arquivo de configuração correspondente para os clientes:
# /etc/openvpn/client.conf remote guiadohardware.no-ip.org proto udp port 22222 client pull dev tun comp-lzo keepalive 10 120 persistkey persisttun float tls-client dh /etc/openvpn/keys/dh1024.pem ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/cliente1.crt key /etc/openvpn/keys/cliente1.key tls-auth /etc/openvpn/static.key
Se você já está com o servidor OpenVPN ativo, precisa apenas reiniciar o serviço para que a nova configuração entre em vigor, como em:
# /etc/init.d/openvpn restart
ou:
# service openvpn restart
Se você receber um "Starting virtual private network daemon: server(FAILED).", verifique todas as opções e cheque se os arquivos dos certificados foram gerados e copiados corretamente.
Como comentei anteriormente, o conteúdo do arquivo de configuração nos clientes Windows é exatamente o mesmo, mudando apenas as linhas com as localizações dos arquivos com os certificados.
No Windows são usadas barras invertidas ao indicar a localização de arquivos e isso se aplica também à configuração do OpenVPN, entretanto as barras invertidas são também usadas como caracteres de escape no shell, por isso, ao indicas localizações de arquivos na configuração do OpenVPN no Windows, você deve duplicar todas as barras invertidas e colocar a localização entre aspas, como em:
static "C:\\Arquivos de programas\\OpenVPN\\keys\\static.key"
Um último truque é que, em um servidor com várias conexões, ou no caso de uma rede com vários servidores de VPN (onde os clientes podem se conectar a qualquer um dos servidores para obter acesso à rede), você pode criar um sistema simples de redundância e de balanceamento de carga especificando os endereços de todos os servidores na configuração dos clientes (criando várias linhas "remote") e adicionando a opção "remote-random", como em:
Isso faz com que o cliente escolha aleatoriamente entre os três endereços especificados a cada conexão, tentando os outros dois caso o primeiro esteja inacessível. Como cada cliente escolherá um servidor diferente a cada conexão, a carga acabará sendo dividida igualmente entre os servidores.
Revogando Certificados
ma parte importante do gerenciamento dos certificados no OpenVPN é a revogação dos certificados que não devem mais ser utilizados. Imagine o caso de um notebook que foi roubado, ou de um funcionário que foi demitido, por exemplo. Se os certificados não forem revogados, qualquer um em posse deles poderá (a menos que você inclua uma senha ao gerar os certificados) se conectar à VPN e assim ter acesso à rede interna da empresa.
O processo de revogação dos certificados consiste em criar um arquivo contendo a lista dos certificados revogados e configurar o servidor para utilizá-lo. A partir daí, não importa mais se os arquivos do certificado revogados sejam distribuídos, já que eles não terão mais serventia alguma.
Para criar a lista, acesse o diretório "/etc/openvpn/easy-rsa" no servidor (ou na máquina que estiver usando para gerar os certificados) e carregue as variáveis do arquivo "vars":
# cd /etc/openvpn/easy-rsa # source vars
Execute o comando "revoke-full", especificando o certificado que será revogado, como em:
# ./revoke-full cliente1
Using configuration from /etc/openvpn/easy-rsa/openssl.cnf Revoking Certificate 08. Data Base Updated Using configuration from /etc/openvpn/easy-rsa/openssl.cnf cliente1.crt: /C=BR/ST=SP/O=GDH/CN=cliente1/emailAddress=foo@bar.com error 23 at 0 depth lookup:certificate revoked
A mensagem "error 23" indica que o certificado foi revogado com sucesso, ou seja, ela não é exatamente uma mensagem de erro e sim uma confirmação.
O comando gera o arquivo "crl.pem", dentro do diretório "/etc/openvpn/easy-rsa/keys". O próximo passo é copiar o arquivo para o diretório "/etc/openvpn/keys" do servidor. Para que ele passe a ser utilizado pelo OpenVPN, adicione o parâmetro "" na configuração do servidor, especificando a localização do arquivo, como em:
crl-verify /etc/openvpn/keys/crl.pem
Para que a alteração entre em vigor, reinicie o OpenVPN:
# /etc/init.d/openvpn restart
Com isso, o cliente perde imediatamente o acesso à VPN e passa a receber um erro "TLS Error: TLS handshake failed" ao tentar se conectar novamente.
Para revogar mais chaves, repita o processo, não se esquecendo de copiar o arquivo atualizado para a pasta "/etc/openvpn/keys" do servidor a cada alteração. Se você está gerando as chaves usando o próprio servidor, pode também especificar diretamente o arquivo na pasta "/etc/openvpn/easy-rsa/keys" na opção; assim você elimina a necessidade de copiar manualmente o arquivo a cada alterãção:
crl-verify /etc/openvpn/easy-rsa/keys/crl.pem
Para que o OpenVPN leia o arquivo atualizado, use o parâmetro "reload" do serviço. Isso atualiza a configuração sem derrubar os clientes conectados:
# /etc/init.d/openvpn reload
Criando bridges
A configuração que vimos até agora faz com que o tráfego seja roteado através da VPN. Isso melhora o desempenho da VPN, pois elimina a transmissão do tráfego de broadcast e de qualquer outro protocolo de rede que não seja o TCP/IP. A desvantagem é que, sem a transmissão do tráfego de broadcast, recursos como a navegação no ambiente de redes (nos clientes Windows) ou a instalação automática de impressoras compartilhadas através do Cups (nos clientes Linux) deixem de funcionar.
Se você está disposto a sacrificar parte do link para que a VPN se comporte como uma rede local, como se todos os micros estivessem conectados ao mesmo switch, existe a opção de criar um bridge, unindo a interface virtual da VPN e a interface da rede local. Com isso, o servidor passa a usar o mesmo endereço, tanto na rede local quanto na VPN e os clientes conectados à VPN podem receber um endereço dentro da faixa usada na rede local e não apenas acessarem, mas também serem acessados pelos demais micros.
Para isso, precisaremos de um pacote adicional, o bridge-utils, que deve ser instalado no servidor. Este é um pacote padrão, que está disponível em todas as principais distribuições e pode ser instalado usando o gerenciador de pacotes, como em:
# apt-get install bridge-utils
ou:
# yum install bridge-utils
Em seguida, precisamos fazer algumas alterações na configuração do servidor. A primeira delas é a criação de dois scripts, um para ativar e o outro para desativar o bridge. Estes scripts serão executados juntamente com o OpenVPN, na ativação e desativação do serviço.
O primeiro deles é o script "/etc/openvpn/bridge-start", que contém os comandos que ativam o bridge. Veja que este script contém uma série de parâmetros (que coloquei em negrito), que precisam ser alterados de acordo com a configuração do servidor:
for t in $tap; do ifconfig $t 0.0.0.0 promisc up done
ifconfig $eth 0.0.0.0 promisc up ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast route add default gw $eth_gw dev $br
iptables -A INPUT -i tap0 -j ACCEPT iptables -A INPUT -i br0 -j ACCEPT iptables -A FORWARD -i br0 -j ACCEPT
A variável "eth" inclui o device da placa de rede e a "eth_ip" contém o endereço utilizado pelo servidor (nesse exemplo o servidor utiliza um endereço de rede interna, pois acessa através de uma conexão compartilhada, onde apenas a porta do OpenVPN é roteada para ele). A variável "eth_gw" inclui o gateway da rede (utilizado pelo servidor) enquanto a "eth_netmask" e "eth_broadcast" incluem a máscara e o endereço de broadcast da rede. Os três comandos finais incluem regras no firewall para permitir o tráfego nas interfaces.
Em seguida temos o script "/etc/openvpn/bridge-stop", responsável por desativar o bridge. Diferente do primeiro, os parâmetros são fixos, mudando apenas em configurações especiais:
#!/bin/bash # /etc/openvpn/bridge-stop
br="br0" tap="tap0" ifconfig $br down brctl delbr $br
for t in $tap; do openvpn --rmtun --dev $t done
Depois de criar os dois scripts, transforme-os em executáveis usando o comando "chmod +x", como em:
Em seguida, temos as mudanças na configuração do servidor. A primeira mudança é que o bridge utiliza a interface "tap" em vez da "tun" (o tap transmite pacotes de broadcast e o tun não), por isso substituímos a linha "dev tun" por "dev tap0".
A linha "server 10.0.0.0 255.255.255.0" dos exemplos anteriores deixa de ser usada, dando lugar ao parâmetro "server-bridge", que contém um conjunto mais extenso de parâmetros:
O primeiro parâmetro (192.168.1.101) inclui o endereço IP do servidor, seguido pela máscara. Os dois endereços seguintes (192.168.1.210 192.168.1.220) especificam uma faixa de endereços que será fornecida aos clientes remotos. Diferente dos exemplos anteriores, usamos uma faixa de endereços dentro da faixa usada na rede local, por isso é importante que você reserve uma faixa de endereços que não seja usada por outros micros da rede e que esteja fora da faixa de endereços fornecidos pelo servidor DHCP.
A linha 'push "route 192.168.1.0 255.255.255.0"' (que define a regra de roteamento que permite aos clientes remotos acessarem a rede local) também deixa de ser usada, já que com o bridge eles passam a ter acesso direto à rede, sem necessidade deu usar roteamento.
Aqui temos um exemplo de arquivo de configuração completo para o servidor:
proto udp port 22223 dev tap0 server-bridge 192.168.1.254 255.255.255.0 192.168.1.210 192.168.1.220 comp-lzo keepalive 10 120 ifconfig-pool-persist /etc/openvpn/ipp.txt tls-server dh /etc/openvpn/keys/dh1024.pem ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/servidor.crt
Na configuração dos clientes, a única mudança é a substituição da linha "dev tun" por "dev tap" (note que, diferente do servidor, usamos "dev tap" e não "dev tap0"). Temos aqui um exemplo de configuração completo. Veja que continuamos usando a linha "pull", que faz com que o cliente obtenha a configuração de rede a partir do servidor:
remote guiadohardware.no-ip.org proto udp port 22223 client pull dev tap comp-lzo keepalive 10 120 tls-client dh /etc/openvpn/keys/dh1024.pem ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/cliente2.crt key /etc/openvpn/keys/cliente2.key ns-cert-type server
Depois de ajustada a configuração, falta apenas ativar o bridge. Para isso, desativamos o serviço do OpenVPN, executamos o script que ativa o bridge e, por último, ativamos novamente o serviço do OpenVPN:
Se você estiver acessando o servidor remotamente, vai perceber que ele ficará alguns segundos sem responder. Isso acontece por que o sistema precisa "aprender" os endereços dos hosts ligados a cada uma das interfaces que compõe o bridge. Entretanto, se ele não voltar depois de uns 30 segundos, é provável que você deixou algum parâmetro incorreto na configuração, que acabou desconectando o servidor da rede. Nesse caso você vai precisar reiniciar o servidor, ou se logar localmente nele para ver o que deu errado.
Depois de ativado o bridge, o servidor ficará com três interfaces de rede. A interface "eth0" ficará sem endereço definido, assim como a interface "tap0", usada pela VPN. Uma terceira interface, a "br0" ficará com a configuração da rede, substituindo ambas. Isso acontece por que a "br0" é justamente a interface virtual do bridge, que combina o tráfego da rede local e da VPN, fazendo com que todos os dados que chegam em uma, sejam retransmitidos na outra.
Ao usar o bridge, não é usado o roteamento de pacotes, por isso não é necessário rodar o comando "echo 1 > /proc/sys/net/ipv4/ip_forward" no servidor, nem nenhum comando adicional no cliente. O sistema simplesmente passa a escutar as duas interfaces e encaminhar todo o tráfego de uma interface para a outra, tratando as duas interfaces como se fossem uma só.
No cliente a configuração é mais simples, você precisa apenas reiniciar o serviço do OpenVPN para que a alteração na configuração entre em vigor e a VPN seja restabelecida:
# /etc/init.d/openvpn restart
Uma vez que o cliente remoto se conecta à bridge, será criada a interface "tap0", utilizando um dos endereços da faixa definida na configuração do servidor, como em "192.168.1.220". Rodando o comando "route" (no cliente), você verá que o sistema automaticamente incluiu uma rota, associando a interface tap à rede "192.168.1.0".
A partir daí, o cliente pode acessar normalmente todos os demais micros da rede local, incluindo outros clientes remotos, e também ser acessado por eles. A única grande limitação é a velocidade do link. Você perceberá que ao utilizar a VPN através de uma conexão discada ou outro link lento, o acesso a compartilhamentos de arquivos e outros recursos ficará realmente muito lento.
Outra dica é que pode demorar alguns minutos até que outros micros da rede tenham acesso ao cliente, pois o sistema precisa receber conexões dos endereços antes de colocá-los na tabela. É normal que você não consiga acessar um cliente que acabou de se conectar à rede (o bridge ainda não aprendeu sobre ele) e consiga se conectar normalmente alguns minutos depois. Veja só:
$ ssh 192.168.1.210
ssh: connect to host 192.168.1.210 port 22: No route to host
$ ssh root@192.168.1.210 # (dois minutos depois)
The authenticity of host '192.168.1.210 (192.168.1.210)' can't be established. RSA key fingerprint is ba:73:11:cd:e5:c5:c2:08:46:6e:d8:c4:02:f8:62:90. Are you sure you want to continue connecting (yes/no)?
Se você tiver muitos micros com o Windows 95/98/ME na rede, o desempenho da VPN também será bastante penalizado pelo tráfego do protocolo NetBIOS (o compartilhamento de arquivos e impressoras). A melhor solução para minimizar o problema é configurar o servidor de arquivos da rede como servidor WINS e configurar todos os clientes para utilizá-lo.
O uso do servidor WINS é também a solução se você quiser que os clientes remotos tenham acesso aos compartilhamentos com a VPN utilizando interfaces tun, onde o tráfego é roteado.
Depois de testar a conexão, você pode automatizar a execução dos scripts para ativar e desativar o bridge adicionando as duas linhas abaixo ao arquivo de configuração do servidor:
up /etc/openvpn/bridge-start down /etc/openvpn/bridge-stop
Com isso, o bridge passa a ser ativado automaticamente durante o carregamento do OpenVPN, sem que você precise executar comandos adicionais.
Usando esta configuração, o bridge deve ser ativado automaticamente durante a inicialização do servidor e (se você está mantendo o serviço do OpenVPN ativo nos clientes, em vez de conectar manualmente) eles devem se conectar à VPN automaticamente assim que alguma conexão estiver disponível.
Como todo o tráfego da VPN é encriptado e os certificados privados não são transmitidos durante o estabelecimento da conexão, você pode usar a VPN sem medo, mesmo ao acessar através de redes inseguras, como redes wireless públicas ou redes de terceiros.
CRÉDITOS/AUTORIA: Carlos E. Morimoto EM 04/04/2008
Anteriormente o Connect-PI disponibilizou aos seus leitores uma solução gratuita, porém muito poderosa na configuração de uma VPN segura e eficaz!
Utilizando o OpenVPN venho disposnibilizar um tutorial ensinando como se configurar uma VPN básica em sua primeira parte, logo em seguida em outro post, disponibilizarei a configuração da mesma em modo avançado
Então vamos lá!!!
Uma VPN (Virtual Private Network, ou rede virtual privada) é, como o nome sugere, uma rede virtual, criada para interligar duas redes distantes, através da Internet. Você pode até mesmo imprimir em impressoras da rede remota, da mesma forma que faria com uma impressora local. Nesse tutorial aprenderemos criar VPNs usando o OpenVPN. Além de ser mais simples de configurar que a maioria das outras soluções de VPN e ser bastante seguro e flexível, ele possui versões Linux e Windows, o que permite criar túneis interligando máquinas rodando os dois sistemas sem grandes dificuldades.
Uma VPN (Virtual Private Network, ou rede virtual privada) é, como o nome sugere, uma rede virtual, criada para interligar duas redes distantes, através da Internet. Usar uma VPN permite que você compartilhe arquivos e use aplicativos de produtividade e de gerenciamento, como se todos os micros estivessem conectados à mesma rede local. Você pode até mesmo imprimir em impressoras da rede remota, da mesma forma que faria com uma impressora local.
Antigamente, a única forma de interligar redes em dois locais diferentes era usar linhas de frame-relay. Para quem não é dessa época, uma linha de frame-relay oferece um link dedicado de 64 kbits entre dois pontos (a matriz e a filial de uma empresa, por exemplo), com um custo mensal fixo. Você pode combinar várias linhas frame-relay em uma única conexão, de acordo com a necessidade, o problema nesse caso é o preço. Atualmente existem outras opções de conexões dedicadas e de conexões de alta disponibilidade, oferecidas pelas operadoras, mas elas ficam fora do orçamento da maioria das pequenas e médias empresas.
Usando uma VPN, você pode obter todos os benefícios de ter uma conexão dedicada entre dois pontos usando conexões via ADSL ou cabo, que são muito mais baratas. Dependendo do volume de uso da rede, você pode tanto utilizar a conexão que já tem, quanto utilizar uma segunda conexão apenas para a VPN. Além de interligar duas ou mais redes, a VPN pode (dependendo da configuração) ser acessada também por funcionários trabalhando remotamente.
Todos dados que trafegam através da VPN são encriptados, o que elimina o risco inerente à transmissão via Internet. Naturalmente, nenhuma VPN pode ser considerada "100% segura", já que sempre existe um pequeno risco de alguém conseguir obter acesso aos servidores, de forma a roubar as chaves de encriptação (por exemplo), mas, em uma VPN bem configurada o risco é realmente muito pequeno. É muito mais provável que um funcionário descontente sabote a rede interna, ou envie informações sigilosas para fora, do que algum invasor consiga efetivamente obter acesso à rede via Internet.
Nesse tópico estudaremos como criar VPNs usando o OpenVPN. Além de ser mais simples de configurar que a maioria das outras soluções de VPN e ser bastante seguro e flexível, ele possui versões Linux e Windows, o que permite criar túneis interligando máquinas rodando os dois sistemas sem grandes dificuldades.
Outras vantagens são que ele pode ser usado por clientes conectando através de uma conexão compartilhada via NAT (apenas o servidor precisa de portas abertas) e a boa tolerância contra conexões ruins, ou ao uso de conexões com IP dinâmico. A VPN pode ser configurada para ser restabelecida de forma automática em caso de interrupção na conexão, o que torna o link bastante confiável.
O OpenVPN pode ser configurado para utilizar chaves estáticas, que oferecem um nível mediano de segurança, em troca de uma configuração mais simples, ou para utilizar certificados X509, onde a configuração é um pouco mais complexa, mas em compensação a segurança é muito maior (bem superior à da maioria das soluções comerciais). Isso permite que você escolha a melhor relação entre praticidade e segurança de acordo com a situação.
Instalando
O primeiro passo é instalar o OpenVPN, tanto no cliente quanto no servidor. Nas distribuições derivadas do Debian você pode instalá-lo rapidamente via apt-get:
# apt-get install openvpn
No final da instalação ele exibirá uma mensagem, perguntando se o OpenVPN deve ser desativado antes de ser atualizado ("Would you like to stop openvpn before it gets upgraded?"). Responda que sim.
No OpenSuSE, abra o Yast e, dentro da seção de gerenciamento de pacotes, faça uma busca pelo pacote "openvpn". A busca resulta em dois resultados "openvpn", que é o pacote em que estamos interessados e "openvpn-devel", que contém o código fonte. Basta selecionar o pacote e concluir a instalação.
No Fedora, a instalação pode ser feita usando o yum. Ele se encarregará de instalar também os pacotes "openssl" e "lzo", que contém as bibliotecas usadas pelo OpenVPN para encriptar e compactar o tráfego da rede:
# yum install openvpn
No CentOS é necessário adicionar o repositório do RPMForge já que (até o CentOS 5.1), o pacote OpenVPN não faz parte dos repositórios oficiais. Você pode adicionar o repositório seguindo as instruções disponíveis aqui: http://wiki.centos.org/Repositories/RPMForge.
O primeiro passo é instalar a chave GPG do repositório:
Com a chave instalada, baixe o pacote RPM do repositório. Este pacote instala o arquivo com a configuração do repositório dentro da pasta "/etc/yum/repos.d". Verifique o link do pacote para a versão do CentOS que está utilizando na página com as instruções. No caso do CentOS 5.1, versão 32 bits, por exemplo, o pacote é o "rpmforge-release-0.3.6-1.el5.rf.i386.rpm". Se você está fazendo a configuração via linha de comando, pode baixar o pacote usando o wget, como em:
A partir daí, você pode instalar o pacote do OpenVPN usando o yum, assim como no Fedora:
# yum install openvpn
No Mandriva, basta instalar o pacote "openvpn" usando urpmi. Assim como no Fedora, ele também se encarrega de instalar as dependências:
# urpmi openvpn
Se você estiver utilizando uma distribuição que não inclua o pacote nos repositórios, ou se a versão disponível for muito antiga, você pode também instalar a partir do pacote com o código fonte, disponível no: http://openvpn.net/index.php/downloads.html
Depois de instalar o pacote, o próximo passo é carregar o módulo tun do Kernel, que é utilizado pelo OpenVPN para criar interfaces virtuais. Cada VPN criada se comporta como se fosse uma nova interface de rede, conectada à rede de destino. Imagine que a VPN se comporta como se existisse um cabo de rede gigante ligando esta interface virtual à rede do outro lado do túnel.
# modprobe tun
Adicione a linha "tun" no final do arquivo "/etc/modules" para que o módulo passe a ser carregado automaticamente durante o boot:
# echo tun >> /etc/modules
Estes três passos, ou seja, a instalação do OpenVPN, o carregamento do módulo e a adição da linha no final do arquivo devem ser executados tanto no servidor quanto nos clientes.
Depois de concluída a instalação, você pode criar um túnel simples, não encriptado, usando os comandos abaixo. Este túnel não pode ser considerado uma "VPN" já que não é seguro, mas serve como um "hello word" dentro da configuração do OpenVPN.
Presumindo que as duas máquinas estejam ligadas em rede e não exista nenhum firewall no caminho, use o comando abaixo no cliente, especificando o endereço do servidor:
Rode o comando "ifconfig" no cliente e você verá que foi criada uma interface de rede virtual, a "tun0", com o endereço "10.0.0.1":
No exemplo, o servidor recebe o endereço "10.0.0.2". Você pode testar a conectividade usando o ping ou qualquer outra ferramenta:
Como comentei, o OpenVPN possui também uma versão Windows, que está disponível no http://openvpn.se.
Esta versão inclui um instalador gráfico e funciona em todas as versões do Windows a partir do Windows 2000. Ela inclui também o driver tun/tap, que é instalado automaticamente, você precisa apenas prestar atenção nas mensagens de instalação. Em um certo ponto, será exibida uma mensagem avisando que o driver TAP/Win32 não passou pelo processo de certificação de compatibilidade com o Windows. Responda "Continuar assim mesmo" para efetuar a instalação, do contrário o OpenVPN não funcionará.
O processo de certificação dos drivers para o Windows é um processo caro e demorado, onde os fabricantes de componentes submetem os drivers de dispositivo à Microsoft para que eles sejam certificados. Este é um processo que não está ao alcance de projetos independentes, como o OpenVPN, daí a exibição da mensagem.
De qualquer forma, isso não significa que o software seja instável ou inseguro, muito pelo contrário. Se a certificação da Microsoft fosse um indicador de qualidade, softwares como o IIS e o IE não teriam tantas falhas e brechas de segurança.
Criando VPNs usando chaves estáticas
A forma mais simples de configurar o OpenVPN é utilizar chaves estáticas, onde um arquivo contendo um algoritmo de encriptação é usado pelas duas partes para encriptar os dados transmitidos através da VPN.
Nesse modo, você gera uma arquivo de texto no servidor, contendo a chave de encriptação e precisa apenas copiá-la para o cliente e fazer uma configuração rápida para criar a VPN. Se você quer apenas criar uma VPN doméstica, ou criar uma VPN temporária entre duas redes, esta é a configuração recomendada.
O grande problema em utilizar uma chave estática é que, como o nome sugere, a mesma chave é utilizada sessão após sessão, sem nunca mudar. Com isso, existe uma pequena possibilidade um atacante obstinado conseguir quebrar a VPN usando um ataque de força bruta. Como a chave é um arquivo de texto, que é armazenado tanto no cliente quanto no servidor, existe também a possibilidade de alguém conseguir copiá-lo, caso tenha acesso físico a uma das máquinas. Outra limitação é que usando uma chave estática o servidor suportará a conexão de um único cliente por VPN.
Para VPNs com vários clientes, ou em redes empresariais, onde a segurança é prioridade, é recomendável utilizar uma estrutura baseada em certificados X509, como veremos no tópico seguinte.
Vamos então à configuração de nossa primeira VPN. Para este exercício inicial, recomendo que utilize duas máquinas da rede local, que não tenham firewall ativo. Depois de entender melhor como o sistema funciona, passaremos para uma configuração mais elaborada.
O primeiro passo é gerar o arquivo com a chave, no servidor. O arquivo deve ser gerada dentro do diretório "/etc/openvpn" (o diretório padrão de configuração), de forma que acessamos o diretório antes de executar o comando que gera a chave:
# cd /etc/openvpn # openvpn --genkey --secret static.key
Isso gerará o arquivo "static.key", que contém a chave de encriptação que será usada para criar a conexão. Ele é um arquivo de texto simples, que contém uma chave de 2048 bits, como em:
Este arquivo deve ser copiado para a pasta "/etc/openvpn" do cliente, usando (por exemplo) o SFTP. Você pode usar também um pendrive, ou outra mídia de uso local, mas não é recomendável enviá-lo por meios não seguros (e-mail por exemplo), já que qualquer um que tenha acesso ao arquivo, poderá se conectar à sua VPN ou desencriptar todo o tráfego transmitido através dela.
Para acessar o servidor (a partir do cliente) via SFTP, use o comando "sftp ip" para se conectar e em seguida use os comandos "cd /etc/openvpn" e "get static.key" para fazer a cópia, como em:
# cd /etc/openvpn
# sftp root@192.168.1.101
Password:
sftp> cd /etc/openvpn
sftp> get static.key
Fetching /etc/openvpn/static.key to static.key
sftp> quit
Com o arquivo contendo a chave presente nas duas máquinas, falta criar os arquivos de configuração que serão usados pelo OpenVPN. Neste exemplo, criarei o arquivo "/etc/openvpn/server.conf" no servidor e o arquivo "/etc/openvpn/client.conf" no cliente. Os nomes podem ser diferentes, mas os arquivos devem ser criados dentro da pasta "/etc/openvpn" e devem terminar com a extensão ".conf"
O arquivo "/etc/openvpn/server.conf", no servidor, fica com o seguinte conteúdo:
dev tun ifconfig 10.0.0.1 10.0.0.2 secret static.key
A linha "ifconfig 10.0.0.1 10.0.0.2" inclui os endereços que serão usados pelas interfaces virtuais da VPN, no servidor e no cliente. No exemplo o servidor utilizará o endereço "10.0.0.1" e o cliente o endereço "10.0.0.2". Você pode utilizar outros endereços se preferir. O importante é que os endereços utilizados na VPN devem ser sempre diferentes dos endereços usados na rede local.
A linha "secret static.key" especifica o arquivo com a chave de encriptação, que criamos no passo anterior. Não esqueça de alterar a linha caso o nome do arquivo seja diferente.
Em seguida vem o arquivo "/etc/openvpn/client.conf", que deve ser criado no cliente:
remote 192.168.1.101 dev tun ifconfig 10.0.0.2 10.0.0.1 secret static.key
A primeira linha especifica o endereço IP do servidor. No exemplo estou utilizando um endereço de rede local, já que estamos apenas testando a VPN, mas em um exemplo real de uso você utilizaria o endereço IP de Internet do servidor ou (ao utilizar uma conexão com IP dinâmico) um domínio virtual utilizado por ele. Se você ainda não tem um, acesse o no-ip.com ou o dyndns.org e faça o registro.
Com os arquivos de configuração criados, inicializar a VPN é incrivelmente simples. Você precisa apenas reiniciar o serviço "openvpn" tanto no cliente quanto no servidor, usando o comando:
# /etc/init.d/openvpn restart
Ao ser iniciado, o serviço procura por arquivos ".conf" dentro do diretório "/etc/openvpn" e inicia as VPNs configuradas automaticamente. Isso não apenas simplifica a configuração, mas faz com que a VPN passe a ser automaticamente restabelecida a cada boot. Para desativá-la, basta parar o serviço:
# /etc/init.d/openvpn stop
Você pode também ativar o OpenVPN manualmente, usando (como root) o comando:
# openvpn --config /etc/openvpn/client.conf
(onde o "client.conf" é o arquivo de configuração que será usado)
Este comando manual permite acompanhar as mensagens de inicialização e de conexão, o que ajuda a descobrir o que está errado em casos em que a VPN não funciona, embora a configuração pareça estar correta.
Se a VPN é usada pelos clientes apenas esporadicamente, você pode criar um ícone no desktop, ou um pequeno script contendo o comando, para que o usuário possa se conectar à VPN apenas quando precisar. Outra opção é instalar o kvpnc (http://home.gna.org/kvpnc/), um cliente gráfico que pode ser usado para se conectar a VPNs baseadas em diversos protocolos, incluindo o OpenVPN:
Depois de estabelecida a VPN, o cliente passará a ter uma nova interface de rede, a "tun0", com o endereço IP "10.0.0.2", que funciona como um link ponto-a-ponto com a interface "tun0" no servidor, que recebe o endereço "10.0.0.1". Teste a conexão usando o ping, ou acessando algum serviço disponível no servidor, como em:
# ssh 10.0.0.1
Depois do teste inicial, você pode fazer um teste realizando a conexão via Internet (você pode usar uma conexão discada ou outra conexão temporária no cliente para fazer o teste).
Para isso, você vai precisar apenas alterar a configuração no cliente, adicionando o endereço de internet do servidor, como em:
remote guiadohardware.no-ip.org dev tun ifconfig 10.0.0.2 10.0.0.1 secret static.key
Não se esqueça de reiniciar o OpenVPN para que a alteração entre em vigor:
# /etc/init.d/openvpn restart
Portas
Diferente de outras soluções de VPN, o OpenVPN utiliza uma única porta de entrada, mesmo que sejam utilizadas várias VPNs simultaneamente. Isso facilita bastante a configuração do firewall ou do roteamento de portas no servidor.
No OpenVPN 2.x é utilizada por padrão a porta 1194 UDP que, deve estar aberta no firewall do servidor (versões antigas, anteriores à 2.0-beta16 utilizavam a porta 5000 UDP). Se o servidor acessa através de uma conexão compartilhada, é necessário configurar o gateway da rede (ou o modem ADSL) para encaminhar a porta para ele.
Como de praxe, é possível alterar a porta padrão usada pelo OpenVPN, desde que você especifique a nova porta tanto na configuração do servidor quanto do cliente. Para isso, usamos a opção "proto udp", seguida pela porta desejada, que deve ser incluída tanto na configuração do servidor quanto na do cliente, como em:
proto udp port 22222
É possível também usar uma porta TCP. Nesse caso, usamos a opção "proto tcp-server" na configuração do servidor e a opção "proto tcp-client" na configuração do cliente, como em:
proto tcp-server port 22222
e:
proto tcp-client port 22222
O grande problema em utilizar o TCP no OpenVPN é que o desempenho da VPN será perceptivelmente pior do que se utilizada uma porta UDP.
Isso ocorre porque no UDP os pacotes são transmitidos diretamente, sem nenhum overhead, o que garante o melhor desempenho. No UDP não existe correção de erros nem retransmissão de pacotes perdidos, mas isso não é um problema no caso do OpenVPN, pois ele é o responsável apenas pela criação do link de dados. Sobre ele temos o protocolo TCP/IP, e as diferentes camadas do sistema operacional, que se encarregam dessa tarefa.
Ao utilizar uma porta TCP, o próprio OpenVPN é obrigado a fazer a checagem e a retransmissão de pacotes, respeitando o modo de funcionamento do protocolo. Isso aumenta bastante a latência da conexão e faz com que cada vez que um pacote é perdido, o OpenVPN precise parar a transmissão de todos os pacotes subsequentes até que a retransmissão seja feita. Quanto maior for o volume de dados que trafegam pela VPN, mais desvantajoso é o uso do TCP no caso do OpenVPN, de forma que é mais recomendável utilizar uma porta UDP sempre que possível.
Estabilizando e otimizando a conexão
Usando a configuração simplificada do exemplo anterior, você notará que a VPN não será muito estável, pois qualquer interrupção na comunicação entre as duas máquinas derrubará o link, até que você reinicie o serviço do OpenVPN (no cliente), forçando a reconexão, como em:
# /etc/init.d/openvpn restart
Vamos então a um conjunto de parâmetros de configuração que permitem estabilizar a VPN, fazendo com que o OpenVPN passe a monitorar a conexão e restabelecê-la automaticamente sempre que necessário.
O primeiro, e mais importante, é o parâmetro "keepalive", que faz com que o servidor e o cliente monitorem a conexão, enviando pings periódicos um para o outro e reiniciem a VPN automaticamente caso não recebam resposta dentro de um período determinado. Esta opção é especialmente importante em VPNs usadas através de links ADSL ou qualquer outro tipo de conexão que não seja completamente estável. Um exemplo de uso seria:
keepalive 10 120
O primeiro número especifica o intervalo dos pings e o segundo o timeout, depois do qual a VPN é reiniciada. Nesse caso, o ping é enviado a cada 10 segundos sem atividade e a VPN é reiniciada depois de 120 segundos sem respostas. Caso o link seja interrompido, o cliente tenta restabelecer a VPN periodicamente, até que tenha sucesso. Esta linha deve ser incluída tanto na configuração do servidor quanto na do cliente.
Opcionalmente, você pode incluir a linha "inactive", para especificar um tempo máximo para as tentativas de reconexão. Se quiser que o cliente desista depois de uma hora, por exemplo, inclua a linha:
inactive 3600
O parâmetro "comp-lzo" faz com que o OpenVPN passe a compactar os dados transmitidos através do túnel (é necessário que o pacote "lzo" esteja instalado). O algoritmo usado pelo OpenVPN é bastante leve, por isso o uso adicional de processamento, tanto no servidor quando nos clientes é pequeno. A compressão dos dados não faz milagres, mas é uma boa forma de melhorar o desempenho da VPN ao utilizar links lentos ou congestionados. Esta é outra opção que deve ser incluída tanto no servidor quanto nos clientes para que seja usada:
comp-lzo
Outras duas opções úteis para tornar a VPN mais confiável e mais resistente a problemas de conectividade são a "persistkey" e a "persisttun". Elas fazem com que o daemon mantenha a interface tun aberta e as chaves carregadas quando é reiniciado (quando a VPN é restabelecida depois de uma queda de conexão, por exemplo), o que torna mais rápida a restauração do link e evita problemas diversos:
persistkey persisttun
Outra opção útil ao utilizar conexões com IP dinâmico é a opção "float", que permite que o túnel continue aberto mesmo que o endereço IP da outra máquina mude. Em situações normais, a mudança de IP faria com que a conexão fosse encerrada e o túnel fosse interrompido até que fosse reiniciado (seja manualmente ou seja pelo uso da opção keepalive). A opção "float" torna o processo mais transparente, já que o OpenVPN passa a monitorar as mudança de endereços, mantendo o túnel aberto enquanto houver conexão entre as duas partes. Essa opção também deve ser incluída tanto na configuração do servidor quanto na do cliente:
float
Temos aqui um exemplo mais incrementado de configuração do servidor, onde a porta é especificada manualmente e são usados os parâmetros que acabamos de ver:
dev tun proto udp port 22222 keepalive 10 120 comp-lzo persistkey persisttun float ifconfig 10.0.0.1 10.0.0.2 secret static.key
A configuração no cliente é praticamente a mesma, com a adição da linha "remote", que especifica o endereço do servidor e da mudança na linha "ifconfig", onde a ordem dos endereços são trocados:
remote guiadohardware.no-ip.org dev tun proto udp port 22222 keepalive 10 120 comp-lzo persistkey persisttun float ifconfig 10.0.0.1 10.0.0.2 secret static.key
Roteando os pacotes
Originalmente, o cliente terá acesso apenas ao próprio servidor. Para que ele tenha acesso aos demais hosts da rede, é necessário realizar mais alguns passos adicionais.
O primeiro é ativar o roteamento de pacotes no servidor, de forma que ele passe a encaminhar os pacotes recebidos do cliente para a interface de rede local. Mesmo que o servidor possua uma única placa de rede, a VPN é vista pelo sistema como uma interface separada, de forma que, do ponto de vista do sistema operacional, a VPN e a rede local são duas placas de rede separadas.
O roteamento é feito usando dois comandos (executados no servidor):
O primeiro ativa o roteamento de pacotes no Kernel e o segundo orienta o sistema a encaminhar os pacotes recebidos a partir do endereço IP do cliente (10.0.0.2, no exemplo) para a interface de rede local (eth0, no exemplo). Estes dois comandos precisam ser adicionados em algum dos scripts de inicialização do sistema para que sejam executados a cada boot.
O próximo passo é executar o comando abaixo no cliente, de forma que ele passe a consultar o servidor ao tentar acessar endereços dentro da faixa usada pela rede local:
Note que o comando especifica a faixa de endereços usada na rede local (192.168.1.0, no exemplo), a máscara, o endereço IP do servidor, do outro lado da VPN e a interface virtual usada pela VPN (tap0).
A partir daí o cliente conseguirá acessar outros micros da rede, montar compartilhamentos ou até mesmo imprimir em impressoras compartilhadas. É importante notar, entretanto, que se o cliente também estiver conectado a uma rede local (acessando através de uma conexão compartilhada, por exemplo), ela deve utilizar uma faixa de endereços diferentes.
Configuração no Windows
A configuração da versão Windows do OpenVPN é bastante similar à da versão Linux, com exceção de alguns detalhes e algumas adaptações feitas devido às diferenças entre os dois sistemas. Depois de baixar o pacote no http://opnvpn.se e instalar o programa, acesse a opção "OpenVPN configuration file directory", dentro da pasta "OpenVPN" que será criada no iniciar:
O atalho leva à pasta "config" dentro do diretório de instalação do programa, onde irão a chave de encriptação e o arquivo de configuração, de forma similar à pasta "/etc/openvpn" que temos no Linux.
Se você pretende usar a máquina Windows como servidor, pode usar a opção "Generate a static OpenVPN key", usando o atalho dentro do menu iniciar. Isso gerará um arquivo "key.txt" dentro do diretório de configuração, que precisa então ser copiado para o cliente.
Se, por outro lado, você quer usar a máquina Windows para se conectar a um servidor Linux, comece copiando o arquivo "static.key" do servidor para dentro da pasta de configuração:
É necessário criar também um arquivo de configuração, com a extensão "ovpn" (usando o bloco de notas), onde são especificadas as opções de configuração. O conteúdo do arquivo é exatamente o mesmo que usaríamos em um cliente Linux:
Depois de copiar a chave e gerar o arquivo de configuração, clique com o botão direito sobre ele e use a opção "Start OpenVPN on this config file" para ativar a VPN:
Isso abrirá uma janela do prompt do MS-DOS mostrando o progresso da conexão:
Assim como no Linux, a VPN aparece como uma nova interface de rede, que recebe o endereço IP definido na configuração:
Depois de testar a conexão, é possível fazer com que ela seja inicializada automaticamente ativando o serviço do OpenVPN, que passa então a monitorar o diretório de configuração, carregando automaticamente os arquivos de configuração colocados dentro dele, assim como no Linux.
Para isso, acesse o "Painel de Controle > Ferramentas Administrativas > Serviços" e mude a configuração do "OpenVPN Service" de "Manual" para "Automático":
