建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
UDP (User Datagram Protocol)是一種無(wú)連接協(xié)議，它通過(guò)IP網(wǎng)絡(luò)提供無(wú)序、不可靠的數(shù)據(jù)傳輸。在網(wǎng)絡(luò)通信中，經(jīng)常需要對(duì)UDP數(shù)據(jù)包進(jìn)行抓包分析，以了解網(wǎng)絡(luò)中傳輸?shù)那闆r。本文介紹在Linux環(huán)境下如何簡(jiǎn)單地使用tcpdump和wireshark兩種工具抓包和分析UDP數(shù)據(jù)包。
成都創(chuàng)新互聯(lián)主要從事做網(wǎng)站、網(wǎng)站設(shè)計(jì)、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)十堰鄖陽(yáng),十載網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專(zhuān)業(yè),歡迎來(lái)電咨詢(xún)建站服務(wù):13518219792
一、使用tcpdump抓包
tcpdump是一種流行的網(wǎng)絡(luò)流量分析工具，可以監(jiān)控和記錄網(wǎng)絡(luò)接口上的數(shù)據(jù)包。要使用tcpdump抓取UDP數(shù)據(jù)包，需要在終端中輸入以下命令：
“`
sudo tcpdump -i udp
“`
其中，“是需要抓包的網(wǎng)絡(luò)接口設(shè)備名，可以通過(guò)`ifconfig`命令查看。例如，如果需要抓取eth0網(wǎng)絡(luò)接口上的UDP數(shù)據(jù)包，可以輸入以下命令：
“`
sudo tcpdump -i eth0 udp
“`
此時(shí)，tcpdump會(huì)開(kāi)始監(jiān)聽(tīng)eth0網(wǎng)絡(luò)接口上的所有UDP數(shù)據(jù)包，并將它們輸出到終端中?？梢栽诮K端中檢查輸出的信息，以了解網(wǎng)絡(luò)中UDP數(shù)據(jù)包的流量情況。
除了輸出數(shù)據(jù)包的信息外，tcpdump還可以使用其他選項(xiàng)來(lái)簡(jiǎn)化網(wǎng)絡(luò)抓包分析。例如，使用`-n`選項(xiàng)可以將IP地址和端口號(hào)轉(zhuǎn)換為數(shù)字形式，以避免DNS反向解析和主機(jī)名查詢(xún)的開(kāi)銷(xiāo)：
“`
sudo tcpdump -n -i eth0 udp
“`
可以使用`-c`選項(xiàng)指定要捕獲的數(shù)據(jù)包數(shù)，以避免數(shù)據(jù)包輸出過(guò)多而造成的信息混亂。例如，下面的命令將捕獲20個(gè)eth0網(wǎng)絡(luò)接口上的UDP數(shù)據(jù)包：
“`
sudo tcpdump -c 20 -i eth0 udp
“`
二、使用wireshark抓包
wireshark是一款功能強(qiáng)大的網(wǎng)絡(luò)協(xié)議分析器，可以使用其GUI界面輕松地對(duì)網(wǎng)絡(luò)數(shù)據(jù)包進(jìn)行深入分析。要使用wireshark抓取UDP數(shù)據(jù)包，需要在終端中輸入以下命令：
“`
sudo wireshark
“`
在wireshark窗口中，點(diǎn)擊“Capture”按鈕，可以打開(kāi)一個(gè)新的窗口進(jìn)行網(wǎng)絡(luò)抓包。在這個(gè)窗口中，可以選擇要捕獲的網(wǎng)絡(luò)接口和捕獲過(guò)濾器。要僅捕獲UDP數(shù)據(jù)包，需要在過(guò)濾器中輸入以下內(nèi)容：
“`
udp port
“`
其中，“是需要監(jiān)控的UDP端口號(hào)。例如，如果需要捕獲的UDP數(shù)據(jù)包是在44444端口上發(fā)送和接收的，可以在過(guò)濾器中輸入以下內(nèi)容：
“`
udp port 44444
“`
此時(shí)，wireshark會(huì)開(kāi)始監(jiān)聽(tīng)網(wǎng)絡(luò)接口上的UDP數(shù)據(jù)包，并將它們以GUI界面方式展示出來(lái)?？梢栽诜治雒姘逯胁榭磾?shù)據(jù)包的詳細(xì)信息，以了解UDP數(shù)據(jù)包的結(jié)構(gòu)和內(nèi)容。
除了展示數(shù)據(jù)包信息以外，wireshark還可以使用其他功能來(lái)輔助網(wǎng)絡(luò)抓包分析。例如，使用過(guò)濾器可以輕松地捕獲或排除特定的數(shù)據(jù)包。使用“Follow UDP Stream”功能可以捕獲整個(gè)UDP數(shù)據(jù)流，并將其以可讀形式展示出來(lái)。
相關(guān)問(wèn)題拓展閱讀：
- 【udp】關(guān)于docker 容器網(wǎng)絡(luò)下使用 UDP 協(xié)議無(wú)法通訊問(wèn)題的分析和處理
【udp】關(guān)于docker 容器網(wǎng)絡(luò)下使用 UDP 協(xié)議無(wú)法通訊問(wèn)題的分析和處理
工作中遇到一個(gè) docker 容器下 UDP 協(xié)議網(wǎng)絡(luò)不通的問(wèn)題，困擾了很久，也比較有意思，所以想寫(xiě)下來(lái)和大家分享。
我們有個(gè)應(yīng)用是基于 UDP 協(xié)議的，部署上去發(fā)現(xiàn)無(wú)法工作，但是換成 TCP 協(xié)議是可以的（應(yīng)用同時(shí)支持 UDP、TCP 協(xié)議，切換成 TCP 模式發(fā)現(xiàn)一切正常）。
雖然換成 TCP 能解決問(wèn)題，但是我們還是想知道到底 UDP 協(xié)議在容器網(wǎng)絡(luò)模式下為什么會(huì)出現(xiàn)這個(gè)問(wèn)題，以防止后面其他 UDP 應(yīng)用會(huì)有異常。
這個(gè)問(wèn)題抽象出來(lái)是這樣的：如果有 UDP 服務(wù)運(yùn)行在宿主機(jī)上（或者運(yùn)行在網(wǎng)絡(luò)模型為 host 的容器里），并且監(jiān)聽(tīng)在 0.0.0.0 地址（也就是所有的 ip 地址），從運(yùn)行在 docker bridge（網(wǎng)橋?yàn)?docker0） 網(wǎng)絡(luò)的容器運(yùn)行客戶(hù)端訪(fǎng)問(wèn)服務(wù)，兩者通信有問(wèn)題。
注意以上的的限制條件，通過(guò)測(cè)試，我們發(fā)現(xiàn)下來(lái)幾種情況都是正常的：
這個(gè)問(wèn)題在 docker 上也有 issue 記錄，但是目前并沒(méi)有合理的解決方案。
這篇文章就分析一下出現(xiàn)這個(gè)問(wèn)題的原因，希望給同樣遇到這個(gè)問(wèn)題的讀者提供些幫助。
這個(gè)問(wèn)題很容易重現(xiàn)，我的實(shí)驗(yàn)是在 ubuntu16.04 下用 netcat 命令完成的，其他系統(tǒng)應(yīng)該類(lèi)似。
在宿主機(jī)上通過(guò) nc 監(jiān)聽(tīng)端口，然后使用 bridge 網(wǎng)絡(luò)模式，run 一個(gè)容器，在容器里面使用 nc 發(fā)數(shù)據(jù)。
之一個(gè)報(bào)文是能發(fā)送出去的，但是以后的報(bào)文雖然在網(wǎng)絡(luò)上能看到，但是對(duì)方無(wú)法接收。
在宿主機(jī)運(yùn)行 nc UDP 服務(wù)器（-u 表示 UDP 協(xié)議，-l 表示監(jiān)聽(tīng)的端口）
注：默認(rèn)沒(méi)有指定綁定ip，就是監(jiān)聽(tīng)在0.0.0.0上。
然后在同一宿主機(jī)上，啟動(dòng)一個(gè)容器，運(yùn)行客戶(hù)端：
nc 的通信是雙方的，不管對(duì)方輸入什么字符，回車(chē)后對(duì)方就能立即收到。
但是在這個(gè)模式下，客戶(hù)端之一次輸入對(duì)方能夠收到，后續(xù)的報(bào)文對(duì)方都收不到。
在這個(gè)實(shí)驗(yàn)中，容器使用的是 docker 的默認(rèn)網(wǎng)絡(luò)，容器的 ip 是 172.17.0.3，通過(guò) veth pair（圖中沒(méi)有顯示）連接到虛擬網(wǎng)橋 docker0（ip 地址為 172.17.0.1），宿主機(jī)本身的網(wǎng)絡(luò)為 eth0，其 ip 地址為 172.16.13.13。
遇到這種疑難雜癥，之一個(gè)想到的抓包。
我們需要在 docker0 上抓包，因?yàn)檫@是報(bào)文必經(jīng)過(guò)的地方。
通過(guò)過(guò)濾容器的 ip 地址，很容器找到感興趣的報(bào)文：
為了模擬多數(shù)應(yīng)用一問(wèn)一答的通信方式，我們一共發(fā)送三個(gè)報(bào)文，并用 tcpdump 抓取 docker0 接口上的報(bào)文：
抓包的結(jié)果如下，可以發(fā)現(xiàn)之一個(gè)報(bào)文發(fā)送出去沒(méi)有任何問(wèn)題。
UDP 是沒(méi)有 ACK 報(bào)文的，所以客戶(hù)端無(wú)法知道對(duì)方有沒(méi)有收到，這里說(shuō)的沒(méi)有問(wèn)題沒(méi)有看到對(duì)應(yīng)的 ICMP 差錯(cuò)報(bào)文。
但是第二個(gè)報(bào)文從服務(wù)端發(fā)送的報(bào)文，對(duì)方會(huì)返回一個(gè) ICMP 告訴端口不可達(dá)；第三個(gè)報(bào)文從客戶(hù)端發(fā)送的報(bào)文也是如此。以后的報(bào)文情況類(lèi)似，雙方再也無(wú)法進(jìn)行通信了。
而此時(shí)主機(jī)上 UDP nc 服務(wù)器并沒(méi)有退出，使用 ss -uan | grep可能看到它仍然在虧蠢監(jiān)聽(tīng)著該端口。
從網(wǎng)絡(luò)報(bào)文的分析中可以看到服好空模務(wù)端返回的報(bào)文源地址不是我們預(yù)想的 eth0 地址，而是 docker0 的地址，而客戶(hù)端直接認(rèn)為該報(bào)文是非法的，返回了 ICMP 的報(bào)文給對(duì)方。
那么問(wèn)題的原因也可以分為兩個(gè)部分：
之一個(gè)問(wèn)題的關(guān)鍵詞是：UDP 和多網(wǎng)絡(luò)接口。
因?yàn)槿绻鳈C(jī)上只有一個(gè)網(wǎng)絡(luò)接口，友緩發(fā)出去的報(bào)文源地址一定不會(huì)有錯(cuò)；而我們也測(cè)試過(guò) TCP 協(xié)議是能夠處理這個(gè)問(wèn)題的。
通過(guò)搜索，發(fā)現(xiàn)這確實(shí)是個(gè)已知的問(wèn)題。
這個(gè)問(wèn)題可以歸結(jié)為一句話(huà)：UDP 在多網(wǎng)卡的情況下，可能會(huì)發(fā)生【服務(wù)器端】【源地址】不對(duì)的情況，這是內(nèi)核選路的結(jié)果。
為什么 UDP 和 TCP 有不同的選路邏輯呢？
因?yàn)?UDP 是無(wú)狀態(tài)的協(xié)議，內(nèi)核不會(huì)保存連接雙方的信息，因此每次發(fā)送的報(bào)文都認(rèn)為是獨(dú)立的，socket 層每次發(fā)送報(bào)文默認(rèn)情況不會(huì)指明要使用的源地址，只是說(shuō)明對(duì)方地址。
因此，內(nèi)核會(huì)為要發(fā)出去的報(bào)文選擇一個(gè) ip，這通常都是報(bào)文路由要經(jīng)過(guò)的設(shè)備 ip 地址。
那么，為什么 dnasq 服務(wù)沒(méi)有這個(gè)問(wèn)題呢？
于是我使用 strace 工具抓取了 dnasq 和出問(wèn)題應(yīng)用的網(wǎng)絡(luò) socket 系統(tǒng)調(diào)用，來(lái)查看它們兩個(gè)到底有什么區(qū)別。
dnasq 在啟動(dòng)階段監(jiān)聽(tīng)了 UDP 和 TCP 的 54 端口
因?yàn)槭窃诒镜貦C(jī)器上測(cè)試的，為了防止和本地 DNS 監(jiān)聽(tīng)的DNS端口沖突，我選擇了 54 而不是標(biāo)準(zhǔn)的 53 端口：
比起 TCP，UDP 部分少了 listen，但是多個(gè) setsockopt(4, SOL_IP, IP_PKTINFO, , 4) 這句。
到底這兩點(diǎn)和我們的問(wèn)題是否有關(guān)，先暫時(shí)放著，繼續(xù)看傳輸報(bào)文的部分。
dnasq 收包和發(fā)包的系統(tǒng)調(diào)用，直接使用 recvmsg 和 sendmsg 系統(tǒng)調(diào)用：
而出問(wèn)題的 UDP 應(yīng)用 strace 結(jié)果如下：
其對(duì)應(yīng)的邏輯是這樣的：使用 ipv6 綁定在 0.0.0.0 和 6088 端口，調(diào)用 getsockname 獲取當(dāng)前 socket 綁定的端口信息，數(shù)據(jù)傳輸過(guò)程使用的是 recvfrom 和 sendto。
對(duì)比下來(lái)，兩者的不同有幾點(diǎn)：
因?yàn)槭窃趥鬏敂?shù)據(jù)的時(shí)候出錯(cuò)的，因此之一個(gè)疑點(diǎn)是 sendmsg 和 sendto 的某些區(qū)別導(dǎo)致選擇源地址有不同，通過(guò) man sendto 可以知道 sendmsg 包含了更多的控制信息在 msghdr。
一個(gè)合理的猜測(cè)是 msghdr 中包含了內(nèi)核選擇源地址的信息！
通過(guò)查找，發(fā)現(xiàn) IP_PKTINFO 這個(gè)選項(xiàng)就是讓內(nèi)核在 socket 中保存 IP 報(bào)文的信息，當(dāng)然也包括了報(bào)文的源地址和目的地址。 IP_PKTINFO 和 msghdr 的關(guān)系可以在這個(gè) stackoverflow 中找到：
而 man 7 ip 文檔中也說(shuō)明了 IP_PKTINFO 是怎么控制源地址選擇的：
如果 ipi_spec_dst 和 ipi_ifindex 不為空，它們都能作為源地址選擇的依據(jù)，而不是讓內(nèi)核通過(guò)路由決定。
也就是說(shuō)，通過(guò)設(shè)置 IP_PKTINFO socket 選項(xiàng)為 1，然后使用 recvmsg 和 sendmsg 傳輸數(shù)據(jù)就能保證源地址選擇符合我們的期望。
這也是 dnasq 使用的方案，而出問(wèn)題的應(yīng)用是因?yàn)槭褂昧四J(rèn)的 recvfrom 和 sendto。
為什么內(nèi)核會(huì)把源地址和之前不同的報(bào)文丟棄，認(rèn)為它是非法的？
因?yàn)槲覀兦懊嬉呀?jīng)說(shuō)過(guò)，UDP 協(xié)議是無(wú)連接的，默認(rèn)情況下 socket 也不會(huì)保存雙方連接的信息。即使服務(wù)端發(fā)送報(bào)文的源地址有誤，只要對(duì)方能正常接收并處理，也不會(huì)導(dǎo)致網(wǎng)絡(luò)不通。
但是 conntrack 不是這樣，內(nèi)核的 netfilter 模塊會(huì)保存連接的狀態(tài)，并作為防火墻設(shè)置的依據(jù)。
它保存的 UDP 連接，只是簡(jiǎn)單記錄了主機(jī)上本地 ip 和端口，和對(duì)端 ip 和端口，并不會(huì)保存更多的內(nèi)容。
關(guān)于 這塊可參考 intables info 網(wǎng)站的文章：
在找到根源之前，我們?cè)?jīng)嘗試過(guò)用 SNAT 來(lái)修改服務(wù)端應(yīng)答報(bào)文的源地址，期望能夠修復(fù)該問(wèn)題，但是卻發(fā)現(xiàn)這種方法行不通，為什么呢？
因?yàn)?SNAT 是在 netfilter 最后做的，在之前 netfilter 的 conntrack 因?yàn)椴徽J(rèn)識(shí)該 connection，直接丟棄了，所以即使添加了 SNAT 也是無(wú)法工作的。
那能不能把 conntrack 功能去掉呢？比如解決方案：
答案也是否定的，因?yàn)?NAT 需要 conntrack 來(lái)做翻譯工作，如果去掉 conntrack 等于 SNAT 完全沒(méi)用。
知道了問(wèn)題的原因，解決方案也就很容易找到。
nc 可以跟兩個(gè)參數(shù)，分別代表 ip 和 端口，表示服務(wù)端監(jiān)聽(tīng)在某個(gè)特定 ip 上。
如果接收到的報(bào)文目的地址不是 172.16.13.13，也會(huì)被內(nèi)核直接丟棄，這種情況下，服務(wù)端和客戶(hù)端也能正常通信。
docker 容器網(wǎng)絡(luò)下 UDP 協(xié)議的一個(gè)問(wèn)題
Setting the source IP for a UDP socket
LinuxC下獲取UDP包中的路由目的IP地址和頭標(biāo)識(shí)目的地址
Source IP address selection
UDP recvmsg 返回目的地址和目的接口信息
告知你不為人知的 UDP：連接性和負(fù)載均衡
告知你不為人知的 UDP：疑難雜癥和使用
linux 抓包 udp的介紹就聊到這里吧，感謝你花時(shí)間閱讀本站內(nèi)容，更多關(guān)于linux 抓包 udp,Linux環(huán)境下UDP抓包簡(jiǎn)單實(shí)用方法,【udp】關(guān)于docker 容器網(wǎng)絡(luò)下使用 UDP 協(xié)議無(wú)法通訊問(wèn)題的分析和處理的信息別忘了在本站進(jìn)行查找喔。
香港服務(wù)器選創(chuàng)新互聯(lián)，2H2G首月10元開(kāi)通。
創(chuàng)新互聯(lián)（www.cdcxhl.com）互聯(lián)網(wǎng)服務(wù)提供商,擁有超過(guò)10年的服務(wù)器租用、服務(wù)器托管、云服務(wù)器、虛擬主機(jī)、網(wǎng)站系統(tǒng)開(kāi)發(fā)經(jīng)驗(yàn)。專(zhuān)業(yè)提供云主機(jī)、虛擬主機(jī)、域名注冊(cè)、VPS主機(jī)、云服務(wù)器、香港云服務(wù)器、免備案服務(wù)器等。
名稱(chēng)欄目：Linux環(huán)境下UDP抓包簡(jiǎn)單實(shí)用方法(linux抓包udp)
當(dāng)前地址：http://www.dlmjj.cn/article/cdipicd.html
