Paquets internes et externes dans une capture VPN : pourquoi les tailles diffèrent

Vous capturez des paquets de 1400 octets sur l’interface du tunnel, vous capturez à nouveau sur l’interface physique, et les chiffres refusent de concorder. Les adresses diffèrent, les tailles diffèrent, et le second fichier ressemble à une autre conversation. Rien n’est cassé. Deux paquets différents se trouvent à deux couches différentes, et l’écart entre eux est ce que le tunnel fait à votre trafic. Lisez les deux vues avant d’accuser le MTU.

Deux points de vue et le paquet que chacun montre

Une capture prise sur l’interface du tunnel montre le paquet interne : la charge de l’application avec sa source et sa destination d’origine, avant qu’une protection quelconque soit appliquée. Une capture sur l’interface physique montre le paquet externe : un en-tête IP, un en-tête de transport, l’encapsulation, puis le paquet interne chiffré comme charge. Même conversation, objets différents. Dès que vous nommez lequel des deux le fichier contient, la discordance cesse d’être un mystère.

La différence de taille est une surcharge, et la différence d’adresse est un choix de conception. Retournez la question et la confusion devient prévisible : les gens comparent un paquet interne de 1400 octets à un paquet externe de 1450 octets, concluent que quelque chose cloche et commencent à modifier des réglages MTU qui n’étaient jamais en cause. Étiquetez le fichier avec l’interface et la couche, car cette étiquette est la première chose dont un lecteur a besoin et la première que les gens omettent.

Décidez la couche avant de commencer la capture

Décidez quelle couche répond à votre question avant que le premier paquet soit écrit. Une question de MTU demande généralement la vue externe, car c’est là que les en-têtes s’accumulent et que la limite du chemin apparaît. Une question applicative demande généralement la vue interne, car c’est là que la charge qui vous intéresse existe encore. Capturer les deux sans plan produit deux fichiers et aucune conclusion.

Utilisez un test inoffensif et autorisé, et filtrez sur la source, la destination et le moment qui vous intéressent. Lisez l’interface et les options de filtre de l’outil de capture avant de collecter, car les métadonnées suffisent généralement et sont bien plus faciles à partager que la charge. Traitez la capture interne comme sensible par défaut, car elle contient des données applicatives non chiffrées qui ne sont protégées que plus loin sur le chemin.

Ce que contient réellement la différence de taille

Le paquet externe porte des en-têtes supplémentaires et du matériel de protection, et combien il en porte dépend du protocole et de ses options. La fragmentation, l’agrégation ou la réorganisation le long du chemin peuvent briser la relation apparemment un pour un entre un paquet interne et les paquets externes qui le portent, si bien qu’une comparaison taille par taille n’est pas toujours disponible. Pour un soupçon de panne MTU, cherchez un retour sur la taille et le point où le trafic s’arrête, puis comparez-le à ce que l’application signale. Un schéma de retransmission sans réponse est un signal différent d’une erreur ICMP portant la taille du saut suivant.

Un seul paquet qui quitte l’hôte ne prouve rien quant à sa réception par l’extrémité distante. Si votre capture s’arrête à votre propre interface, vous avez montré que le noyau a émis quelque chose, ce qui est la preuve la plus faible disponible sur le chemin. Combinez la capture avec un symptôme reproductible : même destination, même opération, même taille, exécuté deux fois avec une variable modifiée.

Lire le délestage dans les chiffres

La segmentation côté hôte et les autres délestages ajoutent une seconde distorsion, et c’est elle qui fait diverger les captures locales du fil. Une capture locale peut montrer des tampons que l’adaptateur découpe ensuite, si bien que les trames sur le lien sont plus petites et plus nombreuses que le fichier ne le suggère. C’est pourquoi un gros tampon dans le fichier de capture ne prouve pas qu’une trame surdimensionnée ait traversé chaque lien. Si les tailles comptent pour votre conclusion, notez où la capture a été prise et si le délestage était actif sur cette interface.

Sinon, vous mesurez le confort de l’hôte plutôt que le comportement du chemin. Deux fichiers étiquetés avec leur interface et leur état de délestage règlent la plupart de ces débats en une minute.

Où la capture cesse d’être une preuve

Voir des paquets externes chiffrés montre qu’une frontière de protection existe dans ces conditions de test, et cela ne dit rien des autres applications de l’appareil, de la gestion de l’opérateur ni de l’état de l’extrémité elle-même. Voir du texte en clair dans le tunnel ne signifie pas non plus que le tunnel est cassé ; cela signifie que vous avez capturé au-dessus du point de chiffrement, ce qui est un endroit légitime où regarder. Une capture est une preuve sur un lieu, pas un verdict sur un système, et le ticket devrait la décrire ainsi. Gardez la phrase de périmètre dans le rapport, car c’est elle qui empêche une seule observation de devenir une affirmation d’audit.

Nommez chaque fichier avec son interface, son filtre et son horodatage, et supprimez-le quand l’enquête se termine. Le manuel de tcpdump documente les options d’interface et de filtre utilisées ici, y compris celles qui gardent une capture petite.

Si vous devez partager des preuves, partagez des tailles, des horodatages et des options plutôt que la charge. La question portait sur la taille des paquets, et la réponse a rarement besoin des données de quelqu’un.