Tutorial de TCP/IP – Parte 46 Implementação e Administração do RRAS – Parte 3

Introdução:

Prezados leitores, esta √© a vig√©sima sexta parte, desta segunda etapa dos tutoriais de TCP/IP. As partes de 01 a 20, constituem o m√≥dulo que eu classifiquei como Introdu√ß√£o ao TCP/IP. O objetivo do  primeiro m√≥dulo (Partes 01 a 20) foi apresentar o TCP/IP, mostrar como √© o funcionamento dos servi√ßos b√°sicos, tais como endere√ßamento IP e Roteamento e fazer uma apresenta√ß√£o dos servi√ßos relacionados ao TCP/IP, tais como DNS, DHCP, WINS, RRAS, IPSec, Certificados Digitais, ICS, compartilhamento da conex√£o Internet e NAT. Nesta segunda parte da s√©rie, que ir√° da parte 20 at√© a parte 40 ou 50 (ou quem sabe at√© 60), apresentarei as a√ß√Ķes pr√°ticas, relacionadas com os servi√ßos DNS, DHCP e WINS no Windows 2000 Server. A partir desta parte, mostrarei o que √©, como trabalhar, implementar e administrar o servi√ßo de Acesso Remoto do Windows 2000 Server, conhecido como RRAS - Routing and Remote Access Service (Servi√ßo de Roteamento e Acesso Remoto).

Protocolos de Tunneling (Tunelamento):

São suportados os protocolos PPTP e L2TP, conforme descrito na tabela a seguir. Você aprenderá mais sobre estes protocolos, mais adiante, neste capítulo.

Os servidores VPN s√£o conectados √† Internet atrav√©s de conex√Ķes WAN permanentes, como linhas T1 ou Frame Relay. Os clientes VPN s√£o conectados √† Internet atrav√©s de conex√Ķes WAN permanentes ou de discagem para um provedor de servi√ßos de Internet (ISP ‚Äď Internet Service Provider) local usando linhas telef√īnicas anal√≥gicas padr√£o ou uma tecnologia de conex√£o em alta velocidade, tais como ISDN ou ADSL.

Protocolos utilizados para conex√Ķes do tipo Dial-up:

Agora voc√™ j√° conhece os princ√≠pios b√°sicos do servidor de acesso remoto do Windows 2000 Server e sabe quais elementos comp√Ķem uma solu√ß√£o de acesso remoto via Dial-up e quais comp√Ķem uma solu√ß√£o de acesso remoto via VPN. O pr√≥ximo passo √© entender os protocolos envolvidos em cada uma destas situa√ß√Ķes. Por exemplo, para uma conex√£o via Dial-up, normalmente √© utilizado o protocolo PPP (Point-to-Point Protocol). J√° para conex√Ķes via VPN, os protocolos utilizados s√£o PPTP ou L2TP.

O objetivo deste t√≥pico √© apresentar os diferentes tipos de protocolos dispon√≠veis para as conex√Ķes do tipo Dial-up. No pr√≥ximo t√≥pico falarei sobre os protocolos utilizados para as conex√Ķes do tipo VPN.

Point-to-point Protocol ‚Äď PPP (Protocolo ponto a ponto):

O Windows 2000 Server (e tamb√©m o Windows Server 2003) d√° suporte ao PPP (Point-to-Point Protocol, protocolo ponto a ponto), um conjunto de protocolos e autentica√ß√£o padr√£o da ind√ļstria de TI, que permite √†s solu√ß√Ķes de acesso remoto operar em uma rede de m√ļltiplos fabricantes (com clientes, software e equipamentos de m√ļltiplos fabricantes) . A utiliza√ß√£o do PPP √© recomendada, principalmente, pelo fato de ter um amplo suporte dos fabricantes de hardware e software. Ou seja, praticamente todos os equipamentos e programas envolvidos em acesso remoto, tem suporte ao protocolo PPP.

