Leopold's Blog
本文大纲
Leopold

文章

分类

标签

27

12

34

github.com/SayNop
gitee.com/WhenTimeGoesBy

Wireshark 与网络协议

2026-02-18
SpiderSpider

本文参考内容 https://www.bilibili.com/video/BV1ducszjEWs/open in new window

抓包原理

网络环境

哪种网络环境下可以进行抓包？如何使wireshark所在网络终端监听到数据包？

  • 主机环境：直接抓包本机网卡的进出流量。此时无需借助第三方的设备

  • 集线器环境：集线器会坐流量泛洪，连接到同一集线器属于同一冲突域（旧环境，现已淘汰）

    • 集线器处于物理层，因此不认识mac地址、ip地址等内容，每次接收到信号（数据包）都会复制并发送到除接收端口以外的所有其他端口，该内容被称为泛洪
    • 连接集线器的客户端（网络终端）安装了wireshark，就可以收到该集线器内都数据，从而实现抓包

  • 交换机环境：交换机处于数据链路层，由于通过mac表明确目标从而进行通信。同一交换机内的两个网络终端进行通信，第三个网络终端无法直接获取数据包

    • 端口镜像（SPAN）：通过此技术，将流量复制一份到第三个网络终端，网卡设置为混杂模式（Wireshark会进行设置），从而实现抓包。大部分网络监控都是使用此模式
    • Arp攻击（Cain&Abel）
      • 当要建立连接时，发送方通过arp协议在局域网内广播询问目标ip网络终端的mac地址
      • 此时可进行arp欺骗，进行响应，污染发送方的arp表，使数据包的目标mac地址变更为第三者
      • 此时交换机会将数据包按照mac地址发送给第三者
      • 第三者收到数据包可进行抓包，再将数据包封装成给真实目标ip的mac，通过交换机发送给真实目标（即数据包在第三者处多绕了一圈）
    • mac泛洪
      • 第三者通过发送大量mac地址（泛洪垃圾包），使交换机的mac表爆表（两个需要建立通信的网络终端的mac地址被挤出mac表）。此时交换机收到未知mac地址的数据包，会进行泛洪（交换机处理未知帧的逻辑）。从而第三者可以监听到数据包并进行抓包

底层架构

Wireshark 自顶向下，通过以下几个内容，对收到的数据包进行采集与分析

  • GTK1/2: GUI。处理用户输入输出
  • Core: 核心引擎。通过函数联动其他模块，如：过滤，插件等
    • Epan
      • Protocol-Tree
      • Dissectors
      • Plugins
      • Display-Filters
  • Wiretap: 格式支持。将数据包分析、解析成对应的文件格式
  • Capture: 抓包引擎（获取比特流）。通过 WinPcap/libpcap 的抓包接口，从不同类型的网络接口（以太网，令牌环网，ATM网等）获取数据包
  • WinPcap/libpcap: Wireshark 抓包所依赖的库文件

常用配置

  • 实用的偏好设置项介绍

    • 文件打开路径：使用打开功能时，默认会进入上次打开的 Session 文件所在路径。可以修改成指定文件夹 Appearance 窗口 -> Open files in
    • 调整 列表窗口、详情窗口、字节流窗口的布局 Appearance -> Layout窗口

  • 数据包列表增加自定义列：在包详情页中选中列后右键。常用列: Time to live(TTL)、Sequence

  • 时间设置

    • 时间列的显示内容调整: 默认从0开始，显示数据包距离开启监听的秒数。可通过 Menu Bar(菜单栏) -> View -> Time Display Format 进行调整
    • 参考时间: 分析其他数据包与某个指定数据包的时间间隔（可设置多个包为参考时间）。列表指定数据包 -> 右键 -> Set/Unset Time Reference

  • 抓包配置 Menu Bar -> Capture -> Option

    • 混杂模式: Input label -> promiscuous mode 默认开启，可以抓取监听到的所有数据包。否则会丢弃指定接口外的数据包
    • 文件输出 Output label
      • 设置 Session 文件路径与文件名: Capture to a permanent file -> File
      • 同一 Session 多文件保存，需要先手动指定文件名称
        • 开启多文件保存功能: 勾选 Use multiple files
        • 设置每个文件的生成规则: 按照文件大小生成文件 / 时间间隔生成文件
        • 设置文件个数: ring buffer ，与 rotate 日志类似，保持文件个数，丢弃最早的包文件
    • 定时器: 指定规则后自动停止抓包 Options label -> Stop capture automatically after...
      • packets 抓取指定个数包后停止
      • files 抓取到指定文件个数后停止
      • 抓包的 Session 大小
      • 时间
    • 显示选项 Display Options
      • 按类型查看流量曲线 Show capture information during live capture
      • Tips: 为了节省资源，可以将 Display Options 中的选项全部不勾选后抓包
    • 名称解析: Wireshark 默认开启了 MAC 地址的名称解析，可以手动开启 IP 地址、端口号等名称解析
      • MAC 地址解析。查看数据包详情中的 Ethernet 部分，显示 Src / Dst 时携带了 MAC 地址所属的厂商信息。
      • 开启名称解析: 勾选 Options label -> Name Resolution 下方名称解析的选项
      • 手动设置名称: 列表或详情页，IP 地址处右键 -> Edit Resolved Name
      • 查看当前 Session 中的名称解析的映射关系 Menu Bar -> Statistics -> Resolved Addresses
      • Tips: 由于名称解析需要对 MAC、IP、端口进行匹配，存在一定资源开销，流量较大时不建议开启

数据包操作

  • 标记数据包：在列表窗口手动高亮指定的数据包 右键 -> Mark/Unmark Selected 此时选中的数据包变更为黑底白字
  • 修改数据包列表中的配色方案
    • 修改当前 session 中与某个地址的指定类型数据包的配色方案 列表窗口指定数据包右键 -> Colorize Conversation
    • 修改指定类型默认的配色方案 Menu Bar -> View -> Coloring Rules...
    • Tips: 在默认配色方案中，正常的包是浅色背景，有问题的包是红色或黑色等深色背景
  • 数据包注释: 列表窗口指定数据包右键 -> Packet Comments 详情窗口中会出现注释信息 Packet Comments
  • 合并 Session Menu Bar -> File -> Merge...
  • 打印: 将 Session 导出为 PDF Menu Bar -> File -> Print...
  • 导出: 将 Session 中的部分数据包单独保存为一个 Session 文件便于分析
    • 通过过滤器过滤后导出过滤结果 Menu Bar -> File -> Export Specified Packets... -> 选择 All packet 和 Displayed
    • 导出选中的包，左肩选择指定包后 Menu Bar -> File -> Export Specified Packets... -> 选择 Selected packets only
    • 导出标记的包，先对目标数据包右键进行标记后 Menu Bar -> File -> Export Specified Packets... -> 选择 Marked packets only
    • 导出其他格式，如 csv/xml 等（将列表窗口中的数据包信息作为列表导出） Menu Bar -> File -> Export Packet Dissections

常用功能：将指定数据包高亮与导出、Session合并

过滤器

通过指定过滤条件，过滤出满足条件的数据包

过滤条件位置: 抓包配置 Menu Bar -> Capture -> Option 窗口中的 Input label -> Capture filter for selected interfaces

抓包过滤器

只抓取指定规则的数据包

BPF 语法

基于 WinPcap / libpcap 的 Berkeley Packet Filter，通过 BPF 实现只抓取满足规则的数据包

共有以下几种规则

  • 类型: 过滤数值的类型 host net port
  • 方向: 过滤数值出现的方向 src dst
  • 协议: 数据包使用的协议 ether ip tcp udp http ftp
  • 逻辑: 多个过滤条件的逻辑关系 与 && 或 || 非 !

例子:

  • 过滤 mac: 当某个 mac 的 ip 在变动 (或不确定流量是走 ipv4 或 ipv6) 时，可通过过滤 mac 定位流量
    • ether host 00:88:ca:86:f8:0d
    • ether src host 00:88:ca:86:f8:0d
    • ether dst host 00:88:ca:86:f8:0d
  • 过滤 ip
    • host 192.168.1.1
    • src host 192.168.1.1
    • dst host 192.168.1.1
  • 过滤端口
    • port 80
    • ! port 80
    • port 80
    • port 80
  • 过滤协议: arp icmp 等
  • 本机 ip （这里假设 ip 是 .2）访问端口 80 的流量 src host 192.168.1.2 && dst port 80
  • 192.168.1.1 与 192.168.1.2 的流量 host 192.168.1.1 || host 192.168.1.2
  • 跳过广播包 !broadcast

