# Résoudre la fragmentation EAP : la clé d’une authentification RADIUS fiable En matière de sécurité réseau, le **Maximum Transmission Unit (MTU)** est un paramètre réseau critique qui définit la taille maximale d’un paquet pouvant être transmis sur un lien réseau sans être fragmenté. Bien que la plupart des utilisateurs n’aient pas besoin de penser au MTU, il devient un facteur important de dépannage dans des scénarios spécifiques, en particulier avec l’authentification RADIUS et EAP-TLS. Cet article examine comment le MTU affecte le protocole RADIUS, notamment lorsqu’il s’agit de charges utiles volumineuses comme les certificats utilisés dans EAP-TLS, et pourquoi cela peut entraîner des échecs d’authentification. *** ## Introduction au MTU et à la fragmentation Le **MTU** est la plus grande taille de paquet qu’un réseau peut gérer sans le découper en morceaux plus petits. Le MTU standard pour la plupart des réseaux Ethernet est de 1500 octets. Lorsqu’un paquet est trop volumineux pour un lien réseau, il doit être soit abandonné, soit découpé en morceaux plus petits et acceptables, un processus appelé **fragmentation IP**. L’hôte de destination est responsable de la réassemblage de tous les fragments pour reconstituer le paquet d’origine. *** ## Fragmentation EAP vs fragmentation IP : pourquoi cette distinction est importante La distinction entre la fragmentation EAP et la fragmentation IP est cruciale pour comprendre les problèmes d’authentification. * **Fragmentation IP (couche réseau)**: C’est là qu’un routeur découpe un seul datagramme UDP en plusieurs paquets IP plus petits. Cela se produit sous la couche applicative RADIUS, qui n’a pas conscience que son paquet a été fragmenté. * **Fragmentation EAP (couche applicative)**: Le protocole EAP lui-même ne prend pas en charge la fragmentation, mais il fournit un cadre dans lequel des méthodes EAP individuelles, telles que EAP-TLS, peuvent mettre en œuvre leurs propres mécanismes de fragmentation. Lorsqu’un message EAP-TLS volumineux (par exemple un certificat) est trop grand pour le MTU, il peut être découpé en plusieurs fragments EAP. Chaque fragment est ensuite encapsulé dans son propre paquet RADIUS et envoyé individuellement. La différence clé est que **fragmentation IP** s’appuie sur le réseau pour réassembler les paquets, un processus qui échoue souvent. **La fragmentation EAP** s’appuie sur le client et le serveur pour gérer le réassemblage, ce qui est un processus plus robuste qui évite les problèmes au niveau du réseau. *** ## Le rôle de l’authentificateur dans la fragmentation Le client RADIUS, ou authentificateur, joue un rôle clé dans ce processus. Bien qu’il agisse comme un proxy, il peut être configuré pour fragmenter les messages EAP afin d’éviter la fragmentation IP. C’est la méthode préférée pour gérer les charges utiles volumineuses. Par exemple, un authentificateur peut être configuré pour découper un grand message EAP reçu d’un supplicant avant de l’encapsuler dans un paquet RADIUS et de l’envoyer au serveur. Cela garantit que le paquet est correctement dimensionné pour le chemin réseau. *** ## Framed-MTU vs taille de fragmentation EAP Le Framed-MTU est souvent confondu avec la fragmentation EAP. Le Framed-MTU est un attribut généralement envoyé dans un `Access-Accept` message du serveur RADIUS vers le client RADIUS. Son objectif est de définir le MTU IP pour la session de données de l’utilisateur après son authentification réussie. Il ne peut pas résoudre les problèmes de fragmentation qui surviennent pendant l’échange d’authentification lui-même, moment où la fragmentation EAP est nécessaire. Dans un scénario moins courant, l’attribut Framed-MTU peut également être envoyé du client RADIUS vers le serveur dans un `Access-Request` message afin d’indiquer le MTU que le client est capable de prendre en charge ou qu’il préférerait utiliser. C’est une indication ou une suggestion, pas une commande. Le serveur RADIUS est libre d’ignorer cette valeur ou de l’utiliser comme facteur pour déterminer le MTU de la session ; toutefois, ce n’est pas un mécanisme standard de négociation de la taille des fragments EAP. *** ## Pourquoi la fragmentation EAP est la meilleure solution La fragmentation EAP doit être configurée à la fois sur l’authentificateur et sur le serveur RADIUS afin de garantir une authentification EAP-TLS fiable et réussie. Comme le processus EAP-TLS est une conversation bidirectionnelle, les deux parties doivent être capables de fragmenter de grandes charges utiles. Il est également recommandé de configurer les deux côtés avec la même taille de fragment EAP afin d’assurer la cohérence et d’éviter les échecs d’authentification. Compte tenu de cette nécessité, lorsqu’un certificat volumineux provoque un échec d’authentification, cela est souvent dû à la fragmentation IP. Les pare-feu ou les dispositifs CGNAT peuvent abandonner les paquets fragmentés, provoquant un dépassement de délai de l’authentification. Au lieu de réduire de manière globale le MTU pour tout le trafic réseau, la bonne pratique consiste à configurer **la fragmentation EAP sur l’authentificateur et le serveur RADIUS.** Cette approche offre plusieurs avantages clés : * **Correctif ciblé**: Configurer une taille de fragment EAP spécifique sur l’authentificateur ou le serveur RADIUS résout directement le problème à sa source. Cela garantit que les paquets d’authentification volumineux sont découpés en morceaux plus petits et acceptables avant d’être envoyés sur le réseau, ce qui évite la fragmentation IP sans affecter les autres trafics. * **Pas d’impact significatif sur les performances du réseau global**: Réduire le MTU global d’une interface affecte tout le trafic réseau, ce qui peut entraîner une augmentation de la surcharge et une baisse de l’efficacité du réseau. En utilisant la fragmentation EAP, le reste du trafic du réseau continue d’utiliser le MTU standard, préservant ainsi des performances optimales. Bien que la fragmentation EAP crée davantage de paquets plus petits pour la même charge utile et puisse introduire une légère latence due à un plus grand nombre d’allers-retours, l’impact sur les performances du réseau global est négligeable et il s’agit d’un compromis nécessaire pour une authentification réussie. * **Conception spécifique au protocole**: Les méthodes EAP qui prennent en charge la fragmentation sont conçues pour gérer de grandes charges utiles. S’appuyer sur cette fonctionnalité intégrée est une approche plus fiable et conforme aux normes qu’un contournement au niveau de la couche réseau. Les équipements courants disposant de capacités client RADIUS (comme les commutateurs et points d’accès de Cisco, Aruba et Juniper) offrent une fonctionnalité permettant de configurer la fragmentation EAP. De même, les serveurs RADIUS comme FreeRADIUS disposent d’un `fragment_size` paramètre permettant de contrôler la taille maximale des fragments EAP. Il est important de noter que tous les fournisseurs n’offrent pas cette fonctionnalité. Par exemple, Meraki ne propose pas de paramètre de fragmentation EAP configurable par l’utilisateur dans son tableau de bord, ce qui peut constituer une limitation importante. *** ## Pourquoi la fragmentation échoue avec le CGNAT La fragmentation IP est une cause fréquente d’échecs d’authentification, en particulier sur les réseaux utilisant le NAT de classe opérateur (CGNAT), comme Starlink. * **Rejet des fragments**: De nombreux pare-feu et dispositifs CGNAT ne sont pas conçus pour gérer efficacement les paquets fragmentés. Pour des raisons de sécurité ou de performances, ils peuvent rejeter les fragments ou ne pas réussir à les réassembler correctement. * **Perte de paquets**: Si ne serait-ce qu’un seul fragment est perdu pendant le transit, le serveur ne peut pas réassembler l’intégralité du datagramme UDP d’origine. Comme UDP est sans connexion et ne dispose d’aucun mécanisme de retransmission, le serveur RADIUS ne reçoit jamais un `Access-Request`, et l’authentification échoue. L’absence de mécanisme de retransmission pour le trafic UDP fragmenté est la raison fondamentale pour laquelle la fragmentation IP est une solution peu fiable pour l’authentification. C’est pourquoi la configuration de la fragmentation EAP est la bonne solution. Elle garantit que les messages EAP sont déjà découpés en petits morceaux, empêchant ainsi leur fragmentation au niveau IP. Cela contourne les problèmes de fragmentation causés par les pare-feu ou les dispositifs CGNAT qui rejettent le trafic fragmenté. *** ## Conclusion L’interaction entre de grandes charges utiles de certificats EAP-TLS et le MTU d’un réseau peut être une cause cachée d’échecs d’authentification. Bien que le protocole RADIUS s’appuie sur le réseau pour gérer la fragmentation, les pare-feu et les dispositifs CGNAT rejettent souvent les paquets fragmentés. En comprenant la distinction entre la fragmentation EAP et la fragmentation IP, et en appliquant la bonne pratique consistant à configurer la fragmentation EAP sur l’authentificateur et le serveur RADIUS, vous pouvez vous assurer que les paquets d’authentification traversent le réseau intacts. Cette approche délibérée au niveau de la couche applicative offre une solution robuste et fiable, évitant les problèmes de connectivité courants et frustrants. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.radiusaas.com/fr/autre/troubleshooting/resoudre-la-fragmentation-eap-la-cle-dune-authentification-radius-fiable.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.