O suporte a PPP permite aos computadores que executam Windows, discar para redes remotas por meio de qualquer servidor compatível com o padrão PPP. A compatibilidade PPP também permite ao computador que executa o serviço de acesso remoto, receber chamadas e fornecer acesso a rede e a programas de software de outros fornecedores.

A arquitetura PPP também permite que os clientes usem qualquer combinação de IPX (Internetwork Packet Exchange), TCP/IP, NetBEUI e AppleTalk. Os clientes de acesso remoto que estejam executando o Windows NT e Windows 2000, Windows 98 e o Windows 95 podem usar qualquer combinação de TCP/IP, IPX e NetBEUI. Os clientes de acesso remoto da Microsoft não oferecem suporte ao uso do protocolo AppleTalk em uma conexão de acesso remoto.

Os padr√Ķes PPP est√£o definidos nas RFCs publicadas pela Internet Engineering Task Force (IETF) e outros grupos de trabalho. Em fim, o protocolo PPP √© um padr√£o de fato, com suporte de todos (√© isso mesmo), de todos os fabricantes de hardware e software de rede. H√°, quando voc√™ se conecta √† Internet, usando uma conex√£o discada, est√° utilizando PPP.

Serial Line Internet Protocol (SLIP):

O Serial Line Internet Protocol (SLIP, protocolo Internet para linhas seriais) √© um padr√£o de acesso remoto mais antigo, geralmente utilizado por servidores de acesso remoto UNIX. Os clientes de acesso remoto que executam o Windows 2000 Professional e o Windows 2000 Server oferecem suporte ao SLIP e podem conectar-se a qualquer servidor de acesso remoto que utiliza o padr√£o SLIP. Isso permite a conex√£o de clientes Windows NT  3.5 ou vers√£o posterior √† ampla base instalada de servidores UNIX. Um servidor de acesso remoto que executa o Windows 2000, Windows XP ou o Windows 2000 Server n√£o oferece suporte aos clientes SLIP. Ou seja, estas vers√Ķes do Windows somente podem atuar como clientes SLIP e n√£o como servidores SLIP (apesar de o Windows XP Professional poder atuar como um servidor de acesso remoto, ele aceita uma √ļnica conex√£o simult√Ęnea).

Nota: No Windows 2000 Server, somente √© poss√≠vel se conectar a um servidor SLIP, usando o protocolo TCP/IP e uma porta Serial.

N√£o esque√ßa: O RRAS n√£o √© um servidor SLIP. Ele somente atua como cliente SLIP. Como servidor de acesso remoto ela da suporta ao PPP para conex√Ķes Dial-up e ao PPTP ou L2TP/IPsec para conex√Ķes VPN.

Protocolo Microsoft RAS:

O protocolo Microsoft RAS (Remote Access Services) √© um protocolo de acesso remoto propriet√°rio da Microsoft, o qual fornece suporte ao padr√£o NetBIOS. H√° suporte para o protocolo Microsoft RAS em todas as vers√Ķes anteriores do acesso remoto da Microsoft e ele √© utilizado em clientes Windows NT 3.1, Windows para Workgroups, MS-DOS e LAN Manager.

Um cliente de acesso remoto que est√° discando de um computar que executa o Windows NT 3.1 ou Windows for Workgroups deve usar o protocolo NetBEUI. O servidor de acesso remoto, ent√£o, atua como um gateway NetBIOS para o cliente remoto, fornecendo acesso aos recursos por meio dos protocolos NetBEUI, NetBIOS sobre TCP/IP ou NetBIOS sobre IPX. Utilizado apenas por quest√Ķes de compatibilidade com clientes mais antigos.

Protocolos utilizados para conex√Ķes do tipo VPN:

Os protocolos utilizados em conex√Ķes de VPN s√£o os seguintes: PPTP e L2TP. O protocolo L2TP √© utilizado em conjunto com o protocolo IPSec, j√° que o L2TP n√£o fornece os servi√ßos de criptografia de dados, fundamentais para as conex√Ķes VPN. Neste caso, a criptografia de dados √© fornecida pelo protocolo IPSec.

