#Blog_IT > orienté systèmes et réseaux

Gestion du MTU avec un VPN ISPEC

Aucun commentaire
On se préoccupe peu du MTU au quotidien, mais pourtant lorsque l’on fait du VPN IPSEC, nous sommes bien obligé de l'appréhender. On peut se retrouver avec un tunnel VPN monté mais avec du trafic qui ne passe pas en TCP.
Il existe des mécanismes dans les routeurs des équipementiers qui permettent de s'affranchir du problème, mais pas toujours de manière optimale et souvent sans le comprendre.

Le Maximum Transmission Unit désigne donc la taille maximum de données pouvant être transmis dans une trame ethernet. Cette taille maximale est de 1500 octets.

Voici une trame Ethernet :



Le problème arrive lorsque les données sont encapsulées par  ESP/AH pour le chiffrage/intégrité des données transitant dans le VPN.




Screen Shot 2013-11-12 at 11.52.30 AM.png



La donnée est encapsulée par ces services et tout cela occupe de la place. Si on avait 1500 octets de donnée maximale au départ on se retrouve avec bien plus et cela ne peut pas passer en une seule transmission. TCP va alors utiliser la fragmentation du paquet IP pour le faire passer en plusieurs fois.
Trop de fragmentation engendre plusieurs problèmes :
- surchage CPU des routeurs
- paquet arrivant dans le désordre
- performance

Faut il encore que nos routeurs puissent fragmenter les paquets et les remettre en ordre....

En théorie avec le PMTU (MTU discover), un signal ICMP est renvoyé à l'émetteur pour lui signaler que la trame a été rejetée à cause de sa longueur. (Fragmentation needed). L'émetteur va alors recommencer, avec des paquets plus petits, jusqu'à ce que ça passe.

De plus si le firewall bloque tous les ICMP on perd la trame Ethernet. C'est le message ICMP type 3 code 4 qui permet le PMTU.

D'où l'importance de connaitre le MTU de ses interconnexions VPN, et d'informer les équipements réseaux du VPN de ce MTU.

Pour connaitre cette MTU, nous allons utiliser un ping depuis une station distante avec l'option don't fragment packet. 

Sur Cisco attention de ne pas avoir de paramétré crypto ipsec df-bit clear sur l'interface à ping

ping ipdel'interfacedurouteur tailledupaquet -f -l
Lorsque il ya un retour icmp ça passe, quand nous avons le message Le paquet doit être fragmenté mais paramétré DF.le paquet est trop gros.

La taille maximale du paquet qui passe nous donnera la MTU du site distant avec la formule : MTU = taille du paquet  max+ 8 octets ICMP + 20 octets en tête IP


Cisco à mis en ligne un outil très intéressant qui permet de calculer la taille occupée par les services IPSEC selon les paramètres de chiffrage, de hachage, etc...

c'est ici :  https://cway.cisco.com/tools/ipsec-overhead-calc/ipsec-overhead-calc.html

On peut donc prévoir la taille du MTU. Ne pas oublier éventuellement PPPOE : 8 octets.

En connaissant le MTU on peut se prémunir de la fragmentation et des transmissions impossibles :

> Soit en fixant cette MTU sur l'interface externe, dans quel cas on oblige les paquets sortant à se mettre au pas de la MTU, mais cela concernera aussi le trafic non VPN

> Soit en utilisant le MSS sur l'interface d'émission du VPN et gérer ansi le trafic entrant et sortant. Le Maximum Segment Size est informé lors d'une négociation TCP

MSS = MTU - 40












Sur un routeur Cisco on indiquera cette valeur sur l'interface intérieur d'une des 2 parties du traffic VPN:

ip tcp adjust-mss valeur
 il est possible de voir la fragmentation en auditant le trafic avec cette commande :

sh ip traffic | include frag

Ceci ne fonctionne que pour TCP.
UDP n'est généralement pas utilisé avec les paquets "large", si c'est le cas, il faut fragmenter à tout prix ... on utilise donc la commande

crypto ipsec df-bit clear









Aucun commentaire :

Enregistrer un commentaire