使用 Azure 网络观察程序执行数据包检查Packet inspection with Azure Network Watcher

使用网络观察程序的数据包捕获功能,可在门户、PowerShell、CLI 中以及通过 SDK 和 REST API 以编程方式在 Azure VM 上启动和管理捕获会话。Using the packet capture feature of Network Watcher, you can initiate and manage captures sessions on your Azure VMs from the portal, PowerShell, CLI, and programmatically through the SDK and REST API. 借助数据包捕获,可通过以随时可用的格式提供信息,来解决需要数据包级数据的方案。Packet capture allows you to address scenarios that require packet level data by providing the information in a readily usable format. 利用免费工具检查数据,可以检测传入和传出 VM 的通信并洞察网络流量。Leveraging freely available tools to inspect the data, you can examine communications sent to and from your VMs and gain insights into your network traffic. 数据包捕获数据的一些示例用途包括:调查网络或应用程序问题、检测网络滥用和入侵企图,或保持合规性。Some example uses of packet capture data include: investigating network or application issues, detecting network misuse and intrusion attempts, or maintaining regulatory compliance. 本文介绍如何使用流行的开放源代码工具打开网络观察程序提供的数据包捕获文件。In this article, we show how to open a packet capture file provided by Network Watcher using a popular open-source tool. 此外,还举例说明了如何计算连接延迟、识别异常流量,以及检查网络统计信息。We will also provide examples showing how to calculate a connection latency, identify abnormal traffic, and examine networking statistics.

准备阶段Before you begin

本文会回顾以前运行的有关数据包捕获的一些预配置方案。This article goes through some pre-configured scenarios on a packet capture that was run previously. 这些方案演示了可以通过查看数据包捕获访问的功能。These scenarios illustrate capabilities that can be accessed by reviewing a packet capture. 本方案使用 WireShark 来检查数据包捕获。This scenario uses WireShark to inspect the packet capture.

本方案假设已在虚拟机上运行数据包捕获。This scenario assumes you already ran a packet capture on a virtual machine. 若要了解如何创建数据包捕获,请访问 Manage packet captures with the portal(使用门户管理数据包捕获);若要了解如何使用 REST 进行相应操作,请访问 Managing Packet Captures with REST API(使用 REST API 管理数据包捕获)。To learn how to create a packet capture visit Manage packet captures with the portal or with REST by visiting Managing Packet Captures with REST API.

方案Scenario

本方案中的操作:In this scenario, you:

  • 检查数据包捕获Review a packet capture

计算网络延迟Calculate network latency

本方案说明如何查看两个终结点之间发生的传输控制协议 (TCP) 对话的初始往返时间 (RTT)。In this scenario, we show how to view the initial Round Trip Time (RTT) of a Transmission Control Protocol (TCP) conversation occurring between two endpoints.

建立 TCP 连接后,在连接中发送的前三个数据包遵循一种通常称作“三次握手”的模式。When a TCP connection is established, the first three packets sent in the connection follow a pattern commonly referred to as the three-way handshake. 通过检查此握手中发送的前两个数据包、客户端发出的初始请求以及服务器发出的响应,我们可以计算建立此连接时的延迟。By examining the first two packets sent in this handshake, an initial request from the client and a response from the server, we can calculate the latency when this connection was established. 此延迟称为“往返时间”(RTT)。This latency is referred to as the Round Trip Time (RTT). 有关 TCP 协议和三次握手的详细信息,请参阅以下资源。For more information on the TCP protocol and the three-way handshake refer to the following resource. https://support.microsoft.com/help/172983/explanation-of-the-three-way-handshake-via-tcp-ip

步骤 1Step 1

启动 WireSharkLaunch WireShark

步骤 2Step 2

从数据包捕获加载 .cap 文件。Load the .cap file from your packet capture. 根据具体的配置,此文件保存在 Blob 中或者虚拟机本地。This file can be found in the blob it was saved in our locally on the virtual machine, depending on how you configured it.

步骤 3Step 3

