一、問(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)行客戶端訪問(wèn)服務(wù)，兩者通信有問(wèn)題。

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

• 使用 TCP 協(xié)議沒(méi)有這個(gè)問(wèn)題
• 如果 UDP 服務(wù)器監(jiān)聽(tīng)在 eth0 ip ，而不是0.0.0.0上，也不會(huì)出現(xiàn)這個(gè)問(wèn)題
• 并不是所有的應(yīng)用都有這個(gè)問(wèn)題，我們的 DNS（dnsmasq + kubeDNS） 也是同樣的部署方式，但是功能都正常

這個(gè)問(wèn)題在 docker 上也有 issue 記錄，但是目前并沒(méi)有合理的解決方案。「https://github.com/moby/moby/issues/15127」「https://github.com/iotaledger/iri/issues/961」

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

二、重現(xiàn)問(wèn)題

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

在宿主機(jī)上通過(guò) nc 監(jiān)聽(tīng) 56789 端口，然后使用 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)的端口）

$nc-ul56789
$ss-uan|grep56789

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

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

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

$dockerrun-itaplinesh
/#nc-u172.16.13.1356789

nc 的通信是雙方的，不管對(duì)方輸入什么字符，回車(chē)后對(duì)方就能立即收到。但是在這個(gè)模式下，客戶端第一次輸入對(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。

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

三、tcpdump抓包分析

遇到這種疑難雜癥，第一個(gè)想到的抓包。我們需要在 docker0 上抓包，因?yàn)檫@是報(bào)文必經(jīng)過(guò)的地方。通過(guò)過(guò)濾容器的 ip 地址，很容器找到感興趣的報(bào)文：

$sudotcpdump-idocker0-nnhost172.17.0.3

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

• 客戶端先向服務(wù)器端發(fā)送 111 字符串
• 服務(wù)器端回復(fù) 222 字符串
• 客戶端繼續(xù)發(fā)送 333 字符串抓包的結(jié)果如下，可以發(fā)現(xiàn)第一個(gè)報(bào)文發(fā)送出去沒(méi)有任何問(wèn)題。

UDP 是沒(méi)有 ACK 報(bào)文的，所以客戶端無(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 告訴端口 38908 不可達(dá)；第三個(gè)報(bào)文從客戶端發(fā)送的報(bào)文也是如此。以后的報(bào)文情況類似，雙方再也無(wú)法進(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

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

四、問(wèn)題原因分析

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

那么問(wèn)題的原因也可以分為兩個(gè)部分：

• 為什么應(yīng)答報(bào)文源地址是錯(cuò)誤的？
• 既然 UDP 是無(wú)狀態(tài)的，內(nèi)核怎么判斷源地址不正確呢？

主機(jī)多網(wǎng)絡(luò)接口 UDP 源地址選擇問(wèn)題第一個(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é)為一句話：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 地址。

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

dnsmasq 在啟動(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 端口：

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，但是多個(gè) setsockopt(4, SOL_IP, IP_PKTINFO, [1], 4) 這句。到底這兩點(diǎn)和我們的問(wèn)題是否有關(guān)，先暫時(shí)放著，繼續(xù)看傳輸報(bào)文的部分。

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
111fterminal19-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
201200111fterminal19-05u50163"...,83}],msg_controllen=28,{cmsg_len=28,cmsg_level=SOL_IP,cmsg_type=,...},msg_flags=0},0)=83

而出問(wèn)題的 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
243160f0
24142222524224"...,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,"k20222102022
2403215241321v2435333TDH2442202024032"...,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

其對(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)：

• 后者使用的是 ipv6，而前者是 ipv4
• 后者使用 recvfrom 和 sendto 傳輸數(shù)據(jù)，而前者是 sendmsg 和 recvmsg
• 前者有調(diào)用 setsockopt 設(shè)置 IP_PKTINFO 的值，而后者沒(méi)有

因?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 中找到：https://stackoverflow.com/questions/3062205/setting-the-source-ip-for-a-udp-socket

而 man 7 ip 文檔中也說(shuō)明了 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)核通過(guò)路由決定。

也就是說(shuō)，通過(guò)設(shè)置 IP_PKTINFO socket 選項(xiàng)為 1，然后使用 recvmsg 和 sendmsg 傳輸數(shù)據(jù)就能保證源地址選擇符合我們的期望。這也是 dnsmasq 使用的方案，而出問(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)于這塊可參考 iptables info 網(wǎng)站的文章：http://www.iptables.info/en/connection-state.html#UDPCONNECTIONS

?

在找到根源之前，我們?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 功能去掉呢？比如解決方案：

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

答案也是否定的，因?yàn)?NAT 需要 conntrack 來(lái)做翻譯工作，如果去掉 conntrack 等于 SNAT 完全沒(méi)用。

五、解決方案

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

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

$nc-l56789

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

$nc-ul172.16.13.1356789

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

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