Pourquoi votre capteur VPN ne voit jamais l’étiquette VLAN de l’agence

Un capteur côté VPN voit deux VLAN d’agence comme un trafic IP ordinaire, et l’étiquette qui identifiait chaque agence sur son propre câble a disparu. C’est ce que fait un tunnel routé : il récupère des paquets, pas les trames Ethernet qui les ont livrés. Que l’étiquette manquante ait de l’importance dépend entièrement de la question que vous posez au capteur. Effectuez les quatre vérifications ci-dessous dans l’ordre et vous saurez quel point d’observation peut y répondre.

Premièrement : établissez ce que votre tunnel récupère

Une interface TUN transporte des paquets IP, donc l’en-tête VLAN de la trame d’agence s’arrête au routeur qui a poussé le trafic dans le tunnel. Une interface TAP transporte des trames Ethernet, ce qui signifie que les étiquettes peuvent survivre lorsque le pont et les règles d’admission VLAN les laissent passer. Lisez le type d’interface avant de raisonner sur ce qu’une capture devrait contenir.

Aucun des deux choix n’est un défaut. Les deux conceptions répondent à des questions différentes et laissent l’étiquette à des endroits différents.

Vérifiez l’interface vous-même au lieu de la déduire du nom du produit. Les détails de la liaison nomment le type d’appareil et montrent les indicateurs en vigueur, et une capture prise sur un appareil TUN ne gagnera pas d’en-tête Ethernet simplement parce que vous l’avez demandé. Si des étiquettes apparaissent malgré tout sur une capture TUN, vous lisez presque certainement une autre interface ou un tunnel qui transporte des trames à l’intérieur de sa charge utile. Notez dans quel cas vous vous trouvez avant de continuer.

Deuxièmement : placez le capteur là où l’objet existe encore

Trois positions couvrent la plupart des conceptions routées : le segment Ethernet de l’agence, le réseau extérieur entre les extrémités du tunnel et le chemin après le traitement du tunnel. Chacune voit un objet différent, et l’étiquette n’existe qu’à la première. Choisir une position de capteur est une décision sur l’objet dont la politique a besoin, pas une question de commodité.

Posez la question de politique dans des termes auxquels la table peut répondre, et elle se règle généralement d’elle-même. Si la règle doit savoir de quelle agence vient un paquet, la correspondance de préfixes en aval peut suffire, mais seulement tant que cette correspondance reste exacte et non ambiguë. Si la règle doit savoir par quel port la trame est arrivée, il vous faut la première position, car rien en aval ne peut la reconstruire. Les capteurs placés par habitude plutôt que par question sont la façon dont les équipes finissent par exiger un champ que la conception n’a jamais porté.

Un tunnel qui transporte de l’Ethernet est une conception différente et demande sa propre vérification de ce que les extrémités préservent ou réécrivent. Choisir TAP seul ne définit toujours pas le pont, les règles d’admission VLAN ni la politique d’inspection.

Troisièmement : gagnez le contexte de source au lieu de lui faire confiance

Une plage d’adresses par agence est le substitut habituel de l’identité VLAN, et elle ne tient que tant que la correspondance reste un pour un. Les préfixes qui se chevauchent, la traduction et une passerelle partagée brisent chacune cette hypothèse d’une manière qui ressemble à un problème de qualité des données plutôt qu’à un problème de conception. Écrivez la correspondance avec ses limites et dites ce qui arrive à un paquet qui correspond à deux lignes. Un préfixe qui apparaît dans deux agences devrait être une erreur que vous détectez, pas un tirage au sort que vous acceptez.

Le contexte fourni par le client n’est pas une preuve d’appartenance. C’est une affirmation, et sa place est dans une autre colonne.

Là où la distinction compte, utilisez des données d’association que vous contrôlez : quelle instance de tunnel a accepté la connexion, sur quelle interface les paquets sont arrivés, ce que la table de routage locale dit de ce pair. Une étiquette fournie par le client est un indice utile et une entrée d’autorisation inutile. Si le capteur ne peut pas établir l’association de son propre côté, la politique a besoin d’une règle plus large plutôt que d’une supposition confiante.

Quatrièmement : confirmez le chemin de réponse et ce que manque le déchiffrement

Un capteur qui ne voit qu’une seule direction peut encore sembler sain, parce que les requêtes continuent d’arriver à l’heure. Vérifiez le chemin de réponse explicitement, et vérifiez-le pour le même flux plutôt que pour une accessibilité générale. La visibilité semi-duplex devient un trou silencieux dans toute conclusion avec état que vous en tirez.

Récupérer le trafic IP interne n’est pas non plus la même chose que voir l’application à l’intérieur, car le TLS transporté sur le tunnel reste du TLS.

ip -d link show tun0
tcpdump -i tun0 -n -e -c 5

Ces deux commandes répondent à la question de l’interface et montrent ce que la capture contient réellement, ce qui est plus rapide que de discuter de l’architecture. Remplacez le nom d’interface que votre conception utilise et lancez la capture pendant que le flux qui vous intéresse est actif. Quand aucune étiquette n’apparaît sur un appareil TUN, le constat est que la conception a routé au lieu de ponter, et non que le capteur a perdu des données. Ensuite, déplacez le capteur vers une position qui peut voir l’étiquette, ou réécrivez la règle dans des termes que la position actuelle peut soutenir.