Docker容器网络下UDP协议的一个问题

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.

关于 UDP 连接的困惑

别的一个困惑是：为什么内核会把源地址和之前不合的报文丢弃?认为它是不法的?因为我们前面已经说过，UDP 协定是无连接的，默认情况下 socket 也不会保存两边连接的信息。即使办事端发送报文的源地址有误，只要对方能正常吸结束处理，也不会导致收集不通。

因为 conntrack，内核的 netfilter 模块会保存连接的状况，并作为防火墙设置的根据。它保存的 UDP 连接，只是简单记录了主机上本地 ip 和端口，和对端 ip 和端口，并不会保存更多的内容。

可以参考 intables info 网站的文┞仿：http://www.iptables.info/en/connection-state.html#UDPCONNECTIONS。

在找到根源之前，我们曾经测验测验过用 SNAT 来修改办事端应答报文的源地址，期望可以或许修复该问题。然则却发明这种办法行不通，为什么呢?

因为 SNAT 是在 netfilter 最后做的，在之前 netfilter 的 conntrack 因为不熟悉该 connection，直接丢弃了，所以即使添加了 SNAT 也是无法工作的。

4/5 首页上一页 2 3 4 5 下一页尾页

　　推荐阅读

　　如何确定恶意软件是否在自己的电脑中执行过？

【51CTO晃荡】8.26 带你与清华大年夜学、搜狗、京东大年夜咖们一路商量基于算法的IT运维实践很不幸，你在本身的电脑里发清楚明了一个恶意的可履行法度榜样!那么问题来了：这个文件到底有>>>详细阅读

本文标题：Docker容器网络下UDP协议的一个问题

地址：http://www.17bianji.com/lsqh/36867.html

1/2 1