Search the Community

Boa tarde a todos Eu tenho um computador em casa que está sempre ligado, computador esse que tem varias câmeras de vigilância ligadas a ele. Eu através do ambiente trabalho remoto consigo aceder-lhe está ligado a minha rede de casa, mas quando estou fora e preciso de lhe aceder não consigo. Pelo que pesquisei uma VPN ia-me resolver o problema. Tenho internet da MEO e o meu roter é um Technicolor TG784n v3. Existe alguma maneira de ter uma VPN gratuita? Já vi um tutorial no PPLWARE (https://pplware.sapo.pt/informacao/tutorial-aceda-remotamente-sua-rede-meo-via-vpn/) já segui todos os passos mas depois não entendo como me ligar a VPN fora de casa.. Se alguém me pudesse ajudar agradecia. Desde já obrigado.

Boas Tenho algumas dúvidas: A firewall do windows server 2012 é suficiente segura? (se sim, como melhor a configurar?) Devo implementar outra (hardware ou software)? (sem anuidades, preferência gratuita) Tenho um ip fixo, como ligar remotamente a um pc da rede ou as pastas do servidor? (VPN como?) Obrigado

Boas, caros amigos. Implmentei uma VPN, recorrendo ao pacote openvpn para o servidor. Neste momento tenho o servidor e clientes a funcionar com certificados, no entanto tenho algumas dúvidas que gostava de saber se me conseguem esclarecer. A autenticação dos clientes no servidor é feita apenas por intermédio de certificados, do que pesquisei existe também a opção de adicionar outro método de autenticação em simultâneo para que a par com os certificados seja necessário introduzir umas credenciais de utilizador/password! No entanto do que pesquisei preciso de criar o script de autenticação, além da entropia que todo este processo vai criar, o esquecimento das passwords, o ter que cancelar certificados e criar novos, etc. Creio que é demasiado trabalho para a pequena vantagem que se obtém! No entanto há outra questão para mim mais importante, que já pesquisei e não encontrei nenhuma referência na internet, ou não fiz a pesquisa pelos termos corretos! Que seria fazer a autenticação do servidor quando os clientes se ligam á VPN ou seja, se o servidor que o cliente se está a tentar ligar não bater certo, o cliente não envia as credênciais/certificados. Quando crio a VPN no ubuntu (gnome-network-manager) além do separador geral, e do segurança, existe também o separador "autenticação TLS", que permite conectar apenas a servidor que cumpram determinados parâmetros. A minha dúvida é como é que isto funciona, tem duas opções "subject match" ou verificação por certificado do servidor. Qual das duas usar, e como usar? -no subject match o que tenho exatamente que colocar?? -e se optar pela verificação do certificado, qual é o ficheiro de certificado que devo aqui colocar (e o remote peer é servidor ou cliente?)? Desde já agradeço pela ajuda prestada.

Boas, após umas horas a ler sobre o assunto, acho que já estou mais claro, para que serve cada uma. Mas agora chega a parte de aplicar na prática e estou com dúvidas sobre qual usar. Sabendo à partida que para aceder a aplicações é mais indicado a VPN SSL, por outro lado se quiser aceder á rede em si a melhor opção seria IPSEC. Ou seja para o utilizador comum, que pretende aceder ao e-mail ou ficheiros, o SSL é o indicado, mas por outro lado, se estivermos a falar de um administrador de sistemas, que imaginemos pode querer fazer um ping a uma determinada máquina na rede, ou aceder a um servidor interno por ssh, por exemplo, sem esse servidor estar acessível do exterior seria vantajoso usar IPSEC! A minha questão é no sentido de saber se é possível usar a OpenVPN para aceder a um servidor da rede interna, via ssh.

Olá pessoal, Estou com um problema, tenho um servidor ubuntu que preciso de ligar via VPN a outro servidor para fazer downloads periódicos de dados. Mas quando ligo o tunel via forticlientsslvpn o servidor deixa de responder aos pedidos que lhe fazem fora do tunel (HTTP, SSH, etc) E como é um servidor remoto depois fico sem acesso a ele e tenho que forçar um reboot pelo painel da OVH, para que o tunel caia (juntamente com o servidor). Por este motivo também não consigo ver o que se passa com as configs de rede, pois fico logo sem acesso. O que queria era ter o tunel aberto, mas que o servidor se mantivesse à escuta no seu ip normal das portas que estão previamente configuradas. Alguém sabe como configurar isto? Obrigado.

Onde posso encontrar um material que explica sobre redes vpn site to multsite usando IPCOP? Preciso de ajudar por favor quem tiver alguma dica...

Boa tarde a todos, Acontece o seguinte, presentemente tenho o estabelecimento A e a filial B, o servidor que por acaso é um sage retail fica no estab A, tendo ligação por VPN para a Filial B. Presentemente tenho a ligação de VPN feita pelo o hamachi, que funciona mas apresenta muitas quedas/falhas, ficando regularmente a base de dados em offline.:S Podem-me indicar um serviço melhor e mais estável que o hamachi?? Já procurei no Google e o que não faltam são opções, no entanto não tenho tempo para as testar todas, se for possível me ajudarem de modo a criar um filtro já seria ótimo. Cumprimentos,

Bom dia pessoal, É o seguinte, tentei ligar-me a uma vpn sem usar API's nem nada, usei isto: System.Diagnostics.Process.Start("rasdial.exe", "nomevpn vpnuser vpnpass"); Mas deparei-me que a conexão precisa de estar criada, mas eu estou a fazer esta app para o bem comum, ou seja para toda a gente, e vai haver gente que não vai saber fazer certos passos e etc. Eu queria saber se existe maneira possível de configurar uma conexão VPN só com C# e se existe maneira também de apagar a mesma. Obrigado.

É possível fazer um programa em C++ que detete que o computador está ligado a determinada rede Wireless e automáticamente ligue a uma VPN já configurada no sistema?

boas, tenho uma ligaçao VPN criada no meu computador e queria que eu a partir do VB.net a consegui se ligar do exemplo, tenho um botao para eu seleccionar a ligaçao que quero e ligar, isso da para fazer?

Viva, Estou com problemas em me ligar à VPN com o network-manager do Gnome. :wallbash: $ cat syslog Já experimentei noutro portátil (com Window$) e consegui ligar-se, por isso não é problema do router nem das minhas credenciais. Alguma ideia do que pode ser? 🤔 cumps

Boa tarde, Alguém aqui já configurou alguma vpn em Fedora 15 com OpenVPN? Na rede da empresa onde estou a trabalhar atualmente tem uns 4 ou 5 servidores, (FileServers/MailServer/WebServer/SqlServer/..) Um dos grandes problemas que temos tido a nivel de acesso externo é quando os comerciais andam na rua em outros países ou mesmo em portugal e querem aceder a umas fotografias de um portefólio ou a catálogos, assim como fichas de especificações técnicas e não conseguem. Estive a investigar o OpenVPN no entanto estou com grandes dúvidas pois já tentei por tunneling, e tentei por bridging . Já ouvi muita gente dizer que por bridging não é aconselhado por causa dos BroadCast's o que não me esclareceu muito a nível prático (O que acontece realmente e quão notório ou problemático seria ter este tipo de ligação) No entanto já consegui ligar em dev=tun e consegui a partir do servidor "pingar" o cliente , no entanto o cliente não conseguia pingar nenhum servidor nem esse mesmo servidor inclusive. Se houver aí alguém que tenha tido a mesma experiência para me tentar ajudar e discutir umas ideias seria ótimo. Obrigado, Cumprimentos.

Boas De um momento para o outro comecei a receber o erro 800 quando tento aceder a um servidor via VPN. Posso garantir que o servidor está online e quando faço a ligação também tenho net. O mais estranho é que consigo estabelecer ligação mas só à quarta ou quinta tentativa (por vezes mais). A que se pode dever? Desde já agradeço

Boas a todos, para fazer ligações remotas entre computadores na net, aconselharam-me um VPN, mas nao sei como se faz isso, nem assim nomes de programas para isso, ou ate se o win xp ja traz isso.. Penso que este topico fica na segurança ne? O que quero é ligar pelo meu smartphone á base da dados sql da empresa, mas deixar as portas abertas do router pode ser perigoso, então falaram dos vpns, alguem me pode dar alguma ajuda em relação a isso ou sugestões? Agradecido.. cmps e bom fds

Boas a todos os fãs desta simples e bela linguagem de programação que é o VB6 Desenvolvi um programa que tem de ir buscar uma serie de ficheiros a um pc remoto e depois copiar para a minha maquina local para serem inseridos na base de dados.Para fazer essa ligação usamos um cliente gratis de VPN que é o Shrew juntamente com um codigo de ler e copiar via FTP.O problema é que agora é preciso controlar se esse tal de Shrew está com a ligação activa ou não,isto porque ele cai várias vezes ao dia e o que se pretende é um processo automático,ou seja,preciso de algo a controlar para ver se o shrew está a fazer o que é suposto fazer.Como não sei por onde começar porque o Shrew não tem nenhuma API e nem por o ter instalado aparece na lista de referências do VB gostava de saber a vossa opinião.Os testes que eu fiz para tentar perceber algo sobre o shrew foi comparar o registo de uma máquina com ele activo e com outra máquina onde ele está instalado mas não activo e não deu para perceber se havia alguma chave onde o estado da ligação esteja registado.A outra tentativa foi ver que portas tinha abertas antes e depois de ele estar activo,mas as que estavam abertas assim ficaram e não houve nenhuma novidade na lista de portas abertas Basicamente o que eu queria saber é como vocês atacavam este problema.Tenho uma aplicação que funciona, só lhe falta controlar é se tenho ligação a algo que usa uma VPN com suporte do protocolo IPsec + ligação a uma servidor para atribuição de um IP dinâmico Obrigado

boas.... alguém sabe como estar conectado ao vpn client e a Internet ao mesmo tempo ?? desde já agradeço uma resposta

Mais um curso... mais um tutorial… Desta vez sobre o OpenVPN. Então cá vai... vai ser um pouco longo, mas espero que seja do agrado de alguem: Índice 0. Sobre essa apostila 0.1 GNU Free Documentation License 1. Introdução 2. Instalação 2.1. Em Debian 2.2. Por RPM 2.3. do tarball 3. Configuração 3.1. Driver TUN/TAP 3.2. OpenSSL 3.3. Gerando os certificados e chaves 3.4. Framework e Teste do OpenSSL 3.5. Modificações no arquivo de configuração do OpenSSL 3.6. Criando arquivos para clientes e servidores 4. Teste 4.1. Configuração de servidor e cliente 5. Inicializando com o Sistema 5.1. Iniciando o VPN com o reboot 6. Como adicionar novas maquinas a VPN 7. Publicando opções de DHCP Sobre essa apostila Conteúdo O conteúdo dessa apostila é fruto da compilação de diversos materiais livres publicados na internet, disponíveis em diversos sites ou originalmente produzido no CDTC em http://www.cdtc.org.br. O formato original deste material bem como sua atualização está disponível dentro da licença GNU Free Documentation License, cujo teor integral encontra-se aqui reproduzido na seção denmesmo nome, tendo inclusive uma versão traduzida (não oficial). A revisão e alteração vem sendo realizada pelo CDTC (suporte@cdtc.org.br), desde outubro de 2006. Criticas e sugestões construtivas são bem-vindas a qualquer tempo. Autores A autoria deste conteúdo, atividades e avaliações é de responsabilidade de André Marra G. Araujo (andremarra@cdtc.org.br) . O texto original faz parte do projeto Centro de Difusão de Tecnolgia e Conhecimento, que vem sendo realizado pelo ITI em conjunto com outros parceiros institucionais, atuando em conjunto com as universidades federais brasileiras que tem produzido e utilizado Software Livre, apoiando inclusive a comunidade Free Software junto a outras entidades no país. Informações adicionais podem ser obtidas atráves do email ouvidoria@cdtc.org.br, ou da home page da entidade, atráves da URL http://www.cdtc.org.br. Garantias O material contido nesta apostila é isento de garantias e o seu uso é de inteira responsabilidade do usuário/leitor. Os autores, bem como o ITI e seus parceiros, não se responsabilizam direta ou indiretamente por qualquer prejuízo oriundo da utilização do material aqui contido. Licença Copyright ©2006,André Marra G. Araujo (andremarra@cdtc.org.br) . Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Chapter being SOBRE ESSA APOSTILA. A copy of the license is included in the section entitled GNU Free Documentation License. GNU Free Documentation License Ver: http://www.gnu.org/licenses/fdl.html 1. Introdução A idéia de utilizar uma rede pública como a Internet em vez de linhas privativas para implementar redes corporativas é denominada de Virtual Private Network (VPN) ou Rede Privada Virtual. As VPNs são túneis de criptografia entre pontos autorizados, criados através da Internet ou outras redes públicas e/ou privadas para transferência de informações, de modo seguro, entre redes corporativas ou usuários remotos. A segurança é a primeira e mais importante função da VPN. Uma vez que dados privados serão transmitidos pela Internet, que é um meio de transmissão inseguro, eles devem ser protegidos de forma a não permitir que sejam modificados ou interceptados. Outro serviço oferecido pelas VPNs é a conexão entre corporações (Extranets) através da Internet, além de possibilitar conexões dial-up criptografadas que podem ser muito úteis para usuários móveis ou remotos, bem como filiais distantes de uma empresa. Uma das grandes vantagens decorrentes do uso das VPNs é a redução de custos com comunicações corporativas, pois elimina a necessidade de links dedicados de longa distância que podem ser substituídos pela Internet. As LANs podem, através de links dedicados ou discados, conectar-se a algum provedor de acesso local e interligar-se a outras LANs, possibilitando o fluxo de dados através da Internet. Esta solução pode ser bastante interessante sob o ponto de vista econômico, sobretudo nos casos em que enlaces internacionais ou nacionais de longa distância estão envolvidos. Outro fator que simplifica a operacionalização da WAN é que a conexão LAN-Internet-LAN fica parcialmente a cargo dos provedores de acesso. O openVPN roda em: Linux, Windows 2000/XP e mais novos, OpenBSD, FreeBSD, NetBSD, Mac OS X e Solaris. Uma versão para PocketPC do OpenVPN está sendo desenvolvida. Aplicações para redes privadas virtuais Abaixo, são apresentadas as três aplicações ditas mais importantes para as VPNs. ACESSO REMOTO VIA INTERNET O acesso remoto a redes corporativas através da Internet pode ser viabilizado com a VPN através da ligação local a algum provedor de acesso (Internet Service Provider - ISP). A estação remota disca para o provedor de acesso, conectando-se à Internet e o software de VPN cria uma rede virtual privada entre o usuário remoto e o servidor de VPN corporativo através da Internet. CONEXÃO DE LANS VIA INTERNET Uma solução que substitui as conexões entre LANs através de circuitos dedicados de longa distância é a utilização de circuitos dedicados locais interligando-as à Internet. O software de VPN assegura esta interconexão formando a WAN corporativa. A depender das aplicações também, pode-se optar pela utilização de circuitos discados em uma das pontas, devendo a LAN corporativa estar, preferencialmente, conectada à Internet via circuito dedicado local ficando disponível 24 horas por dia para eventuais tráfegos provenientes da VPN. CONEXÃO DE COMPUTADORES NUMA INTRANET Em algumas organizações, existem dados confidenciais cujo acesso é restrito a um pequeno grupo de usuários. Nestas situações, redes locais departamentais são implementadas fisicamente separadas da LAN corporativa. Esta solução, apesar de garantir a "confidencialidade" das informações, cria dificuldades de acesso a dados da rede corporativa por parte dos departamentos isolados. As VPNs possibilitam a conexão física entre redes locais, restringindo acessos indesejados através da inserção de um servidor VPN entre elas. Observe que o servidor VPN não irá atuar como um roteador entre a rede departamental e o resto da rede corporativa uma vez que o roteador possibilitaria a conexão entre as duas redes permitindo o acesso de qualquer usuário à rede departamental sensitiva. Com o uso da VPN o administrador da rede pode definir quais usuários estarão credenciados a atravessar o servidor VPN e acessar os recursos da rede departamental restrita. Adicionalmente, toda comunicação ao longo da VPN pode ser criptografada assegurando a "confidencialidade" das informações. Os demais usuários não credenciados sequer enxergarão a rede departamental. O OpenVPN é um software livre, ou seja, você pode olhar o código dele, modificar o código para usá-lo do jeito que você deseja, você pode distribuir e etc. Enfim, são muitas as características que o OpenVPN tem, além de ser software livre. Vejamos algumas. Com o OpenVPN, você pode: • construir um túnel em qualquer subrede ou adaptador ethernet virtual em cima de uma única porta UDP ou TCP, • usar toda a encriptação, autenticação e características de certificação da biblioteca OpenSSL para proteger o tráfico da sua internet privada enquanto ele transita pela internet, • usar qualquer cipher, chave, ou compilador HMAC suportado pela biblioteca OpenSSL, • escolher entre chave-estática baseada em encriptação convencional ou chave-pública baseada em certificação. • usar chaves estáticas pré-compartilhadas ou baseadas em troca dinâmica de chaves TLS • construir um túnel em rede na qual o ponto final seja dinâmico como DHCP ou clientes discados, • criar pontes de ethernet seguras usando virtual tap devices, e • controlar o OpenVPN usando uma GUI no Windows ou Mac OS X. Qual a diferença entre o OpenVPN e outros pacotes VPN? • A principal força do OpenVPN inclui a portabilidade através das muitas plataformas do conhecido universo computacional, excelente estabilidade, suporta centenas ou milhares de clientes, instalação relativamente fácil e suporte a IP dinâmico e NAT. • OpenVPN oferece uma interface de administração que pode ser usada para controlar remotamente ou administrar centralmente um processo OpenVPN. A interface de administração pode ser usada, também, para desenvolver uma GUI ou uma aplicação na web para o OpenVPN. • No Windows, o OpenVPN pode ler certificados e chaves privadas de pequens cartões que suportem o Windows Crypto API. • OpenVPN tem sido construído com um forte design modular. Toda a encriptação é provida pela biblioteca OpenSSL, e todas as funcionalidades de tunelamento de IP são providas pelo driver de rede virtual TUN/TAP. • Enquanto o OpenVPN provê muitas opções para controlar parâmetros de segurança de um túnel VPN, ele também provê opções de proteção à segurança do próprio servidor, como --chroot para restringir uma parte do sistema de arquivo que o daemon do OpenVPN tem acesso, --user e --group para minimizar privilégios do daemon depois da inicialização, e --mlock para ter certeza que o material chave e dados do túnel nunca são gravados no disco onde, depois, esses dados poderiam ser recuperados. Mais informações podem ser obtidas em inglês na página oficial do OpenVPN. http://openvpn.net 2. Instalação O download do OpenVPN pode ser feito pelo site http://openvpn.net/download.html Este é o site oficial do OpenVPN e você pode baixar a versão que quiser. Instalação do OpenVPN no debian 1. Abra o terminal 2. Entre como root ou superusuário 3. Digite #apt-get update 4. Digite #apt-get install openvpn 5. O apt vai baixar o pacote do openvpn e instalá-lo em seguida. Instalação via RPM Primeiramente crie o arquivo RPM. Isso exige que as bibliotecas OpenSSL, pthread, e LZO estejam presentes. Normalmente apenas a biblioteca LZO não está presente nas distruibuições de linux atuais. rpmbuild -tb openvpn-2.0.6.tar.gz O processo de criação do arquivo RPM, irá gerar muitas linhas de saida. Se o processo for bem sucedido, deverá existir uma linha próxima ao final da saida, iniciando com o nome do arquivo RPM criado. Agora você pode instalar o arquivo RPM binario com o comando: rpm -Uvh binary-RPM-file Instalação do tarball Descompacte a distribuição: tar -zxvf openvpn-2.0.6.tar.gz Compile o OpenVPN: cd openvpn-2.0.6 ./configure make make install Se você não deseja as funcionalidades da biblioteca LZO, adicione o parametro --disable-lzo ao comando ./configure. Outras opções podem ser ativadas, como o suporte a pthread (./configure --enable-pthread) para diminuir a latencia usando trocas de chaves SSL/TLS dinamicas. O comando ./configure --help irá exibir todas as opções de configuração. 3. Configuração Configurando o driver TUN/TAP Configurações a serem feitas uma unica vez Se você está usando o kernel 2.4.7 ou superior, as chances são muito boas que seu kernel já tenha o driver TUN/TAP. Você pode confirmar isso com o comando locate if_tun.h que deve reportar um arquivo como /usr/include/linux/if_tun.h. Para o kernel 2.4.7 ou superior, se você o instalou pelo tarball, entre com o seguinte comando para configurar o device TUN/TAP. (você pode omitir isso se você fez a instalação via RPM. Ele já o fez automaticamente para você.): mknod /dev/net/tun c 10 200 Se você está usando o kernel 2.2, você deve obter a Versão 1.1 do modulo TUN/TAP para o kernel e seguir as instruções da instalação. Configurações a serem feitas a cada reboot No linux, antes de usar o OpenVPN ou qualquer outro programa que use o driver TUN/TAP, você deve carregar o driver TUN/TAP modprobe tun e ativar o roteamento de pacotes IP: echo 1 > /proc/sys/net/ipv4/ip_forward OpenSSL O OpenSSL é primeiramente uma biblioteca de funções criptográficas que proporciona uma extensiva API (Application Programming Interface - Aplicação de interface de programação) para programadores. No entanto, ela também inclui uma ferramenta shell que expõe essa API para usuários e scripts. Inicie o shell escrevendo openssl na linha de comando (em um terminal). Daí, você pode escrever comandos no prompt OpenSSL>. [user@computador user]$ openssl OpenSSL> version OpenSSL 0.9.8a 11 Oct 2005 OpenSSL> Você pode executar comando do OpenSSL em batch mode (conjunto de programas pocessados consecutivamente pelo sistema operacional de um microcomputador). Em batch mode, cada comando do OpenSSL é executado separadamente. Shell scripts usualmente usam esta característica; nós faremos o mesmo neste curso: [user@computador user]$ openssl version OpenSSL 0.9.8a 11 Oct 2005 [user@computador user]$ Dos muitos comandos que podem ser executados no shell do OpenSSL, este curso só vai cobrir 5 (cinco): • ca: administração de Autoridades Certificadoras • req: administração de solicitação de Certificado • verify: verificação de Certificado • s_server: Modo de teste seguro de servidor • s_client: Modo de teste seguro de cliente Arquivo de configuração do OpenSSL Quando é instalado a Autoridade Certificadora (OpenSSL), nós precisamos determinar o arquivo de configuração mestre. Este arquivo contém parâmetros padrões para todos os comandos do OpenSSL. O nome deste arquivo é openssl.cnf. Para encontrar a localização deste arquivo, use o comando version com a opção -d: [user@computador user]$ openssl version -d OPENSSLDIR: "/usr/lib/ssl" [user@computador user]$ Uma vez que você sabe onde procurar, edite este arquivo com um editor de texto. Aqui está o arquivo de configuração que usaremos: # openssl.cnf # # OpenSSL example configuration file. # # This configuration file has been derived from the original # example file included with the OpenSSL distribution. It # has been edited mostly to eliminate extensions in order to # simplify it for the purpose of an online tutorial. It has # also been reformatted to limit the maximum line length to # 60 characters for online publication. ############################################################ # This section will configure the ca (Certificate Authority) # command. We will use the ca command to sign user # certificates and periodically generate CRLs. ############################################################ [ ca ] default_ca = CA_default # The default ca section [ CA_default ] dir = /root/CA-DB # Top crl_dir = $dir/crl # The crl location database = $dir/index.txt # Database index file new_certs_dir = $dir/newcerts # Location for new certs certificate = $dir/cacert.pem # The CA certificate serial = $dir/serial # The next serial number crl = $dir/crl.pem # The current crl # All DNs need to be unique. This is the default behavior # but due to an OpenSSL library bug in the 0.9.7d release, # if we don't supply this redundant definition here we will # see a cryptic message when signing certificates. unique_subject = yes # The CA private key private_key = $dir/private/cakey.pem # Private random number file RANDFILE = $dir/private/.rand # Issued certificates will be valid for 1 year default_days = 365 default_crl_days= 30 # Hashing function default_md = md5 # This assignment causes the extensions defined in the # 'user_extensions' section to be included in any # certificates that are signed using the ca command. x509_extensions = user_extensions # This sections describes the policy that will be enforced # on a request to be signed, the subject organization name # must match that in the CA certificate. The request may # contain an optional organizational unit name. The common # name is assigned the policy format 'supplied' which means # it must be present in the certificate request. policy = policy_any [ policy_any ] organizationName = match organizationalUnitName = optional commonName = supplied ############################################################ # This section configures the req (certificate request) # command. ############################################################ [ req ] # The default key length and the filename that will contain # a private key. The public key will be contained in the # certificate request. default_bits = 1024 default_keyfile = privkey.pem distinguished_name = req_distinguished_name # The makeup of our subject name [ req_distinguished_name ] organizationName = Organization Name (eg, company) organizationName_default = Inyo Technical Services organizationalUnitName = Organizational Unit (eg, west) commonName = Common Name (eg, YOUR name) commonName_max = 64 # This assignment mimics that in the ca section but causes # the following extensions to be included in a certificate # request. In our case these extensions will only be # included when we self-sign a certificate using 'req # -new -x509'. x509_extensions = CA_extensions ############################################################ # Extensions that will be added to certificates that are # issued. The 'user_extensions' sections contains # definitions that will be included in certificates that are # signed by this CA. The CA_extensions section contains # extensions that will be included when we create a # self-signed certificate using the req command. ############################################################ [ user_extensions ] # CA:FALSE will not permit this certificate to sign other # certificates. basicConstraints = CA:FALSE [ CA_extensions ] # CA:TRUE will allow this certificate to sign others. basicConstraints = CA:TRUE #[Fim de arquivo] Você precisa fazer apenas uma modificação: • Na seção [CA_default] modifique o parâmetro "dir" para um diretório que você tenha poder de escrita. • default_md = md5 Gerando os certificados e chaves Com o arquivo de configuração arrumado, agora nós podemos fazer a estrutura do diretório para guardar nosso CA. Nós escolhemos o diretório que foi configurado acima ([CA_default]/"dir") criamos nossos diretórios e inicializamos os arquivos serial e crlnumber. [user@computador user]$ mkdir CA-DB [user@computador user]$ cd CA-DB [user@computador CA-DB]$ mkdir crl [user@computador CA-DB]$ mkdir newcerts [user@computador CA-DB]$ mkdir private [user@computador CA-DB]$ mkdir CA-DB [user@computaodr CA-DB]$ echo "01" > serial [user@computador CA-DB]$ echo "01" > crlnumber [user@computador CA-DB]$ touch index.txt [user@computador CA-DB]$ Note que nós inicializamos os arquivos serial e crlnumber com o primeiro serial number. Quando autenticamos certificados, o número guardado nesses arquivos vão incrementando automaticamente sendo que cada certificado vai receber um serial number único. O arquivo index.txt vai gravar todos os certificados autenticados. Com a estrutura do diretório no lugar, nós podemos criar nosso root certificate com nossa própria assinatura. Este certificado vai se sentar no topo da nossa hierarquia de confiança. Nós vamos usá-lo para assinar todo o resto. [user@computador CA-DB]$ openssl req -new -x509 -keyout \ > private/cakey.pem -out cacert.pem Generating a 1024 bit RSA private key ...................................................... writing new private key to 'private/cakey.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- 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) [AU]: State or Province Name (full name) [some-State]: Locality Name (eg, city) []: Organization Name (eg, company) [internet Widgits Pty Ltd]: Organizational Unit Name(eg, section) []: Common Name (eg, YOUR name) []:Root CA Email Address []: [user@computador CA-DB]$ [/i] Para esclarescer alguma pontecial confusão, a opção -x509 vai pedir ao comando req para gerar um certificado de assinatura própria em vez de um certificado de pedido. Nós só vamos usar esta opção com o comando req uma vez criado nosso root certificate. Certificados dos usuários Agora, nós vamos criar um certificado de pedido para o servidor OpenVPN instalado na nossa network. Note que usamos o argumento -nodes. Ele previne que a chave privada gerada com o pedido seja encriptada e protegida por senha. Nós vamos precisar guardar a chave com cuidado por causa disto. Nós não vamos proteger essa chave com senha porque depois nós vamos iniciar o servidor OpenVPN automaticamente no boot quando não há interação com usuário para prover a senha. [i][user@computador CA-DB]$ openssl req -new -nodes -keyout \ > vpnkey.pem -out vpncert-req.pem Generating a 1024 bit RSA private key ........................................................ writing new private key to 'vpnkey.pem' ----- 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) [AU]: State or Province Name (full name) [some-State]: Locality Name (eg, city) []: Organization Name (eg, company) [internet Widgits Pty Ltd]: Organizational Unit Name(eg, section) []: Common Name (eg, YOUR name) []:vpn.curso.com Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name [] [user@computador CA-DB]$ Agora nós assinamos digitalmente o certificado do servidor usando o root certificate que nós criamos inicialmente. O OpenSSL vai restaurar a localização do root certificate do arquivo de configuração, que é o porque de não aparecer como argumento na linha de comando. Este comando vai atualizar os arquivos serial e index.txt quando for completado. [user@computador user]$ openssl ca -out vpncert.pem \ > -in vpncert-req.pem Using configuration from /home/admin/install/openssl.cnf Enter pass phrase for /home/admin/CA-DB/private/cakey.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 1 (0x1) Validity Not Before: May 16 20:46:43 2006 GMT Not After : May 16 20:46:43 2007 GMT Subject: countryName = AU stateOrProvinceName = Some-State organizationName = Internet Widgits Pty Ltd commonName = vpn.curso.com X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 01:C9:91:6B:99:53:E6:6E:D7:56:5D:26:95:22:32:05:E3:7A:BE:9C X509v3 Authority Key Identifier: keyid:87:AB:B8:52:AF:74:EB:69:55:A1:C2:17:7E:A7:64:11:77:25:88:E8 Certificate is to be certified until May 16 20:46:43 2007 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated [user@computador CA-DB]$ Depois de criado o certificado do servidor, nós podemos criar certificados para todos os clientes para quem queremos dar acesso à VPN. O processo é o mesmo, exceto que nós não especificamos a opção -nodes com o comando req. Isso vai encriptar a chave privada e o OpenSSL vai pedir uma senha quando semeado o código. Framework de Teste do OpenSSL Agora, depois de termos criado os certificados de usuários, nós podemos comprovar que nosso procedimento está todo correto em detrimento de dois comandos de teste fornecido pelo pacote OpenSSL. Os programas s_server (secure server) e s_client (secure client) podem exercitar praticamente toda a biblioteca e suas operações são claras. Inicie um s_server do OpenSSL em um terminal. Inicie um s_client do OpenSSL em outro. O cliente vai contactar o servidor usando o protocolo SSL/TLS no localhost usando a porta 4433. Você será capaz de digitar mensagens dentro do console do cliente e vê-las aparecer do console do servidor. Vai ser óbvio se seus certificados não estiverem corretos ou têm algum problema com sua instalação da biblioteca OpenSSL. Aqui nós iniciamos o s_server do OpenSSL na linha de comando. Como argumentos, nós incluimos o certificado do servidor e a chave privada do servidor. O argumento -verify 1 faz o servidor perguntar por qualquer cliente conectando a mandar um certificado para autenticação. [user@computador CA-DB]$ openssl s_server -cert vpncert.pem \ > -key vpnkey.pem -verify 1 verify depth is 1 Using default temp DH parameters Using default temp ECDH parameters ACCEPT Agora, em outro terminal, nós iniciamos o s_client do OpenSSL usando o argumento -cert para fornecer um certificador para o servidor para autenticação. O argumento -key usa a chave privada para encriptar as mensagens e o argumento -CAfile aponta para o root certificate. [user@computador CA-DB]$ cp cacert.pem CA-DB/ [user@computador CA-DB]$ openssl s_client -CAfile \ > CA-DB/cacert.pem -cert client1cert.pem -key client1key.pem Enter PEM pass phrase: CONNECTED(00000003) depth=1 /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=Root CA verify return:1 depth=0 /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=vpn.curso.com verify return:1 --- Certificate chain 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=vpn.curso.com i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=Root CA --- Server certificate -----BEGIN CERTIFICATE----- MIICpTCCAg6gAwIBAgIBATANBgkqhkiG9w0BAQQFADBXMQswCQYDVQQGEwJBVTET MBEGA1UECBMKU29tZS1TdGF0ZTEhMB8GA1UEChMYSW50ZXJuZXQgV2lkZ2l0cyBQ dHkgTHRkMRAwDgYDVQQDEwdSb290IENBMB4XDTA2MDUxNjIwNDY0M1oXDTA3MDUx NjIwNDY0M1owXTELMAkGA1UEBhMCQVUxEzARBgNVBAgTClNvbWUtU3RhdGUxITAf BgNVBAoTGEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDEWMBQGA1UEAxMNdnBuLmN1 cnNvLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA7BB3eDULA2HYMBwo bXis0csx/TNHhWz5JUQMD89qYdudp8QLTc3eOIef50M2nJex6MOdetjdxv1EzPYH Hq8I8BoJ8w3HTbdIHw2O+Mk00HGihyiSNdMLxUf0nUoWL2Abqpfk69WA4L7k/qgY mM9mtiu5Y8n9jceQCLhQ7RQQr0MCAwEAAaN7MHkwCQYDVR0TBAIwADAsBglghkgB hvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYE FAHJkWuZU+Zu11ZdJpUiMgXjer6cMB8GA1UdIwQYMBaAFIeruFKvdOtpVaHCF36n ZBF3JYjoMA0GCSqGSIb3DQEBBAUAA4GBANEEnzesDqdIeiWlNruQmeRXV93Elr22 EYaKOhJo9pNs4YaN2HvbQclQKLKD+GLYsc3uQ8x2MbZcBoD6OxHNtkdYh72qVOzc sngJ6PNxTMnVCXmqEy3X4mVbKkAxS3iJhlge3TVVj4eZ+GKYSk/4UhA6/GiqRWRW aq0Qv6DKiCdC -----END CERTIFICATE----- subject=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=vpn.curso.com issuer=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=Root CA --- No client certificate CA names sent --- SSL handshake has read 1129 bytes and written 1856 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: FBBBE1F495D03337D17A91DB2F69814F8D1638976EEB633CD1B688164144DFC1 Session-ID-ctx: Master-Key: 6109E6EF23FFE25844779B96B6BF2D3C553A3D4EBFA77A381B50B07F0C8D3F30 4C99AC7AF68E5373820C460C85823A46 Key-Arg : None Start Time: 1147813810 Timeout : 300 (sec) Verify return code: 0 (ok) --- Agora você pode escrever mensagens! Tudo o que você escrever neste terminal vai aparecer no outro e vice-versa. Para sair desta sessão, escreva Q e dê ENTER. Agora nós sabemos que nossos certificados podem encriptar mensagens passadas entre as duas aplicações OpenSSL. No entanto, nós não sabemos se podemos usar nossos certificados com qualquer aplicação de certificado seguro X.509. Adicionando a opção -WWW ao comando s_server irá efetivamente criar um web server seguro que pode servir qualquer arquivo local para um navegador cliente conectando usando SSL/TLS. Vamos testar isso a seguir. No mesmo diretório, crie um pequeno arquivo HTML contendo o seguinte texto: <html> <body> <h1>Hello World!</h1> </body> </html> Dê o nome ao arquivo como hello.html e inicie um servidor no mesmo diretório do arquivo usando a opção -WWW. [user@computador CA-DB]$ openssl s_server -cert vpncert.pem -key vpnkey.pem -WWW Using default temp DH parameters Using default temp ECDH parameters ACCEPT Inicie qualquer browser moderno como o Mozilla Firefox. Entre com a URL na barra de endereço. Note que o protocolo é https e não http: https://localhost:4433/hello.html O navegador vai alertá-lo do fato de não reconhecer o assunto no certificado oferecido pelo servidor. A maioria dos browsers vai deixar você aceitar a autenticidade do certificado do servidor temporariamente para a sessão. Depois de clicar as mensagens de aviso, você deve ver uma página aparecer no navegador. O s_server é uma ferramenta muito útil. Estes testes do OpenSSL permitem ao administrador isolar problemas mais facilmente para uma aplicação em network ou seu suporte a uma infra-estrutura de certificado. Um último passo é criar os parâmetros Diffie Hellman com o comando [user@computador CA-DB]$ openssl dhparam -out dh1024.pem 1024 Generating DH parameters, 1024 bit long safe prime, generator 2 This is going to take a long time ...........+.........................+............................................. ....................................+.........++*++*++* [user@computador CA-DB]$ O OpenVPN tem 2 tipos de operação segura, uma baseada em SSL/TLS, usando certificados e chaves RSA, e outro usando uma chave estática pré-compartilhada. Enquanto que as chaves SSL/TLS + RSA são seguramente a opção mais segura, as chaves estaticas tem a vantagem de serem muito mais simples. Se você deseja usar chaves RSA, leia a seguir. Se você deseja usar chaves estáticas pré-compartilhadas, entre nesta página Gerando a chave estática Pré-Compartilhada. Os certificados RSA são chaves publicas que contém vários campos de segurança, como os campos Common Name ou Email Address. O OpenVPN tem a habilidade de fazer alguns testes para melhorar a segurança. Para mais informações, veja a opção --tls-verify na man page do Openvpn. (em inglês) Os arquivos de chaves privadas devem sempre serem mantidas seguras, já os arquivos de chaves públicas, podem ser livremente publicadas e distribuidas. Modificações no arquivo de configuração do openssl: • Considere aumentar o valor do parametro default_days ou sua VPN irá parar de funcionar misteriosamente após exatamente um ano. • Aponte as opções certificate e private_key para o seu certificado mestre da sua autoridade certificadora e as chaves privadas que iremos gerar. Nos exemplos abaixo, nós iremos assumir que certificado mestre da sua autoridade certificadora se chama cacert.pem e que a chave privada se chama cakey.pem. • Crie os arquivos index.txt e serial. Crie o arquivo index.txt em branco e serial para conter um numero inicial serial, como 01. • Se você for paranóico sobre o tamanho de suas chaves, aumente a opção default_bits para 2048. O OpenVPN não irá ter nenhum problema em trabalhar com uma chave RSA de 2048 bits se você compilou o OpenVPN com suporte a biblioteca pthread, para ativar o suporte do processamento das chaves RSA em background. Você ainda pode usar chaves maiores mesmo sem o suporte a biblioteca pthread, mas você irá ver alguma degradação de performace no tunel durante as negociações das chaves SSL/TLS. Para um bom artigo sobre escolher um tamanho de chave RSA, veja a Edição de Abril de 2002 da Bruce Schneier's Crypto-Gram Newsletter. Crie os parametros Diffie Hellman na maquina do escritório com o comando openssl dhparam -out dh1024.pem 1024 Aumente o numero de bits de 1024 para 2048 se você também o aumentou no arquivo openssl.cnf. Para os paranoicos, considere omitir a opção -nodes nos comandos openssl acima. Isso irá fazer com que cada chave privada seja criptografada com uma senha, fazendo com que suas chaves fiquem seguras se alguem acessar seu servidor e roube suas chaves. O problema dessa opção, é que você irá ter que digitar uma senha toda vez que você rodar o OpenVPN. Para mais informações, veja a opção --askpass na man page do openvpn. (em inglês) Se você achar o gerenciamento manual de chaves RSA, note que o OpenVPN irá trabalhar com qualquer certificado X509 ou serviço incluindo as Autoridades Certificadoras comerciais como Thawte ou Verisign. Veja também o projeto OpenCA como um exemplo do que está sendo feito no mundo do Código Aberto para mudar essa realidade. O OpenVPN também tem um pequeno conjunto de scripts que podem ser usadados para simplificar O gerenciamento de chaves e certificados RSA (em inglês). Nota importante sobre o uso de Autoridades Certificadoras comerciais (CAs) com o OpenVPN Você deve ter percebido que o modelo de seguraça do OpenVPN em modo SSL/TLS é orientado para os usuarios que irão gerar seu proprio certificado raiz e virar seu próprio CA. No modo SSL/TLS, o OpenVPN autentica a outra ponta checando se o certificado fornecido pela outra ponta é assinado pelo certificado da Autoridade Certificadora, que é expecificado com a opção --ca. Como no modelo de seguraça SSL da web, a segurança do OpenVPN em modo SSL/TLS está baseada na dificuldade de se forjar um certificado raiz. Esse tipo de autenticação funciona muito bem se você gerou seu próprio certificado raiz, mas é um problema se você usa o certificado raiz de uma Autoridade Certificadora comercial como a Thawte. Se você por exemplo, colocou o certificado raiz da Thawte na opção --ca, qualquer certificado assinado pela Thawte será capaz de se autenticar com a sua ponta OpenVPN -- uma coisa que você certamente não quer. Felizmente existe uma solução para este problema na opção --tls-verify. Essa opção irá permitir a execução de um comando para checar o conteudo do certificado, para selecionar qual certificado é permitido ou não. Veja o script verify-cn do diretorio sample-scripts para um exemplo de como fazer isso. Também consulte a man page na opção --tls-verify. Criando arquivos de configuração para servidores e clientes Adquirindo os arquivos de configuração A melhor maneira de adquirir os arquivos é no site do OpenVPN em sample configuration files como um ponto de começo para sua própria configuração. Esses arquivos também podem ser econtrados em • diretório sample-config-files da districuição source do OpenVPN • diretório sample-config-files em /usr/share/doc/openvpn/examples/ ou /usr/share/doc/openvpn-2.0 se você instalou de um pacote RPM • Menu Iniciar -> Todos os programas -> OpenVPN -> OpenVPN Sample Configuration Files no Windows Note que no Linux, BSD, ou unix-like OSes, os arquivos de configuração são nomeados como server.conf e client.conf. No Windows eles são nomeados como server.ovpn e client.ovpn. Editando o arquivo de configuração do servidor O arquivo de configuração do servidor é o ponto inicial para uma configuração de servidor do OpenVPN. Ele vai criar uma VPN usando uma interface de network(para roteamento) TUN virtual, vai escutar conexões de clientes na porta UDP 1194 (número de porta oficial do OpenVPN), e distribuir endereços virtuais para clientes conectados da subrede 10.8.0.0/24. Antes de usar esse arquivo de configuração, primeiro você deve editar os parâmetros ca, cert, key, e dh para apontar para os arquivos que você gerou na seção PKI acima. Neste ponto, o arquivo de configuração do servidor é usável, no entanto, você pode customizá-lo ainda mais: • Se você está usando Ethernet bridging, você deve usar server-bridge, dev tapserver e dev tun • Se você quiser que o seu OpenVPN escute na porta TCP em vez da porta UDP, use proto tcp em vez de proto udp (Se você quiser que o OpenVPN escute nas duas portas, TCP e UDP, você deve rodar duas instâncias separadas do OpenVPN). • Se você quiser usar um esquema de IP virtual diferente que o 10.8.0.0/24, você deve modificar a diretiva server. Lembre-se que esse esquema de IP virtual deve ser um esquema privado que não é usado na sua network. • Descomente a diretiva client-to-client se você quiser que clientes conectados possam alcançar outros através da sua VPN. Por padrão, os clientes só serão capazes de alcançar o servidor. • Se você está usando Linux, BSD, ou um OS Unix-like, você pode melhorar a segurança descomentando as diretivas user nobody e group nobody. Se você quer rodar múltiplas instâncias do OpenVPN na mesma máquina, cada uma usando um arquivo de configuração diferente, só é possível se você: • Usar um número de porta diferente para cada instância (os protocolos UDP and TCP usam diferentes espaços de portas. Então, você pode rodar um daemon escutando a UDP-1194 e outro na TCP-1194). • Se você estiver usando Windows, cada configuração do OpenVPN precisa ter sua própria TAP-Win32 adapter. Você pode adicionar adaptadores indo em Menu Iniciar -> Todos os programas -> OpenVPN -> Add a new TAP-Win32 virtual ethernet adapter. • Se você está rodando múltiplas instâncias do OpenVPN no mesmo diretório, tenha certeza de editar as diretivas que criam output files para que as múltiplas instâncias não sobrescrevam cada output file da outra. Estas diretivas incluem log, log-append, status e ifconfig-pool-persist. Editando o arquivo de configuração do cliente O arquivo de configuração do cliente (client.conf no Linux/BSD/Unix ou client.ovpn no Windows) espelha as diretivas padrões setadas no arquivo de configuração do servidor. • Como no arquivo de configuração do servidor, primeiro edite os parâmetros ca, cert, e key para apontar para os arquivos que você gerou na seção PKI acima. Note que cada cliente deve ter seu próprio par certificado/chave. Somente o arquivo ca é universal através do servidor OpenVPN e todos os clientes. • Depois edite a diretiva remote para apontar para o hostname/endereço IP e a porta do servidor OpenVPN (Se o seu servidor OpenVPN estiver rodando em uma máquina single-NIC atrás de um firewall/NAT-gateway, use o endereço de IP público do gateway, e a porta que você configurou o gateway para direcionar para o servidor OpenVPN). • Finalmente, tenha certeza de que o arquivo de configuração do cliente está consistente com as diretivas usadas na configuração do servidor. Os pontos mais a checar se estão consistentes são as diretivas dev (tun ou tap) e proto (udp ou tcp). Também tenha certeza que comp-lzo e fragment, se usados, estão presentes em ambos, cliente e servidor, arquivos de configuração. 4. Teste Configuração de servidor e cliente Um arquivo de configuração diz ao OpenVPN como operar. Existem muitas variações possíveis. Aqui, nós vamos configurar os arquivos do servidor e cliente em separado. Nós queremos que a VPN funcione em um modo de servidor com operação de instância única. Isto permite que todas as conexões de clientes passem pela mesma porta do servidor, e isto deixa a configuração mais simples. O arquivo de configuração do servidor está aqui: ################################################# # Sample OpenVPN 2.0 config file for # # multi-client server. # # # # This file is for the server side # # of a many-clients <-> one-server # # OpenVPN configuration. # # # # OpenVPN also supports # # single-machine <-> single-machine # # configurations (See the Examples page # # on the web site for more info). # # # # This config should work on Windows # # or Linux/BSD systems. Remember on # # Windows to quote pathnames and use # # double backslashes, e.g.: # # "C:\Program Files\OpenVPN\config\foo.key" # # # # Comments are preceded with '#' or ';' # ################################################# # Which local IP address should OpenVPN # listen on? (optional) ;local a.b.c.d # Which TCP/UDP port should OpenVPN listen on? # If you want to run multiple OpenVPN instances # on the same machine, use a different port # number for each one. You will need to # open up this port on your firewall. port 1194 # TCP or UDP server? ;proto tcp proto udp # "dev tun" will create a routed IP tunnel, # "dev tap" will create an ethernet tunnel. # Use "dev tap0" if you are ethernet bridging # and have precreated a tap0 virtual interface # and bridged it with your ethernet interface. # If you want to control access policies # over the VPN, you must create firewall # rules for the the TUN/TAP interface. # On non-Windows systems, you can give # an explicit unit number, such as tun0. # On Windows, use "dev-node" for this. # On most systems, the VPN will not function # unless you partially or fully disable # the firewall for the TUN/TAP interface. ;dev tap dev tun # Windows needs the TAP-Win32 adapter name # from the Network Connections panel if you # have more than one. On XP SP2 or higher, # you may need to selectively disable the # Windows firewall for the TAP adapter. # Non-Windows systems usually don't need this. ;dev-node MyTap # Specify tls-server for certificate exchange tls-server # SSL/TLS root certificate (ca), certificate # (cert), and private key (key). Each client # and the server must have their own cert and # key file. The server and all clients will # use the same ca file. # # See the "easy-rsa" directory for a series # of scripts for generating RSA certificates # and private keys. Remember to use # a unique Common Name for the server # and each of the client certificates. # # Any X509 key management system can be used. # OpenVPN can also use a PKCS #12 formatted key file # (see "pkcs12" directive in man page). ca CA-DB/cacert.pem cert vpncert.pem key vpnkey.pem # This file should be kept secret # Check for revoked client certificates. crl-verify CA-DB/crl/crl.pem# Diffie hellman parameters. # Generate your own with: # openssl dhparam -out dh1024.pem 1024 # Substitute 2048 for 1024 if you are using # 2048 bit keys. dh dh1024.pem # Configure server mode and supply a VPN subnet # for OpenVPN to draw client addresses from. # The server will take 10.8.0.1 for itself, # the rest will be made available to clients. # Each client will be able to reach the server # on 10.8.0.1. Comment this line out if you are # ethernet bridging. See the man page for more info. server 10.8.0.0 255.255.255.0 # Maintain a record of client <-> virtual IP address # associations in this file. If OpenVPN goes down or # is restarted, reconnecting clients can be assigned # the same virtual IP address from the pool that was # previously assigned. ifconfig-pool-persist ipp.txt # Configure server mode for ethernet bridging. # You must first use your OS's bridging capability # to bridge the TAP interface with the ethernet # NIC interface. Then you must manually set the # IP/netmask on the bridge interface, here we # assume 10.8.0.4/255.255.255.0. Finally we # must set aside an IP range in this subnet # (start=10.8.0.50 end=10.8.0.100) to allocate # to connecting clients. Leave this line commented # out unless you are ethernet bridging. ;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100 # Push routes to the client to allow it # to reach other private subnets behind # the server. Remember that these # private subnets will also need # to know to route the OpenVPN client # address pool (10.8.0.0/255.255.255.0) # back to the OpenVPN server. ;push "route 192.168.10.0 255.255.255.0" ;push "route 192.168.20.0 255.255.255.0" # To assign specific IP addresses to specific # clients or if a connecting client has a private # subnet behind it that should also have VPN access, # use the subdirectory "ccd" for client-specific # configuration files (see man page for more info). # EXAMPLE: Suppose the client # having the certificate common name "Thelonious" # also has a small subnet behind his connecting # machine, such as 192.168.40.128/255.255.255.248. # First, uncomment out these lines: ;client-config-dir ccd ;route 192.168.40.128 255.255.255.248 # Then create a file ccd/Thelonious with this line: # iroute 192.168.40.128 255.255.255.248 # This will allow Thelonious' private subnet to # access the VPN. This example will only work # if you are routing, not bridging, i.e. you are # using "dev tun" and "server" directives. # EXAMPLE: Suppose you want to give # Thelonious a fixed VPN IP address of 10.9.0.1. # First uncomment out these lines: ;client-config-dir ccd ;route 10.9.0.0 255.255.255.252 # Then add this line to ccd/Thelonious: # ifconfig-push 10.9.0.1 10.9.0.2 # Suppose that you want to enable different # firewall access policies for different groups # of clients. There are two methods: # (1) Run multiple OpenVPN daemons, one for each # group, and firewall the TUN/TAP interface # for each group/daemon appropriately. # (2) (Advanced) Create a script to dynamically # modify the firewall in response to access # from different clients. See man # page for more info on learn-address script. ;learn-address ./script # If enabled, this directive will configure # all clients to redirect their default # network gateway through the VPN, causing # all IP traffic such as web browsing and # and DNS lookups to go through the VPN # (The OpenVPN server machine may need to NAT # the TUN/TAP interface to the internet in # order for this to work properly). # CAVEAT: May break client's network config if # client's local DHCP server packets get routed # through the tunnel. Solution: make sure # client's local DHCP server is reachable via # a more specific route than the default route # of 0.0.0.0/0.0.0.0. ;push "redirect-gateway" # Certain Windows-specific network settings # can be pushed to clients, such as DNS # or WINS server addresses. CAVEAT: # http://openvpn.net/faq.html#dhcpcaveats />;push "dhcp-option DNS 10.8.0.1" ;push "dhcp-option WINS 10.8.0.1" # Uncomment this directive to allow different # clients to be able to "see" each other. # By default, clients will only see the server. # To force clients to only see the server, you # will also need to appropriately firewall the # server's TUN/TAP interface. ;client-to-client # Uncomment this directive if multiple clients # might connect with the same certificate/key # files or common names. This is recommended # only for testing purposes. For production use, # each client should have its own certificate/key # pair. # # IF YOU HAVE NOT GENERATED INDIVIDUAL # CERTIFICATE/KEY PAIRS FOR EACH CLIENT, # EACH HAVING ITS OWN UNIQUE "COMMON NAME", # UNCOMMENT THIS LINE OUT. ;duplicate-cn # The keepalive directive causes ping-like # messages to be sent back and forth over # the link so that each side knows when # the other side has gone down. # Ping every 10 seconds, assume that remote # peer is down if no ping received during # a 120 second time period. keepalive 10 120 # For extra security beyond that provided # by SSL/TLS, create an "HMAC firewall" # to help block DoS attacks and UDP port flooding. # # Generate with: # openvpn --genkey --secret ta.key # # The server and each client must have # a copy of this key. # The second parameter should be '0' # on the server and '1' on the clients. ;tls-auth ta.key 0 # This file is secret # Select a cryptographic cipher. # This config item must be copied to # the client config file as well. ;cipher BF-CBC # Blowfish (default) ;cipher AES-128-CBC # AES ;cipher DES-EDE3-CBC # Triple-DES # Enable compression on the VPN link. # If you enable it here, you must also # enable it in the client config file. comp-lzo # The maximum number of concurrently connected # clients we want to allow. ;max-clients 100 # It's a good idea to reduce the OpenVPN # daemon's privileges after initialization. # # You can uncomment this out on # non-Windows systems. ;user nobody ;group nobody # The persist options will try to avoid # accessing certain resources on restart # that may no longer be accessible because # of the privilege downgrade. persist-key persist-tun # Output a short status file showing # current connections, truncated # and rewritten every minute. status openvpn-status.log # By default, log messages will go to the syslog (or # on Windows, if running as a service, they will go to # the "\Program Files\OpenVPN\log" directory). # Use log or log-append to override this default. # "log" will truncate the log file on OpenVPN startup, # while "log-append" will append to it. Use one # or the other (but not both). ;log openvpn.log ;log-append openvpn.log # Set the appropriate level of log # file verbosity. # # 0 is silent, except for fatal errors # 4 is reasonable for general usage # 5 and 6 can help to debug connection problems # 9 is extremely verbose verb 3 # Silence repeating messages. At most 20 # sequential messages of the same message # category will be output to the log. ;mute 20 Note que nós usamos a opção dh para especificar o arquivo contendo os parâmetros Diffie-Hellman que nós criamos antes. A opção dh só precisa aparecer no arquivo de configuração do servidor e não no arquivo do cliente. Agora, nós listamos os arquivos contendo os certificados que iremos usar, começando com o root. Finalmente, nós indicamos que queremos que o OpenVPN cheque nossa lista de pedidos de certificado antes de autorizar a conexão a um cliente na nossa rede privada especificando a opção crl-verify e dizendo a lozalização de uma crl. Nós iremos demonstrar a verificação crl depois. O arquivo de configuração do cliente é um pouco mais simples. O único item de configuração que não vimos antes é o pull, que complemente o comandopush "route ..." que nós incluímos no arquivo de configuração do servidor. # openvpn-client.conf # # Set tunnel mode dev tun # Hostname for the VPN server remote [ip_do_servidor] 1194 # This end takes the client role for # certificate exchange tls-client # Certificate Authority file ca cacert.pem # Our certificate/public key cert client1cert.pem # Our private key key client1key.pem # Get the rest of our configuration # from the server. pull O próximo passo é instalar o OpenVPN no cliente. Neste passo, só direi que a instalação do OpenVPN é idêntica à instalação no servidor. Depois de instalado, complete o processo distribuindo os seguintes arquivos para o cliente: • A chave privada do cliente. • O certificado do cliente. • Uma cópia do root certificate (cacert.pem, no nosso exemplo). • O arquivo de configuração do cliente. Antes de iniciar o servidor, nós temos um último passo a realizar. Nós precisamos inicializar a crl. A crl vai ter uma lista de certificados que o nosso CA revogou. Embora nós não tenhamos revogado nenhum certificado ainda, nossa configuração ainda pede ao servidor OpenVPN para checar a crl usando a opção crl-verify na configuração do servidor. Se a nossa VPN não achar uma crl, ela vai terminar de forma prematura. Por enquanto, nós vamos iniciar uma crl vazia. Depois, nós vamos revogar um certificado de usuário e atualizar a crl. Para iniciar a crl simplesmente peça ao CA para gerar uma. (A mensagem oculta começando com DEBUG[load_index] vem de um bug inofensivo nesse release particular do OpenSSL; ignore-o.) [admin@tamarack admin]$ openssl ca -gencrl -out \ > CA-DB/crl/crl.pem Using configuration from /home/admin/install/openssl.cnf Enter pass phrase for /home/admin/CA-DB/private/cakey.pem: DEBUG[load_index]: unique_subject = "yes" [admin@tamarack admin]$ cat CA-DB/crl/crl.pem Agora nós estamos prontos para usar o comando a seguir para iniciar um servidor VPN na nossa rede local. Depois que esse comando for executado, clientes poderão se conectar. [root@tamarack admin]# openvpn --config openvpn-server.conf Depois que o servidor iniciar, tente conectá-lo de um cliente. A linha de comando no cliente é bem similar, mas lembre-se de usar o nome apropriado para o arquivo de configuração. Você deve imdediatamente ser capaz de comunicar através da VPN. Se ocorrer um problema, é hora de descobrir defeitos. Neste caso, você será feliz porque testamos a infra-estrutura dos certificados usando o s_server e s_client , assim, você pode isolar o que estiver errado. Verificando o acesso de cliente contra uma crl A tarefa final aqui é desligar de forma confiante o acesso à VPN de usuários quando nós não queremos que eles conectem à nossa rede. Para fazer isso, nós vamos revogar certificados e atualizar nossa crl. Para descobrir qual certificado pertence a cada cliente, use o arquivo index.txt, localizado no diretório árvore de certificado. Olhe no arquivo e procure o registro contendo o atributo commonName assinado ao certificado a ser revogado (lembre-se que nós estabelecemos uma política de assinar o ID único de cada usuário ao atributo commonName). Esse registro também vai conter o serial number que o CA assinou para este certificado. Tendo identificado o serial number, nós podemos localizar o certificado do cliente dentro de newcerts no nosso diretório CA. Este diretório vai conter uma cópia de cada certificado emitido pelo nosso CA. Os nomes dos arquivos contém os serial numbers assinados a estes certificados. Neste exemplo, nós decidimos revogar o certificado do user3. Depois de ter olhado o index.txt, nós achamos que o serial number assinado ao certificado com o atributo commonName que bate com o user3 é 04. Nós agora sabemos que o certificado correto a revogar é newcerts/04.pem. [admin@tamarack admin]$ openssl ca -revoke \ > CA-DB/newcerts/04.pem Using configuration from /home/admin/install/openssl.cnf Enter pass phrase for /home/admin/CA-DB/private/cakey.pem: DEBUG[load_index]: unique_subject = "yes" Revoking Certificate 04. Data Base Updated [admin@tamarack admin]$ O comando revogou o certificado e atualizou o index.txt appropriadamente. Agora nós precisamos gerar uma nova crl que vai ter este novo certificado revogado. Até nós fazermos isso, o OpenVPN não vai saber que nós revogamos este certificado. [admin@tamarack admin]$ openssl ca -gencrl -out CA-DB/crl/crl.pem Using configuration from /home/admin/install/openssl.cnf Enter pass phrase for /home/admin/CA-DB/private/cakey.pem: DEBUG[load_index]: unique_subject = "yes" [admin@tamarack admin]$ A partir de agora, o user3 não vai ter acesso à VPN, enquanto o OpenVPN checa a crl. Lembre-se, sempre que você for revogar um certificado, tenha certeza de gerar uma nova crl. O OpenSSL também inclui o comando verify, que aceita a opção -crl_check que vai permitir que você tenha certeza que a sua lista de certificados revogados funciona. O comando verify requer que o root certificate e a crl estejam no mesmo arquivo. Antes de você fazer este comando, crie um diretório crl temporário concatenando com o certificado CA. [admin@tamarack admin]$ cat \ > CA-DB/cacert.pem CA-DB/crl/crl.pem > tempcrl.pem Use o comando verify com a opção -crl_check para esecificar a crl a ser usada. Aqui está como verificar a rejeição do certificado do user3. [admin@tamarack admin]$ openssl verify -CAfile tempcrl.pem \ > -crl_check user3cert.pem user3cert.pem: /O=Inyo Technical Services/CN=user3 error 23 at 0 depth lookup:certificate revoked [admin@tamarack admin]$ A fim de tentar isso com sua própria instalação, revogue o certificado que você criou para o cliente da sua VPN e gere uma nova crl. Você vai ver que não é possível conectar ao servidor OpenVPN daquele cliente. Iniciando o VPN e testando-o para conectividade inicial Iniciando o servidor Primeiro, tenha certeza que o servidor OpenVPN estará acessível pela Internet. Isso significa: * abrindo a porta UDP 1194 no firewall (ou qualquer porta TCP/UDP que você configurou), ou * setting up a port forward rule to forward UDP port 1194 from the firewall/gateway to the machine running the OpenVPN server. Depois, tenha certeza de que a interface TUN/TAP não está com o firewall sobre ela. Para simplificar a resolução de problemas, é melhor iniciar o servidor OpenVPN na linha de comando (ou clicar com o botão direito sobre o arquivo .ovpn no Windows), ao invés de iniciar como um daemon ou serviço: openvpn [arquivo de configuração do servidor] Um levantamento de um servidor deveria se parecer com isto(esta saída pode variar entre as plataformas): Sun Feb 6 20:46:38 2005 OpenVPN 2.0_rc12 i686-suse-linux [sSL] [LZO] [EPOLL] built on Feb 5 2005 Sun Feb 6 20:46:38 2005 Diffie-Hellman initialized with 1024 bit key Sun Feb 6 20:46:38 2005 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ] Sun Feb 6 20:46:38 2005 TUN/TAP device tun1 opened Sun Feb 6 20:46:38 2005 /sbin/ifconfig tun1 10.8.0.1 pointopoint 10.8.0.2 mtu 1500 Sun Feb 6 20:46:38 2005 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2 Sun Feb 6 20:46:38 2005 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:23 ET:0 EL:0 AF:3/1 ] Sun Feb 6 20:46:38 2005 UDPv4 link local (bound): [undef]:1194 Sun Feb 6 20:46:38 2005 UDPv4 link remote: [undef] Sun Feb 6 20:46:38 2005 MULTI: multi_init called, r=256 v=256 Sun Feb 6 20:46:38 2005 IFCONFIG POOL: base=10.8.0.4 size=62 Sun Feb 6 20:46:38 2005 IFCONFIG POOL LIST Sun Feb 6 20:46:38 2005 Initialization Sequence Completed Iniciando um cliente Assim como no servidor, é melhor iniciar o OpenVPN pela linha de comando(ou clicar com o botão direito sobre o arquivo .ovpn no Windows), ao invés de iniciar como um daemon ou serviço: openvpn [arquivo de configuração do cliente] Agora, tente executar o comando ping pela VPN no cliente. Se você estiver usando roteamento (dev tun no arquivo de configuração do servidor, por exemplo), tente: ping 10.8.0.1 Se você estiver usando ponteamento (dev tap no arquivo de configuração do servidor, por exemplo), tentar executar o ping no endereço IP de uma máquina na subnet do servidor. Se o ping obtiver sucesso, parabéns! Agora você tem uma VPN funcional. 5. Inicializando com o Sistema Configurando o OpenVPN para rodar automaticamente na inicialização do sistema A falta de padrões nesta área significa que a maioria dos sistemas operacionais tem uma maneira diferente de configurar daemons/services para auto iniciar no boot. A melhor maneira de ter isso funcionalmente configurado por padrão é instalar o OpenVPN como um pacote, como RPM no Linux ou usando o instalador do Windows. Linux Se você instalar o OpenVPN via pacote RPM no Linux, o instalador vai configurar um initscript. Quando executado, o initscript irá escanear por arquivos de configuração .conf em /etc/openvpn, e se encontrado, vai iniciar um daemon separado para cada arquivo .conf do OpenVPN. Inciando a VPN automaticamente no reboot Primeiro crie um diretório para armazenar as chaves e arquivos de coniguração do OpenVPN, como /etc/openvpn. Decida se você vai usar o OpenVPN no modo TLS ou chave estática, e copie os arquivos .conf, .up, .key, .pem, e .crt apropriados para o diretório /etc/openvpn. Proteja seus arquivos .key: chmod go-rwx /etc/openvpn/*.key Se você está usando Linux com iptables, edite o arquivo de configuração do firewall, firewall.sh, fazendo as alterações apropriadas para seu sistema e o copie para o diretório /etc/openvpn. Crie um script de inicialização que se pareça com isso: sample-config-files/openvpn-startup.sh #!/bin/bash # Um exemplo de script de inicialição # do OpenVPN para Linux. # Diretorio de configurações do OpenVPN dir=/etc/openvpn # Carrega o firewall $dir/firewall.sh # Carrega o modulo TUN/TAP modprobe tun # ativa o roteamento de pacotes echo 1 > /proc/sys/net/ipv4/ip_forward # Chama o openvpn para cada tunel VPN # em modo daemon. Você também pode remover # a opção "--daemon" da linha de comando # e adicionar a opção "daemon" ao arquivo # de configuração. # # Cada tunel deve rodar em uma porta UDP # separada. Use a opção "port" para controlar # isso. Como todas as opções do OpenVPN, você # pode especificar "--port 8000" na linha de # comando, ou "port 8000" no arquivo de configuração. openvpn --cd $dir --daemon --config vpn1.conf openvpn --cd $dir --daemon --config vpn2.conf openvpn --cd $dir --daemon --config vpn2.conf E crie um script de desligamento como esse: sample-config-files/openvpn-shutdown.sh #!/bin/bash # para com todos os processos do OpenVPN killall -TERM openvpn Finalmente, adicione chamadas para openvpn-startup.sh e openvpn-shutdown.sh para os scripts de inicio e desligamento de seu sistema, ou no diretório /etc/init.d. Gerenciando o inicio e desligamento de varios túneis OpenVPN Aqui está um examplo de um script do /etc/init.d que irá automaticamente iniciar um processo do OpenVPN para cada arquivo .conf que for encontrado no diretório /etc/openvpn. Esse script é instalado por padrão quando você instala o OpenVPN via um pacote RPM. (N.T: Devido a problemas com quebra de linha, é recomendavel que você copie esse script da distribuição do OpenVPN) sample-scripts/openvpn.init #!/bin/sh # # openvpn Este shell script cuida do inicio e finalização # do openvpn no RedHat ou em outro sistema baseado # no chkconfig. # # chkconfig: 345 80 30 # # description: OpenVPN é um programa robusto e flexivel para tunelamento que # usa toda as funcionalidades de encriptação, autenticação e certificação # que a biblioteca OpenSSL fornece, para tunelar seguramente redes IP atraves # de uma simples porta UDP. # # Contribuido para o projeto OpenVPN por # Douglas Keller <doug@voidstar.dyndns.org> # 2002.05.15 # Para instalar: # copie este arquivo para /etc/rc.d/init.d/openvpn # shell> chkconfig --add openvpn # shell> mkdir /etc/openvpn # crie .conf ou .sh files em /etc/openvpn (veja abaixo) # Para desinstalar: # execute: chkconfig --del openvpn # Notas do autor: # # Eu criei um init script em /etc/init.d e alterei o openvpn.spec para automaticamente # registrar o script. Uma vez que o RPM está instalado você pode iniciar e parar # o OpenVPN com "service openvpn start" e "service openvpn stop". # # Esse init script faz o seguinte: # # - Inicia um processo OpenVPN para cada arquivo .conf que ele encontra em /etc/openvpn # # - Se /etc/openvpn/xxx.sh existe para um arquivo xxx.conf então ele o executa # antes de iniciar o OpenVPN (util para fazer openvpn --mktun...). # # - Alem de start/stop você também pode: # # service openvpn reload - SIGHUP # service openvpn reopen - SIGUSR1 # service openvpn status - SIGUSR2 # Modificações 2003.05.02 # * Alterado '==' para '=' para compatibilidade com sh (Bishop Clark). # * Se condrestart|reload|reopen|status, checa se já não está iniciado (James Yonan). # * Adicionado lock, piddir, e work variaveis (James Yonan). # * Se o start é tentado 2 vezes, sem a intervenção de um stop, ou # se start é tentado quando o start anterior não foi bem sucessedido # ele mata qualquer outro processo antes de começar uma nova operação (James Yonan). # * Faz um trabalho melhor de detecção de erros no start, retornando sucesso ou falha (James Yonan). # Localização do binário do OpenVPN openvpn="/usr/sbin/openvpn" # Arquivo de trava lock="/var/lock/subsys/openvpn" # Diretorio de PID piddir="/var/run/openvpn" # Diretório de trabalho work=/etc/openvpn # Código da biblioteca de função. . /etc/rc.d/init.d/functions # Código da configuração de rede. . /etc/sysconfig/network # Checa se a rede está ativa. [ ${NETWORKING} = "no" ] && exit 0 [ -f $openvpn ] || exit 0 # Ve como nós fomos chamados. case "$1" in start) echo -n $"Starting openvpn: " /sbin/modprobe tun >/dev/null 2>&1 # A partir de uma perspectiva segura, eu acho que faz # sentido remover isso, e forçar os usuarios que precisam disso # a ativar explicitamente em seus scripts --up ou nas configurações # de firewall. #echo 1 > /proc/sys/net/ipv4/ip_forward if [ ! -d $piddir ]; then mkdir $piddir fi if [ -f $lock ]; then # nós não fomos desligados corretamente for pidf in /bin/ls $piddir/*.pid 2>/dev/null; do if [ -s $pidf ]; then kill at $pidf >/dev/null 2>&1 fi rm -f $pidf done rm -f $lock sleep 2 fi rm -f $piddir/*.pid cd $work # Inicia cada .conf em $work e executa .sh se existe errors=0 successes=0 for c in /bin/ls *.conf 2>/dev/null; do bn=${c%%.conf} if [ -f "$bn.sh" ]; then . $bn.sh fi rm -f $piddir/$bn.pid $openvpn --daemon --writepid $piddir/$bn.pid --config $c --cd $work if [ $? = 0 ]; then successes=1 else errors=1 fi done if [ $errors = 1 ]; then failure; echo else success; echo fi if [ $successes = 1 ]; then touch $lock fi ;; stop) echo -n $"Shutting down openvpn: " for pidf in /bin/ls $piddir/*.pid 2>/dev/null; do if [ -s $pidf ]; then kill at $pidf >/dev/null 2>&1 fi rm -f $pidf done success; echo rm -f $lock ;; restart) $0 stop sleep 2 $0 start ;; reload) if [ -f $lock ]; then for pidf in /bin/ls $piddir/*.pid 2>/dev/null; do if [ -s $pidf ]; then kill -HUP at $pidf >/dev/null 2>&1 fi done else echo "openvpn: service not started" exit 1 fi ;; reopen) if [ -f $lock ]; then for pidf in /bin/ls $piddir/*.pid 2>/dev/null; do if [ -s $pidf ]; then kill -USR1 at $pidf >/dev/null 2>&1 fi done else echo "openvpn: service not started" exit 1 fi ;; condrestart) if [ -f $lock ]; then $0 stop # avoid race sleep 2 $0 start fi ;; status) if [ -f $lock ]; then for pidf in /bin/ls $piddir/*.pid 2>/dev/null; do if [ -s $pidf ]; then kill -USR2 at $pidf >/dev/null 2>&1 fi done echo "Status written to /var/log/messages" else echo "openvpn: service not started" exit 1 fi ;; *) echo "Usage: openvpn {start|stop|restart|condrestart|reload|reopen|status}" exit 1 esac exit 0 6. Como adicionar novas máquinas a VPN Adicionando novas máquinas à VPN tanto para servidor e cliente. Incluindo múltiplas máquinas no servidor usando uma VPN roteada (dev tun) Uma vez que você tenha uma VPN operacional de ponta a ponta entre cliente e servidor, você deve desejar expandir o escopo da VPN para que clientes atinjam múltiplas máquinas na rede do servidor, em vez de atingir apenas o servidor. Para o propósito deste exemplo, nós vamos assumir que a LAN do servidor usa uma subrede 10.66.0.0/24 e que o endereço de IP da VPN use 10.8.0.0/24 como citado na diretiva no arquivo de configuração do servidor OpenVPN. Primeiramente, você deve mandar a subrede 10.66.0.0/24 ser acessível a clientes atraves da VPN. Isto pode ser facilmente realizado com a seguinte diretiva no arquivo de configuração do servidor: push "route 10.66.0.0 255.255.255.0" Depois, você deve setar um roteamento na gateway da LAN para rotear a subrede do cliente VPN (10.8.0.0/24) ao servidor OpenVPN (isto só é necessário se o servidor OpenVPN e o gateway da LAN estão em máquinas diferentes). Incluindo múltiplas máquinas usando uma VPN ponteada (dev tap) Um dos benefícios de se usar ponteamento em ethernet é que você tenha isto de graça sem precisar de configuração adicional. Incluindo múltiplas máquinas no cliente usando uma VPN roteada (dev tun) Num ambiente típico de acesso remoto, a máquina cliente conecta à VPN como uma única máquina. Mas suponha que a máquinha cliente seja um gateway para uma LAN local, e que você queira que cada máquina na LAN cliente seja capaz de rotear através da VPN. Para este exemplo, nós iremos assumir que a LAN cliente esteja usando uma subrede 192.168.4.0/24, e que o cliente VPN esteja usando um certificado com um common name de client2. Nosso objetivo é configurar a VPN para que qualquer máquinha na LAN cliente possa comunicar com qualquer máquina na LAN do servidor através da VPN. Antes de configurar, há alguns pré-requisitos básicos que devem ser seguidos: * A subrede da LAN cliente (192.168.4.0/24 no nosso exemplo) deve ser exportada à VPN pelo servidor ou qualquer outro cliente que esteja usando a mesma subrede. Toda subrede que seja usada na VPN deve ser única. * O cliente deve ter um único Common Name em seu certificado (client2" no nosso exemplo), e a flag duplicate-cn não deve ser usada no arquivo de onfiguração do servidor OpenVPN. Depois, nós vamos lidar com mudanças necessárias na configuração do servidor. Se o arquivo de configuração do servidor não referencia um diretório para clientes, adicione uma referência agora: client-config-dir ccd Na diretiva acima, ccd deve ser o nome para o diretório que tenha sido pré-criado no diretório padrão onde o daemon do servidor OpenVPN roda. No Linux esse diretório tende a ser /etc/openvpn e no Windows é usualmente \Program Files\OpenVPN\config. Quando um novo cliente se conecta ao servidor OpenVPN, o daemon vai checar este diretório por um arquivo que associe o common name do cliente. Se este arquivo for achado, ele vai ser lido e processado para configurações de diretivas de arquivo adicionais a serem aplicadas ao cliente nomeado. O próximo passo é criar um arquivo chamado client2 no diretório ccd. Este arquivo deve conter a linha: iroute 192.168.4.0 255.255.255.0 Ela vai dizer ao servidor OpenVPN que a subrede 192.168.4.0/24 deve ser roteada para o client2. Depois, adicione a seguinte linha ao arquivo mestre de configuração do servidor (não o ccd/client2): route 192.168.4.0 255.255.255.0 Você deve se perguntar: Por que os estamentos redundantes de route e iroute? A razão é que route controla o roteamento do kernel ao servidor OpenVPN (via interface TUN) enquanto o iroute controla o roteamento do servidor OpenVPN a clientes remotos. Ambos são necessários. Próximo, pergunte a você mesmo se você quer permitir tráfico de rede entre a subrede do client2 (192.168.4.0/24) e outros clientes do servidor OpenVPN. Se sim, adicione a seguinte linha ao arquivo de configuração do servidor. client-to-client push "route 192.168.4.0 255.255.255.0" Isto vai fazer o servidor OpenVPN conectar a subrede do client2 a outros clientes conectados à VPN. O último passo, e um que é freqüentemente esquecido, é adicionar um roteador para o gateway da LAN do servidor que direcione 192.168.4.0/24 à máquina do servidor OpenVPN (você não precisa disto se a máquina do servidor OpenVPN é o gateway para a LAN do servidor). Suponha que você se esqueceu deste passo e você tenha tentado pingar uma máquina (sem ser o servidor OpenVPN) na LAN do servidor com endereço 192.168.4.8. O ping vai sair e provavelmente atingir a máquina, mas essa máquina não vai saber como rotear a resposta do ping, porque ela não tem idéia de como atingir 192.168.4.0/24. Similarmente, se a máquina do cliente rodando o OpenVPN não seja o gateway para a LAN do cliente, então o gateway para a LAN do cliente deve ter um roteamento que direcione todas as subredes que deveriam ser atingidas através da VPN para a máquina cliente OpenVPN. Incluindo múltiplas máquinas ao cliente usando uma VPN ponteada (dev tap) Isto exige uma configuração mais complexa (talvez não tão complicada em prática, mas complicada de ser explicada com detalhes). 7. Publicando opções de DHCP Fazendo o OpenVPN compatível com DHCP Em nosso exemplo acima, o gateway de casa tem um endereço IP dinamico que pode mudar sem qualquer aviso. Se você usa o dhcpcd como seu cliente dhcp, é facil contruir um script que pode ser executado qualquer hora que o endereço IP mudar. O script ficaria em algum lugar como /etc/dhcpc/dhcpcd-eth0.exe. Basicamente, você deve adicionar uma linha neste script que iria mandar um sinal SIGUSR1 ou SIGHUP para o daemon OpenVPN. Seria algo como: killall -HUP openvpn Quando o OpenVPN recebe este sinal, ele irá fechar e re-abrir a conecxão de rede com a outra ponta, usando o novo endereço IP designado pelo servidor DHCP. Você também deve usar a opção --float se você está conectando a uma ponta que está sucetivel a mudanças de IP pelo servidor DHCP. Também é possivel trabalhar com trocas de IP com o sinal SIGUSR1 que é como o sinal SIGHUP exceto que ele oferece um controle melhor dos sub-sistemas do OpenVPN que ele reseta. O sinal SIGUSR1 também pode ser gerado internamente baseado nas opções --ping e --ping-restart. A opção --persist-tun permite um reset sem fechar e abrir o device TUN (que permite que conexões via vpn não se percam, mesmo durante uma troca de IP). A opção --persist-remote-ip permite a preservação do endereço IP remoto, mesmo durante uma troca de IP. Isso permite que ambas as pontas da VPN sejam clientes DHCP. A opção --persist-key não re-lê as chaves durante o restart (o que permite ao daemon OpenVPN ser reiniciado mesmo se seus privilégios forem diminuidos com --user ou --group). Para mais informações sobre como usar o OpenVPN em um endereço dinamico, veja o FAQ. Publicando opções DHCP para clientes O servidor OpenVPN pode publicar opções de DHCP como servidor de endereço DNS e WINS para clientes. Clientes no Windows podem aceitar DHCP publicado nativamente, enquanto clientes não-Windows podem aceitá-las usando um script up que analisa a lista de variáveis ambiente. Veja a man page ou openvpn-users mailing list archive mais informações e exemplos de scripts. Por exemplo, suponha que você queira que clientes conectados usem um servidor DNS interno em 10.66.0.4 ou 10.66.0.5 e um servidor WINS em 10.66.0.8. Adicione esta linha ao arquivo de configuração do servidor OpenVPN: push "dhcp-option DNS 10.66.0.4" push "dhcp-option DNS 10.66.0.5" push "dhcp-option WINS 10.66.0.8" Para testar isto no Windows, roda a seguinte linha de comando no prompt depois que a máquina esteja conectada a um servidor OpenVPN: ipconfig /all Este comando deve dar de saída as opções DHCP oferecidas pelo servidor. Fonte: Cursos cdtc

boas, tou com um "pequeno" problema: ao tentar criar uma rede vpn através do assistente do windows xp clico no primeiro "seguinte", selecciono a opção "ligar a rede do meu local de trabalho" e na janela seguinte as opções aparecem desactivadas... alguem me consegue ajudar??

Titulo do Projecto: VpnManager Líder do Projecto: inginheiiro Descrição: fiz uma app (muito especifica) para gerir um cliente ligado a um servidor VPN com ICMP activo. É necessário o .NET Framework 2.0 http://bragatel.pt/coredump/VpnManager.zip

Estou a tentar criar servidores VPN. Estou a experimentar dois sistemas Linux Centos: http://cleaninglda.no-ip.info:8080'>http://cleaninglda.no-ip.info:8080 Fedora Core 6 : http://cleaninglda.no-ip.info Já experimentei o openvpn mas não consegui. Alguém tem um guia detalhado para o centos ?

Olá a todos. preciso de instalar uma cliente vpn no kubuntu. Alguém sabe de algum software free.