Le mode promiscuité sur un adaptateur VPN tue la connexion

Wireshark se comporte parfaitement sur une interface Ethernet puis, sur un adaptateur VPN, le tunnel cesse de faire passer le trafic à l’instant où la capture commence. La fenêtre de capture continue de se remplir, si bien que l’outil semble sain alors que la connexion en dessous meurt. Le mode promiscuité est la cause habituelle, car un pilote de tunnel à qui l’on demande chaque trame d’un segment qu’il n’a pas peut finir dans un état où rien ne sort.

Désactivez d’abord cette option, puis décidez quelle couche vous avez réellement besoin de voir.

Deux adaptateurs, deux vues différentes

Un client VPN présente généralement deux interfaces : la physique qui transporte le trafic chiffré, et une virtuelle qui transporte le trafic interne déchiffré. Elles répondent à des questions différentes. La capture physique montre les extrémités, les ports et la taille des paquets, tandis que la virtuelle montre les protocoles applicatifs tels que le tunnel les livre. Choisir l’une sans savoir quelle question on pose gaspille la capture.

Aucune vue n’est un sur-ensemble de l’autre, et une capture répond rarement aux deux questions à la fois.

Choisissez l’interface d’après la question plutôt que d’après l’ordre de la liste, car un client de style PPP peut présenter son adaptateur comme un périphérique Ethernet et le nom affiché ne vous dira pas quelle couche vous avez choisie. Une capture sur une passerelle ou un port miroir ajoute une troisième vue, qui montre le chemin après le transfert, et c’est là que le routage asymétrique et le filtrage deviennent visibles.

Pourquoi le mode promiscuité casse un adaptateur de tunnel

Le mode promiscuité demande au pilote de livrer des trames qui ne sont pas adressées à l’hôte, ce qui a du sens sur un segment Ethernet partagé et très peu de sens sur un tunnel point à point. Certains pilotes gèrent la demande avec calme ; d’autres cessent de retirer le trafic d’émission de la file, et l’interface devient silencieusement un trou noir. La capture enregistre toujours ce qui arrive, si bien que le fichier ressemble à la preuve d’une liaison qui fonctionne. Cet écart entre ce que montre le fichier et ce que l’interface a fait, c’est tout le piège.

Désactivez l’option avant le premier paquet, gardez le filtre de capture étroit et utilisez un petit tampon. Un grand tampon circulaire sur une interface chargée laisse tomber précisément les trames qui comptaient, ce qui produit une capture complète partout sauf là où était la panne.

Si la liaison se bloque en pleine capture, arrêtez-la et observez la reprise. Cette seule observation sépare un effet secondaire de la capture d’une véritable panne du tunnel, et elle prend moins de temps que n’importe quel réglage de filtres.

Rendre une capture IPsec lisible

Une capture IPsec seule n’est pas lisible, car ESP chiffre la charge utile. Wireshark peut la décoder lorsque vous fournissez les clés de session, ou lorsqu’il peut suivre la négociation IKE qui les a produites, ce qui signifie que la poignée de main doit se trouver dans le même fichier.

Les clés expirent. Après que les pairs ont renouvelé les clés, un jeu d’anciennes clés cesse de fonctionner au milieu de la capture, et le résultat ressemble à un bogue du décodeur plutôt qu’à une limite temporelle.

Suivez le format de clés documenté par le fournisseur au lieu d’importer du matériel d’une source sans rapport, et attendez-vous à ce que certaines plateformes refusent entièrement ce flux de travail. Quand la passerelle ne veut pas livrer les clés ni autoriser la capture, acceptez que la charge utile ne soit pas inspectable depuis votre position. Les journaux des extrémités et les compteurs d’interface sont les preuves restantes, et ils suffisent généralement pour une question de routage.

Une capture que vous pouvez partager en sécurité

Une capture interne est plus proche d’un vidage d’identifiants que d’un journal. Elle peut contenir des noms, des adresses et du texte en clair issus de protocoles écrits en supposant que personne ne les lirait jamais, ce qui fait du fichier lui-même l’artefact sensible plutôt que de l’analyse.

Assurez-vous que l’hôte et le réseau sont des environnements où vous avez le droit de capturer, notez à la fois l’interface et le filtre avec le résultat, limitez la session aux quelques minutes qui répondent à la question, et supprimez le fichier quand vous avez terminé. S’il doit être partagé, décrivez d’abord le flux ou retirez la charge utile.

Reprenez ensuite la tâche initiale de l’utilisateur. Une capture qui prouve qu’un paquet est arrivé n’est pas la preuve que l’application a accepté la réponse, et la différence entre les deux est généralement là où se trouve la vraie panne.