Point-to-Point Tunneling Protocol (PPTP):

De uma maneira simples, podemos dizer que o PPTP √© o PPP com a adi√ß√£o de alguns mecanismos de criptografia, para garantir a seguran√ßa dos dados. O Point-to-Point Tunneling Protocol (PPTP) √© um protocolo de encapsulamento criado pela Microsoft em conjunto com mais algumas empresas e que primeiro teve suporte no Windows NT 4.0. O PPTP √© uma extens√£o do Point-to-Point Protocol (PPP) e aproveita os mecanismos de autentica√ß√£o, compacta√ß√£o e criptografia do PPP (confirma a id√©ia de que o PPTP √© o PPP com algumas adi√ß√Ķes). Mas o fato concreto √© que, como se diz popularmente, o PPTP ‚Äún√£o pegou‚ÄĚ. N√£o foi adotado amplamente pela ind√ļstria e o futuro deste protocolo √© incerto.

O PPTP √© instalado automaticamente quando o servi√ßo de roteamento e acesso remoto. Por padr√£o, o PPTP √© configurado para aceitar at√© 5 conex√Ķes simult√Ęneas (5 portas PPTP). √Č poss√≠vel ativar mais portas PPTP para acesso remoto de entrada e conex√Ķes de roteamento de discagem Dial-up utilizando o Assistente de roteamento e acesso remoto. N√£o s√£o necess√°rias conex√Ķes adicionais para que servidor de acesso remoto possa aceitar conex√Ķes PPTP. Uma vez que o administrador habilita o servidor para aceitar chamadas, j√° est√£o dispon√≠veis cinco conex√Ķes via PPTP. O administrador pode configurar este n√ļmero, para adicionar um n√ļmero maior de licen√ßas de conex√£o remota via PPTP.

Para fazer uma conexão VPN, primeiro o cliente faz uma conexão PPP com o servidor de acesso remoto. Em seguida, já estando a conexão PPP estabelecida, o cliente faz uma conexão PPTP com o servidor de acesso remoto. O servidor RRAS recebe o pedido de conexão do cliente PPTP e faz a sua autenticação usando o protocolo de autenticação MS-CHAP v2. Ao invés do MS-CHAP v2, deve ser utilizado o protocolo EAP quando o cliente estiver utilizando um Smart Card para autenticação.

N√£o esque√ßa: Para a conex√£o remota, usando autentica√ß√£o via Smart Card, deve ser utilizado o protocolo EAP. N√£o esque√ßa mesmo.

Uma vez estabelecida a conexão VPN, usando o PPTP, todo o tráfego entre o cliente e o servidor RRAS é criptografado. Esta criptografia é feita utilizando uma técnica conhecida como Encapsulamento, descrita logo a seguir.

Importante: N√£o esque√ßa que, para estabelecer uma conex√£o do tipo VPN s√£o realizadas duas conex√Ķes. A primeira √© uma conex√£o PPP padr√£o. Esta conex√£o estabelece a liga√ß√£o, um caminho f√≠sico entre o cliente e o servidor RRAS. A pr√≥xima etapa √© estabelecer a conex√£o VPN propriamente dita, utilizando um dos protocolos dispon√≠veis (PPTP ou L2TP). O objetivo desta segunda conex√£o √© garantir a seguran√ßa dos dados, atrav√©s do uso de t√©cnicas de criptografia e encapsulamento.

Encapsulamento:

O processo de encapsulamento, consiste em adicionar um cabeçalho GRE (Generic Routing Encapsulation) e um cabeçalho IP, ao pacote do protocolo PPP [o qual contém datagramas do protocolo IP, IPX ou AppleTalk). No cabeçalho IP estão os endereços IP de origem e de destino que correspondem ao cliente e ao servidor VPN.

Criptografia:

O quadro PPP é criptografado com a Microsoft Point-to-Point Encryption (MPPE, criptografia ponto a ponto da Microsoft) utilizando chaves de criptografia geradas pelo processo de autenticação de MS-CHAP (Microsoft Challenge Authentication Protocol) ou EAP-TLS (Extensible Authentication Protocol - Transport Layer Security). Os clientes da rede virtual privada devem utilizar o protocolo de autenticação MS-CHAP ou EAP-TLS para criptografar os pacotes PPP. O PPTP aproveita a criptografia do PPP e encapsula quadros PPP previamente criptografados.

Um dos pontos mais criticados do PPTP √© em rela√ß√£o a seguran√ßa. Especialistas em seguran√ßa j√° demonstraram que o PPTP n√£o √© um protocolo seguro e est√° sujeito a ataques de seguran√ßa. Com o Windows 2000 Server √© fornecida a vers√£o 2 do protocolo: PPTP v2. S√≥ o tempo dir√° se esta vers√£o est√° mais segura e confi√°vel. Outro problema de seguran√ßa com o PPTP √© que a fase de autentica√ß√£o entre o cliente e o servidor acontece antes que o t√ļnel criptografado seja estabelecido. Com isso informa√ß√Ķes da fase de autentica√ß√£o poder√£o ser capturadas e utilizadas posteriormente, para tentar quebrar a criptografia dos dados transmitidos. Este √© um dos motivos que podem leva-lo a se decidir pelo uso de Smart Cards em conjunto com o protocolo TCP/IP. Com o uso de Smart Cards, a fase de autentica√ß√£o tamb√©m est√° protegida contra acessos indevidos, uma vez que os dados s√£o criptografados em todas as fases do processo. Para o uso de Smart Cards voc√™ dever√° habilitar o protocolo de autentica√ß√£o EAP, no servidor RRAS. Voc√™ aprender√° a configurar o suporte aos protocolos de autentica√ß√£o na parte pr√°tica.

Uma das vantagens (talvez a √ļnica) do protocolo PPTP √© a sua simplicidade e o fato de ele ser suportado por clientes mais antigos do Windows, tais como o Windows 98. J√° o protocolo L2TP √© suportado apenas por clientes mais novos (veja tabela da Figura 6.4), tais como o Windows 2000, Windows XP e Windows 2000 Server.

Observa√ß√Ķes:

  • √Č poss√≠vel ter uma conex√£o PPTP sem criptografia, na qual o quadro PPP √© enviado em texto simples. Entretanto, n√£o √© recomend√°vel uma conex√£o PPTP sem criptografia para conex√Ķes VPN na Internet, porque comunica√ß√Ķes desse tipo n√£o s√£o seguras.
  • O suporte ao protocolo IPX/SPX n√£o est√° dispon√≠vel nas vers√Ķes de 64 bits do Windows XP e do Windows Server 2003.
  • O protocolo PPTP √© um protocolo de n√≠vel de aplica√ß√£o (camada 7 no modelo OSI).

Layer Two Tunneling Protocol (L2TP Protocolo de encapsulamento de camada 2)

O Layer Two Tunneling Protocol (L2TP) √© um protocolo de encapsulamento com base em padr√Ķes definidos em RFCs e destinado a ser o padr√£o da ind√ļstria. Diferentemente do PPTP (Point-to-Point Tunneling Protocol, protocolo de encapsulamento ponto a ponto), o L2TP n√£o utiliza a Microsoft Point-to-Point Encryption (MPPE, criptografia ponto a ponto da Microsoft) para criptografar os pacotes PPP. O L2TP trabalha em conjunto com o protocolo Internet Protocol Security (IPSec) e usa os servi√ßos do IPSec para servi√ßos de criptografia. A combina√ß√£o de L2TP e IPSec √© conhecida como L2TP atrav√©s de IPSec. O ‚Äú2‚ÄĚ significa camada 2 do modelo OSI. Lembrando que as camadas do modelo OSI, come√ßando da 1 s√£o: F√≠sica, Enlace, Rede, Transporte, Autentica√ß√£o, Apresenta√ß√£o e Aplica√ß√£o.

