一、問題背景

工作中遇到一個 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ù)運行在宿主機上（或者運行在網(wǎng)絡(luò)模型為 host 的容器里），并且監(jiān)聽在 0.0.0.0 地址（也就是所有的 ip 地址），從運行在 docker bridge（網(wǎng)橋為 docker0） 網(wǎng)絡(luò)的容器運行客戶端訪問服務(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 記錄，但是目前并沒有合理的解決方案。「https://github.com/moby/moby/issues/15127」「https://github.com/iotaledger/iri/issues/961」

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

二、重現(xiàn)問題

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

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

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

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

$nc-ul56789
$ss-uan|grep56789

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

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

然后在同一宿主機上，啟動一個容器，運行客戶端：

$dockerrun-itaplinesh
/#nc-u172.16.13.1356789

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

在這個實驗中，容器使用的是 docker 的默認網(wǎng)絡(luò)，容器的 ip 是 172.17.0.3，通過 veth pair（圖中沒有顯示）連接到虛擬網(wǎng)橋 docker0（ip 地址為 172.17.0.1），宿主機本身的網(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 不可達；第三個報文從客戶端發(fā)送的報文也是如此。以后的報文情況類似，雙方再也無法進行通信了。

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

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

四、問題原因分析

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

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

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

主機多網(wǎng)絡(luò)接口 UDP 源地址選擇問題第一個問題的關(guān)鍵詞是：UDP 和多網(wǎng)絡(luò)接口。因為如果主機上只有一個網(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ā)送的報文都認為是獨立的，socket 層每次發(fā)送報文默認情況不會指明要使用的源地址，只是說明對方地址。

因此，內(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 端口

因為是在本地機器上測試的，為了防止和本地 DNS 監(jiān)聽的DNS端口沖突，我選擇了 54 而不是標準的 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
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

而出問題的 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

其對應(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)用是因為使用了默認的 recvfrom 和 sendto。

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

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

但是 conntrack 不是這樣，內(nèi)核的 netfilter 模塊會保存連接的狀態(tài)，并作為防火墻設(shè)置的依據(jù)。它保存的 UDP 連接，只是簡單記錄了主機上本地 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 因為不認識該 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é)議進行通信，它們之間的網(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ù)。