☰

了解 nftables 日志

tag-icon • tag-icon linux debian logs nftables
了解 nftables 日志

下面这些日志条目事件期间发生了什么？

Nov* 8 09:37:12  kernel: [10967.520783] New Input packets: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=192.168.1.2 DST=192.168.1.2 LEN=85 TOS=0x00 PREC=0xC0 TTL=64 ID=6855 PROTO=ICMP TYPE=3 CODE=1 [SRC=192.168.1.2 DST=192.168.1.1 LEN=57 TOS=0x00 PREC=0x00 TTL=64 ID=60616 DF PROTO=UDP SPT=49662 DPT=53 LEN=37 ]

Nov* 8 09:38:13 kernel: [11029.272652] New Input packets: IN=wlo1 OUT= MAC=b8:81:98:cb:ef:a8:5c:77:77:6e:0d:7b:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2

 1.在第一个例子中为什么使用方括号？ 

  1. 方括号中的数字有不同的含义，为什么。

  2. MAC地址末尾的08:00是什么意思？

  3. 在第二个示例中，多播地址和 0.0.0.0 地址的作用是什么。

  4. 为什么 TTL=1

谢谢你！

答案1

Nov* 8 09:37:12  kernel: [10967.520783] New Input packets: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=192.168.1.2 DST=192.168.1.2 LEN=85 TOS=0x00 PREC=0xC0 TTL=64 ID=6855 PROTO=ICMP TYPE=3 CODE=1 [SRC=192.168.1.2 DST=192.168.1.1 LEN=57 TOS=0x00 PREC=0x00 TTL=64 ID=60616 DF PROTO=UDP SPT=49662 DPT=53 LEN=37 ]

[10967.520783]是创建消息时的内核正常运行时间（以秒为单位）。最初这是内核日志消息的第一部分。但该消息似乎已由其他东西（可能是系统日志守护进程？）处理，该程序在其前面加上了人类可读的时间戳，并kernel:表明该消息是由操作系统内核记录的，而不是由任何应用程序或服务记录的。

此日志消息描述的数据包通过环回接口 ( ) 到达 Netfilter IN=lo，因此不涉及真正的以太网层，因此源和目标 MAC 地址均为零。08:00字符串末尾的可能MAC=是以太类型，表明低层数据包的“有效负载”包含 IPv4 数据包。

源IP地址和目标IP地址均为192.168.1.2，因此该数据包似乎是在主机192.168.1.2上本地生成的。在 IPv4 数据包的有效负载中，有一个类型 3、代码 1 的 ICMP 数据包- 即“主机无法访问”错误数据包。

如果您无法弄清楚是什么原因导致错误消息被发送，则错误消息毫无意义，因此 ICMP 错误数据包包含导致检测到错误的原始数据包的标头。这些标头在方括号内解码：

 [SRC=192.168.1.2 DST=192.168.1.1 LEN=57 TOS=0x00 PREC=0x00 TTL=64 ID=60616 DF PROTO=UDP SPT=49662 DPT=53 LEN=37 ]

因此，导致错误消息的数据包Host unreachable源自该主机 (192.168.1.2)，其目的地是 192.168.1.1。协议是 UDP，目标 UDP 端口是 53，即标准 DNS 端口。因此，该主机显然有一些配置（手动或通过 DHCP）告诉它使用 192.168.1.1 作为 DNS 服务器。但当它尝试向 192.168.1.1 的 DNS 服务器发送 UDP 数据包时，出现了问题。内核可能检测到网络连接丢失，或者内核尝试发出 ARP 请求来查找 192.168.1.1 的 MAC 地址，但没有得到响应。于是内核生成了ICMP错误数据包并通过环回接口发送到本地。

Nov* 8 09:38:13 kernel: [11029.272652] New Input packets: IN=wlo1 OUT= MAC=b8:81:98:cb:ef:a8:5c:77:77:6e:0d:7b:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2

时间戳 和 的kernel:解释与第一条消息中的相同。

该消息描述的数据包通过无线网络接口传入wlo1。假设该MAC=字符串只是第 2 层以太网数据包开头的前 14 个字节，则目标 MAC 地址（= 大概是该主机的 MAC 地址）将为b8:81:98:cb:ef:a8。据一位MAC地址查询网站，此 MAC 将属于 Intel 制造的网络适配器（或其他设备）。

源 MAC 地址将为5c:77:77:6e:0d:7b。供应商查找未能透露有关此地址的任何信息。

两个 MAC 地址都是常规的、全球唯一的单播 MAC 地址。这可能会令人惊讶，因为数据包包含多播 IP 地址。这可能是由 Wi-Fi 网络中处理多播消息的方式引起的。

它又08:00是 Ethertype，表示普通的旧 IPv4。

目标 IP 地址 224.0.0.1 是标准的“所有主机”多播地址。由于将数据包发送到整个互联网中所有支持多播的系统是没有意义的，因此TTL=1将此多播限制为仅在单个子网内的所有主机。

PROTO=2表明这是一个互联网组管理协议 (IGMP)数据包：多播路由器和具有多播功能的系统使用这些数据包来找出每个具有多播功能的系统想要加入的多播组。 （每个支持多播的主机始终是所有主机组的一部分。）此消息中的 IGMP 数据未解码，但由于 IP 数据包长度仅为 32 个八位字节 ( LEN=32)，因此这很可能是 IGMPv2 通用成员资格查询数据包。

基本上，具有多播功能的路由器会要求所有具有多播功能的系统报告它们是否想要接收任何多播流量。

相关内容