網(wǎng)絡(luò)下使用UDP協(xié)議無法通訊問題的分析和處理

一、問題背景

工作中遇到一個 docker 容器下 UDP 協(xié)議網(wǎng)絡(luò)不通的問題，困擾了很久，也比較有意思，所以想寫下來和大家分享。

我們有個應(yīng)用是基于 UDP 協(xié)議的，部署上去發(fā)現(xiàn)無法工作，但是換成 TCP 協(xié)議是可以的（應(yīng)用同時支持 UDP、TCP 協(xié)議，切換成 TCP 模式發(fā)現(xiàn)一切正常）。

雖然換成 TCP 能解決問題，但是我們還是想知道到底 UDP 協(xié)議在容器網(wǎng)絡(luò)模式下為什么會出現(xiàn)這個問題，以防止后面其他 UDP 應(yīng)用會有異常。

這個問題抽象出來是這樣的：如果有 UDP 服務(wù)運(yùn)行在宿主機(jī)上（或者運(yùn)行在網(wǎng)絡(luò)模型為 host 的容器里），并且監(jiān)聽在 0.0.0.0 地址（也就是所有的 ip 地址），從運(yùn)行在 docker bridge（網(wǎng)橋為 docker0） 網(wǎng)絡(luò)的容器運(yùn)行客戶端訪問服務(wù)，兩者通信有問題。

注意以上的的限制條件，通過測試，我們發(fā)現(xiàn)下來幾種情況都是正常的：

使用 TCP 協(xié)議沒有這個問題

如果 UDP 服務(wù)器監(jiān)聽在 eth0 ip ，而不是0.0.0.0上，也不會出現(xiàn)這個問題

并不是所有的應(yīng)用都有這個問題，我們的 DNS（dnsmasq + kubeDNS） 也是同樣的部署方式，但是功能都正常

這個問題在 docker 上也有 issue 記錄，但是目前并沒有合理的解決方案。

這篇文章就分析一下出現(xiàn)這個問題的原因，希望給同樣遇到這個問題的讀者提供些幫助。

二、重現(xiàn)問題

這個問題很容易重現(xiàn)，我的實驗是在 ubuntu16.04 下用 netcat 命令完成的，其他系統(tǒng)應(yīng)該類似。

在宿主機(jī)上通過 nc 監(jiān)聽 56789 端口，然后使用 bridge 網(wǎng)絡(luò)模式，run 一個容器，在容器里面使用 nc 發(fā)數(shù)據(jù)。

第一個報文是能發(fā)送出去的，但是以后的報文雖然在網(wǎng)絡(luò)上能看到，但是對方無法接收。

在宿主機(jī)運(yùn)行 nc UDP 服務(wù)器（-u 表示 UDP 協(xié)議，-l 表示監(jiān)聽的端口）

$nc-ul56789
$ss-uan|grep56789

$ss-an|grep56789
udpUNCONN00*:56789*:*
udpUNCONN00[::]:56789[::]:*

注：默認(rèn)沒有指定綁定ip，就是監(jiān)聽在0.0.0.0上。

然后在同一宿主機(jī)上，啟動一個容器，運(yùn)行客戶端：

$dockerrun-itaplinesh
/#nc-u172.16.13.1356789

nc 的通信是雙方的，不管對方輸入什么字符，回車后對方就能立即收到。但是在這個模式下，客戶端第一次輸入對方能夠收到，后續(xù)的報文對方都收不到。

在這個實驗中，容器使用的是 docker 的默認(rèn)網(wǎng)絡(luò)，容器的 ip 是 172.17.0.3，通過 veth pair（圖中沒有顯示）連接到虛擬網(wǎng)橋 docker0（ip 地址為 172.17.0.1），宿主機(jī)本身的網(wǎng)絡(luò)為 eth0，其 ip 地址為 172.16.13.13。

172.17.0.3
+----------+
|eth0|
+----+-----+
|
|
|
|
+----+-----++----------+
|docker0||eth0|
+----------++----------+
172.17.0.1172.16.13.13

三、tcpdump抓包分析

遇到這種疑難雜癥，第一個想到的抓包。我們需要在 docker0 上抓包，因為這是報文必經(jīng)過的地方。通過過濾容器的 ip 地址，很容器找到感興趣的報文：

$sudotcpdump-idocker0-nnhost172.17.0.3

為了模擬多數(shù)應(yīng)用一問一答的通信方式，我們一共發(fā)送三個報文，并用 tcpdump 抓取 docker0 接口上的報文：

