Captură frame-uri dot1q in Wireshark dintr-un VM pe ESXi

Într-un test de laborator recent am încercat să realizez o captură de pachete pentru frame-urile ce tranzitează o interfață trunk pe un switch Cisco. Pentru aceasta, am folosit o mașină virtuală pe un ESXi pe care am instalat Wireshark-ul. VM-ul l-am conectat pe un switch virtual dedicat al cărui singur uplink l-am cuplat direct la switch-ul fizic. Pe switch-ul virtual grupul de porturi a fost configurat cu transport de VLAN-uri către VM-uri – mod cu Virtual Guest Tagging (VLAN ID = 4095) și in regim cu Promiscous Mode = Enabled setat din politicile de securitate pe grup. Portul spre ESXi pe switch-ul fizic l-am configurat ca destinație de mirroring la interfața trunk monitorizată. Schema conexiunilor o vedeți mai jos:

dot1q_tagged_capture_scheme

Până aici totul a fost simplu și mă așteptam ca totul să funcționeze corect, dar nu a fost așa. E adevărat că din moment ce am pornit captura, pachetele aparținând mai multor VLAN-uri au început să ajungă în raportul de Wireshark. Totul părea as expected cu o singură dar importantă excepție: frame-urile înregistrate erau lipsite de header-ul lor original fiind re-încapsulate în frame-uri non-802.1q. Acestea arătau ca și cum făceau parte dintr-un singur VLAN și doar informațiile din header-ul IP-ului mai sugera VLAN-ul origine a pachetelor.

dot1q_tagged_capture_dot1q_stripped

Colegul meu Iurie mi-a sugerat o explicație pentru fenomenul observat. Adevărul e că unele drivere de NIC-uri in configurația lor implicită sunt obligate să re-încapsuleze frame-urile cu tag 802.1q în frame-uri Ethernet fără tag-uri. Așa de exemplu o fac NIC-urile Intel și Broadcom (more info). În VM-ul cu Wireshark am folosit un adaptor Intel emulat (E1000) care se pare că in configurația sa are același comportament ca și conterpart-ul lui fizic – acela de a lipsi frame-urile de header-ul original 802.1q. Mi-a venit atunci în cap să înlocuiesc vNIC-ul din VM cu un alt model disponibil dar se pare că până la urmă E1000 instalat inițial rămâne a fi unica opțiune funcțională. Să revizuim fiecare tip de adaptor disponibil pentru VM-uri pe un host ESXi (pentru mai multe informații totuși, vedeți articolul VMware KB1001805):  

  • adaptor Flexible ce poate funcționa fie in regim cu emulare a dispozitivului AMD PCnet32 (VLANCE) fie in regim sintetic ca vmxnet funcție de disponibilitatea componentelor vmware tools. Nici unul din dispozitive nu știe să opereze cu frame-uri 802.1q – acestea sunt pur și simplu ignorate de vNIC, cel mai probabil pentru că dă un CRC greșit.
  • vmxnet2, vmxnet3 – dispozitive sintetice care înțeleg frame-uri 802.1q dar care totuși sunt limitate în configurația pe driver. Bunăoară, un astfel de dispozitiv poate fi asociat doar cu un singur VLAN, frame-urile din restul VLAN-urilor fiind ignorate. Un VLAN se asociază cu un NIC vmxnet2/3 prin parametru VLAN ID din setările Advanced Settings pe NIC (vezi screen-ul de mai jos)

REM: Se pare că există o excepție pe Linux pentru vmxnet3 care accepta asocierea cu mai multe VLAN-uri (more info in additional information din KB1004252) dar încă nu am verificat să văd cum e.

  • E1000, E1000e – NIC-uri ce emulează dispozitivele Intel 82545EM (Intel PRO/1000 MT)  și respectiv Intel 82574. Ultimul mai nou, disponibil doar in Guest OS-uri recente. Pe un Windows 7/ Windows 2008R2 poate fi instalat doar E1000. Ca și analogul fizic dispozitivele emulate știu să interpreteze frame-uri 802.1q.

Așadar, din toate opțiunile posibile doar E1000 rămâne a fi valid pentru use case-ul nostru. În teorie, pe un VM cu un adaptor E1000 s-ar putea de interpretat frame-uri cu header 802.1q ba chiar să le lăsăm să treacă nemodificate mai sus spre o aplicație Wireshark. Implicit, E1000 scoate header-ul 802.1q așa că va trebui să ajustăm unii parametri din configurația driver-ului ca acesta să lase frame-urile nemodificate.

