Résolution des problèmes L2TP/IPSec de base dans Windows 2000

Cet article contient des informations permettant de résoudre les problèmes liés aux protocoles L2TP (Layer Two Tunneling Protocol) et IPSec (Internet Protocol security) dans Windows.

Le protocole L2TP est une norme qui permet le transfert du trafic PPP (Point-to-Point Protocol) entre différents réseaux, comme le décrit la RFC 2661 « Layer Two Tunneling Protocol L2TP ». Le protocole L2TP s'associe à IPSec pour assurer l'encapsulation et la sécurité de différents paquets de protocole, tels que IP (Internet Protocol) et IPX (Internetwork Packet eXchange), via tout réseau IP.

Le protocole L2TP encapsule les paquets d'origine dans une trame PPP et effectue autant que possible une compression. De plus, il encapsule à l'intérieur d'un paquet de type UDP (User Datagram Protocol) qui est affecté au port 1701. Étant donné que le paquet UDP appartient au protocole de transport IP, le protocole L2TP utilise automatiquement IPSec pour sécuriser le tunnel. Le protocole L2TP effectue cette opération en fonction des paramètres de sécurité dans la configuration utilisateur du tunnel L2TP. Par défaut, le protocole IPSec IKE (Internet Key Exchange) négocie la sécurité pour le tunnel L2TP à l'aide de l'authentification basée sur les certificats. Ce processus d'authentification utilise les certificats d'ordinateur (et non les certificats d'utilisateur) pour vérifier l'approbation mutuelle des ordinateurs sources et des ordinateurs de destination. Si la sécurité du transport IPSec est correctement établie, le protocole L2TP négocie le tunnel et effectue un contrôle d'accès basé sur l'identité de l'utilisateur. Lorsque le protocole L2TP négocie le tunnel, il négocie les options de compression et d'authentification utilisateur.

La structure du paquet L2TP/IPSec ressemble à l'exemple suivant.

Remarque La charge PPP contient le datagramme IP d'origine. Le texte en italique représente la partie chiffrée à l'aide du protocole IPSec. Le protocole MPPE (Microsoft Point-to-Point Encryption Protocol) est négocié par Windows lorsque l'homologue L2TP (client ou serveur) en fait la demande. Le protocole MPPE peut servir à sécuriser la charge PPP lorsque les protocoles EAP-TLS (Extensible Authentication Protocol Transport Layer Security) ou MS-CHAP (Microsoft Challenge Handshake Authentication Protocol) sont utilisés.

Le protocole MPPE fait appel au chiffre continu RSA (Rivest-Shamir-Adleman) RC4 et aux clés secrètes de 40 bits, 56 bits ou 128 bits. Les clés MPPE sont générées à partir des processus d'authentification utilisateur MS-CHAP et EAP-TLS. Vous pouvez configurer le serveur d'accès à distance de sorte à exiger le cryptage des données. Si le client d'accès distant ne peut pas effectuer le chiffrement requis, la tentative de connexion est rejetée et le message d'erreur suivant peut s'afficher : Le protocole IPSec est négocié avant le démarrage de PPP alors que le protocole MPPE est négocié après le démarrage de PPP. PPP s'exécute sur le protocole L2TP à l'aide du protocole IPSec. Au cours de la phase d'authentification PPP, un nom d'utilisateur est envoyé au composant serveur d'accès distant du serveur VPN (virtual private network) à l'aide du protocole d'authentification configuré, par exemple MS-CHAP. Le serveur d'accès distant fait ensuite correspondre le nom d'utilisateur et d'autres propriétés d'appel avec une stratégie d'accès distant. Chaque stratégie possède un profil, et le serveur d'accès distant compare les conditions de l'appel entrant avec le profil pour déterminer si la demande de connexion est acceptée ou non.

Considérations