客戶端先向服務(wù)器端發(fā)送 111 字符串

服務(wù)器端回復(fù) 222 字符串

客戶端繼續(xù)發(fā)送 333 字符串抓包的結(jié)果如下，可以發(fā)現(xiàn)第一個報文發(fā)送出去沒有任何問題。

UDP 是沒有 ACK 報文的，所以客戶端無法知道對方有沒有收到，這里說的沒有問題沒有看到對應(yīng)的 ICMP 差錯報文。

但是第二個報文從服務(wù)端發(fā)送的報文，對方會返回一個 ICMP 告訴端口 38908 不可達(dá)；第三個報文從客戶端發(fā)送的報文也是如此。以后的報文情況類似，雙方再也無法進(jìn)行通信了。

1143.973286IP172.17.0.3.38908>172.16.13.13.56789:UDP,length6
1150.102018IP172.17.0.1.56789>172.17.0.3.38908:UDP,length6
1150.102129IP172.17.0.3>172.17.0.1:ICMP172.17.0.3udpport38908unreachable,length42
1154.503198IP172.17.0.3.38908>172.16.13.13.56789:UDP,length3
1154.503242IP172.16.13.13>172.17.0.3:ICMP172.16.13.13udpport56789unreachable,length39

而此時主機(jī)上 UDP nc 服務(wù)器并沒有退出，使用 ss -uan | grep 56789 可能看到它仍然在監(jiān)聽著該端口。

四、問題原因分析

從網(wǎng)絡(luò)報文的分析中可以看到服務(wù)端返回的報文源地址不是我們預(yù)想的 eth0 地址，而是 docker0 的地址，而客戶端直接認(rèn)為該報文是非法的，返回了 ICMP 的報文給對方。

那么問題的原因也可以分為兩個部分：

為什么應(yīng)答報文源地址是錯誤的？

既然 UDP 是無狀態(tài)的，內(nèi)核怎么判斷源地址不正確呢？

主機(jī)多網(wǎng)絡(luò)接口 UDP 源地址選擇問題第一個問題的關(guān)鍵詞是：UDP 和多網(wǎng)絡(luò)接口。因為如果主機(jī)上只有一個網(wǎng)絡(luò)接口，發(fā)出去的報文源地址一定不會有錯；而我們也測試過 TCP 協(xié)議是能夠處理這個問題的。

通過搜索，發(fā)現(xiàn)這確實是個已知的問題。

這個問題可以歸結(jié)為一句話：UDP 在多網(wǎng)卡的情況下，可能會發(fā)生【服務(wù)器端】【源地址】不對的情況，這是內(nèi)核選路的結(jié)果。

為什么 UDP 和 TCP 有不同的選路邏輯呢？

因為 UDP 是無狀態(tài)的協(xié)議，內(nèi)核不會保存連接雙方的信息，因此每次發(fā)送的報文都認(rèn)為是獨(dú)立的，socket 層每次發(fā)送報文默認(rèn)情況不會指明要使用的源地址，只是說明對方地址。

因此，內(nèi)核會為要發(fā)出去的報文選擇一個 ip，這通常都是報文路由要經(jīng)過的設(shè)備 ip 地址。

那么，為什么 dnsmasq 服務(wù)沒有這個問題呢？于是我使用 strace 工具抓取了 dnsmasq 和出問題應(yīng)用的網(wǎng)絡(luò) socket 系統(tǒng)調(diào)用，來查看它們兩個到底有什么區(qū)別。

dnsmasq 在啟動階段監(jiān)聽了 UDP 和 TCP 的 54 端口

因為是在本地機(jī)器上測試的，為了防止和本地 DNS 監(jiān)聽的DNS端口沖突，我選擇了 54 而不是標(biāo)準(zhǔn)的 53 端口：

socket(PF_INET,SOCK_DGRAM,IPPROTO_IP)=4
setsockopt(4,SOL_SOCKET,SO_REUSEADDR,[1],4)=0
bind(4,{sa_family=AF_INET,sin_port=htons(54),sin_addr=inet_addr("0.0.0.0")},16)=0
setsockopt(4,SOL_IP,IP_PKTINFO,[1],4)=0

##############################################

socket(PF_INET,SOCK_STREAM,IPPROTO_IP)=5
setsockopt(5,SOL_SOCKET,SO_REUSEADDR,[1],4)=0
bind(5,{sa_family=AF_INET,sin_port=htons(54),sin_addr=inet_addr("0.0.0.0")},16)=0
listen(5,5)=0

