Docker容器網(wǎng)絡(luò)下UDP協(xié)議的一個(gè)問題
最近在工作中遇到一個(gè) docker 容器下 UDP 協(xié)議網(wǎng)絡(luò)不通的問題，困擾了很久，也比較有意思，所以想寫下來和大家分享。
我們有個(gè)應(yīng)用是 UDP 協(xié)議的，部署上去發(fā)現(xiàn)無法工作，但是換成 TCP 協(xié)議是可以的(應(yīng)用同時(shí)支持 UDP、TCP 協(xié)議，切換成 TCP 模式發(fā)現(xiàn)一切正常)。雖然換成 TCP 能解決問題，但是我們還是想知道到底 UDP 協(xié)議在網(wǎng)絡(luò)模式下為什么會出現(xiàn)這個(gè)問題，以防止后面其他 UDP 應(yīng)用會有異常。
這個(gè)問題抽象出來是這樣的：如果有 UDP 服務(wù)運(yùn)行在主機(jī)上(或者運(yùn)行在網(wǎng)絡(luò)模型為 Host 的容器里)，并且監(jiān)聽在 0.0.0.0 地址(也就是所有的 ip 地址)，從運(yùn)行在 docker bridge 網(wǎng)絡(luò)的容器運(yùn)行客戶端訪問服務(wù)，兩者通信有問題。
注意以上的的限制條件，通過測試，我們發(fā)現(xiàn)下來幾種情況都是正常的：
- 使用 TCP 協(xié)議沒有這個(gè)問題，這個(gè)已經(jīng)說過了
- 如果 UDP 服務(wù)器監(jiān)聽在 eth0 IP 地址上也不會出現(xiàn)這個(gè)問題
- 并不是所有的應(yīng)用都有這個(gè)問題，我們的 DNS(dnsmasq + kubeDNS) 也是同樣的部署方式，但是功能都正常
這個(gè)問題在 docker 上也有 issue 記錄：https://github.com/moby/moby/issues/15127，但是目前并沒有合理的解決方案。
這篇文章就分析一下出現(xiàn)這個(gè)問題的原因，希望給同樣遇到這個(gè)問題的讀者提供些幫助。
問題重現(xiàn)
這個(gè)問題很容易重現(xiàn)，我的實(shí)驗(yàn)是在 ubuntu16.04 下用 netcat 命令完成的，其他系統(tǒng)應(yīng)該類似。在主機(jī)上通過 nc 監(jiān)聽 56789 端口，然后在容器里使用 nc 發(fā)數(shù)據(jù)。***個(gè)報(bào)文是能發(fā)送出去的，但是以后的報(bào)文雖然在網(wǎng)絡(luò)上能看到，但是對方無法接收。
在主機(jī)上運(yùn)行 nc UDP 服務(wù)器( -u 表示 UDP 協(xié)議， -l 表示監(jiān)聽的端口)
- $ nc -ul 56789
然后啟動一個(gè)容器，運(yùn)行客戶端：
- $ docker run -it apline sh
- / # nc -u 172.16.13.13 56789
nc 的通信是雙方的，不管對方輸入什么字符，回車后對方就能立即收到。但是在這個(gè)模式下，客戶端***次輸入對方能夠收到，后續(xù)的報(bào)文對方都收不到。
在這個(gè)實(shí)驗(yàn)中，容器使用的是 docker 的默認(rèn)網(wǎng)絡(luò)，容器的 ip 是 172.17.0.3，通過 veth pair(圖中沒有顯示)連接到虛擬網(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)過的地方。通過過濾容器的 ip 地址，很容器找到感興趣的報(bào)文：
- $ tcpdump -i docker0 -nn host 172.17.0.3
為了模擬多數(shù)應(yīng)用一問一答的通信方式，我們一共發(fā)送三個(gè)報(bào)文，并用 tcpdump 抓取 docker0 接口上的報(bào)文：
- 客戶端先向服務(wù)器端發(fā)送 hello 字符串
- 服務(wù)器端回復(fù) world
- 客戶端繼續(xù)發(fā)送 hi 消息
抓包的結(jié)果如下，可以發(fā)現(xiàn)***個(gè)報(bào)文發(fā)送出去沒有任何問題(因?yàn)?UDP 是沒有 ACK 報(bào)文的，所以客戶端無法知道對方有沒有收到，這里說的沒有問題是值沒有對應(yīng)的 ICMP 報(bào)文)，但是第二個(gè)報(bào)文從服務(wù)端發(fā)送的報(bào)文，對方會返回一個(gè) ICMP 告訴端口 38908 不可達(dá);第三個(gè)報(bào)文從客戶端發(fā)送的報(bào)文也是如此。以后的報(bào)文情況類似，雙方再也無法進(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ù)器并沒有退出，使用 lsof -i :56789 可能看到它仍然在監(jiān)聽著該端口。
問題原因
從網(wǎng)絡(luò)報(bào)文的分析中可以看到服務(wù)端返回的報(bào)文源地址不是我們預(yù)想的 eth0 地址，而是 docker0 的地址，而客戶端直接認(rèn)為該報(bào)文是非法的，返回了 ICMP 的報(bào)文給對方。
那么問題的原因也可以分為兩個(gè)部分：
- 為什么應(yīng)答報(bào)文源地址是 錯(cuò)誤的 ?
- 既然 UDP 是無狀態(tài)的，內(nèi)核怎么判斷源地址不正確呢?
主機(jī)多網(wǎng)絡(luò)接口 UDP 源地址選擇問題
***個(gè)問題的關(guān)鍵詞是：UDP 和多網(wǎng)絡(luò)接口。因?yàn)槿绻鳈C(jī)上只有一個(gè)網(wǎng)絡(luò)接口，發(fā)出去的報(bào)文源地址一定不會有錯(cuò);而我們也測試過 TCP 協(xié)議是能夠處理這個(gè)問題的。
通過搜索，發(fā)現(xiàn)這確實(shí)是個(gè)已知的問題。在 UNP() 這本書中，已經(jīng)描述過這個(gè)問題，下面是對應(yīng)的內(nèi)容：
這個(gè)問題可以歸結(jié)為一句話：UDP 在多網(wǎng)卡的情況下，可能會發(fā)生服務(wù)器端源地址不對的情況，這是內(nèi)核選路的結(jié)果。 為什么 UDP 和 TCP 有不同的選路邏輯呢?因?yàn)?UDP 是無狀態(tài)的協(xié)議，內(nèi)核不會保存連接雙方的信息，因此每次發(fā)送的報(bào)文都認(rèn)為是獨(dú)立的，socket 層每次發(fā)送報(bào)文默認(rèn)情況不會指明要使用的源地址，只是說明對方地址。因此，內(nèi)核會為要發(fā)出去的報(bào)文選擇一個(gè) ip，這通常都是報(bào)文路由要經(jīng)過的設(shè)備 ip 地址。
有了這個(gè)原因，還要解釋一下問題： 為什么 dnsmasq 服務(wù)沒有這個(gè)問題呢 ?因此我使用 strace 工具抓取了 dnsmasq 和出問題應(yīng)用的網(wǎng)絡(luò) socket 系統(tǒng)調(diào)用，來查看它們兩個(gè)到底有什么區(qū)別。
dnsmasq 在啟動階段監(jiān)聽了 UDP 和 TCP 的 54 端口(因?yàn)槭窃诒镜貦C(jī)器上測試的，為了防止和本地 DNS 監(jiān)聽的 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)和我們的問題是否有關(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
而出問題的應(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 。
對比下來，兩者的不同有幾點(diǎn)：
- 后者使用的是 ipv6，而前者是 ipv4
- 后者使用 recvfrom 和 sendto 傳輸數(shù)據(jù)，而前者是 sendmsg 和 recvmsg
- 前者有調(diào)用 setsockopt 設(shè)置 IP_PKTINFO 的值，而后者沒有
因?yàn)槭窃趥鬏敂?shù)據(jù)的時(shí)候出錯(cuò)的，因此***個(gè)疑點(diǎn)是 sendmsg 和 sendto 的某些區(qū)別導(dǎo)致選擇源地址有不同，通過 man sendto 可以知道 sendmsg 包含了更多的控制信息在 msghdr 。一個(gè)合理的猜測是 msghdr 中包含了內(nèi)核選擇源地址的信息!
通過查找，發(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 文檔中也說明了 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 選項(xiàng)為 1，然后使用 recvmsg 和 sendmsg 傳輸數(shù)據(jù)就能保證源地址選擇符合我們的期望。這也是 dnsmasq 使用的方案，而出問題的應(yīng)用是因?yàn)槭褂昧四J(rèn)的 recvfrom 和 sendto 。
關(guān)于 UDP 連接的疑惑
另外一個(gè)疑惑是：為什么內(nèi)核會把源地址和之前不同的報(bào)文丟棄?認(rèn)為它是非法的?因?yàn)槲覀兦懊嬉呀?jīng)說過，UDP 協(xié)議是無連接的，默認(rèn)情況下 socket 也不會保存雙方連接的信息。即使服務(wù)端發(fā)送報(bào)文的源地址有誤，只要對方能正常接收并處理，也不會導(dǎo)致網(wǎng)絡(luò)不通。
因?yàn)?conntrack，內(nèi)核的 netfilter 模塊會保存連接的狀態(tài)，并作為防火墻設(shè)置的依據(jù)。它保存的 UDP 連接，只是簡單記錄了主機(jī)上本地 ip 和端口，和對端 ip 和端口，并不會保存更多的內(nèi)容。
可以參考 intables info 網(wǎng)站的文章：http://www.iptables.info/en/connection-state.html#UDPCONNECTIONS。
在找到根源之前，我們曾經(jīng)嘗試過用 SNAT 來修改服務(wù)端應(yīng)答報(bào)文的源地址，期望能夠修復(fù)該問題。但是卻發(fā)現(xiàn)這種方法行不通，為什么呢?
因?yàn)?SNAT 是在 netfilter ***做的，在之前 netfilter 的 conntrack 因?yàn)椴徽J(rèn)識該 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
答案也是否定的，因?yàn)?NAT 需要 conntrack 來做翻譯工作，如果去掉 conntrack 等于 SNAT 完全沒用。
解決方案
知道了問題的原因，解決方案也就很容易找到。
使用 TCP 協(xié)議
如果服務(wù)端和客戶端使用 TCP 協(xié)議進(jìn)行通信，它們之間的網(wǎng)絡(luò)是正常的。
- $ nc -l 56789
監(jiān)聽在特定端口
使用 nc 啟動一個(gè) udp 服務(wù)器，監(jiān)聽在 eth0 上：
- ➜ ~ nc -ul 172.16.13.13 56789
nc 可以跟兩個(gè)參數(shù)，分別代表 ip 和 端口，表示服務(wù)端監(jiān)聽在某個(gè)特定 ip 上。如果接收到的報(bào)文目的地址不是 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ù)。