O resultado √© que conex√Ķes de rede virtual privada baseadas em L2TP s√£o uma combina√ß√£o de L2TP e IPSec. O L2TP e o IPSec devem ter suporte do cliente e do servidor de acesso remoto com o qual ser√£o estabelecidas as conex√Ķes VPN.

O L2TP √© instalado, automaticamente, com o RRAS. Por padr√£o, o L2TP √© configurado para aceitar at√© cinco conex√Ķes L2TP, simult√Ęneas. O administrador pode configurar um n√ļmero de portas L2TP maior do que cinco, de acordo com as necessidades da sua rede, sendo que o n√ļmero m√°ximo permitido √© de 256.

O uso de L2TP atrav√©s de IPSec oferece os principais servi√ßos VPN de encapsulamento e criptografia de dados privados. O encapsulamento de L2TP atrav√©s de pacotes IPSec consiste em duas camadas:  o encapsulamento L2TP e o encapsulamento IPSec. Na Figura a seguir, da Ajuda do Windows 2000 Server,  √© apresentada uma vis√£o geral deste processo de encapsulamento no L2TP em conjunto com o IPSec.


Figura - O duplo encapsulamento: L2TP e IPSec.
  
Criptografia: A mensagem L2TP √© criptografada com mecanismos de criptografia IPSec que utilizam chaves de criptografia geradas pelo processo de autentica√ß√£o IPSec.

Nota: √Č poss√≠vel ter uma conex√£o L2TP que n√£o se baseie em IPSec (sem criptografia) quando o quadro PPP √© enviado em texto simples. No entanto, n√£o √© recomend√°vel usar uma conex√£o L2TP sem criptografia para conex√Ķes VPN na Internet, porque comunica√ß√Ķes desse tipo n√£o s√£o seguras.

Algumas considera√ß√Ķes importantes sobre o uso do protocolo L2TP:

  • O uso do L2TP exige que voc√™ tenha implementado uma infra-estrutura de chave p√ļblica (PKI ‚Äď Public Key Infrastructure) na rede da empresa, pois o L2TP dependo do uso de certificados digitais. N√£o precisa ser, necessariamente, uma infra-estrutura de PKI baseada em tecnologia Microsoft. Por√©m neste caso, voc√™ ter√° mais algumas tarefas administrativas a considerar, tais com a emiss√£o manual de certificados, para os computadores que ir√£o utilizar o L2TP/IPsec.
  • O L2TP √© um ‚Äúterr√≠vel monstro consumidor de processador‚ÄĚ. Em outras palavras, o uso do L2TP cria uma carga adicional, consider√°vel, no processador. Isso ocorre porque o algoritmo de criptografia utilizado pelo L2TP (3DES) √© bem mais complexo (e tamb√©m bem mais seguro) do que o algoritmo utilizado pelo PPTP (MPPE ‚Äď Microsoft Point-to-point Encryption). Al√©m disso, com o L2TP, a assinatura digital de cada pacote √© verificada. Uma das maneiras de reduzir o impacto no processador e melhorar o desempenho dos computadores que usam o L2TP/IPSec, √© instalando placas de rede equipadas com co-processadores de IPSec na pr√≥pria placa. Embora melhore bastante o desempenho, √© importante salientar que estas placas tem um custo bem mais elevado do que as placas sem o co-processador de IPSec.
  • Um problema que pode ser dif√≠cil de resolver √© o fato que o protocolo IPSec n√£o √©, digamos assim, muito amigo dos Firewall. O que acontece √© que a maioria dos Firewall bloqueia a passagem dos pacotes IPSec.

Na tabela a seguir eu apresento um resumo das características e as principais diferenças entre os protocolos PPTP e L2TP com IPSec.

N√£o esque√ßa: Conhe√ßa bem as diferen√ßas entre o PPTP e o L2TP/IPsec.

Conclus√£o:

Por enquanto era isso. Na Parte 47 vou tratar sobre os m√©todos de autentica√ß√£o do servidor de Acesso Remoto.