Solução de Problemas da L2TP/IPSec Básicos no Windows

Este artigo oferece informações que ajudam a solucionar problemas dos protocolos L2TP (Layer-Two Tunneling Protocol) e IPSec (Internet Protocol Security) no Windows.

O L2TP é um padrão que permite a transferência de tráfego PPP (Point to Point Protocol) entre redes diferentes (descrito na RFC 2661). O L2TP é usado em conjunto com o IPSec para oferecer tanto o tunelamento quanto a segurança para o IP (Internet Protocol), o IPX (Internetwork Packet Exchange) e outros pacotes de protocolo em qualquer rede IP.

O L2TP encapsula pacotes originais em um quadro PPP (realizando a compactação quando possível), bem como em um pacote do tipo UDP (User Datagram Protocol) atribuído à porta 1701. Como o formato de pacote UDP é IP, o L2TP usa automaticamente o IPSec para proteger o encapsulamento (com base nas definições de segurança descritas na configuração de usuário do encapsulamento L2TP). O protocolo IKE (Internet Key Exchange) IPSec negocia a segurança para a autenticação baseada em certificado que usa o encapsulamento L2TP por padrão. Esse processo de autenticação usa certificados de computador, e não de usuário, para verificar se os computadores de origem e de destino confiam um no outro. Se a segurança de transporte do IPSec for estabelecida, o L2TP negocia o encapsulamento (incluindo as opções de compactação e de autenticação do usuário) e realiza o controle de acesso com base na identidade do usuário.

A estrutura do pacote L2TP/IPSec é semelhante ao exemplo a seguir (o PPP de carga útil contém o datagrama IP original, enquanto o texto em itálico representa o que está criptografado no IPSec): O MPPE (Microsoft Point-to-Point Encryption Protocol), que pode ser usado para proteger a carga útil de PPP quando a EAP-TLS (Extensible Authentication Protocol Transport Layer Security) ou o MS-CHAP (Microsoft Challenge Handshake Authorization Protocol) são usados, é negociado pelo Windows quando o par L2TP (cliente ou servidor) o solicita.

O MPPE usa a codificação de fluxo RC4 RSA (Rivest-Shamir-Adleman) e chaves secretas de 40, 56 ou 128 bits. As chaves MPPE são geradas a partir do protocolo MS-CHAP (Microsoft Challenge Handshake Authentication Protocol) e do processo de autenticação do usuário EAP-TLS. O servidor de acesso remoto pode ser configurado para exigir a criptografia dos dados. Se o cliente de acesso remoto não puder fazer a criptografia necessária, a tentativa de conexão é rejeitada, e a seguinte mensagem (742) pode aparecer: O IPSEC é negociado antes do PPP iniciar; o MPPE é negociado depois que o PPP iniciar. O PPP é executado em LPT2 usando-se o IPSec. Durante a fase de autenticação PPP, envia-se um nome de usuário para o componente RAS (Remote Access Server) do servidor VPN (Virtual Private Network) usando-se o protocolo de autenticação configurado (CHAP, por exemplo). Então, o servidor RAS vê se há correspondência entre o nome de usuário e outras propriedades de chamada para uma Diretiva de Acesso Remoto. Cada diretiva tem um perfil, e o RAS compara as condições da chamada de entrada com o perfil para determinar se deve aceitar a solicitação de conexão.

Considerações