显示过滤器

在数据包列表中，通过工具栏处的 display filter 输入框，过滤出满足条件的数据包

显示过滤器语法

  • 比较操作符: == != > < >= <=
  • 逻辑操作符
    • and
    • or
    • xor 有且仅有一个条件满足
    • not
  • IP
    • ip.addr
    • ip.src
    • ip.dst
  • 端口
    • tcp.port
    • tcp.srcport
    • tcp.dstport
    • tcp.flags.syn tcp 数据包中 syn 标志位的值
    • tcp.flags.ack tcp 数据包中 ack 标志位的值
  • 协议
    • arp
    • ip
    • icmp
    • udp
    • tcp
    • bootp
    • dns
    • oicq QQ的数据包

例子:

  • 过滤协议 arp tcp not http
  • 过滤 IP
    • ip.addr == 192.168.1.2
    • ip.src == 192.168.1.2 and ip.dst == 8.8.8.8 本机发给 8.8.8.8 的包
    • ip.addr == 192.168.1.2 and ip.addr == 8.8.8.8 本机与 8.8.8.8 通信的包
  • 端口过滤
    • tcp.port == 4000 tcp 协议且端口是4000的包
    • tcp.flags.syn == 1 or tcp.flags.ack == 1 抓取指定标志位是指定值的 tcp 包

特殊功能

wireshark 在图形化，统计，报表等方面的功能。在遇到故障分析时也常按照这里的流程进行分析

数据流追踪

将某个网络数据流的过程呈现出来

  • 开始抓包 Menu Bar -> Capture -> Options... -> 选择网卡 -> start
  • 在列表中找到目标数据包，右键 -> Follow 或 Menu Bar -> Analyze -> Follow
  • 此时显示过滤器自动生成过滤规则，过滤出该数据流的条件

专家信息说明

与日志等级类似，将数据包按照特定状态 错误(error) 告警(warning) 注意(note) 对话(chat) 说明(comment) 进行分类

专家信息对话框位置 Menu Bar -> Analyze -> Expert Infomation 可用于分析当前网络情况

统计功能

Wireshark 提供了许多统计相关的功能位于 Menu Bar -> Statistics 此处的统计内容均可通过对数据包列表使用显示过滤器，控制统计范围

汇总信息

当前数据包的汇总信息，可通过显示过滤器获取过滤后的数据包汇总信息。信息对话框位于 Menu Bar -> Statistics -> Capture File Properties，包含 Session 文件大小，时间范围，数据包 等信息

协议分层统计

统计通信流量中不同协议所占百分比。以此分析哪种流量占用多，哪种流量占用少，从而分析是否存在病毒等产生了额外流量

对话窗口位于 Menu Bar -> Statistics -> Protocol Hierarchy ，可查看该 Session 中指定协议数据包量所占总数据包量的的百分比，指定协议的字节数占总流量字节数的百分比

数据包长度

将 Session 中的数据包按照长度进行统计 Menu Bar -> Statistics -> Packet Lengths，可用于查看是否存在小型帧攻击或巨型帧攻击（常用于分析是否存在安全攻击）

以下是常见协议的数据包长度

  • Arp: 详情共两部分 Ethernet 与 Arp

    • Ether 以太网协议长度 14 bytes（数据包详情点击 Ethernet 栏，左下角显示大小）
    • Arp 28字节（Arp包详情点击 Address Resolution Protocol 栏）
    • Arp 包共 42 字节（Ether 14 + Arp 28 = 42）

  • ICMP: 详情共三部分 Ethernet、IP、ICMP

    • Ether 14 bytes
    • IP 头部 20 bytes
    • ICMP 80+
    • 共 100+

  • DNS: 共4部分 Ethernet、IPV4、UDP、DNS

    • Ether 14 bytes
    • IP 头部 20 bytes
    • UDP 8 bytes
    • DNS 100+
    • 共 200 左右

  • TCP

    • 控制信息包: 握手，挥手 50-70
    • 数据传输包: 常见 800 - 1000

网络节点 与 会话统计

  • 网络会话 Menu Bar -> Statistics -> Conversations : 统计会话收发的数据包数量与字节。通过此功能可找出哪个会话（IP/端口）最占带宽，从而进行限速等后续所需操作

  • 网络节点 Menu Bar -> Statistics -> Endpoints : 统计会话中每个节点的收发的数据包数量与字节。通过此功能可找出哪个会话（IP/端口）最占带宽，从而进行限速等后续所需操作

图表分析

  • IO 图表（I/O Graphs）: 对网络中的吞吐流量进行实时图形显示 Menu Bar -> Statistics ->I/O Graphs 可通过自行增加曲线并配置曲线的过滤条件和 y 轴内容（数据包数量或字节数）查看流量波动情况

  • 数据流图（Flow Graph）: 会话通信过程通过图形可视化（例如 TCP 三次握手的箭头图）Menu Bar -> Statistics -> Flow Graph

TCP/IP 协议栈分析

多家网络公司、机构（IEEE）等推出了自己的网络协议栈，导致市面有多种网络协议栈，但随着发展，TCP/IP 协议栈是如今最主流的协议栈

发展过程

  • 网络的诞生：美国国防部在冷战中设计与使用的阿帕网（ARPANET）
    • 单点网络：一个设备出现故障，整个网络瘫痪
    • 不能跨军种共享，陆军使用DEC，海军使用Honeywell，空军使用IBM。不同公司使用不同的协议栈
  • 75年，TCP/IP协议栈诞生
  • 82年，TCP/IP规范诞生，Unix使用TCP/IP通信
  • 83年，美国国防部将TCP/IP作为阿帕网通信标准
  • 随着阿帕网商业化，TCP/IP成为事实通信标准

协议栈有很多，随着发展，最终胜出的是 TCP/IP 协议栈

模型: DoD模型

4层，早于 OSI 7层模型

  • 应用层: HTTP FTP TELNET SMTP DHCP DNS TFTP
  • 传输层: TCP UDP
  • 网络层: ARP RARP IP ICMP
  • 链路层: Ethernet

将从底向上进行协议分析，采用用 GNS3 软件模拟路由交换环境。该网络模拟软件可直接使用 Wireshark 抓取软件中模拟网络设备间的数据包

以太网协议

局域网使用最广泛的协议，部署简单，价格低廉。局域网链路层还有令牌网、令牌总线网、FDDI网等，随着以太网的发展，其他协议被抛弃

介质

  • 共享介质型: 多个网络终端通过同轴线缆与集线器连接，等待没有数据传输时才会发送数据。常用标准: 10BASE-T(数字表示10M BASE表示基带，T表示线缆)
  • 独享介质型: 多个网络终端通过网线与交换机连接，每个终端处于不同的冲突域中（不会冲突）常用标准: 100BASE-TX(100M 基带的 以太网线)

标准

IEEE 802.3 （有线以太网协议都是 802.3，无线以太网是 802.1）

  • CSMA/CD: 用于解决链路数据包冲突
  • 10BASE-T: 以太网标准。数字表示速度，BASE表示，T表示线缆
  • 10BASE-F: F表示光纤
  • 100BASE-TX: 快速以太网标准
  • 100BASE-FX
  • 1000BASE-T
  • 1000BASE-LX: Gb以太网标准

封装

数据帧封装分为两种格式。其中的数据部分的长度与 MTU（最大传输单元）有关

  • RFC 894: Ethernet帧（Wireshark标记为 Ethernet）。各大网络公司刚推出以太网协议采用的格式。大部分常采用此封装，更简洁高效。可查看 ARP 协议的数据包详情中的链路层内容

    • 目的地址: 6字节
    • 源地址: 6字节
    • 类型: 2字节。标明该数据包类型。如图，0806 表示 ARP 、8035 表示 RARP
    • 内容: 如图 46 - 1500 字节，ARP/RARP 内容的长度 28+18 共 46 字节

  • RFC 1042: 802.3帧（Wireshark标记为 IEEE 802.3 Ethernet）。IEEE 标准化创立的格式。CDP/VTP/PAGP等，一些Cisco等推出的私有协议常在此基础上设计。Wireshark中可查看 CDP/VTP... 等协议的数据包详情中的链路层内容

ARP 协议

地址解析协议，实现从 IP 地址到 MAC 地址的映射