比起 TCP，UDP 部分少了 listen，但是多個 setsockopt(4, SOL_IP, IP_PKTINFO, [1], 4) 這句。到底這兩點和我們的問題是否有關(guān)，先暫時放著，繼續(xù)看傳輸報文的部分。

dnsmasq 收包和發(fā)包的系統(tǒng)調(diào)用，直接使用 recvmsg 和 sendmsg 系統(tǒng)調(diào)用：

recvmsg(4,{msg_name(16)={sa_family=AF_INET,sin_port=htons(52072),sin_addr=inet_addr("10.111.59.4")},msg_iov(1)=[{"315
1?1?????1fterminal19-05u50163"...,4096}],msg_controllen=32,{cmsg_len=28,cmsg_level=SOL_IP,cmsg_type=,...},msg_flags=0},0)=67

sendmsg(4,{msg_name(16)={sa_family=AF_INET,sin_port=htons(52072),sin_addr=inet_addr("10.111.59.4")},msg_iov(1)=[{"315
201200?1?1???1fterminal19-05u50163"...,83}],msg_controllen=28,{cmsg_len=28,cmsg_level=SOL_IP,cmsg_type=,...},msg_flags=0},0)=83

而出問題的 UDP 應(yīng)用 strace 結(jié)果如下：

[pid477]socket(PF_INET6,SOCK_DGRAM,IPPROTO_IP)=124
[pid477]setsockopt(124,SOL_IPV6,IPV6_V6ONLY,[0],4)=0
[pid477]setsockopt(124,SOL_IPV6,IPV6_MULTICAST_HOPS,[1],4)=0
[pid477]bind(124,{sa_family=AF_INET6,sin6_port=htons(6088),inet_pton(AF_INET6,"::",&sin6_addr),sin6_flowinfo=0,sin6_scope_id=0},28)=0

[pid477]getsockname(124,{sa_family=AF_INET6,sin6_port=htons(6088),inet_pton(AF_INET6,"::",&sin6_addr),sin6_flowinfo=0,sin6_scope_id=0},[28])=0
[pid477]getsockname(124,{sa_family=AF_INET6,sin6_port=htons(6088),inet_pton(AF_INET6,"::",&sin6_addr),sin6_flowinfo=0,sin6_scope_id=0},[28])=0

[pid477]recvfrom(124,"j20124502012422413215242321
243?160f0
241422?22524224?"...,2048,0,{sa_family=AF_INET6,sin6_port=htons(38790),inet_pton(AF_INET6,":172.17.0.3",&sin6_addr),sin6_flowinfo=0,sin6_scope_id=0},[28])=168

[pid477]sendto(124,"k2022?2102022
2403215241321v2435333TDH244?2202024032"...,533,0,{sa_family=AF_INET6,sin6_port=htons(38790),inet_pton(AF_INET6,":172.17.0.3",&sin6_addr),sin6_flowinfo=0,sin6_scope_id=0},28)=533

其對應(yīng)的邏輯是這樣的：使用 ipv6 綁定在 0.0.0.0 和 6088 端口，調(diào)用 getsockname 獲取當(dāng)前 socket 綁定的端口信息，數(shù)據(jù)傳輸過程使用的是 recvfrom 和 sendto。

對比下來，兩者的不同有幾點：

后者使用的是 ipv6，而前者是 ipv4

后者使用 recvfrom 和 sendto 傳輸數(shù)據(jù)，而前者是 sendmsg 和 recvmsg

前者有調(diào)用 setsockopt 設(shè)置 IP_PKTINFO 的值，而后者沒有

因為是在傳輸數(shù)據(jù)的時候出錯的，因此第一個疑點是 sendmsg 和 sendto 的某些區(qū)別導(dǎo)致選擇源地址有不同，通過 man sendto 可以知道 sendmsg 包含了更多的控制信息在msghdr。一個合理的猜測是 msghdr 中包含了內(nèi)核選擇源地址的信息！

通過查找，發(fā)現(xiàn) IP_PKTINFO 這個選項就是讓內(nèi)核在 socket 中保存 IP 報文的信息，當(dāng)然也包括了報文的源地址和目的地址。IP_PKTINFO 和 msghdr 的關(guān)系可以在這個 stackoverflow 中找到：https://stackoverflow.com/questions/3062205/setting-the-source-ip-for-a-udp-socket

而 man 7 ip 文檔中也說明了 IP_PKTINFO 是怎么控制源地址選擇的：

IP_PKTINFO(sinceLinux2.2)
PassanIP_PKTINFOancillarymessagethatcontainsapktinfostructurethatsuppliessomeinformationabouttheincomingpacket.Thisonlyworksfordatagramori‐
entedsockets.TheargumentisaflagthattellsthesocketwhethertheIP_PKTINFOmessageshouldbepassedornot.Themessageitselfcanonlybesent/retrievedas
controlmessagewithapacketusingrecvmsg(2)orsendmsg(2).

structin_pktinfo{
unsignedintipi_ifindex;/*Interfaceindex*/
structin_addripi_spec_dst;/*Localaddress*/
structin_addripi_addr;/*HeaderDestination
address*/
};

ipi_ifindexistheuniqueindexoftheinterfacethepacketwasreceivedon.ipi_spec_dstisthelocaladdressofthepacketandipi_addristhedestinationaddress
inthepacketheader.IfIP_PKTINFOispassedtosendmsg(2)andipi_spec_dstisnotzero,thenitisusedasthelocalsourceaddressfortheroutingtablelookup
andforsettingupIPsourcerouteoptions.Whenipi_ifindexisnotzero,theprimarylocaladdressoftheinterfacespecifiedbytheindexoverwritesipi_spec_dst
fortheroutingtablelookup.

如果 ipi_spec_dst 和 ipi_ifindex 不為空，它們都能作為源地址選擇的依據(jù)，而不是讓內(nèi)核通過路由決定。

也就是說，通過設(shè)置 IP_PKTINFO socket 選項為 1，然后使用 recvmsg 和 sendmsg 傳輸數(shù)據(jù)就能保證源地址選擇符合我們的期望。這也是 dnsmasq 使用的方案，而出問題的應(yīng)用是因為使用了默認(rèn)的 recvfrom 和 sendto。

為什么內(nèi)核會把源地址和之前不同的報文丟棄，認(rèn)為它是非法的？

因為我們前面已經(jīng)說過，UDP 協(xié)議是無連接的，默認(rèn)情況下 socket 也不會保存雙方連接的信息。即使服務(wù)端發(fā)送報文的源地址有誤，只要對方能正常接收并處理，也不會導(dǎo)致網(wǎng)絡(luò)不通。

但是 conntrack 不是這樣，內(nèi)核的 netfilter 模塊會保存連接的狀態(tài)，并作為防火墻設(shè)置的依據(jù)。它保存的 UDP 連接，只是簡單記錄了主機(jī)上本地 ip 和端口，和對端 ip 和端口，并不會保存更多的內(nèi)容。

?

關(guān)于這塊可參考 iptables info 網(wǎng)站的文章：http://www.iptables.info/en/connection-state.html#UDPCONNECTIONS

?

在找到根源之前，我們曾經(jīng)嘗試過用 SNAT 來修改服務(wù)端應(yīng)答報文的源地址，期望能夠修復(fù)該問題，但是卻發(fā)現(xiàn)這種方法行不通，為什么呢？

因為 SNAT 是在 netfilter 最后做的，在之前 netfilter 的 conntrack 因為不認(rèn)識該 connection，直接丟棄了，所以即使添加了 SNAT 也是無法工作的。

那能不能把 conntrack 功能去掉呢？比如解決方案：

iptables-IOUTPUT-traw-pudp--sport5060-jCT--notrack
iptables-IPREROUTING-traw-pudp--dport5060-jCT--notrack

答案也是否定的，因為 NAT 需要 conntrack 來做翻譯工作，如果去掉 conntrack 等于 SNAT 完全沒用。

五、解決方案

知道了問題的原因，解決方案也就很容易找到。

1、使用 TCP 協(xié)議如果服務(wù)端和客戶端使用 TCP 協(xié)議進(jìn)行通信，它們之間的網(wǎng)絡(luò)是正常的。

$nc-l56789

2、監(jiān)聽在特定綁定在指定接口上使用 nc 啟動一個 udp 服務(wù)器，監(jiān)聽在 eth0 上：

$nc-ul172.16.13.1356789

nc 可以跟兩個參數(shù)，分別代表 ip 和 端口，表示服務(wù)端監(jiān)聽在某個特定 ip 上。如果接收到的報文目的地址不是 172.16.13.13，也會被內(nèi)核直接丟棄，這種情況下，服務(wù)端和客戶端也能正常通信。

3、改動應(yīng)用程序?qū)崿F(xiàn)修改應(yīng)用程序的邏輯，在 UDP socket 上設(shè)置 IP_PKTIFO，并通過 recvmsg 和 sendmsg 函數(shù)傳輸數(shù)據(jù)。

審核編輯：劉清