最近在工作中遇到一個(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)絡(luò)的容器運(yùn)行客戶端訪問(wèn)服務(wù)，兩者通信有問(wèn)題。

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

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

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

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

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

這個(gè)問(wèn)題很容易重現(xiàn)，我的實(shí)驗(yàn)是在 ubuntu16.04 下用 netcat 命令完成的，其他系統(tǒng)應(yīng)該類似。在主機(jī)上通過(guò) nc 監(jiān)聽(tīng) 56789 端口，然后在容器里使用 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 -ul 56789 

然后啟動(dòng)一個(gè)容器，運(yùn)行客戶端：

$ docker run -it apline sh 
/ # nc -u 172.16.13.13 56789 

nc 的通信是雙方的，不管對(duì)方輸入什么字符，回車后對(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.1            172.16.13.13 

tcpdump 抓包

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

$ tcpdump -i docker0 -nn host 172.17.0.3 

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

1. 客戶端先向服務(wù)器端發(fā)送 hello 字符串
2. 服務(wù)器端回復(fù) world
3. 客戶端繼續(xù)發(fā)送 hi 消息

抓包的結(jié)果如下，可以發(fā)現(xiàn)***個(gè)報(bào)文發(fā)送出去沒(méi)有任何問(wèn)題(因?yàn)?UDP 是沒(méi)有 ACK 報(bào)文的，所以客戶端無(wú)法知道對(duì)方有沒(méi)有收到，這里說(shuō)的沒(méi)有問(wèn)題是值沒(méi)有對(duì)應(yīng)的 ICMP 報(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)行通信了。

11:20:43.973286 IP 172.17.0.3.38908 > 172.16.13.13.56789: UDP, length 6 
11:20:50.102018 IP 172.17.0.1.56789 > 172.17.0.3.38908: UDP, length 6 
11:20:50.102129 IP 172.17.0.3 > 172.17.0.1: ICMP 172.17.0.3 udp port 38908 unreachable, length 42 
11:20:54.503198 IP 172.17.0.3.38908 > 172.16.13.13.56789: UDP, length 3 
11:20:54.503242 IP 172.16.13.13 > 172.17.0.3: ICMP 172.16.13.13 udp port 56789 unreachable, length 39 

而此時(shí)主機(jī)上 UDP nc 服務(wù)器并沒(méi)有退出，使用 lsof -i :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è)部分：

1. 為什么應(yīng)答報(bào)文源地址是 錯(cuò)誤的 ?
2. 既然 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)題。在 UNP() 這本書(shū)中，已經(jīng)描述過(guò)這個(gè)問(wèn)題，下面是對(duì)應(yīng)的內(nèi)容：

這個(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 地址。

有了這個(gè)原因，還要解釋一下問(wèn)題： 為什么 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\n\1 \0\1\0\0\0\0\0\1\fterminal19-0\5u5016\3"..., 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\n\201\200\0\1\0\1\0\0\0\1\fterminal19-0\5u5016\3"..., 83}], msg_controllen=28, {cmsg_len=28, cmsg_level=SOL_IP, cmsg_type=, ...}, msg_flags=0}, 0) = 83 

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

[pid   477] socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 124 
[pid   477] setsockopt(124, SOL_IPV6, IPV6_V6ONLY, [0], 4) = 0 
[pid   477] setsockopt(124, SOL_IPV6, IPV6_MULTICAST_HOPS, [1], 4) = 0 
[pid   477] 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 
 
[pid   477] 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 
[pid   477] 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 
 
[pid   477] recvfrom(124, "j\201\2450\201\242\241\3\2\1\5\242\3\2\1\n\243\0160\f0\n\241\4\2\2\0\225\242\2\4\0"..., 2048, 0, {sa_family=AF_INET6, sin6_port=htons(38790), inet_pton(AF_INET6, "::ffff:172.17.0.3", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 168 
 
[pid   477] sendto(124, "k\202\2\0210\202\2\r\240\3\2\1\5\241\3\2\1\v\243\5\33\3TDH\244\0220\20\240\3\2"..., 533, 0, {sa_family=AF_INET6, sin6_port=htons(38790), inet_pton(AF_INET6, "::ffff: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 (since Linux 2.2) 
              Pass  an  IP_PKTINFO  ancillary message that contains a pktinfo structure that supplies some information about the incoming packet.  This only works for datagram ori‐ 
              ented sockets.  The argument is a flag that tells the socket whether the IP_PKTINFO message should be passed or not.  The message itself can only be sent/retrieved as 
              control message with a packet using recvmsg(2) or sendmsg(2). 
 
                  struct in_pktinfo { 
                      unsigned int   ipi_ifindex;  /* Interface index */ 
                      struct in_addr ipi_spec_dst; /* Local address */ 
                      struct in_addr ipi_addr;     /* Header Destination 
                                                      address */ 
                  }; 
 
              ipi_ifindex  is the unique index of the interface the packet was received on.  ipi_spec_dst is the local address of the packet and ipi_addr is the destination address 
              in the packet header.  If IP_PKTINFO is passed to sendmsg(2) and ipi_spec_dst is not zero, then it is used as the local source address for the  routing  table  lookup 
              and  for  setting up IP source route options.  When ipi_ifindex is not zero, the primary local address of the interface specified by the index overwrites ipi_spec_dst 
              for the routing table lookup. 

如果 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 。

關(guān)于 UDP 連接的疑惑

另外一個(gè)疑惑是：為什么內(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ò)不通。

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

可以參考 intables 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 -I OUTPUT -t raw -p udp --sport 5060 -j CT --notrack 
iptables -I PREROUTING -t raw -p udp --dport 5060 -j CT --notrack 

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

解決方案

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

使用 TCP 協(xié)議

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

$ nc -l 56789 

監(jiān)聽(tīng)在特定端口

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

➜ ~ nc -ul 172.16.13.13 56789 

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

這種情況下，服務(wù)端和客戶端也能正常通信。

改動(dòng)應(yīng)用程序?qū)崿F(xiàn)

修改應(yīng)用程序的邏輯，在 UDP socket 上設(shè)置 IP_PKTIFO ，并通過(guò) recvmsg 和 sendmsg 函數(shù)傳輸數(shù)據(jù)。