过程

  • 当发送方向接收方发送数据包时，需要得知对方的 MAC 地址。因此发送 ARP request（广播请求，目的地址全F），询问指定 IP 的 MAC 地址（Who has 12.1.1.1? Tell 12.1.1.1）
  • 目标 IP（接收方）发送 ARP Reply（单播回复），告知指定 IP 的 MAC 地址值（12.1.1.2 is as cc:01:01:68:00:00）
  • 此时发送方的 ARP 缓存表中记录了目标 IP 的 MAC 地址
  • 发送方查询自己的 ARP 缓存表，封装数据包
  • 发送方发送数据包

封装

  • Hardware type: 硬件类型，标识链路层协议
  • Protocol type: 协议类型，标识网络层协议
  • Hardware size: 硬件地址大小，标识 MAC 地址长度（通常为6）
  • Protocol size: 协议地址大小，标识 IP 地址长度（通常为4，ipv4 地址长度 ）
  • Opcode: 操作代码，标识 ARP 数据包类型（1 请求，2 回复）
  • Sender MAC address: 发送者 MAC
  • Sender IP address: 发送者 IP
  • Target MAC address: 目标 MAC，全0表示在通过 ARP 协议获取未知的 MAC
  • Target IP address: 目标 IP

分类

  • ARP: 普通ARP流程在过程中已说明

  • 代理ARP（Proxy ARP）: 当发起跨网段的 ARP 请求时，出口路由/网关设备将自身 MAC 地址回复该请求时，该过程称为代理 ARP

    • 过程: 路由器在收到 ARP request 时，发现时跨网段的 ARP 请求，路由器发送 ARP Reply，回复自己的 MAC 地址。此 ARP Reply 称为代理ARP（路由器此时跨越了网段，且能访问其他网段的客户端。例如路由器的一个端口与一台PC连接且在一个网段，另一个端口与另一台PC连接且在另一个网段）
    • 场景
      • 没有路由功能的主机（网络终端）
      • 网络设备有路由功能（路由器或网络终端），目的地指向本地出口（默认路由指向本地接口，而不是接收方的接口，ip route 192.168.2.0 255.255.255.0 f0/0 f0/0 接口 - 1.0网段的接口，可以连接到 2.0 网段）

  • 免费ARP（Gratuitous ARP）: 无故ARP。用于检测局域网内部IP地址冲突

    • 场景: 获取 IP 后检查该 IP 是否已被其他设备使用
      • IP 地址被修改
      • DHCP 刚获取地址
    • 过程:
      • 在获取到 IP 后，发送 GARP Request（我的 IP 是 192.168.1.1，MAC 是 xxx，谁的 IP 是 192.168.1.1），询问当前的 IP 是否已被使用
      • 已使用该 IP 的设备回复 GARP Reply（广播），我的 IP 是 192.168.1.1，MAC 是 xxx
      • 发送 GARP Request 的设备收到代表冲突的免费 ARP Reply 后，也发送免费 ARP Reply（广播，我的 IP 是 192.168.1.1，MAC 是 xxx），表明冲突依然存在
      • 双方互相发送 GARP Reply，表明冲突持续存在

  • 逆向ARP（Inverse ARP）: 中继网络（已淘汰）环境下，用于实现 IP 和 DLCI 地址映射

    • 中继网络: 在该网络环境下，设备通过帧中继交换机连接。与以太网交换机不同，此处不使用 MAC 地址，而是使用 DLCI 号（标志符）来进行数据交换，接口与 DLCI 号映射表进行转发（不是接口与 MAC 地址映射表进行转发）
    • IARP 是周期性的（每60秒），而不是指定场景触发性
    • 过程: 每个网络终端都会发送 IARP request，该局域网的其他终端会回复 IARP Reply
      • IARP request: 192.168.1.1 的 DLCI 号是 100（与 GARP 类型，发送自己的 IP 与 DLCI 号）
      • IARP Reply: 192.168.1.2 的 DLCI 号是 200

  • 翻转ARP（Reverse ARP）: 原本 ARP 是已知对方 IP，获取对应的 MAC。RARP 是已知自身 MAC，获取自身 IP

    • 场景: 无盘工作站通过 RARP 获取 IP，后续可通过 TFTP 引导加载系统。如网吧，机房等，客户端没有本地硬盘，而是需要无盘服务器提供的网络硬盘
    • 过程
      • 无盘工作站发送 RARP Request: 我的 MAC 是 xxx，IP 是多少？
      • 无盘服务器发送 RARP Reply: xxx 对应的 IP 是 192.168.1.10

IP 协议

提供了数据的面向无连接和不可靠传输功能。为接入互联网的设备提供 IP 地址，保证设备的唯一性

封装

  • Version 版本号，标识 IP 协议版本。目前 v4 版本的地址已经枯竭，V6 慢慢成为主流
  • Header length 头部长度。默认20字节，最大60字节（扩展到60字节见 ICMP 中的 IP 记录路由、IP 源站路由等）
  • Differentiated Services Field 服务区分符，表示服务类型（TOS），应用在 QoS 技术中。给数据包打标签，数据包的紧急程度
  • Total length 总长度。标识 IP 头部加上上层协议的数据包大小（IP数据包的内容就是上层数据包），IP 包总长度最大 65535个字节（配合头部长度快速定位头部与数据的位置）
  • Identification 标识符，标识分片进程。用于实现 IP 分片的重组，标识分片属于哪个进程，不同进程通过不同 ID 区分（与不同设备通信使用不同的ID）
  • Flags 标志符。用于确认是否还有 IP 分片，实现 IP 分片重组（分片是否发完）
    • Reserved bit
    • Don't fragment: 0 - 允许分片，1 - 不允许分片
    • More fragment: 后续是否还有数据包 0 - 没有，1 - 有
  • Fragment offset 分片偏移量，用于标识 IP 分片未知，实现 IP 分片重组
  • Time to live 生存时间，标识 IP 数据包还能生存多久。不同OS，TTL初始值不同。每经过一个三层设备（如路由器），TTL - 1，TTL 为 0 时数据包被丢弃
  • Protocol 协议号。标识 IP 协议上层应用（类似 TCP/UDP 中的端口，此 IP 数据包的上一层协议的种类）。ICMP 为 1，TCP 为 6， UPD 为 17
  • Header checksum 头部校验，用于检验 IP 数据包是否完整或被修改，存在问题时数据包被丢弃
  • Source 源 IP 地址。32 bit
  • Destination 目的 IP 地址，32 bit

头部的额外说明

  • 最简单的头部 20 Bytes，可扩展到60字节（扩展内容见 ICMP 中的 IP 记录路由、IP 源站路由等）。没有分片时，分片相关头部字段值都是全0

  • 头部变动: 经过一个路由器时，数据包的 IP 头部会产生变化

    • TTL值会发送变动（逐跳改变）
    • Header checksum 头部校验和 也会跟着变动
    • IP 地址不变
    • Ethernet 中的源与目的 MAC 会逐段改变（源/目的 MAC ，当前数据包所处位置两端的 MAC 地址。例如 PC1 连接路由器 A 口，PC2连接路由器 B 口，数据从 PC1 到 PC2。PC1 或 A 口处，源 MAC 是 PC1，目的 MAC 是 A 口，在 B 口或 PC2 处，源 MAC 是 B 口，目的 MAC 是 PC2）

  • IP 分片: 发送的数据过大时，需要将数据切分，通过多个 IP 数据包发送。且接收者（每一跳的设备）都会对分片进行重组

  • 当网络中 MTU 低时（即单个数据包的装载内容变少），会产生更多的 IP 分片。此时若 IP 头部为通常值 20 Bytes，则数据内容长度为 MTU 值 - 20 Bytes

  • Identification 标识符补充。当两个设备同时有多个进程进行通信，为了使接收端收到数据包后得知该数据包是哪个通信进程的数据，需要使用 Identification 进行区分

  • Flags 标志符补充。告知接收端是否已经发完所有分片，可对数据包中的数据进行组装

    • Reserved bit
    • Don't fragment: 0 - 允许分片，1 - 不允许分片。数据发送方可设置该数据包内容能否进行分片。当后续设备收到此数据包时，若该包不能分片，且内容长度大于接收设备的 MTU，则丢弃这个过大的数据包，并不能分片的响应
    • More fragment: 后续是否还有数据包 0 - 没有，1 - 有。最开始发送的数据包都为 1， 当收到 0 时，说明可以开始进行数据组装

  • Fragment offset （OF）分片偏移量。决定了分片数据在组装时的顺序。数据包的偏移应为数据内容长度，即 MTU 值 - IP头部（20） Bytes。当数据内容都按100切分时，第一个包的 offset 是 0，第二个是 100，以此类推