• Si votre client VPN Microsoft Windows 2000 Professionnel avec Service Pack 2 ou antérieur se trouve derrière un périphérique réseau chargé d'effectuer la traduction d'adresses réseau (NAT), la session L2TP échoue parce que les paquets ESP (Encapsulating Security Payload) IPSec chiffrés sont endommagés. Si le client VPN est sur le même ordinateur que la traduction d'adresses réseau et le partage de connexion Internet Windows, celui-ci devrait pouvoir établir une session L2TP dans la mesure où la traduction d'adresses réseau n'effectue pas de traduction de ports ni d'adresses IP lorsque les paquets proviennent de son propre mode. Pour plus d'informations sur les améliorations du protocole IPSec permettant la communication aux clients VPN situés derrière des périphériques NAT, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
  818043  (http://support.microsoft.com/kb/818043/ ) Mise à jour L2TP/IPSec NAT-T pour Windows XP et Windows 2000
• Vous devez disposer d'un certificat d'ordinateur équipé d'une clé privée. La clé privée se trouve dans le magasin du certificat personnel de l'ordinateur local.
  
  Pour plus d'informations sur l'installation d'un certificat, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
  253498  (http://support.microsoft.com/kb/253498/ ) Comment faire pour installer un certificat à utiliser avec la sécurité IP
  En l'absence d'un certificat d'ordinateur, le protocole L2TP émet un avertissement correspondant, sans savoir si le certificat possède une clé privée associée et correctement installée pour le certificat existant. IKE détermine ce point au cours de la négociation. Démarrez le composant logiciel enfichable Certificats de l'ordinateur local, double-cliquez sur Certificat, puis vérifiez que Général indique "Vous avez une clé privée qui correspond à ce certificat". Vérifiez également que le chemin d'accès du certificat est complet et que le certificat est valide.
  
  Le client doit disposer d'un certificat d'ordinateur dont l'Autorité de certification racine est la même que le certificat sur le certificat de passerelle. La raison de l'échec du certificat est consignée par IKE dans l'entrée du journal de sécurité. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
  257225  (http://support.microsoft.com/kb/257225/ ) Résolution des problèmes IPSec de base dans Microsoft Windows 2000 Server
  Pour plus d'informations sur le type de certificat d'ordinateur qui fonctionne correctement, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
  249125  (http://support.microsoft.com/kb/249125/ ) Utilisation de certificats pour l'interopération VPN Cisco IOS et Windows 2000
  Les deux parties doivent être capables de réussir la validation du certificat. Si l'authentification par certificat réussit, une entrée dans le journal de sécurité consigne la réussite de l'établissement d'une association de sécurité de mode principal IPSec (ouverture/fermeture de session).
• Échec IKE à négocier : Vous pouvez vérifier si IPSec fonctionne en exécutant Ipsecmon.exe lorsque vous disposez d'autorisations d'administrateur local et lorsque les options sont configurées pour une mise à jour à intervalle d'une seconde. Si l'association SA IPSec apparaît, cela signifie que IPSec a réussi. Vous pouvez alors conclure que le protocole L2TP est à l'origine du problème. La commande netdiag /test:ipsec /v /debug vous permet d'afficher les détails de la stratégie IPSec.
  
  Remarque Vous ne pouvez pas consulter toute la stratégie si un administrateur de domaine a défini la stratégie sur votre ordinateur local. Pour plus d'informations sur Ipsecmon.exe et la commande netdiag, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
  257225  (http://support.microsoft.com/kb/257225/ ) Résolution des problèmes IPSec de base dans Microsoft Windows 2000 Server
  Tenez également compte des points suivants :
  • Délai d'attente IKE : IKE peut connaître un délai d'attente au cours de la demande de négociation initiale si les routeurs devant le serveur VPN n'activent pas le port UDP 500. IKE peut également connaître un délai d'attente si le serveur VPN n'a pas de stratégie IPSec appropriée configurée. Cela signifie généralement que le serveur Routage et Accès Distant n'a pas de ports L2TP activés ou qu'un paramètre de stratégie IPSec a été mal configuré. Lorsqu'IKE connaît un délai d'attente, la piste d'audit montre que l'homologue n'a pas répondu, et une trace de la capture réseau indique que les paquets UDP ISAKMP ne proviennent que de votre client. Si le client VPN n'est pas configuré spécifiquement pour L2TP, le message d'erreur suivant s'affiche :
    Le délai de la négociation de sécurité a été dépassé.
    Si le client VPN est configuré automatiquement, il effectue une nouvelle tentative à l'aide du protocole suivant dans sa liste, en l'occurrence PPTP.
  • Échec IKE : L'échec de la négociation d'IKE et les raisons de cet échec sont enregistrés dans le journal de sécurité si vous activez les paramètres de sécurité, audits des échecs d'ouverture/de fermeture de session. IKE peut échouer parce que les informations d'identification de certificat ne fonctionnent pas ou en raison d'un problème de configuration de la stratégie IPSec si elles définissent une stratégie IPSec manuelle. Pour plus d'informations sur la stratégie automatique, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
    248750  (http://support.microsoft.com/kb/248750/ ) Description de la stratégie IPSec créée pour L2TP/IPSec
    La réussite de la négociation IKE est consignée dans la piste d'audit. Pour que réussisse l'ensemble de la négociation de la sécurité IPSec, vous avez besoin de l'établissement d'une association de sécurité de mode principal et de mode rapide pour le port UDP 1701.
• Si l'un des points suivants se vérifie, le problème n'est pas dû à IPSec :
  • La piste d'audit indique la réussite de l'établissement de ces deux modes.
  • Le traçage de la capture réseau montre qu'un trafic ESP provient du client ou du serveur.
  • Ipsecmon.exe indique une association de sécurité IPSec.
  Remarque Il y a toujours l'établissement de deux associations de sécurité IPSec : une pour chaque direction, chacune avec son propre index SPI (Security Parameter Index). Cependant, Ipsecmon.exe n'indique que l'association de sécurité sortante.
• ESP bloqué : Lorsque la traduction d'adresses réseau est devant le client ou lorsque les routeurs sont devant le réseau VPN, le serveur peut ne pas activer le protocole 50 ESP. Le trafic ESP sortant avec le nombre d'index SPI apparaît alors que les paquets ESP entrants de la passerelle avec un nombre d'index SPI différent n'apparaissent pas.
• ESP modifié : Si la traduction d'adresses réseau ou éventuellement un commutateur défectueux ou un autre n?ud réseau modifie ou endommage les paquets au cours du trajet, ceux-ci sont abandonnés par le pilote IPSec, et l'événement suivant apparaît dans le journal système du système récepteur :

  ID de l'événement : 4285
  Description :
  Échec de l'authentification du hachage.

  Les paquets peuvent également être endommagés par une carte réseau ayant des fonctions de déchargement IPSec. Pour déterminer si une interface possède cette fonction, utilisez la commande suivante :
  netsh int ip show offload
• Si la fonction de déchargement IPsec d'une carte réseau est la cause suspectée, lancez une capture Moniteur réseau ainsi que le fichier Ipsecmon.exe pour analyser chaque tentative de connexion et pour vérifier le compteur « Octets confidentiels reçus » qu'il contient pour déterminer si les paquets sont perdus à la réception. Vous pouvez aussi affecter zéro à la valeur DWORD de la sous-clé du Registre suivante :
  HKLM\System\CurrentControlSet\Services\IPSEC\EnableOffload
  Si la connexion réussit, le problème est lié au déchargement. Une autre solution consiste à désactiver la stratégie IPSec automatique. Pour plus d'informations sur la désactivation de la stratégie IPSec automatique, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
  240262  (http://support.microsoft.com/kb/240262/ ) Comment faire pour configurer une connexion L2TP/IPSec en utilisant l'authentification par clé pré-partagée
• Si l'agent de stratégie IPSec a été arrêté par l'intermédiaire du composant logiciel enfichable Services ou de la commande net stop policyagent, la configuration de la stratégie automatique L2TP est perdue. Pour les clients VPN, la stratégie est automatiquement transmise lorsque le connectoïde client est démarré. Vérifiez que le service d'agent de stratégie IPSec a démarré et s'exécute avant de lancer la connexion client. Après avoir cliqué sur Se connecter et que la tentative de connexion est en cours, utilisez la commande netdiag /test:ipsec /v /debug pour consulter les statistiques IPSec et les filtres actifs.
  
  Remarque Si vous n'avez pas d'autorisations d'administrateur de domaine, vous ne pouvez pas utiliser le commutateur /debug. Pour plus d'informations sur d'autres problèmes possibles, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
  247231  (http://support.microsoft.com/kb/247231/ ) ID de l'événement 20111, Erreur 792 ou Erreur 781 lors de l'établissement d'une connexion L2TP/IPSec

Pour plus d'informations sur VPN, consultez le site Web Microsoft à l'adresse suivante (en anglais) : Pour plus d'informations sur la résolution des problèmes IPSec, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.