若要查看 TCP 对话中的初始往返时间 (RTT),只需检查 TCP 握手中涉及的前两个数据包。To view the initial Round Trip Time (RTT) in TCP conversations, we will only be looking at the first two packets involved in the TCP handshake. 我们将使用三次握手中的前两个数据包,即 [SYN]、和 [SYN, ACK] 数据包。We will be using the first two packets in the three-way handshake, which are the [SYN], [SYN, ACK] packets. 这两个数据包是根据 TCP 标头中的标志命名的。They are named for flags set in the TCP header. 本方案不使用握手中的最后一个数据包,即 [ACK] 数据包。The last packet in the handshake, the [ACK] packet, will not be used in this scenario. [SYN] 数据包由客户端发送。The [SYN] packet is sent by the client. 收到该数据包后,服务器将发送 [ACK] 数据包,表示确认收到客户端发来的 SYN。Once it is received the server sends the [ACK] packet as an acknowledgment of receiving the SYN from the client. 利用服务器响应所需的开销极少这一事实,可通过对客户端收到 [SYN, ACK] 数据包的时间与客户端发送 [SYN] 数据包的时间进行减法运算,来计算 RTT。Leveraging the fact that the server's response requires very little overhead, we calculate the RTT by subtracting the time the [SYN, ACK] packet was received by the client by the time [SYN] packet was sent by the client.

使用 WireShark 可以计算此值。Using WireShark this value is calculated for us.

为了更轻松地查看 TCP 三次握手中的前两个数据包,我们将利用 WireShark 提供的筛选功能。To more easily view the first two packets in the TCP three-way handshake, we will utilize the filtering capability provided by WireShark.

若要应用 WireShark 中的筛选器,请展开捕获中 [SYN] 数据包的“Transmission Control Protocol”段,检查 TCP 标头中设置的标志。To apply the filter in WireShark, expand the "Transmission Control Protocol" Segment of a [SYN] packet in your capture and examine the flags set in the TCP header.

由于我们想要针对所有 [SYN] 和 [SYN, ACK] 数据包执行筛选,因此应在标志下面确认 Syn 位设置为 1,并右键单击 Syn 位 ->“应用为筛选器”->“选定项”。Since we are looking to filter on all [SYN] and [SYN, ACK] packets, under flags confirm that the Syn bit is set to 1, then right select on the Syn bit -> Apply as Filter -> Selected.

图 7

步骤 4Step 4

筛选窗口内容以便仅显示设置了 [SYN] 位的数据包后,可以轻松选择所需的对话来查看初始 RTT。Now that you have filtered the window to only see packets with the [SYN] bit set, you can easily select conversations you are interested in to view the initial RTT. 在 WireShark 中查看 RTT 的一种简单方法是选择带有“SEQ/ACK”分析标记的下拉框。A simple way to view the RTT in WireShark simply select the dropdown marked "SEQ/ACK" analysis. 然后便会显示 RTT。You will then see the RTT displayed. 在本例中RTT 为 0.0022114 秒,即 2.211 毫秒。In this case, the RTT was 0.0022114 seconds, or 2.211 ms.

图 8

不需要的协议Unwanted protocols

在 Azure 中部署的虚拟机实例上可能运行了大量的应用程序。You can have many applications running on a virtual machine instance you have deployed in Azure. 其中的许多应用程序可能在未得到明确许可的情况下通过网络通信。Many of these applications communicate over the network, perhaps without your explicit permission. 使用数据包捕获存储网络通信,可以调查应用程序如何在网络上通信,以及检查是否出现了任何问题。Using packet capture to store network communication, we can investigate how application is talking on the network and look for any issues.

在本示例中,我们会检查以前运行的数据包捕获是否存在不需要的协议,这可能表示计算机上运行的应用程序正在进行未经授权的通信。In this example, we review a previous ran packet capture for unwanted protocols that may indicate unauthorized communication from an application running on your machine.

步骤 1Step 1