ICMP 协议

Internet Control Message Protocol 互联网控制信息协议。用于实现 IP 网络层与上层协议的连通性测试和差错报告。源发送者或上层协议根据返回的 ICMP 协议信息进行下一步操作

常用的 ping 与 tracert 程序便是基于 ICMP 协议进行开发。从功能来看，属于 IP 的附属协议，可当作网络层。从分组角度来看，由于在 IP 的上层，与 TCP/UDP 同层，可当作传输层

封装

  • 0-7: Type 类型值 8 位，标识 ICMP 分组类型

  • 8-15: Code 代码值 8 位，标识 ICMP 分组类型的某一种具体分组

  • 16-31: Checksum 校验和 16 位，用于校验数据包是否完整或被修改

  • Identifier 标识符，标识进程号 16 位。与 IP 中的 id 类似，区分多个目的通信

  • Sequence Number 序列号 16 位，标识本地到目的地数据包序号，一般从 1 开始。当 ping -t 时，会从 0 开始，每次发包 +1

  • 32-: 内容

  • 说明: 不同类型下的不同代码值组合，说明了该数据包表达的信息

    TypeCode描述查询/差错
    0-Echo响应0Echo响应报文（Ping 应答）查询
    3-目的不可达0目标网络不可达报文差错
    1目标主机不可达报文差错
    2目标协议不可达报文差错
    3目标端口不可达报文差错
    4要求分段并设置DF flag标志报文差错
    5源路由失败报文差错
    6未知的目标网络报文差错
    7未知的目标主机报文差错
    8源主机隔离报文差错
    9禁止访问的网络报文差错
    10禁止访问的主机报文差错
    11对特定的TOS网络不可达报文差错
    12对特定的TOS主机不可达报文差错
    13由于过滤 网络流量被禁止报文差错
    14主机越权报文差错
    15优先权终止生效报文差错
    5-重定向0重定向网络报文差错
    1重定向主机报文差错
    2基于TOS的网络重定向报文差错
    3基于TOS的主机重定向报文差错
    8-Echo请求0Echo请求报文（Ping请求）查询
    9-路由器通告0路由通告报文查询
    10-路由器请求0路由器的发现/选择/请求报文查询
    11-ICMP超时0TTL超时报文差错
    1分片重组超时报文差错
    12-参数问题0IP报首部参数错误报文差错
    1丢失必要选项报文差错
    2不支持的长度报文差错
    13-时间戳请求0时间戳请求报文查询
    14-时间戳应答0时间戳应答报文查询
    15-信息请求0信息请求报文查询
    16-信息应答0信息应答报文查询

