一、問題背景

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

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

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

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

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

• 使用 TCP 協議沒有這個問題
• 如果 UDP 服務器監聽在 eth0 ip ，而不是0.0.0.0上，也不會出現這個問題
• 并不是所有的應用都有這個問題，我們的 DNS（dnsmasq + kubeDNS） 也是同樣的部署方式，但是功能都正常

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

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

二、重現問題

這個問題很容易重現，我的實驗是在 ubuntu16.04 下用 netcat 命令完成的，其他系統應該類似。

在宿主機上通過 nc 監聽 56789 端口，然后使用 bridge 網絡模式，run 一個容器，在容器里面使用 nc 發數據。

第一個報文是能發送出去的，但是以后的報文雖然在網絡上能看到，但是對方無法接收。

在宿主機運行 nc UDP 服務器（-u 表示 UDP 協議，-l 表示監聽的端口）

$nc-ul56789
$ss-uan|grep56789

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

注：默認沒有指定綁定ip，就是監聽在0.0.0.0上。

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

$dockerrun-itaplinesh
/#nc-u172.16.13.1356789

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

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

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

三、tcpdump抓包分析

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

$sudotcpdump-idocker0-nnhost172.17.0.3

為了模擬多數應用一問一答的通信方式，我們一共發送三個報文，并用 tcpdump 抓取 docker0 接口上的報文：

• 客戶端先向服務器端發送 111 字符串
• 服務器端回復 222 字符串
• 客戶端繼續發送 333 字符串抓包的結果如下，可以發現第一個報文發送出去沒有任何問題。

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

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

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 服務器并沒有退出，使用 ss -uan | grep 56789 可能看到它仍然在監聽著該端口。

四、問題原因分析

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

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

• 為什么應答報文源地址是錯誤的？
• 既然 UDP 是無狀態的，內核怎么判斷源地址不正確呢？

主機多網絡接口 UDP 源地址選擇問題第一個問題的關鍵詞是：UDP 和多網絡接口。因為如果主機上只有一個網絡接口，發出去的報文源地址一定不會有錯；而我們也測試過 TCP 協議是能夠處理這個問題的。

通過搜索，發現這確實是個已知的問題。

這個問題可以歸結為一句話：UDP 在多網卡的情況下，可能會發生【服務器端】【源地址】不對的情況，這是內核選路的結果。

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

因為 UDP 是無狀態的協議，內核不會保存連接雙方的信息，因此每次發送的報文都認為是獨立的，socket 層每次發送報文默認情況不會指明要使用的源地址，只是說明對方地址。

因此，內核會為要發出去的報文選擇一個 ip，這通常都是報文路由要經過的設備 ip 地址。

那么，為什么 dnsmasq 服務沒有這個問題呢？于是我使用 strace 工具抓取了 dnsmasq 和出問題應用的網絡 socket 系統調用，來查看它們兩個到底有什么區別。

dnsmasq 在啟動階段監聽了 UDP 和 TCP 的 54 端口

因為是在本地機器上測試的，為了防止和本地 DNS 監聽的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) 這句。到底這兩點和我們的問題是否有關，先暫時放著，繼續看傳輸報文的部分。

dnsmasq 收包和發包的系統調用，直接使用 recvmsg 和 sendmsg 系統調用：

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 應用 strace 結果如下：

[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

其對應的邏輯是這樣的：使用 ipv6 綁定在 0.0.0.0 和 6088 端口，調用 getsockname 獲取當前 socket 綁定的端口信息，數據傳輸過程使用的是 recvfrom 和 sendto。

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

• 后者使用的是 ipv6，而前者是 ipv4
• 后者使用 recvfrom 和 sendto 傳輸數據，而前者是 sendmsg 和 recvmsg
• 前者有調用 setsockopt 設置 IP_PKTINFO 的值，而后者沒有

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

通過查找，發現 IP_PKTINFO 這個選項就是讓內核在 socket 中保存 IP 報文的信息，當然也包括了報文的源地址和目的地址。IP_PKTINFO 和 msghdr 的關系可以在這個 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 不為空，它們都能作為源地址選擇的依據，而不是讓內核通過路由決定。

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

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

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

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

?

關于這塊可參考 iptables info 網站的文章：http://www.iptables.info/en/connection-state.html#UDPCONNECTIONS

?

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

因為 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 協議如果服務端和客戶端使用 TCP 協議進行通信，它們之間的網絡是正常的。

$nc-l56789

2、監聽在特定綁定在指定接口上使用 nc 啟動一個 udp 服務器，監聽在 eth0 上：

$nc-ul172.16.13.1356789

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

3、改動應用程序實現修改應用程序的邏輯，在 UDP socket 上設置 IP_PKTIFO，并通過 recvmsg 和 sendmsg 函數傳輸數據。