Redian新闻
>
关于容器网络下使用UDP协议无法通讯问题的分析和处理

关于容器网络下使用UDP协议无法通讯问题的分析和处理

公众号新闻

推荐关注↓

作者:Bogon

https://www.jianshu.com/p/31f29098186a

一、问题背景

工作中遇到一个 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 -ul 56789
$  ss  -uan | grep 56789

$ ss -an | grep 56789
udp    UNCONN     0      0         *:56789                 *:*
udp    UNCONN     0      0      [::]:56789              [::]:*

注:默认没有指定绑定ip,就是监听在0.0.0.0上。

然后在同一宿主机上,启动一个容器,运行客户端:

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

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

三、tcpdump抓包分析

遇到这种疑难杂症,第一个想到的抓包。我们需要在 docker0 上抓包,因为这是报文必经过的地方。通过过滤容器的 ip 地址,很容器找到感兴趣的报文:

$  sudo tcpdump -i docker0 -nn host 172.17.0.3

为了模拟多数应用一问一答的通信方式,我们一共发送三个报文,并用 tcpdump 抓取 docker0 接口上的报文:

  • 客户端先向服务器端发送 111 字符串
  • 服务器端回复 222 字符串
  • 客户端继续发送 333 字符串抓包的结果如下,可以发现第一个报文发送出去没有任何问题。

UDP 是没有 ACK 报文的,所以客户端无法知道对方有没有收到,这里说的没有问题没有看到对应的 ICMP 差错报文。

但是第二个报文从服务端发送的报文,对方会返回一个 ICMP 告诉端口 38908 不可达;第三个报文从客户端发送的报文也是如此。以后的报文情况类似,双方再也无法进行通信了。

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 服务器并没有退出,使用 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\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

而出问题的 UDP 应用 strace 结果如下:

[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

其对应的逻辑是这样的:使用 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 (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 不为空,它们都能作为源地址选择的依据,而不是让内核通过路由决定。

也就是说,通过设置 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 -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 完全没用。

五、解决方案

知道了问题的原因,解决方案也就很容易找到。

1、使用 TCP 协议如果服务端和客户端使用 TCP 协议进行通信,它们之间的网络是正常的。

$ nc -l 56789

2、监听在特定绑定在指定接口上使用 nc 启动一个 udp 服务器,监听在 eth0 上:

$  nc -ul   172.16.13.13   56789

nc 可以跟两个参数,分别代表 ip 和 端口,表示服务端监听在某个特定 ip 上。如果接收到的报文目的地址不是 172.16.13.13,也会被内核直接丢弃,这种情况下,服务端和客户端也能正常通信。

3、改动应用程序实现修改应用程序的逻辑,在 UDP socket 上设置 IP_PKTIFO,并通过 recvmsg 和 sendmsg 函数传输数据。

六 、参考

[1] docker 容器网络下 UDP 协议的一个问题「https://cizixs.com/2017/08/21/docker-udp-issue/」

[2] Setting the source IP for a UDP socket「https://stackoverflow.com/questions/3062205/setting-the-source-ip-for-a-udp-socket」

[3] LinuxC下获取UDP包中的路由目的IP地址和头标识目的地址「https://www.cnblogs.com/kissazi2/p/3158603.html」

[4] Source IP address selection「https://www.ibm.com/docs/en/zos/2.1.0?topic=profiletcpip-source-ip-address-selection」

[5] UDP recvmsg 返回目的地址和目的接口信息「http://blog.chinaunix.net/uid-16813896-id-4593514.html」

[6] 告知你不为人知的 UDP:疑难杂症和使用「https://cloud.tencent.com/developer/article/1004554」


- EOF -


加主页君微信,不仅Linux技能+1

主页君日常还会在个人微信分享Linux相关工具资源精选技术文章,不定期分享一些有意思的活动岗位内推以及如何用技术做业余项目

加个微信,打开一扇窗


推荐阅读  点击标题可跳转

1、超详细!一文详解容器网络发展

2、图解 TCP、UDP,流量控制,拥塞控制,一次看懂

3、如何在 60秒内优化提升 Linux 性能?只有 2% 的人知道


看完本文有收获?请分享给更多人

推荐关注「Linux 爱好者」,提升Linux技能

点赞和在看就是最大的支持❤️

微信扫码关注该文公众号作者

戳这里提交新闻线索和高质量文章给我们。
相关阅读
Supercell资深策划:如何看待和处理游戏内的通货膨胀?5030 血壮山河之武汉会战 九江战役 5人类最终将毁于AI洛杉矶县警察局长命令员警展示纹身,接受关于涉嫌帮派的讯问!女子派出所等讯问时死亡,官方通报北大姚洋关于中美误判问题的最新判断谷歌Bard是拿ChatGPT数据训练的?BERT一作抗议无果,跳槽OpenAI...新AirPods Pro或采用USB-C接口/特斯拉第二季度交付超预期/周鸿祎:别想用一个大模型解决所有问题最近三年到底有多少青年人失业?关于目前就业问题的几点研究分析热射病,这样预防和处理能救命!今天开始!加拿大人可以使用Uber租车Bard是拿ChatGPT数据训练的?谷歌顶级科学家抗议无果,出走OpenAI外交部发布关于阿富汗问题的中国立场亚马逊或将修改免费退货政策,使用UPS退货需付费(古詩詞英譯) 梅花 - 王安石〔宋代〕这5个跟PPT有关的AI神器网站,我玩上瘾了~国民警卫队会保卫特朗普吗?【双养日课】关于艾滋病,孩子需要知道的风险和处理方法44图详解《最高人民法院关于审理建设工程施工合同纠纷案件适用法律问题的解释(一)》腾讯问卷:“炒”货之路的诱惑与颠沛-用户消费行为洞察空乘人员集会抗议无偿工作!多伦多皮尔逊机场:旅客不受影响!Tars-Cpp协程实现分析“IPO对赌协议”会计处理及实务案例分析毁三观!网传50多人通讯录Y趴聚会失联!暗地糜烂无法想象关于MBA中两难问题的深度探讨 | 五一对谈精华数据分析和你数据分析专业能力并无半毛钱关系ChatGPT能解决信息抽取吗?一份关于性能、评估标准、鲁棒性和错误的分析连出重拳!加大直播带货监管和处罚力度,来看监管最新表态!《祖国》&《可能》Kubernetes 如何保障容器可用性?一文介绍探针的使用YTsaurus:EB 级存储和处理系统现已开源最高法 最高检《关于办理强奸、猥亵未成年人刑事案件适用法律若干问题的解释》DPU与智能网卡技术公开课上新!三位技术大牛主讲开源DPU、内生安全智能网卡与DPU云化裸金属术中突发寂静肺,果然麻醉医生最怕的还是无法通气趣图:实操和前期分析和测试完全不一样
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。