UDP数据包在操作系统级别被拒绝？答案

【问题标题】：UDP packets rejected at OS-level?UDP数据包在操作系统级别被拒绝？
【发布时间】：2014-01-14 20:36:07
【问题描述】：

在 Linux 系统上运行，从另一个计算机地址获取 UDP 数据包，比如说 192.168.0.2 从另一个地址，比如说 192.168.166.66，我可以看到 tcpdump 进来的 UDP 数据包。但是，如果我使用 netcat，我实际上不会收到数据包。

如果我在 192.168.166.XXX 网络上创建一个接口，那么 netcat 可以接收数据包没有问题。

我缺少什么基本的网络概念？当我可以通过 tcpdump 看到它们正在正确传递时，为什么我需要在发送 IP 的网络上拥有一个接口？

【问题讨论】：

源主机和目的主机之间是否有正确的路由？我假设0.2 知道如何路由到166.66，因为你说你可以看到数据包进来；你确定返回的流量被正确路由到0.2吗？主机之间的简单 ping 流量是否按预期工作？
admdrew，ping 不起作用，因为接收器 (192.168.0.2) 在 192.168.166.XXX 网络上没有接口。但是使用 tcpdump 我可以验证数据包是否正在到达接口，只是在那一点被丢弃。

【解决方案1】：

默认情况下，tcpdump 会将接口置于混杂模式，这让您可以看到所有到达您的网络接口的数据包。但是，您的操作系统只处理发往本地系统的数据包，例如具有本地或广播地址作为目的地。

【讨论】：

UDP 流量为 192.168.166.66 --> 192.168.0.2。 192.168.0.2是接收机器的地址，为什么包会在OS层面被拒绝？
根据您最初的描述，我认为他们被拒绝了，因为 192.168.0.2 不是您的本地地址。使用有关您的网络设置的新但仍然很少的详细信息，我假设没有返回发件人的路由，因此他们被拒绝。也许你应该发布 ifconfig -a 和 netstat -rn 的输出，这样你就可以真正看到你的网络是如何设置的
那么，如果我设置一条返回 192.168.166.66 的路线，我就能从该地址接收它们？我认为您不需要它来使 UDP 工作。这是我缺少的基本网络概念吗？
如果没有回复的路由，数据包通常会被操作系统拒绝。更安全的系统还将检查传出路由是否位于数据包传入的同一接口上。

【解决方案2】：

此问题的最终解决方案是禁用接口上的反向路径转发 (RPF)。这里存在安全隐患，但经过仔细审查后，在这种特殊情况下，这是正确的前进道路。

通过修改/etc/sysctl.conf关闭RPF：

net.ipv4.conf.eth0.rp_filter=0

更多关于 RPF 的信息：

【讨论】：