Product SiteDocumentation Site

10.2. Rede Privada Virtual

Uma Rede Privada Virtual (ou VPN, de Virtual Private Network) é uma forma de conectar duas redes locais diferentes através de um túnel pela internet; o túnel é normalmente criptografado para confidencialidade. VPNs são em geral usadas para integrar uma máquina remota numa rede local de uma empresa.
Várias ferramentas fornecem isto. O OpenVPN é uma solução eficiente, fácil de publicar e manter, baseado em SSL/TLS. Outra possibilidade é usar o IPsec para criptografar o tráfego IP entre duas máquinas; esta criptografia é transparente, o que significa que aplicações rodando nestas máquinas não precisam ser modificadas para serem compatíveis com VPN. SSH também pode ser usado para fornecer uma VPN, adicionalmente às suas funcionalidades mais convencionais. Finalmente, uma VPN pode ser estabelecida usando o protocolo PPTP da Microsoft. Outras soluções existem, mas estão além do escopo deste livro.

10.2.1. OpenVPN

O OpenVPN é um pedaço de software dedicado a criar redes virtuais privadas. Sua configuração envolve a criação de interfaces de rede virtual em um servidor VPN e no(s) cliente(s); ambas interfaces tun (para túneis IP-level) e tap (para túneis Ethernet-level) são suportadas. Na pratica, a interface tun irá geralmente ser a mais usada, excerto quando os clientes VPN forem feitos para serem integrados na rede local do servidor por meio de uma ponte (brigde) Ethernet.
O OpenVPN depende do OpenSSL para criptografia SSL/TLS e funcionalidades associadas (confidencialidade, autenticação, integridade, não-repudio). Ele pode ser configurado tanto com uma chave privada compartilhada, como usando um certificado X.509 baseado em uma infraestrutura de chave pública. Essa última configuração é fortemente preferida já que permite grande flexibilidade quando lida com um crescente número de usuários "roaming" acessando a VPN.

CULTURA SSL e TLS

O protocolo SSL (Secure Socket Layer) foi inventado pela Netscape para dar segurança nas conexões com servidores web. Ele foi, depois, padronizado pela IETF sob o acrônimo TLS (Transport Layer Security). Desde então o TLS continuou a evoluir e hoje em dia o SSL está depreciado devido a múltiplas falhas de projeto que tem sido descobertas.

10.2.1.1. Infraestrutura de Chaves Públicas: easy-rsa

O algorítimo RSA é amplamente usado em criptografia de chave pública. Trata-se de um “par de chaves”, composto de uma chave privada e uma chave pública. As duas chaves são intimamente ligadas uma a outra, e suas propriedades matemáticas são tais que uma mensagem criptografada com a chave pública só pode ser descriptografada por alguém que conhece a chave privada, o que garante confidencialidade. Na direção oposta, uma mensagem criptografada com a chave privada pode ser descriptografada por qualquer um que saiba a chave pública, o que permite autenticar a origem da mensagem já que apenas alguém com acesso a chave privada poderia gerá-la. Quando associada a uma função digital hash (MD5, SHA1, ou uma variante mais recente), isso leva a um mecanismo de assinatura que pode ser aplicado a qualquer mensagem.
Contudo, qualquer um pode criar um par de chaves, armazenar qualquer identidade nele, e fingir ser a identidade de sua escolha. Uma solução envolve o conceito de uma Certification Authority (CA), formalizado pelo padrão X.509. Esse termo cobre uma entidade que possui um par de chaves confiável conhecido como um root certificate. Esse certificado só é usado para assinar outros certificados (par de chaves), após os passos apropriados terem sido tomados para checar a identidade armazenada no par de chaves. Aplicações usando o X.509 podem então checar os certificados apresentados a elas, se elas souberem sobre os root certificates confiáveis.
O OpenVPN segue essa regra. Como CAs públicos apenas emitem certificados em troca de uma (pesada) taxa, também é possível criar um certificado de autoridade privado dentro da companhia. O pacote easy-rsa provê ferramentas que servem como uma infraestrutura de certificação X.509, implementada como um conjunto de scripts usando o comando openssl.