• Se o cliente da VPN (Virtual Private Network) estiver controlando qualquer dispositivo de rede que esteja executando a NAT (Network Address Translation), a sessão L2TP falha porque os pacotes ESP (Encapsulating Security Payload) de IPSec criptografados foram corrompidos. Se o cliente da VPN estiver no mesmo computador que o Compartilhamento de Conexão com a Internet/Conversão de endereço de rede, é provável que ele consiga estabelecer uma sessão L2TP porque a NAT não realiza nenhuma conversão de endereços IP ou de portas quando os pacotes têm origem no seu próprio nó.
• Você precisa de um certificado de computador com uma chave particular, que pode ser encontrada no armazenamento de Certificados Pessoais no Computador.
  
  Para obter informações adicionais sobre como instalar um certificado, clique no número abaixo para visualizar o artigo na Base de Dados de Conhecimento da Microsoft:
  253498  (http://support.microsoft.com/kb/253498/PT-BR/ ) How to Install a Certificate for Use with IP Security
  Se um certificado de computador não for encontrado, o L2TP emite um aviso lhe indicando o problema, mas ele não sabe se o certificado tem uma chave particular instalada corretamente para o certificado já existente. A troca de chaves na Internet (IKE) verifica isso durante a negociação. Inicie o suplemento Certificados do Computador Local, clique duas vezes em Certificado, e veja se Geral indica "Tem uma chave particular correspondente a este certificado." Também verifique se o caminho do certificado está completo, e se o certificado é válido.
  
  O cliente deve ter um certificado de computador cuja autoridade do certificado raiz é a mesma do certificado no certificado de gateway. A razão da falha do certificado é observada pelo IKE na entrada de evento do log de segurança. Para obter informações adicionais, clique no número abaixo para visualizar o artigo na Base de Dados de Conhecimento da Microsoft:
  257225  (http://support.microsoft.com/kb/257225/PT-BR/ ) Basic IPSec Troubleshooting in Windows 2000
  Para obter informações adicionais sobre qual tipo de certificado de computador funciona corretamente, clique no número abaixo para visualizar o artigo na Base de Dados de Conhecimento da Microsoft:
  249125  (http://support.microsoft.com/kb/249125/PT-BR/ ) Using Certificates for Windows 2000 and Cisco IOS Interoperation
  Ambos os lados precisam ter a capacidade de processar a validação do certificado. Se a autenticação do certificado der certo, uma entrada no log de segurança observa o evento referente ao estabelecimento do SA no modo principal de IPSec (logon/logoff).
• Falha de IKE ao negociar: Você pode verificar se o IPSec está funcionando, executando Ipsecmon.exe (como administrador local) com as opções definidas para atualizar em intervalos de um segundo. Se você vir o IPSec SA, isso indica que o IPSec funcionou; assim, você pode concluir que o L2TP é a origem do problema. Use o comando netdiag /test:ipsec /v /debug para ver os detalhes da diretiva IPSec (você não consegue ver toda a diretiva caso um administrador do domínio tenha definido a diretiva no seu computador local).
  
  Para obter informações adicionais sobre Ipsecmon.exe e o comando Netdiag, clique no número abaixo para visualizar o artigo na Base de Dados de Conhecimento da Microsoft:
  257225  (http://support.microsoft.com/kb/257225/PT-BR/ ) Basic IPSec Troubleshooting in Windows 2000
  Também observe o seguinte:
  • Tempo limite de IKE: IKE pode expirar durante a solicitação da negociação inicial, caso os roteadores no servidor VPN não permitirem a saída através da porta UDP 500. Ele também expira no caso do servidor VPN não ter a diretiva IPSec correta configurada, o que normalmente quer dizer que o servidor RRAS não tem as portas L2TP ativas, ou que a configuração de diretiva IPSec manual está configurada de maneira errada. Quando IKE expira, o log de auditoria mostra que o par deixou de responder, e que o comando trace de uma captura de rede mostra os pacotes UDP ISAKMP iniciando apenas a partir do seu cliente. Se for configurado especialmente para L2TP, o cliente VPN responde usando a seguinte mensagem de erro:
    O tempo da negociação de segurança se esgotou.
    Se for configurado em Automático, ele tenta realizar a tarefa novamente usando o próximo protocolo em sua lista, ou seja, PPTP.
  • Falha de IKE: A falha ao negociar o IKE e as razões para essa falha estão registradas no log de segurança, caso você tenha ativado Configurações de segurança, Logon/Logoff failure audits. O IKE pode falhar porque as credenciais de certificado não funcionam, ou porque há um problema na configuração da diretiva de IPSec, caso estejam definidos para a diretiva IPSec manual.
    
    Para obter informações adicionais sobre a diretiva automática, clique no número abaixo para visualizar o artigo na Base de Dados de Conhecimento da Microsoft:
    248750  (http://support.microsoft.com/kb/248750/PT-BR/ ) Description of IPSec Policy created for L2TP/IPSec
    O êxito na negociação IKE é registrado no log de auditoria. Para que toda a negociação de segurança IPSec dê certo, você precisa estabelecer tanto o modo SA principal quanto o rápido para a porta 1701 UDP.
• Se houver um dos seguintes sintomas, o IPSec não está causando o problema:
  
  
  • O log de auditoria mostra os estabelecimentos dos modos principal SA e rápido SA.
  • O comando trace da captura de rede mostra o tráfego ESP originário do cliente ou do servidor.
  • Ipsecmon.exe mostra um IPSec SA.
  NOTA: Sempre há dois SAs IPSec estabelecidos: um para cada direção, cada um com o seu próprio SPI (Security Parameter Index); no entanto, Ipsecmon.exe mostra apenas o SA de saída.
• ESP bloqueado: Quando uma NAT estiver no cliente ou os roteadores estiverem na VPN, talvez o servidor não permitam o protocolo 50. O tráfego ESP de saída com o número SPI aparece, mas os pacotes de entrada a partir do gateway com um número SPI diferente, não.
• ESP modificado: Se a NAT, ou um switch ou outro nó de rede com falhas, estiver modificando ou corrompendo pacotes em alguma parte do caminho, eles são descartados pelo driver IPSec com o Evento 4285 "Failed to authenticate hash" aparecendo no log de sistema do sistema que está recebendo. Os pacotes também podem ser corrompidos por uma interface de rede com recursos de descarga IPSec. Para verificar se uma interface tem essa capacidade, use o seguinte comando:
  netsh int ip show offload
• Se o recurso de descarga IPSec de uma NIC for a possível causa, inicie uma captura do Monitor de rede e Ipsecmon.exe para analisar cada tentativa de conexão e verificar o contador "Bytes confidenciais recebidos" em Ipsecmon e determinar quais pacotes estão sendo perdidos ou recebidos. Você também pode definir o valor do registro HKLM\System\CurrentControlSet\Services\IPSEC\EnableOffload DWORD para 0. Se a conexão der certo, o problema está relacionado à descarga. Uma outra forma de solucionar o problema é desativando a diretiva automática IPSec.Para obter informações adicionais sobre como desativar a diretiva automática IPSec, clique no número abaixo para visualizar o artigo na Base de Dados de Conhecimento da Microsoft:
  240262  (http://support.microsoft.com/kb/240262/PT-BR/ ) Como Configurar Uma Conexão L2TP-IPSec Usando Autenticação de Chave Pré-compartilhada
• Se o Agente da diretiva IPSec for interrompido usando-se os suplemento Serviços ou o comando net stop policyagent, a configuração da diretiva IPSec de L2TP é perdida. Para clientes VPN, a diretiva é automaticamente inserida quando o conectóide do cliente é iniciado. Certifique-se de que o serviço do agente de diretiva IPSec foi iniciado e de que está em execução antes de você lançar o conectóide do cliente. Depois de clicar em Conectar e a tentativa de conexão estiver em andamento, você pode usar o comando netdiag /test:ipsec /v /debug para ver estatísticas do IPSec e os filtros ativos (se não tiver privilégios de administrador de domínio, você não poderá usar a chave /debug). Para obter informações adicionais sobre outros possíveis problemas, clique no número abaixo para visualizar o artigo na Base de Dados de Conhecimento da Microsoft:
  247231  (http://support.microsoft.com/kb/247231/PT-BR/ ) Event ID 20111 When Establishing a L2TP/IPSec Connection

Para obter mais informações sobre a VPN, consulte o artigo "Microsoft Privacy Protected Network Access: Virtual Private Networking and Intranet Security" no seguinte local: Para obter informações adicionais sobre a solução de problemas do IPSec, clique no número abaixo para visualizar o artigo na Base de Dados de Conhecimento da Microsoft: