Как анализировать трафик виртуальной инфраструктуры, использующей VMware NSX

Виртуализация прочно вошла в нашу жизнь, и мы все чаще в проектах встречаем необходимость захвата трафика или снятие копии трафика для мониторинга производительности приложений, которые развернуты внутри виртуальной инфраструктуры. Компания VMWARE представила и активно развивает новую платформу NSX для виртуализации сети, которая набирает популярность. Поэтому в рамках данного практикума мы решили рассказать, как встроенное средство ESXi - pktcap-uw можно использовать для диагностики NSX и захвата трафика.

Для того чтобы оценить возможности был собран вот такой стенд. Для каждого эксперимента генерировался трафик ICMP и/или SSH между виртуальными машинами:

На скриншоте ниже указаны правила, настроенные на NSX Distributed Firewall (DFW).

Ну а теперь приступим к захвату трафика в разных местах виртуального пространства.

1. Захват трафика из и в виртуальную машину

Для того чтобы контролировать трафик на уровне входа и выхода из виртуальной машины мы можем воспользоваться идентификатором порта виртуального коммутатора –switchport . В данной точке мы видим трафик еще не затронутый правилами NSX файервола и не инкапсулированный в какой-либо VXLAN. В данном примере мы будем собирать трафик при общении между двумя виртуальными машинами Web 1 и Web 2 на уровне виртуального сетевого адаптера Web1. Точка захвата указана на диаграмме.

Для того чтобы получить идентификатор порта (port-ID) существуют два способа. Первый способ запустить команду esxtop на ESXi Compute1 и получить список, в котором присутствует и наш сервер Web 1:

Способ 2 запустить команду net-stats -l и также увидеть port-ID:

[root@compute1:~] net-stats -l

PortNum Type SubType SwitchName MACAddress ClientName

33554434 4 0 vSwitch0 00:0c:29:db:8c:f0 vmnic0

33554436 3 0 vSwitch0 00:0c:29:db:8c:f0 vmk0

33554437 3 0 vSwitch0 00:50:56:63:1b:bb vmk1

33554438 3 0 vSwitch0 00:50:56:65:b8:b8 vmk3

50331650 4 0 vSwitch1 00:0c:29:db:8c:04 vmnic2

67108866 4 0 vSwitch2 00:0c:29:db:8c:0e vmnic3

83886082 4 0 DvsPortset-0 00:0c:29:db:8c:fa vmnic1

83886084 3 0 DvsPortset-0 00:50:56:6c:a8:61 vmk2

83886086 5 9 DvsPortset-0 00:50:56:9c:36:ac WEB1.eth0

[root@compute1:~]

Для того чтобы видеть трафик в двух направлениях нам необходимо запустить 2 сессии захвата трафика — для направления из машины Web1 – это направление –dir 0, а направление в машину Web 1 - dir 1. Формат и опции команды pktcap-uw можно уточнить в базе знаний Vmware.

Между машинами генерировался трафик и все пакеты сохранялись в файлы VM-WEB1.OUT.pcap и VM-WEB1-IN.pcap

[root@compute1:~] [root@compute1:~] pktcap-uw --switchport 83886086 --dir 0 --dstip 10.1.100.12 -o VM-WEB1.OUT.pcap

The switch port id is 0x05000006

The dir is Rx

The session filter destination IP address is 10.1.100.12

The output file is VM-WEB1.OUT.pcap

No server port specifed, select 46305 as the port

Local CID 2

Listen on port 46305

Accept...Vsock connection from port 1067 cid 2

Dump: 6, broken : 0, drop: 0, file err: 0Join with dump thread failedDestroying session 43

Dumped 6 packet to file VM-WEB1.OUT.pcap, dropped 0 packets.

Done.

[root@compute1:~]

[root@compute1:~] pktcap-uw --switchport 83886086 --dir 1 --srcip 10.1.100.12 -o VM-WEB1-IN.pcap

The switch port id is 0x05000006

The dir is Tx

The session filter source IP address is 10.1.100.12

The output file is VM-WEB1-IN.pcap

No server port specifed, select 46308 as the port

Local CID 2

Listen on port 46308

Accept...Vsock connection from port 1068 cid 2

Dump: 1, broken : 0, drop: 0, file err: 0Join with dump thread failedDestroying session 44

Dumped 1 packet to file VM-WEB1-IN.pcap, dropped 0 packets.

Done.

[root@compute1:~]

Далее можно воспользоваться TCP Dump или Wireshark для анализа трафика:

[root@compute1:~] tcpdump-uw -r VM-WEB1-OUT.pcap

reading from file VM-WEB1-OUT.pcap, link-type EN10MB (Ethernet)

09:08:18.111526 IP 10.1.100.11 > 10.1.100.12: ICMP echo request, id 7877, seq 1, length 64

09:08:20.913056 IP 10.1.100.11.43534 > 10.1.100.12.ssh: Flags [S], seq 2293133161, win 29200, options [mss 1460,sackOK,TS val 278378 ecr 0,nop,wscale 5], length 0

09:08:21.912298 IP 10.1.100.11.43534 > 10.1.100.12.ssh: Flags [S], seq 2293133161, win 29200, options [mss 1460,sackOK,TS val 278628 ecr 0,nop,wscale 5], length 0

09:08:23.112307 ARP, Request who-has 10.1.100.12 tell 10.1.100.11, length 46

09:08:23.916291 IP 10.1.100.11.43534 > 10.1.100.12.ssh: Flags [S], seq 2293133161, win 29200, options [mss 1460,sackOK,TS val 279129 ecr 0,nop,wscale 5], length 0

09:08:27.928284 IP 10.1.100.11.43534 > 10.1.100.12.ssh: Flags [S], seq 2293133161, win 29200, options [mss 1460,sackOK,TS val 280132 ecr 0,nop,wscale 5], length 0

[root@compute1:~]

[root@compute1:~] tcpdump-uw -r VM-WEB1-IN.pcap

reading from file VM-WEB1-IN.pcap, link-type EN10MB (Ethernet)

06:48:29.883208 IP 10.1.100.12 > 10.1.100.11: ICMP echo reply, id 9484, seq 1, length 64

[root@compute1:~]

Как видно из примера ICMP трафик прошел от машины Web 1 к машине Web 2 и получен ответ. А вот трафик SSH не прошел и тут сработали правила на файерволе NSX DFW (помним выше, что мы разрешили проход только ICMP трафика).

2. Захват трафика после NSX Distributed Firewall (DFW)

В процессе диагностики может потребоваться проверить работу NSX DFW и поэтому рассмотрим следующую точку после фильтров файервола. Для этого существуют две опции для pktcap-uw:

–capture <точка захвата>

Варианты и применение двух точек захвата:

Для того чтобы трафик захватить в точке 2 (см. диаграмму) нам нужна опция –capture PostDVFilter:

–dvfilter <filter name>

DVFilter который мы хотим применить для конкретной виртуальной сетевой карты vNIC

В данном эксперименте мы будем захватывать трафик от машины Web 1 в точке PostDVFilter. Но сначала мы должны узнать имя фильтра для карты Web 1. Это может быть сделано, используя команду summarize-dvfilter:

[root@compute1:~] summarize-dvfilter

Fastpaths:

agent: dvfilter-faulter, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter

agent: ESXi-Firewall, refCount: 5, rev: 0x1010000, apiRev: 0x1010000, module: esxfw

agent: dvfilter-generic-vmware, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter-generic-fastpath

agent: dvfilter-generic-vmware-swsec, refCount: 2, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter-switch-security

agent: bridgelearningfilter, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: vdrb

agent: dvfg-igmp, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfg-igmp

agent: vmware-sfw, refCount: 2, rev: 0x1010000, apiRev: 0x1010000, module: vsip

Slowpaths:

Filters:

world 0

port 33554436 vmk0

vNic slot 0

name: nic-0-eth4294967295-ESXi-Firewall.0

agentName: ESXi-Firewall

state: IOChain Attached

vmState: Detached

failurePolicy: failOpen

slowPathID: none

filter source: Invalid

port 33554437 vmk1

vNic slot 0

name: nic-0-eth4294967295-ESXi-Firewall.0

agentName: ESXi-Firewall

state: IOChain Attached

vmState: Detached

failurePolicy: failOpen

slowPathID: none

filter source: Invalid

port 83886084 vmk2

vNic slot 0

name: nic-0-eth4294967295-ESXi-Firewall.0

agentName: ESXi-Firewall

state: IOChain Attached

vmState: Detached

failurePolicy: failOpen

slowPathID: none

filter source: Invalid

port 33554438 vmk3

vNic slot 0

name: nic-0-eth4294967295-ESXi-Firewall.0

agentName: ESXi-Firewall

state: IOChain Attached

vmState: Detached

failurePolicy: failOpen

slowPathID: none

filter source: Invalid

world 36278 vmm0:WEB1 vcUuid:'50 1c 3a f6 63 50 fc 29-88 09 5a a6 9e 7a c3 00'

port 83886086 WEB1.eth0

vNic slot 2

name: nic-36278-eth0-vmware-sfw.2

agentName: vmware-sfw

state: IOChain Attached

vmState: Detached

failurePolicy: failClosed

slowPathID: none

filter source: Dynamic Filter Creation

vNic slot 1

name: nic-36278-eth0-dvfilter-generic-vmware-swsec.1

agentName: dvfilter-generic-vmware-swsec

state: IOChain Attached

vmState: Detached

failurePolicy: failClosed

slowPathID: none

filter source: Alternate Opaque Channel

[root@compute1:~]

Далее мы можем опять запустить захват трафика (ICMP и SSH).

[root@compute1:~] pktcap-uw --capture POSTDVFILTER --dvfilter nic-36278-eth0-vmware-sfw.2 --ip 10.1.100.12 -o WEB1-POSTDVFILTER.pcap

The session capture point is POSTDVFILTER

The name of the dvfilter is nic-36278-eth0-vmware-sfw.2

The session filter IP(src or dst) address is 10.1.100.12

The output file is WEB1-POSTDVFILTER.pcap

No server port specified, select 50163 as the port

Local CID 2

Listen on port 50163

Accept...Vsock connection from port 1071 cid 2

Dump: 2, broken : 0, drop: 0, file err: 0Join with dump thread failedDestroying session 47

Dumped 2 packet to file WEB1-POSTDVFILTER.pcap, dropped 0 packets.

Done.

[root@compute1:~]

Посмотрим наш файл WEB1-POSTDVFILTER.pcap:

[root@compute1:~] tcpdump-uw -r WEB1-POSTDVFILTER.pcap

reading from file WEB1-POSTDVFILTER.pcap, link-type EN10MB (Ethernet)

07:01:06.487368 IP 10.1.100.11 > 10.1.100.12: ICMP echo request, id 9486, seq 1, length 64

07:01:06.487849 IP 10.1.100.12 > 10.1.100.11: ICMP echo reply, id 9486, seq 1, length 64

[root@compute1:~]

Как мы видим, трафик ICMP прошел без проблем, а SSH трафика не видно, так как его не пропустил файервол.

3. Захват инкапсулированного трафика VXLAN

В данном примере мы будем захватывать трафик после его инкапсуляции. Например, для решения проблем связи виртуального коммутатора с физическим сетевым адаптером на физическом сервере. Для решения этой задачи используются следующие опции для pktcap-uw:

–capture <точка захвата>
Точка захвата как всегда зависит от направления трафика:

–uplink <vmnicX>

Имя физического сетевого адаптера (vmnic)

–vxlan <VNI>

Номер VXLAN

В данном примере мы захватываем VXLAN трафик для VNI 5001 – точка «3» на диаграмме.

Во время захвата выполнили команду ping от Web1 в сторону Web2.

[root@compute1:~] pktcap-uw --uplink vmnic1 --capture UplinkSnd --vxlan 5001 -o VXLAN-Sn

d.pcap

The name of the uplink is vmnic1

The session capture point is UplinkSnd

The vxlan is 5001

The output file is VXLAN-Snd.pcap

No server port specifed, select 52459 as the port

Local CID 2

Listen on port 52459

Accept...Vsock connection from port 1043 cid 2

Dump: 2, broken : 0, drop: 0, file err: 0Join with dump thread failedDestroying session 19

Dumped 2 packet to file VXLAN-Snd.pcap, dropped 0 packets.

Done.

[root@compute1:~]

Итог представлен ниже:

[root@compute1:~] tcpdump-uw -enr VXLAN-Snd.pcap

reading from file VXLAN-Snd.pcap, link-type EN10MB (Ethernet)

13:06:46.313928 00:50:56:6c:a8:61 > 00:50:56:62:54:8f, ethertype IPv4 (0x0800), length 148: 172.16.1.10.58914 > 172.16.1.11.8472: VXLAN, VNI 5001, Flags [I]

00:50:56:9c:36:ac > 00:50:56:9c:b0:9a, ethertype IPv4 (0x0800), length 98: 10.1.100.11 > 10.1.100.12: ICMP echo request, id 7998, seq 1, length 64

13:06:51.321047 00:50:56:6c:a8:61 > 00:50:56:62:54:8f, ethertype IPv4 (0x0800), length 110: 172.16.1.10.49290 > 172.16.1.11.8472: VXLAN, VNI 5001, Flags [I]

00:50:56:9c:36:ac > 00:50:56:9c:b0:9a, ethertype ARP (0x0806), length 60: Reply 10.1.100.11 is-at 00:50:56:9c:36:ac, length 46

[root@compute1:~]

Как видим выше ICMP echo request был инкапсулирован и отправлен с интерфейса VTEP VMkernel Compute1 (172.16.1.10) в сторону интерфейса VTEP VMkernel Compute2 (172.16.1.11).

Для смены направления захвата трафика необходимо заменить точку захвата с UplinkSnd на UplinkRcv.

4. Захват трафика после маршрутизатора NSX Distributed Logical Router (DLR)

Если необходимо проверить корректность работы встроенного распределенного логического маршрутизатора, то для решения этой задачи необходимо выяснить идентификатор порта port-ID маршрутизатора vdrport. Для этого мы можем воспользоваться утилитой ESXTOP или через командную строку NSX:

nsx-manager1.ipcraft.lab> show cluster all

No. Cluster Name Cluster Id Datacenter Name Firewall Status

1 temp domain-c715 DC1 Not Enabled

2 Management & Edge domain-c189 DC1 Enabled

3 Cluster-A domain-c7 DC1 Enabled

4 Cluster-B domain-c9 DC1 Enabled

nsx-manager1.ipcraft.lab> show cluster domain-c7

Datacenter: DC1

Cluster: Cluster-A

No. Host Name Host Id Installation Status

1 compute1.ipcraft.lab host-22 Ready

nsx-manager1.ipcraft.lab> show logical-switch host host-22 vni 5001 verbose

VXLAN Global States:

Control plane Out-Of-Sync: No

UDP port: 8472

VXLAN network: 5001

Multicast IP: N/A (headend replication)

Control plane: Enabled (multicast proxy,ARP proxy)

Controller: 192.168.0.211 (up)

MAC entry count: 0

ARP entry count: 0

Port count: 2

VXLAN port: vdrPort

Switch port ID: 83886085

vmknic ID: 0

VXLAN port: 68

Switch port ID: 83886086

vmknic ID: 0

nsx-manager1.ipcraft.lab>

Для определения направления трафика мы используем опции –dir 0 для захвата трафика от DLR (egress) в сторону виртуального коммутатора. Кроме этого мы можем указать интерфейс с исходящим трафиком, используя –vxlan <VNI>.

На примере ниже мы используем интерфейс VXLAN 5009 и опять генерируем.

[root@compute1:~] pktcap-uw --switchport 83886085 --dir 0 --vxlan 5009 --dstip 10.1.2.11 -o DLR-Egress.pcap

The switch port id is 0x05000005

The dir is Rx

The vxlan is 5009

The session filter destination IP address is 10.1.2.11

The output file is DLR-Egress.pcap

No server port specifed, select 28758 as the port

Local CID 2

Listen on port 28758

Accept...Vsock connection from port 1072 cid 2

Dump: 1, broken : 0, drop: 0, file err: 0Join with dump thread failedDestroying session 48

Dumped 1 packet to file DLR-Egress.pcap, dropped 0 packets.

Done.

[root@compute1:~]

Так выглядит захваченный трафик:

[root@compute1:~] tcpdump-uw -enr DLR-Egress.pcap

reading from file DLR-Egress.pcap, link-type EN10MB (Ethernet)

02:53:41.655412 02:50:56:56:44:52 > 00:50:56:9c:fa:4d, ethertype IPv4 (0x0800), length 98: 10.1.100.11 > 10.1.2.11: ICMP echo request, id 10187, seq 1, length 64

[root@compute1:~]

5. Захват управляющего трафика в NSX

Мы можем использовать pktcap-uw для анализа управляющего трафика между хостом ESXi и контроллером NSX и NSX менеджером. Трафик при общении зашифрован, но мы сможем проверить корректность заголовков на уровне 2, 3 или 4 модели OSI.

На ESXi управляющий трафик отправляется и получается через интерфейс VMkernel, поэтому для начала необходимо определится с точкой захвата.

Первый параметр, который необходимо указать для pktcap-uw это название интерфейса VMkernel –vmk. Интерфейс управления на нашем ESXi называется vmk0. Далее нам необходимо указать направление для захвата трафика – точку захвата:

На примере ниже мы захватываем трафик между хостом ESXi и контроллером NSX. Управляющий трафик – это netcpa, который использует порт 1234 в точке «5»:

Мы активируем две сессии для каждого из направлений (хост ESXi – контроллер NSX) в файл netcpad-to-Controller.pcap:

[root@compute1:~] pktcap-uw --vmk vmk0 --dstport 1234 --capture PortInput -o netcpad-to-

Controller.pcap

The name of the vmk is vmk0

The session filter destination TCP port is 1234

The session capture point is PortInput

The output file is netcpad-to-Controller.pcap

No server port specifed, select 18075 as the port

Local CID 2

Listen on port 18075

Accept...Vsock connection from port 1059 cid 2

Dump: 8, broken : 0, drop: 0, file err: 0Join with dump thread failedDestroying session 35

Dumped 8 packet to file netcpad-to-Controller.pcap, dropped 0 packets.

Done.

[root@compute1:~]

Сессия для захвата netcpa в направлении от контроллера NSX в сторону хоста ESXi:

[root@compute1:~] pktcap-uw --vmk vmk0 --srcport 1234 --capture PortOutput -o ne

tcpad-fr-Controller.pcap -s 0

The name of the vmk is vmk0

The session filter source TCP port is 1234

The session capture point is PortOutput

The output file is netcpad-fr-Controller.pcap

The snap len is 0

No server port specifed, select 18078 as the port

Local CID 2

Listen on port 18078

Accept...Vsock connection from port 1060 cid 2

Dump: 8, broken : 0, drop: 0, file err: 0Join with dump thread failedDestroying session 36

Dumped 8 packet to file netcpad-fr-Controller.pcap, dropped 0 packets.

Done.

[root@compute1:~]

Пакеты в файлах выглядят следующим образом:

[root@compute1:~] tcpdump-uw -enr netcpad-to-Controller.pcap

reading from file netcpad-to-Controller.pcap, link-type EN10MB (Ethernet)

14:46:40.989398 00:0c:29:db:8c:f0 > 00:50:56:9c:6e:c7, ethertype IPv4 (0x0800), length 135: 192.168.0.205.15669 > 192.168.0.211.1234: Flags [P.], ack 2204720771, win 130, options [nop,nop,TS val 2182465 ecr 134584671], length 69

14:46:41.495263 00:0c:29:db:8c:f0 > 00:50:56:9c:6e:c7, ethertype IPv4 (0x0800), length 66: 192.168.0.205.15669 > 192.168.0.211.1234: Flags [.], ack 70, win 130, options [nop,nop,TS val 2182516 ecr 134587171], length 0

14:46:50.998976 00:0c:29:db:8c:f0 > 00:50:56:9c:6e:c7, ethertype IPv4 (0x0800), length 135: 192.168.0.205.15669 > 192.168.0.211.1234: Flags [P.], ack 70, win 130, options [nop,nop,TS val 2183466 ecr 134587171], length 69

14:46:51.485171 00:0c:29:db:8c:f0 > 00:50:56:9c:6e:c7, ethertype IPv4 (0x0800), length 66: 192.168.0.205.15669 > 192.168.0.211.1234: Flags [.], ack 139, win 130, options [nop,nop,TS val 2183515 ecr 134589671], length 0

14:47:01.007521 00:0c:29:db:8c:f0 > 00:50:56:9c:6e:c7, ethertype IPv4 (0x0800), length 135: 192.168.0.205.15669 > 192.168.0.211.1234: Flags [P.], ack 139, win 130, options [nop,nop,TS val 2184467 ecr 134589671], length 69

14:47:01.485063 00:0c:29:db:8c:f0 > 00:50:56:9c:6e:c7, ethertype IPv4 (0x0800), length 66: 192.168.0.205.15669 > 192.168.0.211.1234: Flags [.], ack 208, win 130, options [nop,nop,TS val 2184515 ecr 134592172], length 0

14:47:11.017465 00:0c:29:db:8c:f0 > 00:50:56:9c:6e:c7, ethertype IPv4 (0x0800), length 135: 192.168.0.205.15669 > 192.168.0.211.1234: Flags [P.], ack 208, win 130, options [nop,nop,TS val 2185468 ecr 134592172], length 69

14:47:11.484969 00:0c:29:db:8c:f0 > 00:50:56:9c:6e:c7, ethertype IPv4 (0x0800), length 66: 192.168.0.205.15669 > 192.168.0.211.1234: Flags [.], ack 277, win 130, options [nop,nop,TS val 2185515 ecr 134594672], length 0

[root@compute1:~]

[root@compute1:~] tcpdump-uw -enr netcpad-fr-Controller.pcap

reading from file netcpad-fr-Controller.pcap, link-type EN10MB (Ethernet)

14:46:40.989819 00:50:56:9c:6e:c7 > 00:0c:29:db:8c:f0, ethertype IPv4 (0x0800), length 66: 192.168.0.211.1234 > 192.168.0.205.15669: Flags [.], ack 3041791823, win 83, options [nop,nop,TS val 134587073 ecr 2182465], length 0

14:46:41.382309 00:50:56:9c:6e:c7 > 00:0c:29:db:8c:f0, ethertype IPv4 (0x0800), length 135: 192.168.0.211.1234 > 192.168.0.205.15669: Flags [P.], ack 1, win 83, options [nop,nop,TS val 134587171 ecr 2182465], length 69

14:46:50.999589 00:50:56:9c:6e:c7 > 00:0c:29:db:8c:f0, ethertype IPv4 (0x0800), length 66: 192.168.0.211.1234 > 192.168.0.205.15669: Flags [.], ack 70, win 83, options [nop,nop,TS val 134589576 ecr 2183466], length 0

14:46:51.382398 00:50:56:9c:6e:c7 > 00:0c:29:db:8c:f0, ethertype IPv4 (0x0800), length 135: 192.168.0.211.1234 > 192.168.0.205.15669: Flags [P.], ack 70, win 83, options [nop,nop,TS val 134589671 ecr 2183466], length 69

14:47:01.007915 00:50:56:9c:6e:c7 > 00:0c:29:db:8c:f0, ethertype IPv4 (0x0800), length 66: 192.168.0.211.1234 > 192.168.0.205.15669: Flags [.], ack 139, win 83, options [nop,nop,TS val 134592078 ecr 2184467], length 0

14:47:01.382519 00:50:56:9c:6e:c7 > 00:0c:29:db:8c:f0, ethertype IPv4 (0x0800), length 135: 192.168.0.211.1234 > 192.168.0.205.15669: Flags [P.], ack 139, win 83, options [nop,nop,TS val 134592172 ecr 2184467], length 69

14:47:11.018032 00:50:56:9c:6e:c7 > 00:0c:29:db:8c:f0, ethertype IPv4 (0x0800), length 66: 192.168.0.211.1234 > 192.168.0.205.15669: Flags [.], ack 208, win 83, options [nop,nop,TS val 134594580 ecr 2185468], length 0

14:47:11.383095 00:50:56:9c:6e:c7 > 00:0c:29:db:8c:f0, ethertype IPv4 (0x0800), length 135: 192.168.0.211.1234 > 192.168.0.205.15669: Flags [P.], ack 208, win 83, options [nop,nop,TS val 134594672 ecr 2185468], length 69

[root@compute1:~]

В дальнейшем мы можем объединить два разных файла в один с помощью Wireshark для удобства анализа двунаправленного трафика, используя функцию Merge: