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

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

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

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

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

問題重現(xiàn)

這個問題很容易重現(xiàn)，我的實驗是在 ubuntu16.04 下用 netcat 命令完成的，其他系統(tǒng)應(yīng)該類似。在主機上通過 nc 監(jiān)聽 56789 端口，然后在容器里使用 nc 發(fā)數(shù)據(jù)。***個報文是能發(fā)送出去的，但是以后的報文雖然在網(wǎng)絡(luò)上能看到，但是對方無法接收。

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

$ nc -ul 56789 

然后啟動一個容器，運行客戶端：

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

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.1            172.16.13.13 

tcpdump 抓包

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

$ tcpdump -i docker0 -nn host 172.17.0.3 

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

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

抓包的結(jié)果如下，可以發(fā)現(xiàn)***個報文發(fā)送出去沒有任何問題(因為 UDP 是沒有 ACK 報文的，所以客戶端無法知道對方有沒有收到，這里說的沒有問題是值沒有對應(yīng)的 ICMP 報文)，但是第二個報文從服務(wù)端發(fā)送的報文，對方會返回一個 ICMP 告訴端口 38908 不可達;第三個報文從客戶端發(fā)送的報文也是如此。以后的報文情況類似，雙方再也無法進行通信了。

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 

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

問題原因

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

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

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

主機多網(wǎng)絡(luò)接口 UDP 源地址選擇問題

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

通過搜索，發(fā)現(xiàn)這確實是個已知的問題。在 UNP() 這本書中，已經(jīng)描述過這個問題，下面是對應(yīng)的內(nèi)容：

這個問題可以歸結(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\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 

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

其對應(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 (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)核通過路由決定。

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

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

另外一個疑惑是：為什么內(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)容。

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

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

解決方案

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

使用 TCP 協(xié)議

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

$ nc -l 56789 

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

使用 nc 啟動一個 udp 服務(wù)器，監(jiān)聽在 eth0 上：

➜ ~ nc -ul 172.16.13.13 56789 

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

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

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

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