NOTE easy-rsa antes da Jessie

Em versões do Debian até o Wheezy, o easy-rsa era distribuido com parte do pacote openvpn, e seus scripts eram para ser encontrados em /usr/share/doc/openvpn/examples/easy-rsa/2.0/. A criação de um CA envolvia a cópia desse diretório, ao invéz de usar o comando make-cadir como documentado aqui.
os adminitradores da Falcot Corp usam essa ferramenta para criar os certificados necessários, tanto para servidor quanto para clientes. Isso permite que a configuração de todos os clientes sejam similar já que eles apenas terão de ser configurados para confiar em certificados vindos da CA local daFalcot. Esse CA é o primeiro certificado a ser criado; para esse fim, os administradoresconfiguram um diretório com os arquivos necessários para o CA em um local apropriado, preferencialmente em uma máquina não conectada a rede, de maneira a mitigar o risco da chave privada CA ser roubada. 
$ make-cadir pki-falcot
$ cd pki-falcot
Eles então armazenam os parâmetros requeridos dentro do arquivo vars, especialmente aqueles nomeados com o prefixo KEY_; essas variáveis são então integradas ao ambiente: 
$ vim vars
$ grep KEY_ vars
export KEY_CONFIG=`$EASY_RSA/whichopensslcnf $EASY_RSA`
export KEY_DIR="$EASY_RSA/keys"
echo NOTE: If you run ./clean-all, I will be doing a rm -rf on $KEY_DIR
export KEY_SIZE=2048
export KEY_EXPIRE=3650
export KEY_COUNTRY="FR"
export KEY_PROVINCE="Loire"
export KEY_CITY="Saint-Étienne"
export KEY_ORG="Falcot Corp"
export KEY_EMAIL="admin@falcot.com"
export KEY_OU="Certificate authority"
export KEY_NAME="Certificate authority for Falcot Corp"
# If you'd like to sign all keys with the same Common Name, uncomment the KEY_CN export below
# export KEY_CN="CommonName"
$ . ./vars
NOTE: If you run ./clean-all, I will be doing a rm -rf on /home/roland/pki-falcot/keys
$ ./clean-all
O próximo passo é a criação do próprio par de chaves CA (as duas partes do par de chaves será armazenada sob keys/ca.crt e keys/ca.key durante esse passo): 
$ ./build-ca
Generating a 2048 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) [FR]:
State or Province Name (full name) [Loire]:
Locality Name (eg, city) [Saint-Étienne]:
Organization Name (eg, company) [Falcot Corp]:
Organizational Unit Name (eg, section) [Certificate authority]:
Common Name (eg, your name or your server's hostname) [Falcot Corp CA]:
Name [Certificate authority for Falcot Corp]:
Email Address [admin@falcot.com]:
O certificado para o servidor VPN pode, agora, ser criado, assim como os parâmetros Diffie-Hellman necessários para o lado do servidor em uma conexão SSL/TLS. O servidor VPN é identificado pelo seu nome DNS vpn.falcot.com; esse nome é reutilizado nos arquivos de chave gerados (keys/vpn.falcot.com.crt para certificado público, keys/vpn.falcot.com.key para chave privada): 
$ ./build-key-server vpn.falcot.com
Generating a 2048 bit RSA private key
.....................................................................................................................+++
...........+++
writing new private key to 'vpn.falcot.com.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) [FR]:
State or Province Name (full name) [Loire]:
Locality Name (eg, city) [Saint-Étienne]:
Organization Name (eg, company) [Falcot Corp]:
Organizational Unit Name (eg, section) [Certificate authority]:
Common Name (eg, your name or your server's hostname) [vpn.falcot.com]:
Name [Certificate authority for Falcot Corp]:
Email Address [admin@falcot.com]:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /home/roland/pki-falcot/openssl-1.0.0.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'FR'
stateOrProvinceName   :PRINTABLE:'Loire'
localityName          :T61STRING:'Saint-\0xFFFFFFC3\0xFFFFFF89tienne'
organizationName      :PRINTABLE:'Falcot Corp'
organizationalUnitName:PRINTABLE:'Certificate authority'
commonName            :PRINTABLE:'vpn.falcot.com'
name                  :PRINTABLE:'Certificate authority for Falcot Corp'
emailAddress          :IA5STRING:'admin@falcot.com'
Certificate is to be certified until Mar  6 14:54:56 2025 GMT (3650 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
$ ./build-dh
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
[…]
O próximo passo cria certificados para os clientes VPN; um certificado é necessário para cada computar ou pessoa ser autorizada a usar a VPN: 
$ ./build-key JoeSmith
Generating a 2048 bit RSA private key
................................+++
..............................................+++
writing new private key to 'JoeSmith.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) [FR]:
State or Province Name (full name) [Loire]:
Locality Name (eg, city) [Saint-Étienne]:
Organization Name (eg, company) [Falcot Corp]:
Organizational Unit Name (eg, section) [Certificate authority]:Development unit
Common Name (eg, your name or your server's hostname) [JoeSmith]:Joe Smith
[…]
Agora que todos os certificados foram criados, eles precisam ser copiados para um local apropriado: a chave pública do root certificate (keys/ca.crt) será armazenada em todas as máquinas (tanto servidor quanto clientes) como /etc/ssl/certs/Falcot_CA.crt. O certificado do servidor é instalado apenas no servidor (keys/vpn.falcot.com.crt vai para /etc/ssl/vpn.falcot.com.crt, e keys/vpn.falcot.com.key vai para /etc/ssl/private/vpn.falcot.com.key com restritivas permissões para que apenas o administrador possa lê-la), com os parâmetros Diffie-Hellman correspondentes (keys/dh2048.pem) instalados em /etc/openvpn/dh2048.pem. Certificados do clientes são instalados no cliente VPN correspondente de maneira similar.

10.2.1.2. Configurando o Servidor OpenVPN

Por padrão, o script de inicialização do OpenVPN tenta iniciar todas as redes virtuais privadas definidas em /etc/openvpn/*.conf. A configuração de um servidor VPN é portanto uma questão de armazenar o arquivo de configuração correspondente neste diretório. Um bom ponto de partida é o /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz, que orienta em como ter um servidor padrão. Claro que alguns parâmetros precisam ser adaptados: ca, cert, key e dh precisam descrever as localizações selecionadas (respectivamente, /etc/ssl/certs/Falcot_CA.crt, /etc/ssl/vpn.falcot.com.crt, /etc/ssl/private/vpn.falcot.com.key e /etc/openvpn/dh2048.pem). A diretiva server 10.8.0.0 255.255.255.0 define a sub-rede a ser usada pela VPN; o servidor usa o primeiro endereço IP nesse intervalo (10.8.0.1) e o resto dos endereços são alocados para os clientes.
Com essa configuração, ao iniciar o OpenVPN, é criada uma interface de rede virtual, usualmente sob o nome de tun0. Contudo, firewalls são geralmente configurados ao mesmo tempo que interfaces de rede reais, o que acontece antes do OpenVPN ser iniciado. A boa prática então recomenda a criação de uma interface de rede virtual persistênte, e configurara o OpenVPN a usar essa pré-existente interface. Isso inclusive permite a escolha do nome dessa interface. Para esse fim, openvpn --mktun --dev vpn --dev-type tun cria uma interface de rede virtual de nome vpn do tipo tun; esse comando pode ser facilmente integrado ao script de configuração do firewall, ou na diretiva up do arquivo /etc/network/interfaces. O arquivo de configuração do OpenVPN deve também ser atualizado em conformidade com as diretivas dev vpn e dev-type tun.
Salvo ações posteriores, clientes VPN só podem acessar o próprio servidor VPN pelo caminho do endereço 10.8.0.1. Permitir que os clientes acessem a rede local (192.168.0.0/24) requer a adição da diretiva push route 192.168.0.0 255.255.255.0 na configuração do OpenVPN para que os clientes VPN automaticamente recebam o roteamento dizendo a eles que essa rede é alcançável através da VPN. Além do mais, máquinas na rede local também precisam ser informadas que a rota para a VPN passa pelo servidor VPN (isso funciona de maneira automática quando o servidor VPN é instalado no gateway). Alternativamente, o servidor VPN pode ser configurado para desempenhar um mascaramento IP, e assim as conexões vidas de clientes VPN aparecem com se elas viessem do servidor VPN (see Seção 10.1, “Gateway”).

10.2.1.3. Configurando o Cliente OpenVPN

Configurar um cliente OpenVPN também requer a criação de um arquivo de configuração em /etc/openvpn/. Uma configuração padrão pode ser obtida usando /usr/share/doc/openvpn/examples/sample-config-files/client.conf como ponto de partida. A diretiva remote vpn.falcot.com 1194 descreve o endereço e porta do servidor OpenVPN; ca, cert and key também precisam ser adaptadas para descrever a localização dos arquivos com as chaves.
Se a VPN não deve ser iniciadas automaticamente na inicialização, configure a diretiva AUTOSTART para none no arquivo /etc/default/openvpn. Iniciar ou parar uma determinada conexão VPN é sempre possível com os comandos service openvpn@name start and service openvpn@name stop (aonde a conexão nome casa com uma definida em /etc/openvpn/nome.conf).
O pacote network-manager-openvpn-gnome contém uma extensão para o Network Manager (see Seção 8.2.5, “Configuração Automática de Rede para Usuários em Roaming”) que permite o gerenciamento de redes virtuais privadas OpenVPN. Isso permite que todo usuário configure e controle as conexões OpenVPN graficamente através do ícone de gerenciamento de redes.

10.2.2. Rede Privada Virtual com SSH

Existem, na verdade, duas maneiras de criar uma rede virtual privada com SSH. A mais antiga envolve estabelecer uma camada PPP sobre uma ligação SSH. Esse método é descrito em um documento HOWTO:
→ http://www.tldp.org/HOWTO/ppp-ssh/
O segundo método é mais recente, e foi introduzido no OpenSSH 4.3; agora é possível para o OpenSSH criar interfaces de rede virtual (tun*) nos dois lados de uma conexão SSH, e essas interfaces virtuais podem ser configuradas exatamente como se elas fossem interfaces físicas. O sistema de túnel ("tunneling") deve ser primeiro ativado configurando PermitTunnel como “yes” no arquivo de configuração do servidor SSH (/etc/ssh/sshd_config). Ao estabelecer uma conexão SSH, a criação de um túnel deve ser explicitamente requisitada com a opção -w any:any (any pode ser substituída pelo desejado número de dispositivo tun). Isso requer que o usuário tenha privilégios de administrador nos dois lados, assim como ser capaz de criar o dispositivo de rede (em outras palavras, a conexão deve ser estabelecida como root).
Ambos os métodos para criação de rede virtual privada pelo SSH são bem simples. Contudo, a VPN que eles implementam não é a mais eficiente disponível, em particular, ela não lida muito bem com elevados níveis de tráfego.
A explicação é que quando uma pilha TCP/IP é encapsulada dentro de uma conexão TCP/IP (para SSH), o protocolo TCP é usado duas vezes, uma vez para a conexão SSH e outra dentro do túnel. Isso leva a problemas, especialmente devido ao modo o TCP se adaptar as condições da rede, alterando os atrasos de "timeout". O seguinte sítio descreve o problema mais detalhadamente:
→ http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
VPNs sobre SSH deve portanto ser restrita a "one-off tunnels" sem restrições de desempenho.

10.2.3. IPsec

O IPsec, apesar de ser o padrão em VPNs IP, é um pouco mais envolvido em sua implementação. O próprio mecanismo IPsec é integrado no núcleo Linux; as partes do espaço usuário necessárias, as ferramentas de controle e configuração, são fornecidas pelo pacote ipsec-tools. Em termos concretos, o /etc/ipsec-tools.conf de cada máquina contém os parâmetros para os túneis IPsec (ou Security Associations, na terminologia IPsec) que o hospedeiro se preocupa; o script /etc/init.d/setkey fornece uma maneira para iniciar e parar um túnel (cada túnel é uma ligação segura para outra máquina conectada a rede virtual privada). Esse arquivo pode ser construído manualmente a partir da documentação fornecida pela página de manual setkey(8). Contudo, escrever explicitamente os parâmetros para todas as máquinas em um conjunto não-trivial de máquinas rapidamente se torna uma tarefa árdua, já que o número de túneis cresce rápido. Instalar um daemon IKE (para IPsec Key Exchange) como o racoon ou strongswan torna o processo muito mais simples, por reunir a administração em um ponto central, e mais seguro por rotacionar as chaves periodicamente.
Apesar do seu status como referência, a complexidade de criação de IPsec restringe seu uso na prática. As soluções baseadas em OpenVPN irão geralmente ser preferidas quando os necessários túneis não forem muitos ou não forem muito dinâmicos.

ATENÇÃO IPsec e NAT

IPsec e Firewalls que fazem NAT não funcionam bem juntos: como o IPsec assina os pacotes, qualquer alteração nesses pacotes que o firewall possa a vir fazer irá anular essa assinatura, e assim, os pacotes serão rejeitados em seu destino. Várias implementações incluem agora a técnica NAT-T (para NAT Traversal), o que basicamente encapsula o pacote IPsec dentro de um pacote UDP padrão.

SEGURANÇA IPsec e firewalls

O modo padrão de operação do IPsec envolve troca de dados pela porta UDP 500 para troca de chave (também pela porta UDP 4500 para o caso que o NAT-T esteja em uso). Além disso, os pacotes IPsec usam dois protocolos IP dedicados que o firewall tem que deixar passar; a recepção desses pacotes é baseada nos seus números de protocolo, 50 (ESP) e 51 (AH).

10.2.4. PPTP

PPTP (Point-to-Point Tunneling Protocol) usa dois canais de comunicação, um para controlar dados e um para dados de carga útil (payload); o último usa o protocolo GRE (Generic Routing Encapsulation). Um link PPP padrão é então configurado sobre o canal de troca de dados.

10.2.4.1. Configurando o Cliente

O pacote pptp-linux contém um cliente PPTP para Linux fácil de configurar. As instruções a seguir foram inspiradas na documentação oficial:
→ http://pptpclient.sourceforge.net/howto-debian.phtml
Os administradores da Falcot criaram vários arquivos: /etc/ppp/options.pptp, /etc/ppp/peers/falcot, /etc/ppp/ip-up.d/falcot, e /etc/ppp/ip-down.d/falcot.

Exemplo 10.2. O arquivo /etc/ppp/options.pptp

# PPP options used for a PPTP connection
lock
noauth
nobsdcomp
nodeflate

Exemplo 10.3. O arquivo /etc/ppp/peers/falcot

# vpn.falcot.com is the PPTP server
pty "pptp vpn.falcot.com --nolaunchpppd"
# the connection will identify as the "vpn" user
user vpn
remotename pptp
# encryption is needed
require-mppe-128
file /etc/ppp/options.pptp
ipparam falcot

Exemplo 10.4. O arquivo /etc/ppp/ip-up.d/falcot

# Create the route to the Falcot network
if [ "$6" = "falcot" ]; then
  # 192.168.0.0/24 is the (remote) Falcot network
  route add -net 192.168.0.0 netmask 255.255.255.0 dev $1
fi

Exemplo 10.5. O arquivo /etc/ppp/ip-down.d/falcot

# Delete the route to the Falcot network
if [ "$6" = "falcot" ]; then
  # 192.168.0.0/24 is the (remote) Falcot network
  route del -net 192.168.0.0 netmask 255.255.255.0 dev $1
fi

SEGURANÇA MPPE

A segurança do PPTP envolve o uso do recurso MPPE (Microsoft Point-to-Point Encryption), o qual está disponível nos núcleos oficiais Debian como módulo.

10.2.4.2. Configurando o Servidor

ATENÇÃO PPTP e firewalls

Firewalls intermediários precisam ser configurados para deixar passar pacotes IP que usam protocolo 47 (GRE). Além do mais, a porta do servidor PPTP 1723 precisa estar aberta para que a comunicação pelo canal possa acontecer.
pptpd é o servidor PPTP para Linux. Seu principal arquivo de configuração, /etc/pptpd.conf, requer muito poucas alterações: localip (endereço IP local) e remoteip (endereço IP remoto). No exemplo abaixo, o servidor PPTP sempre usa o endereço 192.168.0.199, e os clientes PPTP recebem endereços IP entre 192.168.0.200 e 192.168.0.250.

Exemplo 10.6. O arquivo /etc/pptpd.conf

# TAG: speed
#
#       Specifies the speed for the PPP daemon to talk at.
#
speed 115200

# TAG: option
#
#       Specifies the location of the PPP options file.
#       By default PPP looks in '/etc/ppp/options'
#
option /etc/ppp/pptpd-options

# TAG: debug
#
#       Turns on (more) debugging to syslog
#
# debug

# TAG: localip
# TAG: remoteip
#
#       Specifies the local and remote IP address ranges.
#
#       You can specify single IP addresses separated by commas or you can
#       specify ranges, or both. For example:
#
#               192.168.0.234,192.168.0.245-249,192.168.0.254
#
#       IMPORTANT RESTRICTIONS:
#
#       1. No spaces are permitted between commas or within addresses.
#
#       2. If you give more IP addresses than MAX_CONNECTIONS, it will
#          start at the beginning of the list and go until it gets
#          MAX_CONNECTIONS IPs. Others will be ignored.
#
#       3. No shortcuts in ranges! ie. 234-8 does not mean 234 to 238,
#          you must type 234-238 if you mean this.
#
#       4. If you give a single localIP, that's ok - all local IPs will
#          be set to the given one. You MUST still give at least one remote
#          IP for each simultaneous client.
#
#localip 192.168.0.234-238,192.168.0.245
#remoteip 192.168.1.234-238,192.168.1.245
#localip 10.0.1.1
#remoteip 10.0.1.2-100
localip 192.168.0.199
remoteip 192.168.0.200-250
A configuração PPP usada pelo servidor PPTP também requer algumas mudanças em /etc/ppp/pptpd-options. Os parâmetros importantes são o nome do servidor (pptp), o nome de domínio (falcot.com), e o endereço IP para os servidores DNS e WINS.

Exemplo 10.7. O arquivo /etc/ppp/pptpd-options

## turn pppd syslog debugging on
#debug

## change 'servername' to whatever you specify as your server name in chap-secrets
name pptp
## change the domainname to your local domain
domain falcot.com

## these are reasonable defaults for WinXXXX clients
## for the security related settings
# The Debian pppd package now supports both MSCHAP and MPPE, so enable them
# here. Please note that the kernel support for MPPE must also be present!
auth
require-chap
require-mschap
require-mschap-v2
require-mppe-128

## Fill in your addresses
ms-dns 192.168.0.1
ms-wins 192.168.0.1

## Fill in your netmask
netmask 255.255.255.0

## some defaults
nodefaultroute
proxyarp
lock
O último passo envolve o registro do usuário vpn (e senha correspondente) no arquivo /etc/ppp/chap-secrets. Ao contrário de outras instâncias onde um asterisco (*) funcionaria, o nome do servidor tem que ser preenchido explícitamente aqui. Além do mais, clientes PPTP em Windows são identificados sob a forma DOMAIN\\USER, ao invés de apenas fornecer um nome de usuário. Isso explica o porque do arquivo também mencionar o usuário FALCOT\\vpn. Também é possível especificar um endereço IP individual para usuários; um asterisco neste campo especifica que endereços dinâmicos devem ser usados.

Exemplo 10.8. O arquivo /etc/ppp/chap-secrets

# Secrets for authentication using CHAP
# client        server  secret      IP addresses
vpn             pptp    f@Lc3au     *
FALCOT\\vpn     pptp    f@Lc3au     *

SEGURANÇA Vulnerabilidades PPTP

A primeira implementação do PPTP da Microsoft atraiu severas críticas porque ela tinha várias vulnerabilidades de segurança; a maioria foi, desde então, consertada em versões mais recentes. A configuração documentada nestas seção usa a última versão do protocolo. Esteja ciente então de que removendo algumas das opções (como require-mppe-128 e require-mschap-v2) fará com que o serviço fique vulnerável novamente.