ICMP 使用情形

  • Ping

    • 发起 Ping 方(192.168.1.1)发送 Echo Request 请求回显（8|0）: 192.168.1.2，是否在那里
    • 连通状态: 被 Ping 方(192.168.1.2)发送 Echo Reply 回显应答（0|0）: 192.168.1.1，我在这里
    • 非连通状态: 没有回显应答

  • Traceroute: 最常用的链路追踪工具，用于探测源目双方沿途设备的 IP 地址（windows 中该命令是 tracert，其他系统中通常是 traceroute）

    • 向目的地址发送 TTL=1 ，高端口号（如55555，目的地址大概率没有提供此端口的服务）的 UDP 数据包（非 windows 系统使用 UDP，windows 使用 ICMP 的 Ping）
    • 到达下一跳后，不是发给我，需要我转发，但 TTL 变成 0，告知发送方 此包已失效。返回给发送方 ICMP 协议的 TTL 超时报文（ICMP Type-Code 11|0，此时该报文的发送方是自己的 IP 地址，接收方是 traceroute IP。网络层与传输层 data 内容与 UDP 数据包一致）
    • 此次追踪结束。TTL+1来追踪下一跳
    • 直到该数据包到达接收地址。由于接收地址匹配，此时不会触发 TTL-1 并检查 TTL 有效性，而是检查此包访问的端口，而该端口不可用，发送 ICMP 协议的 端口不可达（3|3）报文，而不是 ICMP 协议的 TTL 超时报文
    • 此时追踪完成
    • 说明
      • 每一跳会发送 3 个 TTL 值相同的包（可通过 probe 参数控制数量）。每一跳能看到 3 个延时，最大、最小、平均
      • 由于 windows 的 tracert 采用 Ping 包进行追踪
        • 在真实环境中，一些设备的防火墙会开启防 Ping，因此不是每一跳都有响应数据包，从而出现结果列表中存在 请求超时 的点。
        • 由于采用 Ping 包探测，到达终点后，返回的数据包是 ICMP Reply。而不是 ICMP 端口不可达

  • ICMP 不可达: 根据分组列表，Type = 3 时，共 16 种不同的 Code。此处以最常见的三种为例

    • 主机不可达（1）: 网络设备收到了数据包，但本地没有到此数据包目的地的路径时，丢弃此包并发送 ICMP 协议的 主机不可达（3|1 host unreachabled）报文
    • 端口不可达（3）: 当目标系统收到 IP 数据包请求某个服务，且本地没有该服务，则向源头返回 ICMP 协议的 端口不可达（3|3）报文
      • 请求 TFTP 服务（69 端口，UDP 协议报文），本地没有 69 端口服务，返回 ICMP 协议的 端口不可达（3|3 post unreachabled）报文，用于发送端终止 UDP 进程
      • 请求 TCP 服务（80端口，TCP 协议报文），本地没有 80 端口服务，返回 TCP 协议 RST 重置位（RST 标志位 = 1）报文，重置发送方的 TCP 服务（此处端口不可达的情况下没有使用 ICMP ，而是 TCP 的重置位）
    • 禁止不可达（13）: IP 数据包沿途设备做了策略控制且不允许通过时，执行策略设备会丢弃数据包并返回 ICMP 禁止不可达 报文
      • 网络设备做了防火墙或访问列表，禁止数据包进入，丢弃数据包，并返回 ICMP 协议的 administratively prohibited unreachable 3|13 报文
    • 分片不可达 需要分片但 IP 头部设置不可分片的 DF Flag（4）: 参考 IP 分片 中的流程
      • 设备 A ping 3.3.3.3 size 200 df-bit，通过路由器 B 连接到设备 C (3.3.3.3)
      • 路由器 B 设置了 MTU 为 100，因此需要分片，但数据包中设置了 DF 位
      • 路由器 B 直接返回 ICMP 需要分片但有 DF 位的不可达（frag. needed and DF set unreachable 3|4）报文

  • ICMP 重定向（5|1）: 当本地收到的 IP 数据包目的地的下一跳 IP 地址与源发送者处于同一网段时，则告知源发送者将路由重定向到邻居设备

    • 重定向包的示例

      • 设备 A（12.0.0.1/24）与设备 B（12.0.0.2/24 / 2.2.2.2/32） 通过交换机连接到路由器（12.0.0.3/24）。设备 B ip route add 12.0.0.2 255.255.255.0 ip route add 2.2.2.2 255.255.255.255
      • 当设备 A ping 2.2.2.2 时，由于该 IP 与设备 A 不在同一网段，因此该数据包到达网关（即路由器）
      • 路由器发现该 IP 属于设备 B（路由器的路由表中存在静态路由 2.2.2.2 指向 12.0.0.2/24），而设备 B 与设备 A 属于同一局域网（直接连接设备 B 才是最优路线，次优路径的解决流程）
        • 将该数据包转发给设备 B
        • 同时发送 ICMP 重定向 包给设备 A 告知该 IP 的包可直接发送给设备 B
      • 设备 A 收到重定向报文后，增加本地路由表信息，该 IP 指向设备 B 的局域网 IP

    • 数据包流程

      • 通过 ARP 数据包获取网关 12.0.0.3 的 MAC
      • 设备 A 发送 ICMP 包，目的 MAC 是网关的 MAC
      • 设备 A 收到 ICMP 协议的 Redirect for host （5|1，ICMP 的前2字节）报文，携带了 Gateway address: 12.0.0.2（ICMP 的5-8字节，3-4字节是校验和）。数据部分是 IP 报文 Src 12.0.0.1，Dst 2.2.2.2
      • 设备 A 收到重定向报文后，路由表除了默认网关 12.0.0.3 外，增加了一条记录: Host 2.2.2.2 Gateway 12.0.0.2
      • 后续的 Echo (ping) request 与 Echo (ping) Reply 均发生在设备 A 与 设备 B 之间

  • IP 记录路由（IP 协议，IP 头部扩展，需要借助 ping、traceroute 验证）: 在 IP 协议的第 4-7 位表示的 4 位头部长度中，最大值 0b1111 时，即 15×4=60 字节

    • 概述
      • 通过 IP 记录路由，可将沿途设备等出接口 IP 地址都记录下来，最多记录 9 个
      • 由于记录选项受限于 IP 头部长度，没法对大型网络进行记录跟踪，后续才开发 Traceroute
      • （IP 头部长度最多扩展到 60 字节，其中 20 字节是 IP 基础头部，只可用 40 字节的 IP Options 长度。4×9=36，即 40 字节最多只能放入 9 个 IP地址）
    • 过程: 设备 A （12.1.1.1）连接路由器 B f0/0（12.1.1.2）接口，路由器 B f0/1（23.1.1.2）接口连接到 设备 C（23.1.1.3 / 3.3.3.3）
      • 设备 A 使用扩展 ping，开启 Record 选项
      • 数据包详情 Internet Protocol Version 4 栏内出现 Options: (40 bytes), Record Route. End of Options List (EOL)
      • 数据包每经过一个出口，列表中增加一条 IP 记录
        • 从 A 发出 Echo (ping) request，到达 B 前: 只有 12.1.1.1 (A 的出口 IP)
        • 从 B 发出 Echo (ping) request，到达 C 前: 增加 23.1.1.2（B 的出口 IP）
        • 从 C 发出 Echo (ping) Reply，到达 B 前: 增加 3.3.3.3（目的地址）23.1.1.3（C 的出口 IP）
        • 从 B 发出 Echo (ping) Reply，到达 A 前: 增加 12.1.1.2（B 的出口 IP）
      • 数据包 Options 中的完整记录
        • 12.1.1.1 （设备 A 的出口 IP）
        • 23.1.1.2 (路由器 B 发送时的出口 f0/1 的 IP)
        • 3.3.3.3（目的地 IP）
        • 23.1.1.3（目的地出口 IP）
        • 12.1.1.2（路由器 B 返回时的出口 f0/0 的 IP）
        • 12.1.1.1 <*> （返回发送人 IP，用星号标记已经到达目的地）

  • IP 源站路由: 通过 IP 源站路由选项，可以在源发送者指定特定路径（将路径放入 IP 头部选项）来进行数据转发。即向目的地发送数据包时，指定数据包经过的IP

    • Options头部内容(Options 最大长度 40 bytes，最大使用长度 39 bytes): code(1) len(1) ptr(1) IP addr #1(4) ... IP addr #9(4)

    • 实现方式: 网络设备收到数据包后，在 Options 中通过 Ptr 获取下一跳 IP 地址，将数据包发送过去，从而达到数据包在传输时会经过指定 IP 的效果

    • 分类

      • 严格源站路由: 发送端指明 IP 数据报所必须采用的确切路由。如果一个路由器发现源路由所指定的下一个路由器不在其连接的网络上，那么它就返回一个 源站路由失败 ICMP 差错报文（不依赖路由，即使中间设备关闭 OSPF 路由协议，依然可以发送）网络设备收到该数据包时不查询路由表，而是直接发送给 Options 中指定的下一跳 IP 地址
        • 使用扩展 ping，开启 Strict 选项，填写多个路径 IP 地址，使用空格分隔（此处使用以下拓扑结构，示例路径地址为 14.1.1.4 24.1.1.2 25.1.1.15 35.1.1.3, 每个 IP 都是路径设备入口 IP，直至 Dst 设备入口 IP，R4 - R2 - R5 - R3）
        • 数据包从 Src 发送到第一跳 R1 时 IP 报文头部
          • IP 头部 Dst 的位置字段被解析成 Current Route，其值为列表中取出的当前跳的地址（第一个跳的入口 IP）。此时 列表长度 - 1
          • 为了使 Ptr 指向下一个地址，Ptr=Ptr+4=4 此时指向的 IP 是 Ptr−4 - Ptr−1 。 Ptr=4 即指向的是 0 - 3 ，列表中的第一个 IP 是输入的第二个 IP
          • 列表中除了被输入的多个路径 IP 被解析成 Source Route 外，还自动在 Option 列表末尾追加了 Dst 的 IP。此时 列表长度复原
          • 第一跳设备使列表记录 后续的入口 IP + Dst。且当前位置通过 Current Route 记录（列表内容始终是先前地址+后续地址+dst，不包含当前地址）
        • 数据包从第一个路径 IP 发出后，到达第二跳 R2
          • IP 头部 Dst 依然被解析为 Current Route，其值为 Ptr 指向的地址，此时是列表的第一个地址（R2 入口 IP），作为当前跳地址。同时将列表中 Ptr 指向地址 替换为 上一跳的出口 IP。此时被解析成 Recorded Route
          • Options 中的指针 Ptr=Ptr+4=8 用于指向下一跳地址（通过 IP 头部的 Ptr，使设备明确该数据包下一跳的 IP，来保证数据包始终按照给的路线）
          • 第二跳设备开始，使列表中记录了之前的出口 IP + 后续的入口 IP + Dst。当前位置通过 Current Route 记录（列表内容始终是先前地址+后续地址+dst，不包含当前地址）
        • 依次类推，直至 Echo (ping) request 包到达目的地。由于列表被修改，最终包含所有途径出口 IP + Dst IP
        • 目的地发送 Echo (ping) reply 包
          • 由于收到的列表时途径的出口IP + Dst。构造 reply 包时会将该列表反转后放回 Option 3.3.3.3 35.1.1.5(R5出口) 25.1.1.2(R2出口) 14.1.1.4(R4出口)，此时，之前的出口就作为回复包需要经过的入口。但第一项是 Dst。因此 Ptr 的初始值为 4
        • 到达第一跳后
          • IP 头部 Dst 的位置字段被解析成 Current Route。此时是从数组中取出所指向的 IP，即回复包第一跳设备的入口 IP 35.1.1.5。同时，列表第一项，变更为 Recored Route 记录回复包出口 IP 35.1.1.3。最后一个出口被解析成 Dst
          • Ptr=Ptr+4=8，此时指向的 IP 是 Ptr−4 - Ptr−1 。即 4 - 7，列表中第二个 IP，R2发包的出口IP
          • 后续列表操作与发包时保持一致。（列表内容始终是先前地址+后续地址+最后一项被解析成dst，不包含当前地址）
        • 依次类推，直到返回
      • 宽松源站路由: 发送端指明数据报经过的 IP 地址清单，但清单指明的任意两个地址之间可以经过其他路由器（还需要依据路由表进行）
        • 使用扩展 ping，开启 Loose 选项，填写多个路径 IP 地址，使用空格分隔。例如经过 2.2.2.2 只设置经过 R2
        • 到达第一个设置的IP。此时变化与严格模式类似
          • IP 头部 Dst 字段解析为 Current Route，其值为列表中取出的第一个地址（2.2.2.2），列表默认再追加真实 Dst 3.3.3.3
          • 为了使 Ptr 指向下一个地址，Ptr=Ptr+4=4 此时指向的 IP 是 Ptr−4 - Ptr−1 。 Ptr=4 即指向的是 0 - 3 ，列表中的第一个 IP，此时即为最终的 Dst
        • 到达下一个列表中的目标，即目的地 Dst
          • 取出 Ptr−4 - Ptr−1 的值 3.3.3.3 作为 Dst/Current Route，此时没有下一跳地址，解析成 Dst。同时将列表中当前指向的 IP 替换为 上一跳的出口 IP 23.1.1.2。此时被解析成 Recorded Route
          • Ptr=Ptr+4=8
        • 目的地发送 Echo (ping) reply 包
          • 设置初始值 Ptr=4
          • 根据 Ptr 指针，取出 Ptr−4 - Ptr−1 的地址 23.1.1.2（2.2.2.2 的出口地址）作为 reply 的下一跳。列表长度 - 1
          • 在 Options 中列表末尾追加 Dst IP，使列表长度不变

UDP 协议

User Datagram Protocol 用户数据报协议，提供面向无连接的不可靠传输服务，与 TCP 协议一起处于传输层

特征

  • 不可靠（传输时丢包不会重传，不需要处理数据包时序问题，从而保证实时性）
  • 无连接（不会与接收端协商，直接发送数据包，接收端无法得知数据包的大小）
  • 不分片（上层给到的数据包，不对其进行分片，直接加上 UDP 头部封装成 UDP 包，交给下层的 IP 协议自行分片）
  • 速度快
  • 实时性（适合实时视频和语音流）