De menționat că la adăugarea unui dispozitiv E1000 la un VM, de regulă, automat sunt instalate driverele distribuite cu sistemul de operare (in cazul meu MS Windows). Acestea diferă de cele originale Intel și sunt limitate ca posibilități de configurații adiționale. Așa că pentru început va trebui să înlocuim driverele Microsoft cu drivere Intel. Pentru un ghid detaliat revizuiți KB-ul VMware: KB1004252. In KB scopul înlocuirii driver-ului e pentru a face posibilă instalarea extensiilor Intel Advanced Network Services (ANS) – din care mai departe să se creeze sub-interfețe asociate cu mai multe VLAN-uri și e altul decât scopul nostru de a modifica configurația driver-ului în așa fel încât frame-urile să treacă cu header-ul lor original. Pe scurt, pentru a înlocui driver-ul pentru un NIC E1000 într-un VM cu OS Windows:

  • se descarcă pachet-ul de instalare ce conține driverul pentru Intel PRO/1000 MT. Articolul dă un link direct dar poate fi gasit cu search pe pagina de download Intel.
  • se despachetează pachet-ul de instalare (prowinx64.exe) – eu am folosit WinRAR-ul.
  • manual se instalează driver-ul dispozitivului. Din proprietățile adaptorului se accesează Update Driver Software Browse my computer .. – Let me pick from a list of .. – Have Disk după care se specifică calea către fișierul inf: pro1000\winx64\ndis61\e1g6032e.inf.

REM: De menționat că driverele pot fi instalate doar in regim manual așa cum e descris mai sus, executarea directă a pachetului de instalare nu instalează drivere – acesta e destinat pentru instalarea extensiilor Intel Advanced Network Services (ANS)

  • se reboot-ează VM-ul. Din acest loc dacă e nevoie pot fi instalate și extensiile ANS (care arată ca tab-uri in plus in fereastra standard de configurare a unui NIC). Prin ANS se pot realiza mai multe configurații suplimentare gen sub-interfețe asociate cu VLAN-uri, team-inguri de high availability și load balancing ș.a.m.d Chiar dacă oferă configurații in plus ANS-ul nu are settings-ul căutat de noi pentru livrarea nemodificata a frame-urile dot1q prin NIC spre aplicații.

În screen mai jos, Advanced Settings pentru un adaptor VMXNET3 și tab-uri de configurație Intel Advanced Networking Services în fereastra de configurație a unui adaptor E1000 (Intel PRO/1000 MT):

dot1q_tagged_capture_NIC_advanced_settings

Acum că ne-am înarmat cu drivere originale Intel, putem încerca re-configurarea driver-ului pentru ca acesta să lase nemodificate frame-urile cu header dot1q. Pentru un sistem de operare Microsoft Windows pașii de parcurs sunt descriși în următorul articol Intel: My Sniffer is Not Seeing VLAN, 802.1q, or QoS Tagged Frames și de fapt se reduc la introducerea în regiștrii sistemului de operare a parametrului MonitorModeEnabled=1.  Din articol, MonitorModeEnabled=1 e descris ca: „(Store bad packets. Store CRCs. Do not strip 802.1Q vlan tags)  și este exact ceea ce căutăm.

De aici încolo lucrurile au început să nu mai funcționeze. Am încercat pașii descriși în articol pentru reconfigurarea driver-ului dar fără nici un efect, toate frame-urile tagged ca și înainte erau re-încapsulate în frame-uri non-dot1q. Posibil am dat de un bug, posibil să fi făcut eu ceva greșit dar până la urmă așa și nu a mai funcționat. Dacă cuiva totuși i sa primit configurația, scrieți-mi un mail, sunt nerăbdător să confirm că funcționează.

Așa cum procedeul de mai sus nu a mai fost posibil, până la urmă am găsit o altă soluție alternativă. Se pare că pe sistemele de operare Linux driver-ul pentru PRO/1000 MT in configurația lui implicită nu re-încapsulează frame-urile dot1q, fapt remarcat în articolul Intel menționat mai sus: „For Linux … By default, the driver in promiscuous mode does not strip VLAN tags.În așa fel, soluția finală a fost să re-instalez in VM-ul cu Windows un distributiv Linux (am folosit Ubuntu) pe care am pus Wireshark-ul. Fără nici o setare in plus, după pornirea capturii, Wireshark-ul a început să înregistreze frame-uri în formatul lor original, nemodificate, cu header 802.1q. Includ mai jos un screen cu detaliile la câteva pachete înregistrate in VM-ul cu Linux.

dot1q_tagged_capture_dot1q_Linux_notstripped

Articole menționate în text: