了解 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.在第一個例子中為什麼使用方括號？ 

2. 方括號中的數字具有不同的含義，為什麼。
3. MAC地址末尾的08:00是什麼意思？
4. 在第二個範例中，多播地址和 0.0.0.0 地址的作用是什麼。
5. 為什麼 TTL=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]是創建消息時的核心正常執行時間（以秒為單位）。最初這是核心日誌消息的第一部分。但是該消息似乎已由其他東西（可能是 syslog 守護程序？）處理過，它在其前面加上了一個人類可讀的時間戳，並kernel:表明該消息是由作業系統核心記錄的，而不是由任何應用程序或服務記錄的。

此日誌消息描述的數據包通過環回介面 ( IN=lo) 到達 Netfilter，因此不涉及真正的乙太網層，因此源 MAC 地址和目標 MAC 地址均為零。字元串08:00末尾的可能是EtherType，表示低級數據包的“有效負載”包含 IPv4 數據包。MAC=

源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 屬於英特爾製造的網路適配器（或其他設備）。

源 MAC 地址將是5c:77:77:6e:0d:7b。供應商查找未能提供有關此地址的任何資訊。

兩個 MAC 地址都是正常的、全球唯一的單播 MAC 地址。這可能令人驚訝，因為數據包包含多播 IP 地址。這可能是由 Wi-Fi 網路中多播消息的處理方式引起的。

再次是 Ethertype，表示普通的08:00舊 IPv4。

目標 IP 地址 224.0.0.1 是標準的“所有主機”多播地址。因為將數據包發送到整個網際網路中的所有支持多播的系統是沒有意義的，所以TTL=1將這種多播限制為僅在單個子網中的所有主機。

PROTO=2表示這是一個Internet 組管理協議 (IGMP)數據包：多播路由器和支持多播的系統使用這些數據包來找出每個支持多播的系統想要加入哪些多播組。（每個支持多播的主機始終是 all-hosts 組的一部分。）此消息中未解碼 IGMP 數據，但由於 IP 數據包長度僅為 32 個八位字節（LEN=32），這很可能是 IGMPv2 通用成員資格查詢數據包.

基本上，支持多播的路由器要求所有支持多播的系統報告它們是否想要接收任何多播流量。

引用自：https://unix.stackexchange.com/questions/662548