Balises VLAN non affichées dans la capture de paquets (Linux) via tcpdump

J'ajoute un VLAN balisé sur eth0:

#ip link add link eth0 name eth0.20 type vlan id 20

Il en résulte:

#ip link
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
 link/ether 9c:c7:a6:95:65:1c brd ff:ff:ff:ff:ff:ff
....
12: eth0.20@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
 link/ether 9c:c7:a6:95:65:1c brd ff:ff:ff:ff:ff:ff

#ip -d link show eth0.20
70: eth0.20@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 9c:c7:a6:95:65:1c brd ff:ff:ff:ff:ff:ff
    vlan id 20 <REORDER_HDR>

#cat /proc/net/vlan/config
VLAN Dev name    | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
eth0.234       | 234  | eth0
eth0.20        | 20  | eth0

Maintenant je démarre dhclient:

#dhclient -d -v -1 eth0.20

Ce que je vois dans tcpdump est un cadre de découverte DHCP non balisé:

#tcpdump -i eth0 -XX
0x0000:  ffff ffff ffff 9cc7 a695 651c 0800 4500 
                                       ^^^^

Pourquoi n'est-il pas marqué?

Le module 802.1q semble être utilisé:

#lsmod | grep 8021q
8021q                  28324  0
garp                   14311  1 8021q

(OS: noyau SLES11SP2 3.0.13-0.27 par défaut)

BTW autre trafic n'est pas marqué non plus (au moins tcpdump ne l'affiche pas) ...

Mise à jour 16 octobre

 # tcpdump -Uw - | tcpdump -i eth0 -en -r - &
[1] 7310
 # tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

 # dhclient -d -v -1 eth0.20
Internet Systems Consortium DHCP Client 4.2.3-P2
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0.20/9c:c7:a6:95:65:1c
Sending on   LPF/eth0.20/9c:c7:a6:95:65:1c
Sending on   Socket/fallback
DHCPDISCOVER on eth0.20 to 255.255.255.255 port 67 interval 3
reading from file -, link-type EN10MB (Ethernet)
18:49:14.437882 9c:c7:a6:95:65:1c > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 347: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 9c:c7:a6:95:65:1c, length 305
                                                                       ^^^^^^

Donc, toujours aucune balise affichée ici.

Mais en effet, le compteur de transmission pour eth0.20 dans / proc / net / dev s'incrémente lors de l'exécution de dhclient ...

dhcp linux-networking vlan

— Marki
source

pouvez-vous exécuter "ip -d link show eth0.20"?

— Danila Ladner

Bien sûr, j'ai ajouté les informations à la question.

— Marki

Êtes-vous sûr que le trafic apparaît également sur le câble sans balises VLAN? Cela pourrait simplement être une bizarrerie libpcap avec la façon dont les interfaces VLAN sont implémentées ip link.

— le-wabbit

ok, aussi ce que "cat / proc / net / vlan / config" dit?

— Danila Ladner

J'ai étendu la question avec la sortie de configuration. J'essaierai également de capturer en dehors du système d'exploitation et de vous tenir au courant.

— Marki

Vous ne pouvez pas voir la balise VLAN à partir de la tcpdump -i eth0sortie sur l'architecture i686 / x86_64 en raison de l'accélération VLAN. la couche VLAN sera filtrée par le noyau afin qu'elle ait toujours l'air non balisée. Veuillez vous référer au bogue 498981 - tcpdump ne peut pas gérer la balise vlan 802.1q

Selon votre cas, vous pouvez obtenir des balises VLAN via:

tcpdump -i eth0 -Uw - | tcpdump -en -r - vlan 20

Vous devriez voir la sortie suivante:

<timestamp> <mac-addr-of-eth0> > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 20, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP

— shawmzhu
source

Vous avez tort. Je parle de l' envoi par Linux d' une découverte DHCP. Il doit être étiqueté. Soit ce n'est pas le cas, soit l'affichage est incorrect. Cela n'a rien à voir avec l'interrupteur auquel la machine est connectée.

— Marki

@Marki désolé de ne pas avoir bien compris votre point. voici la version mise à jour après une étude de 20 minutes via google. ce commentaire est la clé de votre question.

— shawmzhu

Ouais tu sembles avoir raison. Il faut être prudent avec tout ce qui se trouve sur la couche 2. Il faut également faire attention au client DHCP car il semble utiliser des sockets bruts dans certains cas (donc vous ne pouvez même pas capturer les paquets à l'aide d'iptables). Et en outre, lorsque vous utilisez VMware, vous ne devez en aucun cas marquer les paquets dans la machine virtuelle car le vSwitch les rejettera, vous devez configurer une interface dédiée pour cette machine virtuelle dans ce VLAN sur le vSwitch. Rassembler tout cela n'était pas facile ... ;-)

— Marki

D'un autre côté ... voir mon montage ci-dessus ... ne semble pas être si simple après tout. Mais de toute façon mon problème est résolu, je ne peux pas envoyer de paquets marqués de la machine virtuelle de toute façon. Mais pour les hôtes purement physiques, cela pourrait être un problème ...

— Marki