由于以上特性，交互过程快，包少，一般都基于 UDP 实现。常见的基于 UDP 协议的上层协议: DHCP、DNS、TFTP、OICQ

封装

UDP头部 8 bytes

  • 源端口 2 bytes
  • 目的端口 2 bytes
  • 长度 2 bytes UDP 头部与上层头部的长度和
  • 校验和 2 bytes

基于 UDP 的 OICQ

QQ 使用的协议 数据包详情

  • Frame ...（内容省略）
  • Ethernet ...
  • Internet Protocl Version 4 ...
  • User Datagram Protocol
    • Source Port: 4000
    • Destination Port: 8000
    • Length: 63 （UDP 报文长度）
    • Checksum
  • OICQ
    • Flag: 0x02 （1 byte）
    • Version: 0x3601（2 bytes）
    • Command: (2 bytes)
    • Sequence:（2 bytes）
    • Data(OICQ Number,id sender is client): QQ号（4 bytes）
    • Data: 数据内容（已加密）

DHCP 协议

Dynamic Host Configuration Protocol 动态主机配置协议，为网络中的设备提供动态IP地址信息，包括 IP 地址、网关、DNS 等等。DHCP 使整个网络等地址分片变得简单，减低了网络管理员的工作量。

基于 UPD 协议，使用 67（DHCP服务端） 与 68（DHCP客户端） 端口

过程

由于客户端在 DHCP 过程中没有 IP。客户端发包时使用的 Src 为 0.0.0.0。且 DHCP 获取 IP 的过程中的以下四个包都以广播形式，Dst 是广播地址 255.255.255.255

  • 客户端发送 DHCP DISCOVER: 哪个服务器能分配 IP
  • 服务端发送 DHCP OFFER: 你的 IP 是 x.x.x.x
  • 客户端发送 DHCP REQUEST: 需要这个地址
  • 服务端发送 DHCP ACK: 这个 IP 正式分配给你

封装

DHCP 共 8 种请求。下图是通用数据包格式，需配合具体种类分析

案例

  • DHCP 地址请求。如过程中描述，涉及到 4 种 DHCP 请求。请求中最重要的部分是 DHCP 头部的 Option（Option 编号 1bytes + 内容长度 1 bytes + 内容值）

    • 数据包详情

      • Discover: 客户端没有 IP，使用 0.0.0.0 作为 IP

        • Internet Protocol Version 4, Src: 0.0.0.0 Dst: 255.255.255.255
        • User Datagram Protocol, Src Port: 68, Dst Port 67（客户端68，发送给服务端67）
        • Bootstrap Protocol (Discover) （DHCP 协议由 Bootstrap Protocol 发展而来，Wireshark使用协议名显示过滤时，需要使用 bootq 而不是 dhcp）
          • ...省略部分头部，以下仅展示部分字段
          • Hardware type: Ethernet (0x01)
          • Hardware address length: 6 （以太网 mac 地址的字节数）
          • Hops: 0 （跳数。跨网段，需要中继时 + 1）
          • Client IP address: 0.0.0.0 （客户 IP - 客户端使用字段）
          • Your (client) IP address: 0.0.0.0 （服务端分配的客户 IP - 服务端使用字段）
          • Next server IP address: 0.0.0.0 （服务器 IP）
          • Relay agent IP address: 0.0.0.0 （代理 IP）
          • Client MAC address: xx:xx:xx:xx:xx:xx （客户端 MAC 地址）
          • Option: (53) DHCP Message Type (Discover) （标识该 DHCP 包的分组类型，原文: 35 01 01）
            • Length: 1
            • DHCP: Offer (1)
          • Option: (57) Maximum DHCP Message Size （标识最大的 DHCP 分组长度）
          • Option: (61) Client identifier （客户端标识符）
          • Option: (12) Host Name （标识客户端的 Hostname 主机名）
          • Option: (55) Parameter Request List （客户端请求参数 - 选项值1+长度1+内容8 共10字节）
            • Length: 8 （参数列表长度）
            • Parameter Request List Item: (1) Subnet Mask
            • Parameter Request List Item: (6) Domain Name Server （DNS）
            • Parameter Request List Item: (15) Domain Name
            • Parameter Request List Item: (44) NetBIOS over TCP/IP Name Server
            • Parameter Request List Item: (3) Router
            • Parameter Request List Item: (33) Static Route
            • Parameter Request List Item: (150) TFTP Server Address
            • Parameter Request List Item: (43) Vendor-Specific Information
          • Option: (255): End

      • Offer: 与 Discover 类似，Src 变更为 DHCP 服务端的 IP，UDP 端口互换。下面是 DHCP 头部的重点部分

        • Client IP address: 0.0.0.0 （客户 IP）
        • Your (client) IP address: 12.1.1.3 （服务端分配的 IP）
        • Next server IP address: 0.0.0.0 （服务器 IP）
        • Relay agent IP address: 0.0.0.0 （代理 IP）
        • Client MAC address: xx... (将客户端的 MAC 原样传回)
        • Option: (53) DHCP Message Type (Offer) （标识该 DHCP 包的分组类型，原文: 35 01 02）
          • Length: 1
          • DHCP: Offer (2)
        • Option: (54) DHCP Server Identifier （服务器地址，discover中没有，用于告知客户端 DHCP 服务器的地址，原文 36 04 0c 01 01 02）
          • Length: 4
          • DHCP Server Identifier: 12.1.1.2
        • Option: (51) IP Address Lease Time （IP 的租期 604800s 7天，原文 33 04 00 09 3a 80）
        • Option: (58) Renewal Time Value （重绑时间 T1，302300s 3天12hr）
        • Option: (59) Rebinding Time Value （重绑时间 T2）
        • Option: (1) Subnet Mask （子网掩码）
        • Option: (3) Router （网关地址）
        • Option: (6) Domain Name Server （返回主副DNS地址，内容长度 8 ，原文 06 08 08 08 08 08 df 05 05 05）
        • Option: (255): End

      • Request: 此时还没正式确定使用该 IP，客户端 IP 依然 0.0.0.0。最关键的 Option 是 Option 50

        • Option: (53) DHCP Message Type (Request) （标识该 DHCP 包的分组类型，原文: 35 01 03）
        • Option: (54) DHCP Server Identifier (标识接收该请求的 DHCP 服务器，在多 DHCP 服务器场景下，用于进行区分)
        • Option: (50) Requested IP Address （标识客户端所请求的 IP 地址，原文: 32 04 0c 01 01）
          • Length: 4
          • Requested IP Address: 12.1.1.3

      • ACK: 与 Offer 包类似

    • 重点

      • 客户端没有 IP，如何发送 DHCP 包？ 使用 0.0.0.0 全网地址
      • 为什么都用广播包？
        • DHCP 流程结束表明客户端分配到了 IP。在流程中，客户端没有 IP，因此服务器到客户端使用广播
        • 当多 DHCP 服务端环境时，为了防止多个 DHCP 服务器进行响应，客户端使用广播包，服务端也使用广播包，使其他服务端得知已经有服务端处理 DHCP 请求，且分配到具体地址。防止后续其他服务器将该地址分配，导致地址冲突（免费 ARP 的效果）
      • 为什么用 4 个包而不是 2 个？ 多 DHCP 服务器环境中，客户端的请求会导致多个 DHCP 同时分配地址，此时客户端收到多个地址。没有确认过程时，服务端不知道哪个地址被使用，只能默认都被分配，造成地址浪费。通过确认包可以使服务器明确哪些地址未被使用，从而进行回收

  • DHCP 地址续租: 客户端在地址租期到期之前，通过 DHCP Request 向 DHCP 服务器续约 IP。此时客户端已有 IP，因此只需 2 个包即可完成续约，且都是单播包

    • 当客户端地址达到 50% 租用期（Renew Time, T1）时，客户端进入 RENEW 状态，使用 DHCP Request 报文续约。见之前的 Discover 请求头
    • 当客户端地址达到 87.5% 租用期（Rebinding Time, T2）时，客户端进入 REBINDING 状态，使用 DHCP Request 报文续约。见之前的 Discover 请求头
    • 数据包
      • Request
        • Client IP address: 12.1.1.3 （此时客户端在使用的 IP）
        • Your (client) IP address: 0.0.0.0 （服务端分配的 IP）
        • Next server IP address: 0.0.0.0 （服务器 IP）
        • Relay agent IP address: 0.0.0.0 （代理 IP）
      • ACK
        • Client IP address: 12.1.1.3 （此时客户端在使用的 IP）
        • Your (client) IP address: 12.1.1.3 （服务端分配的 IP）
        • Next server IP address: 0.0.0.0 （服务器 IP）
        • Relay agent IP address: 0.0.0.0 （代理 IP）

  • DHCP 地址释放: 客户端通过 DHCP Release 向 DHCP 服务器释放其所用的地址。同续租，客户端已有 IP，因此数据包是单播包

    • Release
      • Client IP address: 12.1.1.3 （此时客户端在使用的 IP）
      • Your (client) IP address: 0.0.0.0 （服务端分配的 IP）
      • Next server IP address: 0.0.0.0 （服务器 IP）
      • Relay agent IP address: 0.0.0.0 （代理 IP）
      • Option: (53) DHCP Message Type (Release) （原文: 35 01 07）

  • DHCP 地址冲突: 客户端通知服务器，其所分配的地址已经被使用，要求重新获取

    • 避免静态 IP 冲突
      • DHCP 服务器在收到 Discover 后，从地址池中选定 IP，在局域网内发送 ARP(同一局域网)/ICMP(DHCP中继时，使用ping，可见下一部分) 检测该地址是否被客户端使用（第一次检测，服务端检测）
        • (ARP)Who has 12.1.1.1? Tell 12.1.1.0 : DHCP 服务器在局域网内对将分配的 IP 检测是否被使用
      • 若有其他客户端通过静态 IP 方式使用了该地址，导致该地址在 DHCP 池中但已经被客户端使用。则在收到 ARP/ICMP 检测后回复 ARP/ICMP 该地址已使用
        • (ARP)12.1.1.1 is at xx.:xx:xx:xx:xx:xx : 静态地址的客户端通过单播 ARP 包告知 DHCP 服务器已使用该 IP
        • (ICMP)Echo (ping) request : DHCP 服务器通过 ping 确认该地址已使用
      • DHCP 服务端重新选择 IP 并检查后，发送 DHCP Offer 包
        • (ARP)Who has 12.1.1.2? Tell 12.1.1.0 : DHCP 服务器在局域网内将重新选择的 IP 检测是否被使用。没有回复，说明 OK
        • (DHCP)DHCO Offer
      • 客户端收到 Offer 包，走完 DHCP 流程后 。发送免费 ARP 检测该 IP 是否被使用（第二次检测，客户端检测）
        • (DHCP)DHCP Request : 客户端请求获取该 IP
        • (DHCP)DHCP ACK : 服务端确认
        • (ARP)Gratuitous ARP for 12.1.1.2 : 客户端发送免费 IP 检测（双重保险）
    • 双网卡冲突: 使用 DHCP Decline 包让服务端更换 IP
      • 客户端拥有两个网卡，其中一个网卡设置了静态 IP（或通过回环口模拟双网卡 int lo1 + ip add 12.1.1.1 255.255.255.0）
      • 另一个网卡通过 DHCP 请求拿到 IP 后，发现与静态 IP 一致。不允许两网卡使用相同 IP
        • DHCP Discover、Offer、Request、ACK : DHCP 流程拿到 IP 12.1.1.1
      • 发送 DHCP Decline 包给服务端进行婉拒，告知服务器 IP 不可用。并重新发起 DHCP 流程
        • (DHCP)DHCP DHCP Decline
          • Option: (53) DHCP Message Type (Decline)
          • Option: (50) Requested IP Address （指明当前分配给我的，但不可用的地址）
        • (DHCP)DHCP Request
      • 服务端重新选择地址，ARP 检测通过后发起 Offer，完成 DHCP 流程

  • DHCP 中继代理（DHCP Relay）: 当跨网段执行 DHCP 请求时，通过 DHCP 中继代理，将请求信息以单播方式转发给 DHCP 服务器

    • 当 ip address dhcp 跨网段时，中继设备（路由器/三层交换机）需要开启 RELAY 中继代理功能 ip helper-address 23.1.1.3(DHCP 服务端 IP)。则客户端发送的 DHCP 包因为广播包无法跨网段，导致 DHCP 服务器无法收到
    • 对客户端来说，是不关心上层情况的。即客户端与 DHCP Relay 间依旧收发广播包，DHCP Relay 与服务端都使用单播包进行收发
    • 网络拓扑: 客户端在 12.1.1.0/24 连接中继路由器 12.1.1.2 的接口。中继路由器的 23.1.1.2 接口连接 DHCP 服务器 23.1.1.3 接口
    • 客户端: 4 个 DHCP 包都是广播，其中收到的广播包地址是客户端所在网关 IP，即客户端所连接中继设备的接口地址
      • DHCP Discover -> ICMP ping（服务端检测IP） -> Offer -> Request -> ACK -> ARP（客户端检测IP）
    • DHCP Relay: 4 个 DHCP 单播包的 Src / Dst 是客户端所在网关接口 12.1.1.2 与 DHCP 服务端接口 23.1.1.3 间进行。不涉及中继路由连接服务端的 23.1.1.2 接口
      • DHCP Discover Src 12.1.1.2 Dst 23.1.1.3
      • ICMP ping Src 23.1.1.3 12.1.1.5 (服务端检查 .5 IP 是否被使用)
      • DHCP Offer Src 23.1.1.3 Dst 12.1.1.2
      • DHCP Request Src 12.1.1.2 Dst 23.1.1.3
      • DHCP ACK Src 23.1.1.3 Dst 12.1.1.2

DNS 协议

Domain Name System 域名系统，用于互联网上提供域名到 IP 的解析服务。访问互联网时不用采用难记的 IP 地址，直接采用直观的域名即可

DNS 协议基于 UDP 和 TCP 协议，端口号 53。用户到服务器采用 UDP，DNS 服务器通信采用 TCP。大型的运营商、互联网机构等会向公众提供免费的 DNS 服务，如谷歌 8.8.8.8 与 8.8.4.4，阿里的 223.5.5.5 与 223.6.6.6

当 DNS 出现问题时，QQ 等不走 DNS 协议的应用可以正常使用，但域名解析都会出现问题

域名结构

如下图所示，域名以 . 作为层级分隔符，从后往前，层级依次下降。例如 news.baidu.com 中，com 是顶级域名，baidu 是二级域名，news 是三级域名。

通过域名分层，使域名解析实现分布式（不同层级的解析交由不同 DNS 服务器进行，如指定服务器只存储顶级域名是 com 的数据，从而可以继续进行拆分）。当解析指定域名，如顶级域名 .cn 的服务异常时，则该域名的 URL 都无法访问

注意: 顶级域名与二级域名中都常见 gov、edu 等，注意区分。严格按照 . 分隔后，从后往前的方式确定该 gov 或 edu 等域名的层级

域名查询与区域传送

DNS 服务中常见的请求与传输如下

  • 正向查询: 查询指定域名的 IP
  • 反向查询: 查询 IP 对应的域名
  • 递归查询:（如同函数调用一样，DNS 服务区请求其他 DNS 服务）收到 DNS Query 的 DNS 服务不知道结果，再次发起 DNS Query 询问其他 DNS 服务。收到 DNS Response 结果后，再发送 DNS Reponse 告知 DNS Query 的发送方。对于请求发送方来说，只发送了一次请求，不知道上层是否发送递归查询。对末端的 DNS 服务端来说，收到的请求就是客户端发过来的（即使是中继 DNS 服务端发起的递归查询，其数据包与客户端无异）
  • 迭代查询: DNS Query 发送方收到 DNS 服务提供其他 DNS 服务的地址，于是重新发送 DNS Query 请求其他 DNS 服务。由于递归查询的存在，DNS Query 发送方可能是客户端或上层 DNS 服务。对于请求发送方来说，发送了多次请求
  • 递归 + 迭代:（真实环境常见情况）客户端发送请求给 DNS 服务1，DNS 服务1 递归查询发送给 DNS 服务2，DNS 服务2 无对应数据，将 DNS 服务3 的地址响应给 DNS 服务1。DNS 服务1 迭代查询 DNS 服务3，拿到 DNS Response 后进行递归响应给客户端
  • 区域传送: 用于 DNS 服务主从备份，通过 TCP 传输域名映射关系，防止单点故障

封装

DNS 的封装分为 5 个部分: 头部部分，查询部分（查询包含有），回答部分（响应包含有），授权部分（响应包含有），额外信息（响应包含有）。如下图所示

案例

  • DNS 查询应答

    • 配置
      • 客户端
        • 开启域名解析。如果本地没有，则请求其他 DNS 服务 ip domain-lookup
        • 定义 DNS 服务器（有指定时DNS请求为单播，否则是广播）ip name-server 192.168.1.2
        • 访问域名，测试能否通过 DNS 正常解析为地址 ping www.xxx.com
      • 服务端
        • 开启 DNS 服务 ip dns server
        • 建立 IP 与域名映射 ip host www.xxx.com 5.5.5.5
        • 查看已建立的映射 show hosts
    • 流程
      • 客户端发起 Ping 操作来访问域名
        >: ping www.xxx.com
Translating "www.xxx.com"...domain server (192.168.1.2) [OK]
      • DNS 请求包 Source 192.168.1.1 Dst 192.168.1.2 DNS Standard query 0x0001 A www.xxx.com （由于指定了 DNS 服务器，发送请求时是单播包）
        • User Datagram Protocol, Src Port: xxxxx(发起 DNS 请求的应用运行的端口), Dst Port: 53 （DNS 基于 UDP，且 DNS 服务端口 53）
        • Domain Name System (query) （DNS 包，以下是包内重点关注的内容）
          • Transaction ID: 0x0001 （事务 ID 值，包信息中 DNS Standard query 后方的内容，DNS 请求序号，功能与 ICMP 中的标识符一致，用于应用区分是当前进程发送 DNS 的第几个包。DNS 头部的第一个字段）
          • Flags: 0x0100 Standard query （标记该 DNS 请求的类型，是 query 还是 response）
            • 0... .... .... .... = Response: Message is a query (0-请求包，1-响应包)
            • .... ...1 .... .... = Recursion desired: Do query recursively （渴望递归请求，如果服务器没有对应数据，可自行发送递归请求获取数据后返回，通常为1。本包中仅该标志位是1）
          • Questions: 1 （问题数，请求了几个域名）
          • Additional RRs: 0（额外记录信息，DNS 头部的最后一个字段）
          • Queries（查询部分，查询信息，多条记录）
            • www.xxx.com: type A, class IN （记录: 域名+类型+类）
              • Name: www.xxx.com
              • [Name Length: 11] （域名的字节数。此字段是 Wireshark解析，不是数据包内的内容）
              • [Label count: 3] （域名层级数。此字段是 Wireshark解析，不是数据包内的内容）
              • Type: A (Host Address) (1) （DNS查询类型: A 类，域名查询 IPv4 地址。其他包含查询邮箱的地址、查询出 IPv6 地址等）
      • DNS 回复包: 服务端通过 53 端口返回给客户端发送端口的单播包
        • Domain Name System (response)
          • Transaction ID: 0x0001 （事务 ID 值，与请求包中的值保持一致）
            • Flags: 0x8180 Standard query （标记该 DNS 请求的类型，是 query 还是 response）
              • 1... .... .... .... = Response: Message is a response （标记为响应包 0-请求包，1-响应包）
              • .000 0... .... .... = Opcode: Standard query (0)
              • .... ..0. .... .... = Truncated: Message is not truncated
              • .... ...1 .... .... = Recursion desired: Do query recursively
              • .... .... 1... .... = Recursion available: Server can do recursive queries （告知客户端能做递归查询，与前一个标志位配合）
              • .... .... .0.. .... = Z: reserved (0)
              • .... .... ...0 .... = Non-authenticated data: Unacceptable
            • Questions: 1 （问题数，请求了几个域名）
            • Answer RRs: 0 （与上一个字段配合，表示当前包有一个问题的回复）
            • Queries （回复包会将请求包中的该字段保持一致，记录问题的原本内容）
            • Answers （回复部分，回复序列）
              • www.xxx.com: type A, class IN, addr 5.5.5.5 （告知请求方域名对应的 IP）

  • DNS 查询应答（多服务器）: 当服务宕机，出现单点故障时。客户端请求 DNS 主服务出现问题，自动请求 DNS 从服务

    • 客户端配置 DNS 时配置主从服务 ip name-server 192.168.1.2 192.168.1.3
    • 流程
      • 客户端请求向主服务发起 DNS 请求时，由于主服务 192.168.1.2 关闭，收到服务端响应的 端口不可达 ICMP 差错报文
        • User Datagram Protocol, Src Port: xxxxx, Dst Port: 53 （服务器告知客户端，本机的 DNS 的 53 端口不可达）
      • 客户端再次向从服务发起 DNS 请求包
      • 从服务正常返回 DNS 响应包

  • DNS 递归查询

    • 配置
      • DNS-SERVER 1 （当服务端自身没有对应内容，发起递归查询请求其他 DNS 服务器时，与客户端类似。需要配置客户端所配置的内容）
        • 定义请求的 DNS 服务器 ip name-server 192.168.1.3
        • 开启域名解析。如果本地没有，则请求其他 DNS 服务 ip domian-lookup
      • DNS-SERVER 3
        • 开启 DNS 服务 ip dns server
        • 存储映射关系 ip host www.yyy.com 55.55.55.55
    • 流程
      • 客户端向 DNS-SERVER 1 发起 DNS 请求包
        • IP Src 192.168.1.1 （客户端 IP） Dst 192.168.1.2（DNS-SERVER 1 IP）
      • DNS-SERVER 1 作为下级客户端向 DNS-SERVER 2 发起递归请求
        • IP Src 192.168.2.2 （DNS-SERVER 1 连接 SERVER 2 接口的 IP） Dst 192.168.2.3（DNS-SERVER 2 IP）
        • DNS 内的 Transaction ID、Flags 等保持 DNS 服务端收到客户端时的值
      • DNS-SERVER 2 发送 DNS Response 给 DNS SERVER 1
      • DNS SERVER 1 将内容构造成自己的 DNS Response (将 DNS 内容原样取出后封装成自己的 DNS Response) 发送给客户端

  • DNS 区域传送

    • 配置: 保证主从相互连通，这里使用的方案是都配置了同一虚拟网卡 VMnet1
      • 主服务: VMware 环境 WinServer2008
        • VMware 网络配置: VMnet1（Host Only）
        • 系统网盘配置: IP 1.1.1.1 DNS 1.1.1.1
        • 开启 WinServer 的 DNS 服务功能
        • 主服务开启 Wireshark 进行抓包
        • 在 DNS 服务中的配置
          • 创建映射文件（创建主域名）: 新建区域向导 -> 主要区域(主服务的标志) -> 区域名称（当前 DNS 服务的主域名，填写到二级域名，如 xxx.com，即完成了该域名主服务的创建）
          • 在映射文件内增加 DNS 记录: 右键 -> 新建主机 （增加主域名下的子域名，如 www.xxx.com news.xxx.com 等）
          • 将映射记录传输到从服务: 映射文件 右键 -> 属性 -> 区域传送 -> 添加从服务地址（此时服务会开始和从服务进行沟通，并发送数据包）
      • 从服务: VMware 环境 WinServer2008
        • VMware 网络配置: VMnet1（Host Only）
        • 系统网盘配置: IP 1.1.1.2 DNS 1.1.1.2
        • 开启 WinServer 的 DNS 服务
        • 在 DNS 服务中的配置
          • 创建映射文件（创建主域名）: 新建区域向导 -> 辅助区域(从服务的标志) -> 区域名称（保持主域名一致，表明当前是主域名的从服务） -> 填写主服务 IP（此时回响应主服务的沟通，完成数据传输）
    • 过程
      • 区域 SOA 查询 （DNS 协议包，从服务器向主服务器请求获取当前完整的 DNS 记录）
        • 数据包: Src 1.1.1.2 Dst 1.1.1.1 DNS Standard query 0xc46f SOA xxx.com
          • DNS 内容: Transaction ID、Flags 等与普通请求一致，但 Queries 中存在不同
            • Queries
              • xxx.com: type SOA
                • Name: xxx.com
                • Type: SOA (Start of zone of authority) （此处标记出是区域认证的初始传送）
      • 区域 SOA 应答（DNS 协议包，主服务器对从服务器的请求进行回应）
      • TCP 传输内容: 三个 TCP 包实现 TCP 三次握手
      • 从服务器再次发起 DNS SOA 请求（握手已建立，此时数据包内含有 TCP 协议封装）
      • 主服务器发起 DNS SOA 应答 （数据包体积较大，DNS 协议封装中的 Answers 内包含要传输的映射关系）
        • Answers
          • xxx.com: type SOA, class IN, mname win-xxxxx
          • xxx.com: type NS, class IN, ns win-xxxxx
          • test.xxx.com: type A, class IN, addr x.x.x.x
          • www.xxx.com: type A, class IN, addr x.x.x.x
Released under the MIT License.
Copyright © 2023-present Leopold