在前一方案中的同一个捕获中,选择“统计信息” > “协议层次结构” Using the same capture in the previous scenario select Statistics > Protocol Hierarchy

协议层次结构菜单

此时会显示协议层次结构窗口。The protocol hierarchy window appears. 此视图提供在捕获会话期间使用的所有协议的列表,以及使用协议传输和接收的数据包数目。This view provides a list of all the protocols that were in use during the capture session and the number of packets transmitted and received using the protocols. 在查找虚拟机或网络上不需要的网络流量时,此视图可能很有作用。This view can be useful for finding unwanted network traffic on your virtual machines or network.

打开的协议层次结构

如以下屏幕截图中所示,有的流量使用了 BitTorrent 协议来建立对等文件共享。As you can see in the following screen capture, there was traffic using the BitTorrent protocol, which is used for peer to peer file sharing. 管理员不希望此特定虚拟机上出现 BitTorrent 流量。As an administrator you do not expect to see BitTorrent traffic on this particular virtual machine. 现在我们发现了这种流量,可以删除此虚拟机上安装的对等软件,或者使用网络安全组或防火墙来阻止该流量。Now you aware of this traffic, you can remove the peer to peer software that installed on this virtual machine, or block the traffic using Network Security Groups or a Firewall. 此外,可以选择按计划运行数据包捕获,以便定期检查虚拟机上使用的协议。Additionally, you may elect to run packet captures on a schedule, so you can review the protocol use on your virtual machines regularly. 有关如何在 Azure 中自动执行任务的示例,请参阅使用 Azure 自动化监视网络资源For an example on how to automate network tasks in Azure visit Monitor network resources with Azure automation

查找最常使用的目标和端口Finding top destinations and ports

在监视网络上的应用程序和资源或者对其进行故障排除时,了解流量类型、终结点以及通信时所用的端口非常重要。Understanding the types of traffic, the endpoints, and the ports communicated over is an important when monitoring or troubleshooting applications and resources on your network. 利用上述数据包捕获文件,可以快速了解与 VM 通信最频繁的目标以及使用的端口。Utilizing a packet capture file from above, we can quickly learn the top destinations our VM is communicating with and the ports being utilized.

步骤 1Step 1

在前一方案中的同一个捕获中,选择“统计信息” > “IPv4 统计信息” > “目标和端口” Using the same capture in the previous scenario select Statistics > IPv4 Statistics > Destinations and Ports

数据包捕获窗口

步骤 2Step 2

从带有线框的结果中可以看出,通过端口 111 建立了多个连接。As we look through the results a line stands out, there were multiple connections on port 111. 最常用的端口是 3389(远程桌面使用的端口),其余的端口是 RPC 动态端口。The most used port was 3389, which is remote desktop, and the remaining are RPC dynamic ports.

尽管这种流量可能无害,但许多连接都使用了此端口,而管理员并不了解这些连接。While this traffic may mean nothing, it is a port that was used for many connections and is unknown to the administrator.

图 5

步骤 3Step 3

确定有问题的端口后,可以根据该端口筛选捕获。Now that we have determined an out of place port we can filter our capture based on the port.

本方案中的筛选器为:The filter in this scenario would be:

tcp.port == 111

在筛选器文本框中输入上面所示的筛选器文本,并按 Enter。We enter the filter text from above in the filter textbox and hit enter.

图 6

从结果可以看出,所有流量来自同一子网中的某个本地虚拟机。From the results, we can see all the traffic is coming from a local virtual machine on the same subnet. 如果仍不了解出现此流量的原因,可以进一步检查数据包,确定该流量为何在端口 111 上发出这些调用。If we still don't understand why this traffic is occurring, we can further inspect the packets to determine why it is making these calls on port 111. 使用这些信息可以采取相应的措施。With this information we can take the appropriate action.

后续步骤Next steps

访问 Azure network monitoring overview(Azure 网络监视概述),了解网络观察程序的其他诊断功能Learn about the other diagnostic features of Network Watcher by visiting Azure network monitoring overview